Does AI make the 'big rewrite' a viable strategy again?

A Hacker News discussion explores whether large language models have fundamentally altered the cost-benefit analysis of rewriting legacy codebases, or if they just accelerate the path to new problems.

Where it happened

A mid-July thread on Hacker News, responding to a blog post about the changing economics of software development, drew over 400 comments from developers, architects, and founders. The discussion centered on a perennially controversial topic in engineering: the full rewrite of a legacy system. Participants debated whether the productivity gains from AI code generation tools finally tip the scales in favor of a strategy long considered a cardinal sin in software management.

Side A: The rewrite is now cheaper and faster

This position argues that large language models (LLMs) drastically reduce the primary cost of a rewrite, which is the sheer volume of developer hours required. Proponents, like user jessamica, claim that AI assistants excel at the most tedious parts of the process. This includes translating code from old languages or frameworks (like COBOL to Java, or AngularJS to React), generating boilerplate for new services, and creating comprehensive unit test suites.

According to this view, the classic arguments against a rewrite, famously articulated by Joel Spolsky, were based on an economic reality that no longer exists. The risk of missing subtle business logic is mitigated because developers can now focus their attention on high-level architecture and validation, leaving the rote transcription to the machine. One commenter, tlb_hitter, claimed, "We did a full rewrite of a 10-year-old Django monolith to FastAPI in 4 months with two engineers and GPT-4. That would have been a year-long, 5-person project before."

Side B: AI introduces new, subtle, and expensive risks

The opposing camp contends that AI doesn't eliminate the core dangers of a rewrite; it just hides them under a layer of plausible-looking code. This side, represented by users like legacycoder, argues that the true difficulty of a rewrite is not in writing new code, but in perfectly understanding and porting the implicit business rules embedded in the old system. LLMs, they argue, are incapable of this deep contextual understanding.

The risk is that AI generates code that is 99% correct, but the final 1% contains subtle bugs, race conditions, or security flaws that are far harder to detect than human-written errors. These flaws often only surface under production load. As one high-karma account put it, "AI is great at generating code that looks right. The problem is that a rewrite's success depends on the code being exactly right. The cost of finding the subtle bugs introduced by an LLM will dwarf the initial time savings." This side believes AI encourages a superficial approach, leading to brittle systems that are more expensive to maintain in the long run.

What's underneath

The disagreement hinges on the definition of 'cost' in a software project. Side A focuses on the upfront cost, measured in developer-hours and project timeline, which AI demonstrably reduces. They see the rewrite as a task of code translation and generation. Side B uses a more expansive definition of cost that includes long-tail maintenance, the risk of production outages, and the business impact of incorrect logic. They see the rewrite as a task of knowledge archeology and preservation. Both sides are likely correct, depending on the complexity of the system being rewritten and the organization's tolerance for risk.

The investor read

This debate signals a potential repricing of technical debt. If Side A is even partially correct, companies previously stalled by legacy systems may become more agile, creating new competitive threats or undervalued acquisition targets. However, if Side B's concerns are borne out, a new category of 'AI-brittle' companies could emerge. These companies might look modern on the surface but carry significant, hidden operational risk from subtly flawed, machine-generated code. This shift complicates technical due diligence, which must now assess not just the age of a codebase, but the method and potential hidden risks of its modernization.

Pull quote: “The disagreement hinges on the definition of 'cost' in a software project.”