What AI coding agents actually change about shipping client software

We use coding agents every day, on work clients pay for. Not as an experiment, not as a demo we run for prospects — as part of how the work gets done. So we have opinions, and most of them are less exciting than the marketing around this technology.

The short version: agents changed where the work is, not how much work there is. They compressed the part of the job that was always the least interesting — producing text that conforms to a pattern — and left every hard part exactly where it was. In some cases they made the hard parts harder, because now there's more code arriving faster and someone still has to understand all of it before it goes near a client's users.

This post is an attempt to be specific about that. What genuinely got faster, what didn't and why, and the practices we've settled on to keep agents from turning into a liability on paid work.

What genuinely gets faster

These are real and we're not going to pretend otherwise. On a fairly narrow set of tasks, an agent is dramatically faster than a person, and the output quality is fine.

Greenfield scaffolding. A new service, a new module, the boring skeleton around a feature — routes, DTOs, config wiring, the folder structure your codebase already uses everywhere else. This is pattern reproduction, and pattern reproduction is what these models are best at. There's no design judgement in the twentieth CRUD controller.

Test writing. Especially the tedious tests: edge cases around a function whose behaviour is already settled, fixtures, table-driven cases, the eight input variations you'd have written eventually and probably wouldn't have. Agents are good at enumerating cases a tired human skips. You still decide what should be true — that's the specification, and it's yours — but expanding a spec into thorough coverage is mechanical.

Migrations and mechanical refactors. Rename a concept across forty files. Move from one date library to another. Change a function's signature and update every call site. These were always the tasks where careful was slow and fast was dangerous, and an agent with a type-checker in the loop is genuinely better at them than a person doing find-and-replace at 6pm.

Exploring an unfamiliar API. Not "what does the doc say" — you can read the doc — but "show me the four ways this could be wired up so I can see which one fits." Getting to a working first call against an SDK you've never used is the kind of friction that used to eat an afternoon.

Reading a large codebase you didn't write. This one surprised us most. Inheriting someone else's system and asking questions of it — where does auth actually get enforced, what touches this table, why does this run twice — is faster with an agent that can grep, read, and summarise across hundreds of files. It's a research assistant, and the answers are checkable, which is what makes it useful.

First-draft documentation. A README, an architecture note, an onboarding doc. The first draft is the expensive part and the agent produces a decent one from the code itself. The edit is still yours, because the agent will confidently document what the code appears to do rather than what it's supposed to do.

What doesn't get faster

Here's the part that vendor material skips.

Domain modelling. Deciding that an order and a fulfilment are separate entities, or that a subscription's lifecycle has five states and not three, is a conversation with a client about their business. An agent will happily produce a schema. It cannot tell you whether that schema matches how this particular business actually operates, because that information isn't in any repository — it's in someone's head, and getting it out is interviewing, not typing.

Deciding what to build. Most of the value in a client project is in what you talk them out of. Scope, sequencing, which of the twelve requested features actually move the number they care about. Generation speed is irrelevant to a decision problem.

Debugging genuinely novel failures. Agents are strong on bugs that resemble bugs they've seen — the misconfigured middleware, the off-by-one, the async race with a familiar shape. They're weak exactly where you need them most: the failure that only happens in production, only for some users, and doesn't reproduce. That work is hypothesis, instrumentation, and patience. An agent asked to debug something it doesn't recognise will produce plausible, confident, wrong theories, and each one costs you time to rule out.

Anything requiring taste or accountability. Is this abstraction earned or is it premature? Is this error message something a real user can act on? Is this the right trade between a clean model and a shipping date? These are judgements, and judgement is the thing a studio is actually hired for.

Integration against undocumented third-party systems. This is the one that bites hardest in practice. When you're wiring up a payment gateway or a logistics provider, the model's training data contains an older version of the API, a different regional variant, or a doc page that no longer reflects reality. It will generate something that looks exactly right and fails against the live sandbox. On our Puratan Ayurveda build, the payment and shipping integrations were the parts where an agent helped least and where reading the actual provider responses helped most.

The pattern in that list is consistent: agents accelerate work where the target is already known and the task is to produce a well-formed artifact. They do nothing for work where deciding the target is the work.

The review bottleneck

This is the real change, and it took us a while to name it.

Before agents, the constraint on shipping was how fast a competent engineer could produce correct code. Now the constraint is how fast a competent engineer can understand code that already exists. Generated code is cheap. Understood code costs exactly what it always did.

