Should AI Agents Write Production Code? A CTO's Rules After Running Agent Teams

Yes, and mine do every day. AI agents can own boilerplate, tests, migrations and well-specified features. What they cannot own is the decision to merge. Every agent-written change in my repos goes through a review gate sized to its blast radius, and money, auth and data deletion stay human-only. Veracode found that about 44% of AI code-generation tasks introduce a security flaw. I read that as an argument for gates, not for abstinence. Here is the policy we actually run.

Our founding engineer at Pairty is an OpenClaw agent we named web3jason. He manages his own Trello cards, posts standups to Slack, and opens pull requests against a Turborepo backend and a React Native mobile app. I wrote up how that team runs, prompts included, in Rethinking Agile for AI Engineering Teams.

When we audited the repos he inherited, the list of known issues included a secret echoed into the Android build logs, four files that disagreed about the app's version number, and a CI workflow that had never once fired. Some of that predates the agents. All of it is the kind of thing an agent will reproduce faithfully if nobody tells it not to.

That list is why I have a merge policy instead of a feeling about AI code.

Veracode's 2025 GenAI Code Security Report tested more than 100 language models and found that AI-generated code introduced risky security flaws in 45% of tests. Their 2026 follow-up put the number at roughly 44%, with an average security pass rate of 56% against 55% the year before. The best model they tested passed 68% of security tasks, which still means it fails about one in three. Their line for it was "syntax is solved, security is not."

I don't find that discouraging. Humans don't write flawless code either. We invented code review because authorship was never the guarantee. The question was never whether agents can write production code. It is what process makes their code safe to merge.

Three tiers, sorted by what breaks if the change is wrong.

Work that is well specified, reversible and covered by existing tests. Formatting, dependency bumps with passing CI, new tests, documentation, internal tooling. The agent writes it and CI is the reviewer. If CI can't tell whether the change is safe, it isn't Tier 1.

This is the default for feature work. The card moves through the same lifecycle every time: ToDo, Present, Stakeholder Review, TDD execution, PR, QA Review, human review, merge. One card per pull request. Rebase on main and run the full suite before opening. The human reviewer holds the same bar as for any PR, with extra attention on injection surfaces and error paths, because that is where the Veracode data says models fail most.

At Pairty these are hard locks, not guidelines: auth and Privy, swap logic, wallet operations, production endpoints, bonding-curve parameters, CI secrets. If a card touches one of them, the stakeholder review flags it and a human has to approve before execution even begins. The agent can propose. It cannot author or merge.

These are from our own repos, published in the operating prompts, so treat them as one small team's experience rather than a survey.

A secret in the build logs. The Android deploy workflow echoed PROD_API_URL into its logs. Nothing exotic, just a line that should never have been there. The fix was mechanical. The policy change was that CI secrets became a Tier 3 lock, so no agent can edit a deploy workflow without a human in the loop.

Four versions of the truth. app.json said 1.0.0, package.json said 0.0.1, Xcode said 1.0.5 and CI hard-coded 1.0.4. An agent asked to "bump the version" would have picked one and been confidently wrong. Now package.json is the single source and everything else derives from it.

The trigger that never fired. Our Qodo autofix workflow listened for a workflow name that didn't exist, so it had never run. Green checks, zero coverage of the thing they were supposed to check. This is my standing reminder to review what a test asserts, not just that it passes.

The three-minute kill. Jest hung on open handles from Apollo and Privy, and someone had papered over it with a three-minute kill workaround. That masks real shutdown bugs. It is on the retro board with an owner and a date, which is how these things get fixed in a team that doesn't sleep.

I have been writing about review since 2013, when I ran code reviews over pizza and opened with a YouTube clip to loosen the room, and when behavior-driven development was how we got business owners and engineers to agree on what "done" meant. The mechanics changed. The purpose didn't.

Three things are different when the author is an agent.

I review the spec before the diff. The most dangerous agent code I have seen implements the wrong thing perfectly, because the agent resolved an ambiguity without asking.

I trust the tests less. The agent wrote those too. I read what they assert.

Every agent-authored PR is labeled as such. Reviewers calibrate differently when they know, and it settles the accountability question before it comes up: the human who merged owns it in production.

Agent code is done when the spec it implements was approved by a human, CI and evals pass, a human reviewed it at the tier its blast radius requires, security-sensitive surfaces got explicit attention, the PR is labeled agent-authored, and a named person merged it and owns it. Miss any one of those and it is a draft.

Every coding task runs through Claude Code on the flat subscription. CI-automated fixes run in GitHub Actions. Pay-per-token API usage is reserved for product features, with metering and budgets. That split keeps the bill boring, which is what I want from an engineering cost. I have not published dollar figures and I won't until I have a full quarter I trust.

What percentage of production code can an agent write safely? I don't think in percentages. With tiered gates, most routine changes can be agent-authored. Without them, no number is safe.

Who is accountable for an agent's bug? The person who merged it. That is why the label matters.

Do agents make senior engineers unnecessary? The opposite. Specification and review judgment become the scarce skills, and agents expose weak specs faster than junior engineers ever did.

The agents write most of our code now. The merge button is still mine.