The Outcomes — Section 04

Production-Ready Code

What the phrase has to mean here, and the gates that make it true

Define It First

Otherwise it is a claim nobody can check

“Production-ready code generation” was one of your four outcomes. It is also the one most often sold and least often delivered, because the phrase usually goes undefined. So we define it as a gate: code is production-ready when it passes the same checks a human's code has to pass.

That definition has an awkward consequence for n.tasc today. Those checks are not currently enforced on anyone's code. So the first half of this outcome is not about agents at all — it is about building the gate. Once the gate exists, generated code either clears it or it does not, and the claim becomes measurable.

The eight checks a change must clear

ANY CHANGE hand-written or agent-drafted the gate does not care which same bar for both Today: none of these eight are enforced by a pipeline that is the first fix 1 It compiles, with warnings treated as errors 2 Analyzers and style rules pass 3 Full unit suite green — blocks the merge 4 A test per acceptance criterion exists 5 Integration tests pass on a real database 6 Security pass: injection, encoding, authz, secrets 7 Golden datasets pass, if critical logic changed 8 A named human read it and committed it PRODUCTION-READY by definition, not by assertion Why this framing matters You never have to argue about whether generated code is “good enough”. It either cleared eight gates or it did not

What Makes an Agent's First Draft Good

Four constraints. Without them you get plausible code that fails review.

The four grounding rules
These are enforced in the agent definitions, not left to judgement
1
Reuse before writing new
The agent must search for an existing service, repository, helper or partial that already does this, and say why it is not usable, before creating one. This is the single biggest cause of bloated generated code.
2
Follow the pattern already in that project
Not a generic best practice. Whatever this codebase actually does for error handling, logging, validation and layering, recorded in .ai-memory/patterns/ during Stage 1.
3
No invention
Endpoints, component names, column names and database logic come from the real inventory. If the agent cannot find what it needs, it stops and asks instead of producing a plausible name that does not exist.
4
Stay inside the change map
It cannot touch a file the approved change map did not list. Scope creep in generated code destroys reviewer trust faster than any other failure, because it makes every diff expensive to read.

Rule 2 is why Stage 1 exists

An agent that has not read your conventions will write correct, idiomatic code that looks nothing like the rest of the file. Reviewers reject that, correctly, and then conclude the tool does not work. Capturing the real patterns first is what turns a first draft from a starting point into something close to mergeable.

The Code Review Agent

Runs before a human opens the pull request

Review is usually the queue nobody plans for. A change sits waiting for a free reviewer, and when the reviewer arrives they are reading the whole diff cold. The review agent takes the mechanical part of that job so the human gets a smaller, cleaner diff and can spend their attention on design and correctness.

What it checks, and what it hands over
The left column is automatable. The right column is not, and stays with the developer.
Agent handles
  • Coding standards and analyzer violations
  • Null handling and boundary conditions
  • Injection, output encoding, authorisation checks
  • Hardcoded secrets, connection strings, thresholds
  • Files touched outside the approved change map
  • Duplicated logic that already exists elsewhere
  • Missing tests against acceptance criteria
  • Obvious performance traps in a real-time path
→
Human still decides
  • Is this the right design for where the code is going?
  • Does this match how we want that layer structured?
  • Is the business logic actually correct?
  • Is this abstraction worth its cost?
  • Should this have been a smaller change?
  • Does this create a maintenance problem in six months?
  • Anything requiring judgement about the domain

The review agent reviews human code too

It runs on every pull request, not only agent-drafted ones. Two reasons. The gate has to be the same for both or the standard is not a standard. And a defect in hand-written code costs exactly as much in production as a defect in generated code.

Where Generated Code Falls Short

Named up front, because a tool sold as universally good gets dropped the first time it is not

✗

Novel algorithms

A new calculation methodology or a business rule nobody has implemented before. The agent has nothing to ground on. Expect to design that by hand and use the agent for the surrounding plumbing.

✗

Tiny changes in familiar code

A two-line fix in a file the developer knows well is faster to make than to specify. Routing it through the pipeline costs more than it saves. Record that boundary and stop pretending otherwise.

✗

Deep performance work

Tuning a hot path in a calculation engine needs profiling and judgement about your actual load. The agent can suggest and measure, but the call is a person's.

✗

Anything with no clear correct answer

Exploratory spikes, architectural direction, trade-offs between competing client needs. The agent will produce something confident. That is exactly the problem.

Measuring the Claim

Three numbers, tracked from the pilot onward

↓
Review iterations per pull request
↑
Share of drafted lines surviving to merge
=
Post-merge defect rate, agent-touched vs hand-written
MeasureWhat it tells youWhat bad looks like
Review iterations per PR Whether the first draft is close enough to be worth having Iterations rise. The draft looks right and is not, so it eats senior attention
Drafted lines surviving to merge How much of the generated code is actually used rather than rewritten Low share. The agent is not grounded well enough — usually a memory gap, not a model problem
Post-merge defect rate Whether agent-touched code fails in production more than hand-written code Higher than hand-written. Then generation is not production-ready and we say so
Review agent catch rate How many findings it catches before the human reviewer sees the diff Near zero, or all trivial. The agent is not earning its place in the pipeline

The number that would end this outcome

If review iterations rise enough to cancel the drafting gain, generation is costing more than it saves. That is the specific failure we watch for during the pilot, and it is the one most often missed — because drafting speed is visible and review cost is not. Both get measured from Stage 0.