Wisedocs's six-month move from ten repositories to a monorepo was worthwhile because it reduced pipeline time and cost while making feature work much faster.
2
Coding agents improved sharply on the same refactor, from three hours of back-and-forth with o3 and ten major mistakes to one pass with Opus 4.8.
3
Current models can produce scaffolding while missing the working system, so long agent runs should be judged at 80% to 99% success rather than at coin-flip odds.
Summary
Denys Linkov describes why Wisedocs refactored an ML pipeline from more than ten legacy repositories into a monorepo. The pipeline processes medical-claims PDFs larger than 10,000 pages and had become difficult to scale and change. The refactor took six months, but the new repository reached parity, then continued shipping features faster. Commit velocity stayed high, more developers contributed, and work that had taken months could ship in under a week. Linkov benchmarks the same refactor across coding agents. o3 required three hours of conversation in Cursor and made ten major mistakes. Sonnet 4.6 solved it after one extra iteration, while Opus 4.8 nearly completed it in one pass. A zero-shot GPT 5.5 extra high run finished in 10 minutes and 22 seconds but produced scaffolding without the actual models or deployment commands. Linkov's conclusion is that refactoring was worth doing, although better models are making later cleanup easier.
Technical debt can grow faster than the return from the feature that created it
Linkov compares technical debt with financial debt. A team may accept complexity to build a feature or win customers, but the added cost can quickly exceed the return. At Wisedocs, the ML pipeline had become difficult to update because it was spread across more than ten repositories. The company was also too slow to meet customer demand, and developers did not want to work in the codebase. Those problems made the debt a business concern, rather than a matter of code style. The six-month refactor was an attempt to recover capacity that the old structure was consuming.
Faster software delivery can coexist with worse reliability and maintainability
Linkov says technology products have improved while the code and products behind them have not always improved with them. Teams are moving faster through the technology life cycle, but customer focus, maintainability, and reliability can decline. He shows uptime figures from two unnamed leading companies that fall below three nines or four nines. His point is that shipping speed alone does not prove that an engineering organization is producing better software. The refactor therefore had to be judged by more than the amount of code generated or the speed of individual changes.
Agent-assisted research can speed up evaluation while still requiring verification
Wisedocs spent about two months evaluating five open-source orchestrators for its AI pipeline. A team of three built proof of concepts and compared the options against 17 criteria. Linkov says current tooling could make that process about 90% faster through deep research, sub-agents, and automated evaluation. He is cautious about trusting a long report because a feature described in research may not exist in the product. The team still needs to match findings against its requirements, build proof of concepts, and check the actual behavior before committing to a choice.
The same refactor became far easier as models and harnesses improved
Linkov gave o3 a refactor task after manually working through an implementation. The process took three hours of back-and-forth in Cursor and still produced ten major mistakes. Rerunning the task with Sonnet 4.6 required one additional iteration, while Opus 4.8 was essentially able to solve it in one pass. Newer harnesses also made more tool calls, including sub-agents, planning, shell commands, and verification. The model execution cost more, but the process required much less manual intervention. Linkov estimates that repeating the task with current systems would take about one fifth of the original time.
Agent length should be measured at a high success rate
Linkov uses the METR task-length graph to explain why a 50% success rate is a poor planning measure. A task that takes an hour and succeeds half the time has a high chance of wasting an hour and the engineer's attention. He prefers looking at 80% or 90% success, and says 99% may be more useful for handing an agent a plan or specification with confidence. METR's frontier-model data still shows success declining around the four-hour mark, with some tasks failing consistently much earlier. Models are improving, but they are not yet reliable enough for every unattended run.
The monorepo improved delivery after it reached parity with the old repositories
Wisedocs combined ten repositories into a monorepo and built new features on top of it. The old repositories had existed for more than six years, with relatively slow progress. During the first six months of the rebuild, the team reached parity with the previous system, then continued shipping. Commit velocity stayed high after the parity point, and more developers joined the work. Almost every developer at the company now commits to the monorepo, including changes to schemas and API calls outside their usual area. Linkov says the pipeline became faster and cheaper, larger files became supportable, and features that once took months could ship in under a week.
A fast zero-shot completion can hide missing system behavior
Linkov tested whether GPT 5.5 extra high could refactor the codebase from a high-level goal. The run finished in 10 minutes and 22 seconds and wrote about 2,000 lines of code. That result looked suspicious, so he inspected it. The model had created scaffolding without implementing the underlying models. Its own output said it had not added a Ray Serve deployment or bootstrap command. Linkov uses this experiment to show why generated code must be tested and validated. A short run is not evidence that the complete system works.
Refactoring also changed who was willing to work in the repository
Linkov's case for the refactor includes social evidence. Developers began asking to work in the new codebase because it was cleaner and made contribution easier. Patterns from the monorepo spread to other repositories inside Wisedocs. He says the team achieved business goals after refactoring, including lower pipeline time and cost and support for larger files. He also accepts that a full refactor is not always required. Teams can isolate parts of a system and use a layered approach, but they still need guardrails so AI-generated code does not become another difficult legacy system.
"You don't want to be creating a plan or a spec and then have a 50/50 chance of coming back and knowing that you wasted compute and your attention span."08:33
Who should watch
You are deciding whether to refactor a growing ML or software system now, or wait for coding agents to improve.
Your team is measuring agent performance by fast demos or 50% success rates and needs a stricter standard for unattended work.
You maintain several repositories and want to understand the delivery and collaboration effects of combining them.