That's not a small reframing. It means the bottleneck moved from a step we could parallelise — more engineers, more output — to one we mostly can't, because comprehension doesn't split cleanly across people. Two reviewers don't understand a diff twice as fast; they understand half of it each and assume the other half is fine.

Our operating rule is blunt: if nobody on the team can explain a diff, it doesn't ship. Not "it passed tests." Explain — what it does, why it's shaped that way, what happens when the input is empty, what it would take to change it in six months. If the answer is "the agent wrote it and the tests are green," that's an unreviewed diff wearing a costume.

The practical consequence is that we deliberately keep generation slower than it could be. It's easy to have an agent produce two thousand lines in an afternoon. It is not possible to properly review two thousand lines in an afternoon, and unreviewed code in a client's repository is a debt with the client's name on it and ours on the invoice.

Practices that make agents safe on client work

None of these are clever. They're the boring controls that make the difference between a useful tool and an incident.

• Small scoped tasks, not big-bang generation. One coherent change at a time, sized so a human can hold it in their head. A tightly scoped task also produces better output — the failure mode of "build the whole feature" is a large, confident, subtly wrong diff.
• Tests as the specification. Where behaviour matters, we write or agree the tests first and let the agent work against them. This turns a vague instruction into a checkable target and gives review something objective to lean on.
• Repo-level context files. Every project gets a file the agent reads first: conventions, architecture, the things that look wrong but are deliberate, and an explicit do-not list. Most bad agent output we've seen came from missing context, not missing capability.
• Branch and sandbox isolation. Agents work on branches, in environments where the worst outcome is a discarded branch. Never directly on a mainline, never against production data.
• No unattended writes to production paths. Deploy scripts, migrations, infrastructure config, anything touching live systems — human hands only. The speed benefit there is near zero and the downside is unbounded.
• Secrets never go in prompts. Not keys, not client credentials, not customer data pulled from a live database to "help it debug." This is a contractual obligation, not a preference.
• Human sign-off on every merge. A named person who read the diff and takes responsibility for it. No exceptions for small changes; small changes are where this slips first.

Verification discipline

The single most expensive habit you can pick up with agents is accepting "it works" as a report.

Model confidence is not evidence. An agent will tell you a change is complete and correct in the same tone whether it is or isn't, because the tone isn't connected to the truth of the claim. It's a fluent summary of an intention, not a test result.

So we verify the same way regardless of who wrote the code: build it, run the tests, run the type-checker and the linter, exercise the actual behaviour, and read the diff line by line. Reading the diff is not optional and it's not covered by the other steps — plenty of code compiles, passes tests, and is still wrong in ways only a reader notices. Deleted error handling. An edge case quietly swallowed. A retry loop with no ceiling.

If a step fails, it goes back. If a step passes but the reader can't explain a section, it also goes back. The loop closes on comprehension, not on green checks.

What we tell clients

We tell them we use coding agents, because they'd be right to ask and we'd rather say it first.

We're also clear about what it doesn't mean. It isn't a discount excuse — the expensive parts of a project are discovery, design, integration, review, and support, and none of those got cheaper. It isn't a quality excuse either. We're accountable for every line in a client's repository regardless of what authored it, and "the agent generated that" is not a defect report we'd ever accept from ourselves.

Provenance and licensing belong in the conversation too. A client taking delivery of a codebase is taking on whatever came with it, and that's their commercial risk as much as ours. We keep generated work inside the same review and dependency-hygiene process as everything else, and we'd rather discuss it openly at the start than have it surface during someone's due diligence.

TL;DR

Coding agents are genuinely fast at scaffolding, tests, mechanical refactors, unfamiliar APIs, navigating code you didn't write, and first-draft docs. They do nothing for domain modelling, deciding what to build, novel debugging, design taste, or integration against third-party systems whose real behaviour disagrees with their documentation.

The change that matters is that the bottleneck moved. Typing was never the expensive part; understanding is, and now there's more code arriving to understand. Small scoped tasks, tests as the specification, repo context files, branch isolation, no production writes, no secrets in prompts, human sign-off, and a verification loop that ends in someone reading the diff — that's the whole discipline.

Our opinion, plainly: the studios that win the next few years aren't the ones generating the most code. They're the ones with the tightest verification loop around it.

If you want to know how we'd handle agents on your codebase, let's talk.