What Happened
Hunter Software Consulting published a detailed analysis of how AI coding tools change the calculus on full code rewrites - one of the most notoriously risky decisions in software engineering.
The article breaks rewrite risk into three categories: engineering risk (minimal, since the functionality already exists), product management risk (substantial, because teams must "tread water" instead of building revenue-generating features), and project management risk (the actual killer, since nobody has long-term incentives to push a rewrite across the finish line).
The author lays out five strategic approaches: the Strangler Fig pattern (incremental replacement), migration by customer cohort, complexity-first rewrites (tackle the hardest parts first to get realistic timelines), revenue-first rewrites (prioritize income-generating features), and the wholesale rewrite - which gets explicitly flagged as the most likely to be cancelled around the 12-18 month mark.
The core argument: AI tools compress engineering timelines, which is exactly what rewrites need. A faster project means lower delivery risk. But speed alone doesn't solve the organizational dysfunction that causes most rewrites to stall.
Why It Matters
If you're using tools like Cursor, Claude Code, Aider, or Amazon Q Developer to write production code, this framing matters. The AI coding discourse tends to focus on raw output speed - how fast can you generate code, how many lines per hour, how quickly can you scaffold a new project.
But for the hardest real-world engineering challenge - replacing a working system with a new one while keeping the business running - the bottleneck was never typing speed. It was the 12-18 month organizational patience required to see it through.
AI tools genuinely help here. A rewrite that previously took 18 months might take 9. That's not just faster delivery; it's the difference between a project that survives budget season and one that gets axed. The author's rule of thumb is telling: a decade-old company should expect roughly a decade of rebuild effort using traditional methods. Even cutting that in half with AI is significant.
Our Take
This is one of the more grounded takes on AI coding tools we've seen. The author avoids both the "AI writes all your code now" hype and the dismissive "it's just autocomplete" take.
The real insight is that AI tools don't change what you should build - they change what you can realistically finish. The Strangler Fig and complexity-first approaches were already the right strategies. AI just makes them more viable by compressing the window where organizational patience runs out.
The wholesale rewrite remains a bad idea even with AI. If your team can't stay aligned for 18 months, cutting it to 9 months with AI is better, but switching to an incremental strategy and using AI to accelerate each slice is better still.
For teams evaluating AI coding tools, this is a useful mental model. Don't ask "how fast can AI write code?" Ask "which projects become feasible now that weren't before?" Full rewrites are one answer - but only if you pair the speed gains with a strategy that accounts for the human side.