AI does not ruin code. In an architect's hands it raises quality
The market consensus says language models flood repositories with lower-quality code. Our experience modernising a large platform is the opposite — on one condition.
The popular thesis goes: AI assistants increase the amount of code but lower its quality. More duplication, less understanding, more technical debt. When the work is driven by someone who does not understand the system, that is probably true.
Our observation from more than a year of working with AI agents on modernising a large SaaS platform is different. For an experienced architect, AI is not a code-typing machine. It is a way to finally do the work that was always too expensive.
What changed
Every project has a list of things that "should be done": full test coverage, up-to-date documentation, refactoring the module everyone is afraid of, comparison tests before a migration. They do not get done not because the architect does not know how, but because each one means days of tedious work that lose out to urgent features.
AI agents changed the economics of that list. The numbers from one modernised service:
- automated tests: from zero in mid-2025 to more than 200 in autumn 2026,
- technical documentation: from nothing to 37 documents, including an authentication modernisation plan (about 1,800 lines) and a description of the old-vs-new comparison tests (of similar length),
- legacy-vs-new comparison tests: billing, authentication, invalid-input handling and performance checked automatically on a shared database before switching traffic,
- a code knowledge graph spanning six related repositories — more than 9,000 nodes and 12,000 relations, used by subsequent working sessions.
None of this was impossible before. Each item was simply too expensive.
Accepting complex changes becomes easier
The second change is less obvious. The biggest risk in a modernisation is not writing the code but accepting a large change: do we understand all of its consequences? An agent that first generates tests for the current behaviour, then shows which of them changed and why, shortens a review from days to hours — and makes it more thorough.
That flips the usual problem. The architect no longer avoids ambitious changes, because verifying them is no longer the bottleneck.
Conditions without which it does not work
To be fair: AI in the hands of someone who does not understand the system produces exactly the code the market warns about. It works for us because of a few rules:
- A project rules file as a contract. Every repository has a description of architecture, conventions and prohibitions that the agent reads before working. Every agent mistake ends with a new rule added to that file, so the same mistake does not repeat in later sessions — much as a new team member learns from code-review comments.
- Tests before change. Before an agent changes behaviour, it first captures the current behaviour in tests.
- Human review. Every commit goes through a person who understands the system. AI-assisted commits are labelled.
- Procedures instead of improvisation. Repeatable tasks — deploying a new version, assessing upgrade risk, starting a process — are written down as procedures the agent follows step by step.
What we are not claiming
We are not claiming AI increases the number of commits — in some repositories it did not. Nor that it replaces experience. We are claiming that it changes what is worth doing. And the things that suddenly became worth doing — tests, documentation, verification — are exactly the ones that determine quality.
An example from the same project: a BPM engine embedded in an existing CRM — 19 commits, 17 of them made together with an AI agent, four days to production, with tests from day one.