Key Takeaway
When agents write the code, the unit of delivery stops being code and becomes an accountable milestone: written acceptance criteria, an architecture decision before the build, review gates where mistakes are expensive, and one named person who owns the result.
Coding agents changed what’s expensive in software delivery. This article is for CTOs and engineering leaders who want agent speed without inheriting code nobody owns. It lays out the governed milestone, a one-page production plan, and the four questions to ask any team that delivers with agents.
Writing code used to be the slow, costly part. Now an agent can produce a working feature, with tests, in the time it takes to write the ticket. That’s real, and it isn’t going back.
What didn’t get cheaper is everything around the code. Deciding the architecture. Checking that the tests verify the right behaviour. Catching the security gap nobody asked about. Owning the result when it breaks in production six months later. Those were always the hard parts. Agents just made them the only hard parts.
Deloitte’s May 2026 piece on agentic AI in software engineering describes a move from the traditional SDLC (software development life cycle) to an “agent orchestrated development life cycle,” with the engineer “shifting from hands-on builder to human-in-the-loop supervisor.” The line that matters most for anyone buying or running delivery is short: “Humans own architecture, validation, and accountability.” They also warn that “governance gaps can erase productivity gains.”
Our view: once code generation stops being the constraint, the unit of delivery stops being code. It becomes an accountable outcome. A milestone with written acceptance criteria, reviewed at the points that matter, with one named person answerable for it.
Where does agent-built software go wrong?
Later, quietly, and in ways that are hard to trace. Agent-written code usually compiles, passes its own tests and demos well. The problems show up months on, and they’re governance problems more than model problems.
Architectural drift. Each agent session makes reasonable local decisions. Across dozens of sessions, a codebase collects several auth patterns, inconsistent error handling and a data model nobody actually designed. Deloitte names architectural drift as a core risk for the same reason.
Tests that confirm instead of verify. Agents write tests that describe what the code does. A test that checks what the code should do needs a written spec to test against. Without one, coverage climbs and confidence doesn’t.
Security by omission. Missing input validation, an over-broad IAM (identity and access management) role, secrets in a config file. Nobody chose these. They just weren’t in the prompt.
Knowledge atrophy. If nobody on the team understood the code when it was written, nobody will understand it when it fails. The agent doesn’t remember the session.
Diffuse ownership. “The team” owns it, which in practice means nobody does. When the incident comes, there’s no one who can explain the design decisions.
A better agent cuts the volume of mistakes. It doesn’t decide who’s accountable for the ones that remain.
What is a governed milestone?
It’s a piece of agent-built work wrapped in six parts that make it reviewable and owned. We recommend this structure to any team running agent-driven delivery, and the order matters as much as the parts.
1. A scoped outcome. One sentence on what exists at the end that doesn’t exist today. “Customers can export usage data as CSV and receive a webhook when a monthly threshold is crossed.” Not “improve reporting.”
2. Written acceptance criteria. Specific, testable conditions, agreed before any code is written. They become the spec agents build against and the checklist humans accept against. Ambiguity here is the biggest single source of agent rework.
3. An architecture decision before the build. A senior engineer decides how the work fits the existing system: data model, interfaces, auth, where it runs. It goes into a short decision record. Agents build inside those decisions instead of inventing their own.
4. Agent build with defined boundaries. Agents handle implementation, unit tests and documentation drafts, working against the acceptance criteria and the architecture record. Their access is limited to the repository and environments the milestone needs.
5. Review gates where decisions are expensive to reverse. Not line-by-line review of everything. Targeted gates, each with a named reviewer.
6. One named owner. A single senior person accountable for the milestone end to end: it meets the criteria, it’s maintainable and it’s safe. Not a committee. A name the client can call.
Acceptance criteria and architecture come first because they’re what make agent output reviewable. Without them, reviewers judge code against their own guesses about intent.
Which review gates does agent-written code need?
Five, placed where a wrong call costs the most to undo. Each one has a named reviewer and a specific checklist.
| Gate | When | What the reviewer checks |
|---|---|---|
| Architecture | Before build | Fit with existing system, data model, interface design |
| Security | Before merge | Auth and permissions, input handling, secrets, dependency risk |
| Test adequacy | Before merge | Tests verify acceptance criteria and edge cases, beyond the happy path |
| Acceptance | Before release | Every acceptance criterion demonstrated, performance targets met |
| Operability | Before handover | Logging, alerts, runbook, rollback path |
What should a production plan for agent-built work include?
One page per milestone. It’s what a CTO should expect to see from any provider, including us, before work starts.
| Section | Contents |
|---|---|
| Outcome | One sentence |
| Acceptance criteria | Numbered, testable list |
| Architecture notes | Key decisions, systems touched, interfaces used or created |
| Agent work | What agents build: components, tests, docs |
| Human work | Architecture decision, each review gate, integration with client systems, acceptance |
| Review gates and reviewers | Gate, timing, named reviewer |
| Accountable owner | One name |
| Delivery package | What the client receives (see below) |
| Price and milestone date | Fixed, based on the outcome |
If a provider can’t produce this page for a contained piece of work, the speed they’re promising has nothing underneath it.
What should you receive when an agent-built milestone is delivered?
Code, plus the evidence that it’s correct and the material to run it. Agent speed is wasted if the handover is a repository link and a goodbye. A complete package includes:
- Source code in your repository, following your conventions, with history.
- Tests mapped to acceptance criteria, so your team can see which test proves which requirement.
- The architecture decision record and any interface specifications.
- A review record: each gate, who reviewed it, what changed as a result.
- Operational material: deployment steps, configuration, alerts, a runbook and a rollback path.
- A short walkthrough with the engineer who’ll own it on your side.
The review record gets skipped most often, and it’s the piece that matters most later. It’s your audit trail and your answer to “why was it built this way?”
When the feature itself uses AI, a separate governance layer applies: bias testing, explainability, audit logs. We cover it in AI governance for product teams.
What does this look like on a real backlog item?
Here’s one item taken from “someday” to a dated milestone. The example is illustrative. It shows the structure, not a specific client engagement.
The item. A B2B SaaS company’s largest customers have asked for usage exports and threshold alerts for over a year. Product agrees it matters. It has slipped through four quarterly plans because the core team is committed to the platform roadmap.
The production plan, summarized.
- Outcome: Admins can export 12 months of usage as CSV and register a webhook that fires when monthly usage crosses a configurable threshold.
- Acceptance criteria: eight items, including: export completes in under 30 seconds for the largest tenant; webhook signed with a shared secret and retried with backoff; tenant isolation verified by test; feature behind a flag.
- Architecture notes: reads from the existing usage aggregates through a new read-only service endpoint; webhooks go through a small queue-backed dispatcher; no writes to core billing tables.
- Agent work: export endpoint, dispatcher, admin UI components, unit and integration tests, API documentation draft.
- Human work: architecture decision, security review of webhook signing and tenant isolation, test adequacy review, acceptance demo with the client’s product lead, handover session.
- Accountable owner: one senior engineer, named on the plan.
- Delivery: fixed milestone, outcome-based price, shipped behind a feature flag in the client’s repository.
What changed for the CTO. The item got a date without pulling anyone off the roadmap. The CTO’s team spent time in two places: approving the architecture decision and attending the acceptance demo. Everything else arrived with a review trail.
What it looks like at full scale. A mid-market travel SaaS company forecast two years and 16 developers for a multi-agent product. An eight-person Chrono team, with senior engineers directing pods of agents and each one accountable for what their pods produced, had it production-ready in nine months: 72 team-months of effort against a 384 developer-month forecast. Nothing shipped unless it passed that engineer’s check on quality and on the outcome the client asked for. The full story is in how a travel SaaS shipped 15 months early.
The gates hold on small builds too. On a creator platform agent that went live in under three weeks, nothing merged without a green suite of 398 automated tests and its own preview deployment.
What should you ask a provider that delivers with AI agents?
Four questions. They separate accountable delivery from fast code generation, and they work just as well on a vendor, an internal platform team or your own process.
- What are the acceptance criteria, in writing, before work starts? Vague answers here predict rework later.
- Where do senior engineers review, and what exactly do they check? “Everything is reviewed” usually means nothing in particular is.
- Who’s the one person accountable for this milestone? If the answer is a team or a process, keep asking.
- What’s in the delivery package? Code alone isn’t enough. Ask for tests mapped to criteria, the decision record and the review record.
Should agents build it for you or with your team?
It depends on how close the work sits to your core platform. Both models follow the same principle: agents do more of the typing, people own the decisions and the outcome.
We build it for you. You describe what you need. We scope it into a governed milestone with a committed price. AI agents do the build work, supervised by senior engineers who own the architecture, the reviews and the result. It fits contained work your team can’t get to: a backlog item, an internal tool, a new product line you want to test without diverting engineers. See how we build products.
We build it with you. Senior AI engineers join your standups and work in your codebase, so your team builds the capability alongside them. It fits work that’s tightly woven into your core platform. We describe that model in what embedded AI teams look like.
Building agents into your own product, not your delivery process? The production concerns are different. See AI agent architecture: what production systems actually look like.
Frequently Asked Questions
Who is accountable for code written by an AI coding agent?
A named senior engineer, not the agent and not “the team.” That person approves the architecture, makes sure each review gate happens, and answers for the milestone in production.
Do AI coding agents remove the need for code review?
No, they change where review happens. Line-by-line review of everything doesn’t scale, so review moves to targeted gates: architecture before the build, security and test adequacy before merge, acceptance before release, operability before handover.
Why do acceptance criteria matter more with AI agents?
Agents build exactly what the spec says and write tests that describe what they built. Written criteria give both the agent and the reviewer something to check against, and vague ones are the biggest source of agent rework.
Which backlog item would you hand to agents tomorrow?
Pick the one that keeps slipping. You don’t need to redesign your engineering organization to test this model.
Send it to us. We’ll turn it into a production plan with the scope, the acceptance criteria, where agents do the work, where senior engineers review, and who owns the outcome. You’ll see whether the model fits before you commit to anything. Scope a milestone with our engineers.