AI changes the economics of software rewrites
AI tools are changing how teams think about rewriting legacy software, with some engineers reporting faster migrations and cheaper bespoke builds when models can reliably follow tests and documentation. Others counter that large-scale refactors still fail for the same old reasons—poor test coverage, messy architectures, and organizational culture—arguing that LLMs often miss edge cases, forget constraints, or produce “patch-on-patch” code that’s hard to maintain. The exchange also reflects broader skepticism toward hype-heavy, LinkedIn-style claims that AI has “solved” coding, emphasizing that careful engineering judgment, clear specs, and good tests remain essential.
AI and the Economics of Rewrites
- Many argue AI does make rewrites cheaper and faster, especially for small–medium codebases, making “sunk cost” less of a barrier.
- Others say this mostly ignores the cost of bugs, maintenance, and organizational dysfunction; swapping symbols faster doesn’t fix deeper issues.
- Some see AI as reducing the cost of “feature-exact ports” (e.g., to escape obsolete frameworks or platforms) without changing semantics.
Tests, Fidelity, and Maintainability
- Strong consensus: usefulness of AI rewrites depends heavily on test coverage and harnesses.
- Supporters claim AI can preserve legacy edge cases better than human rewrites and can help generate test harnesses.
- Skeptics report that LLMs miss corner cases, “sand off edges,” forget constraints, and need constant correction.
- Even with AI, verifying behavior parity often requires line-by-line mapping and extensive manual or automated testing.
When Rewrites Make Sense (or Not)
- Some emphasize Joel Spolsky–style caution: rewrites often fail, especially when you change features and tech simultaneously.
- Others counter that extreme tech debt and obsolete stacks can paralyze organizations; sometimes a rewrite plus simplification is necessary.
- A prevalent view: if you do rewrite, first aim for behavior-identical replacement, then simplify and evolve.
Stack Choice, Buy vs Build, and Org Factors
- Popular, stable stacks help both AI and hiring; heavy deprecation can confuse models.
- Good internal docs can make bespoke frameworks workable for AI.
- AI lowers the cost of bespoke “build,” but “buy” and “build” both still include long-term maintenance.
- Many note that organizational culture, incentives, and regulatory constraints often dominate technical economics.
Perceived Limits and Use Patterns of LLMs
- LLMs are compared to junior devs: good at localized tasks when guided; poor as autonomous architects or large-scale refactorers.
- Reports include failures on unusual DSLs, misclassification of system behavior, and patchy reasoning.
- Some see promise in AI-assisted transpilers and in using AI to design architecture and tests, but only with human oversight.
Meta: Quality of the Article and AI Discourse
- Multiple comments criticize the linked piece as LinkedIn-style “broetry” and likely LLM-written, with little empirical substance.
- Broader frustration is expressed about repetitive, polarized, low-signal AI commentary.