Claude Code and subagents cut a legacy rewrite from three months to one week

The gap between three months and one week in this story is not explained by models suddenly writing perfect code. It comes from the author ceasing to use AI as a smart autocomplete and turning it into a full engineering pipeline. Using two Go projects of the same scale, he shows that when legacy code is untangled by hand and by intuition, speed is capped by chaos. When the model has roles, procedures, review and a testing loop, rewriting a monolith speeds up many times over.

A year ago, the starting point was technical debt after an MVP, which many teams will recognize. The project had a single main.go of about two thousand lines, where business logic, configuration, HTTP handlers, database access and other supporting plumbing were all dumped in one place. Such a structure can survive an early product launch but copes poorly with growth: any change drags side effects along, the code is hard to split into areas of responsibility, and tests become an added pain rather than a support. The author recalls that he pulled the system into a proper architecture piece by piece, with homemade tests and constant manual rechecking.

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 whether behavior had broken, then move on to the next.

A recent project of the same scale produced a very different result. The author took Claude Code with the Opus model, connected three reviewer subagents and built around them about thirty skills, which are repeatable scripts for typical operations. The rewrite took a week, and a noticeable part of that time went not to moving the code itself but to a BDD layer on top of the implementation. By his estimate, without the godog scenarios the task could have taken about three days.

The point of the article is not that one specific tool proved stronger than another, but that the author changed how he works. He contrasts his practice with popular advice along the lines of "give the neural network a good prompt and wait for the result." In real legacy code that is not enough: the model needs not only context but a controlled environment.

Subagents provide a parallel view of the changes and catch errors before they reach the main branch. Skills remove routine, standardize steps and reduce the number of decisions that have to be made anew. BDD adds an external behavioral contract, so the rewrite does not turn into a quiet substitution of business logic with a nice new structure.

That is why the author names as the most important result not merely the speedup but the emergence of a working toolchain, level85. In essence, it is a set of agreements between the human, the model and the auxiliary agents: how to decompose a task, how to verify intermediate results, how to limit the freedom of generation and where to bring in tests. This approach makes AI not a magic button but a disciplined participant in development.

The author does not try to sell a universal recipe. On the contrary, he stresses that even in the assembled configuration pitfalls remain: excess context, wrong decomposition, weak checks or a badly chosen moment for automation can easily eat the gain. The main takeaway is practical: speedup in AI-assisted development comes not from a single model but from the operating system around it.

If a team keeps treating AI as a chat window for one-off hints, monolithic code will still be rewritten slowly and nervously. But if the model becomes part of the process, with roles, review, scenarios and fixed techniques, even heavy legacy code can be taken apart several times faster without abandoning engineering discipline. That is arguably the main lesson of the article.