Two years ago the live argument was whether an AI model could write useful production code. That argument is finished. Agents now open a branch, read an unfamiliar codebase, write the change, run the tests, and put up a pull request that a senior engineer will sometimes merge without edits.
The interesting question is no longer capability. It is what a software team should look like when a large share of every first draft arrives already written, and almost nobody has redesigned their process for that.
We build software for clients, so we run this experiment on our own delivery every week. What follows is what has actually held up.
The short version
- The cost of a first draft of code has collapsed. The cost of reviewing, owning and operating that code has not moved at all.
- That inverts the old team shape. Teams used to be bottlenecked on people who could write. They are now bottlenecked on people who can judge.
- The gains are real and uneven. Agents are strongest on well-specified, well-tested, boring work, and weakest exactly where your business logic is strangest.
- Four failure modes show up within a quarter: review debt, hallucinated dependencies, orphaned code, and measuring output instead of outcome.
- If you change nothing else, change two things: shrink your pull requests and name a human owner for every merged change.
What actually changed: the price of a first draft
For thirty years, the scarce input in software was a person who could turn a described behaviour into working code. Every management practice in the industry, sprint planning, story points, team topology, hiring funnels, was built around rationing that person's time.
That input is no longer scarce in the same way. A competent engineer directing an agent produces first-draft code at a rate that has no precedent, and the draft is usually structurally reasonable rather than nonsense.
What this should change: stop planning capacity in terms of how much code your team can produce. That number is no longer the binding constraint, so optimising it buys you nothing. Plan capacity in terms of how much change your team can safely absorb per week, which is a review, testing and operations number.
What did not change: everything after the first draft
Here is the part that gets skipped in every vendor deck. A merged line of code carries obligations that no agent takes on:
- Someone has to understand it when it breaks at 2am eighteen months from now.
- Someone has to decide it is correct, which means holding the business rule in their head and checking the code against it, not against the prompt.
- Someone has to own the blast radius: the migration, the rollback, the customer whose data it touched.
- Someone has to say no, because a large fraction of the best engineering work is refusing to build the thing that was asked for.
None of that got cheaper. So the total cost of a feature fell by much less than the drop in typing time suggests, and teams that budgeted on the typing number are now behind, not ahead.
Where the gains are real, and where they are not
| Type of work | Agent leverage | What a human still has to do |
|---|---|---|
| Test coverage for existing code | Very high | Confirm the tests assert behaviour, not implementation |
| Migrations and refactors with a clear pattern | Very high | Define the pattern once, spot-check the tail |
| CRUD, admin screens, integrations with documented APIs | High | Review auth, validation and error paths |
| Bug fixes with a reproducible failing test | High | Write the failing test honestly |
| Performance work | Medium | Measure first; agents optimise what you point at, not what is slow |
| Novel business logic, pricing, entitlements, anything money touches | Low | Specify it, review it line by line, test it adversarially |
| Architecture and data modelling | Low | Own it entirely. This is where a wrong call costs you a year |
The pattern is consistent: leverage is highest where the specification is unambiguous and the feedback loop is automated, and lowest where the correct answer depends on knowledge that lives in someone's head and in no document.
That has a blunt implication. The value of writing things down went up. Teams with real specifications, good test suites and documented business rules are getting several times the benefit of teams without them, from the identical tooling. If you want the leverage, the prerequisite work is the unglamorous work, and it is the same prerequisite work that made teams effective before any of this. Our five-day SOP playbook is written for operations, but the logic transfers directly to engineering.
The four failure modes
1. Review debt
The first thing that happens is pull request volume triples while reviewer capacity stays flat. Review quality silently degrades into approval, because no human reads eight hundred lines of plausible code carefully at 5pm on a Thursday.
This is the dangerous one, because it does not look like a problem. Throughput is up, the team feels fast, and the defects are being deposited into a future quarter.
The fix: cap pull request size and enforce it. A change an agent wrote should be smaller than one a human wrote, not larger, because the author cannot be asked what they were thinking. If your reviewers cannot keep up, you do not have a tooling problem, you have a batch size problem.
2. Confident, wrong dependencies
Agents add packages. Sometimes those packages do not exist, have been abandoned, carry an incompatible licence, or share a name with something an attacker registered specifically because models suggest that name. This is a genuine supply chain issue and it is not theoretical.
The fix: a dependency allowlist, automated licence and vulnerability scanning in CI, and a rule that any new third-party package needs explicit human sign-off. Start from the OWASP guidance rather than inventing your own.
3. Orphaned code
Code nobody wrote is code nobody owns, and unowned code rots faster than any other kind. Six months on, a team can be sitting on a large volume of merged work that no current engineer has ever read.
The fix: every merged change gets a named human owner in the commit trailer or the code owners file. Not the agent, not the team, a person. If nobody will put their name on it, it does not merge.
4. Measuring output instead of outcome
Pull requests merged, lines changed, tickets closed: every one of these metrics became worthless in the same week. They are now measures of how much an agent typed, and they can be inflated arbitrarily without producing any customer value.
The fix: measure change failure rate, time to restore, escaped defects and cycle time from request to production. Those still mean something because they include the expensive half of the work. If you want the wider argument about metrics that predict health versus metrics that flatter, we wrote it up in the KPIs that actually predict business health.
What we would do with a delivery team right now
- Week one: instrument the honest metrics. Change failure rate and cycle time to production. You cannot tell whether any of this is working without a baseline, and most teams do not have one.
- Week two: shrink the batch. Hard cap on pull request size. This single change does more for safety than any policy about which tools people may use.
- Week three: write down the business rules. The pricing logic, the entitlement rules, the edge cases everyone knows and nobody documented. This is the input that determines how much leverage you get.
- Week four: set the dependency and ownership rules. Allowlist, scanning in CI, named owner per change.
- Ongoing: move senior time from writing to reviewing and specifying. This is a real job change and it needs saying out loud, because your best engineers will notice and some of them will not like it.
What this means for hiring
The junior hiring question is genuinely hard and we are not going to pretend otherwise. The honest position: the tasks that used to train juniors are the tasks agents now do, so the old apprenticeship path has been cut, and no one has replaced it yet.
What we would do is hire for judgement earlier than it used to be reasonable to expect it, and accept that a junior's first year now looks like reviewing, testing and debugging rather than greenfield writing. That is a harder first year, and it needs deliberate mentoring rather than a hope that volume teaches.
For the broader argument about what to delegate to an agent and what to supervise, we set that out in AI agents and middle management.
Frequently asked questions
Will AI coding agents replace software engineers?
Not on current evidence, but they have changed what the job is. The work moved from producing code to specifying, reviewing and owning it. Teams that treated engineers as code producers are finding that role genuinely compressed. Teams that treated engineers as decision makers are getting more out of the same people.
How much faster is a team using coding agents?
Anyone quoting a single number is selling something. The honest answer is that first-draft time falls dramatically and end-to-end delivery time falls much less, because review, testing and deployment did not speed up. Measure your own cycle time to production before and after, and ignore everyone else's figure.
Is it safe to use AI agents on a commercial codebase?
It depends entirely on your controls, not on the tool. The material risks are code leaving your environment, dependency supply chain attacks, and unreviewed logic reaching production. All three are manageable with a clear policy. All three are unmanaged at most companies we look at.
What should a small business with one or two developers do?
Exactly the same things, in a smaller form. Small teams get the largest relative gain, because agents cover the breadth a small team never had. They also carry the most risk, because there is often no second pair of eyes. If that is you, the review discipline matters more, not less.
Where to go next
If you are planning a build and want the delivery process designed properly rather than retrofitted, our custom software development and web development teams work this way by default. If you want a second opinion on an existing team's delivery, talk to us.
