R&D with AI agents: what actually changes in the development process

Over the past year we built most of our products with coding agents as a permanent part of the team. The question managers ask is always "how much faster", and the honest answer is less exciting and more useful: speed is not what changed - the location of the bottleneck is.

What actually got shorter

Routine code, format conversions, first-pass tests, documentation, one-off scripts, migrations and adaptations - all noticeably shorter. So did getting into unfamiliar code: reading a whole module and explaining what it does is a task an agent does well.

What did not get shorter

Architecture decisions. Defining what the system should do in the first place. Understanding the business domain. Verifying that the result is correct in business terms rather than merely running without errors. In all three, an agent helps you articulate; it does not replace judgment.

And most importantly: review. As the volume of code written grows, the volume of code that must be reviewed grows with it. That is the new bottleneck.

Three things we do differently

1. Specification before code, always. The cheaper writing becomes, the faster a vague spec produces wrong code. We write a short document for every task - what goes in, what comes out, what counts as correct - before anything starts.

2. Tests are the first deliverable. When code is written fast, tests are what separates progress from debt. We ask for the tests and the success criterion before the implementation.

3. Human review on every change that touches money or customer data. No exceptions. Elsewhere you can be flexible; in those two areas the cost of an error exceeds any time saved.

What this means for team size

The mistake we have seen at clients is to conclude that the team can shrink. What actually happens is a change of composition: less time writing, more time on definition, review, integration and quality. A small experienced team gains far more from this than a large team of juniors - because the value moved from writing to judgment.

What to measure

Stop measuring lines of code or tickets closed. Three metrics that reflect the new reality:

• Idea-to-production time - how many days pass between a decision and a real user touching the feature
• Post-release fix rate - going up? review is probably not keeping pace with writing
• Review time per change - if it creeps upward, that is the bottleneck, and that is where to invest

And finally, the financial side

Faster development shortens the time to first revenue, but it also shortens the time in which you can burn budget on the wrong direction. That is why our R&D plans are always built on two axes: a technical schedule and a cash-flow model beside it. Fast is only an advantage if you know where you are going.