Claude Code and Subagents Cut Legacy Project Rewrite from Three Months to One Week

The difference between three months and one week in this story is explained not by the fact that models suddenly started writing perfect code, but by the fact that the author stopped using AI as a smart autocomplete and turned it into a full-fledged engineering pipeline. Using two Go-projects of the same scale as an example, he shows: when legacy is refactored manually and intuitively, speed is limited by chaos; when the model has roles, procedures, review, and a testing loop, monolith rewriting accelerates exponentially. A year ago, the starting point was familiar technical debt after an MVP.

The project had one main.go of approximately two thousand lines, where business logic, configuration, HTTP handlers, database operations, and other supporting code were mixed together in one place. Such a structure can survive the early product launch, but doesn't scale well: any change causes side effects, code is difficult to divide into zones of responsibility, and tests become additional pain rather than support.

The author recalls that back then he was pulling the system into normal architecture piece by piece, with homemade tests and constant manual re-verification. He did the first refactoring in Cursor and spent about three months on it. It was a careful, almost surgical process: extract one block, check if behavior broke, then move to the next.

A recent project of similar scale yielded very different results. The author took Claude Code, Opus model, connected three reviewer sub-agents, and built around them approximately thirty skills — repeatable scenarios for typical operations. As a result, rewriting took a week, with a significant portion of that time not spent on code migration itself, but on the BDD layer on top of the implementation.

By his estimate, without godog scenarios the task could fit into approximately three days. The essence of the article is not that one specific tool proved stronger than another, but that the author changed his way of working. He contrasts his practice with popular advice from the series "give the neural network a good prompt and wait for the result."

In real legacy this is not enough: models need not only context, but also a managed environment. Sub-agents provide a parallel perspective on changes and catch errors before they reach the main branch. Skills eliminate routine, standardize steps, and reduce the number of decisions that need to be made anew.

BDD adds an external behavior contract so that rewriting doesn't turn into quiet substitution of business logic with a beautiful new structure. This is why the author calls the most important result not simply acceleration, but the emergence of a working toolchain level85. Essentially, this is a set of agreements between a person, a model, and auxiliary agents: how to decompose a task, how to check intermediate results, how to limit the freedom of generation, and where to plug in tests.

Such an approach makes AI not a magic button, but a disciplined development participant. At the same time, the author is not trying to sell a universal recipe. On the contrary, he emphasizes that even in the assembled configuration there are pitfalls: extra context, incorrect decomposition, weak checks, or incorrectly chosen moment for automation easily eat up the gain.

The main conclusion here is practical: acceleration in AI-assisted development is born not from one model, but from the operational system around it. If a team continues to work with AI as a chat window for one-off advice, monolithic code will still be rewritten slowly and nervously. But if you turn the model into part of the process — with roles, review, scenarios, and fixed techniques — even heavy legacy can be taken apart several times faster without abandoning engineering discipline entirely.

And this, perhaps, is the main lesson of the article.