How I build software with AI agents

Since July 2026, about nine in ten of my commits have been written with a coding agent, almost all of them Claude Code. This page is what that looks like on a real production system: what the agent does, what I do, the checks between the two, and the numbers, including the ones that are not flattering.

The numbers

Every commit Claude Code makes carries a Co-Authored-By line. Counting those across the commits I authored in 18 repositories gives this:

Month	My commits	Agent co-authored	Share
Feb 2026	167	0	0%
Mar 2026	171	0	0%
Apr 2026	104	0	0%
May 2026	185	36	19%
Jun 2026	242	136	56%
Jul 2026	945	812	86%
Aug 2026	578	535	93%
Sep 2026	416	377	91%

On Enrixa Store, the multi-tenant platform I lead, 1,276 of my 1,357 commits were agent co-authored. None of the three other developers' commits carry the trailer, and every push from all four of us goes through the same CI gates. Three things these numbers are not:

They are not lines of code. A commit is a unit of change, and agent commits tend to be smaller and more frequent. That is also why July looks so busy.
They are not a productivity claim. I do not have a clean before-and-after measure of delivery speed, and commit counts are not one. I would rather say that than quote a multiplier I cannot defend.
They are a lower bound. The trailer only exists when the agent makes the commit itself. Anything an agent wrote that I committed by hand does not show up.

You can check the pattern yourself in the public repositories: bouncer-gates, estate, and this site.

Who does what

The agent writes most of the code, the tests, the migrations and the documentation updates. It runs the checks and reports what failed. I decide what to build and how it fits together. I write the rules the agent works under, and turn the ones that matter into checks. I read every change that touches money, tenancy, authentication or the database schema. I own production: nothing deploys that I did not approve. The useful mental model is not a faster pair of hands. It is a capable contributor who never tells you which part they were unsure about. Agent code usually compiles, matches the local style and has tests. The risk is volume: a lot of plausible code with no signal about which part deserves attention. Everything below exists to put that signal back.

The setup, layer by layer

Each rule goes in the cheapest place that can actually hold it. The further down this list, the more it costs to build and the more it is worth.

1. An instructions file that is an index, not a manual

The agent's entry point is a short CLAUDE.md that says what the system is, lists the rules that are never negotiable, and maps every other document so the agent opens only the one its task needs. That shape came from a mistake. The entry point used to tell every session to read the project log first, and the log had grown to 861 KB, roughly 210,000 tokens, in one file. Every session started by drowning. It is now 59 KB, with older history archived in files the agent searches rather than reads.

2. Rules that matter are checks, not sentences

The instructions file says tenant isolation is sacred, money is integer minor units, and new migrations must not break the running app. Instructions get followed most of the time, and for a rule like tenant isolation, most of the time is not good enough. So each of those rules also exists as a script: check:tenant, check:money, check:migrations, plus check:safety for anything shaped like a credential or an attack, and check:docs for links that point at deleted files.

3. A hook that stops the agent reading secrets

A PreToolUse hook runs before every shell command, file read and search the agent makes, and blocks any that would read the contents of a secret file. It checks whether a protected file is the operand of a command that prints contents, not whether the command merely mentions it, so listing or ignoring a .env passes and printing it does not. It is there to catch accidents. It would not stop an agent that was trying to get round it, because anything running as me can read what I can read. But accidents are what actually happen: two leaks in one day, before the hook existed.

4. A small permission policy, and one door to production

The agent's permission list had grown to 662 rules, one of which allowed arbitrary remote commands by wildcard. It is now 62, with explicit deny rules for the old patterns. Production access goes through one committed command-line tool with named subcommands for status, deploy, logs and SQL. It resolves credentials itself, so the agent never sees one, and it can print a fingerprint of a secret to confirm which one is loaded without revealing it.

5. Review skills for what a static check cannot see

check:tenant catches a query that reaches around the tenant-scoped client. It cannot follow a client bound inside a transaction callback, judge whether a written exception is still true, or notice a new model that never got registered as tenant-owned. A tenant-check skill makes the agent read every database change for exactly those cases and report each finding as a file, a line, the risk and the fix. The static check is necessary. The skill is what makes it close to sufficient.

6. CI that treats the agent exactly like a person

Every push runs the tenant check, the migration compatibility check, lint, typecheck, tests and build. There is no lighter path for agent changes. More changes arriving faster is a reason for stricter checks, not looser ones. I have been blocked by my own tenant rule, which is the point: a gate that only constrains the agent is one you route around under deadline pressure.

7. A human in the loop who does not have to be at the desk

When the agent asks for permission to do something outside its policy, the request reaches my phone with approve and deny buttons. If that bridge is down or I do not answer in time, it falls back to the normal prompt in the editor. Nothing is ever approved by default.

8. Behaviour tests, when the agent is the product

Enrixa AI is a shopping assistant that is itself an agent, so it needs a different kind of check. A regression suite of 132 cases runs the real agent, with its router, model calls and tools, against a seeded demo store, and asserts behaviour: did it show products, resolve "the first one", refuse a prescription bypass, respect a budget. Every production chat failure becomes a case, and any failure exits non-zero so it can block a deploy.

What went wrong

These are the failures that shaped the setup above. Sessions kept being refused. The early deploy tooling had the agent write a throwaway script with a root password in the source, decode an encoded blob into a remote path and run it detached. Each step was legitimate. Together they are indistinguishable from an intrusion, and sessions were flagged, escalated or cut short. The fix was the single committed operations tool in layer 4. One in three fixes came back. An agent loop that works merchant feedback tickets end to end had a third of its fixes reopened within six weeks. Almost every one had been reasoned from the markup and never observed in a browser. The loop now has to reproduce the problem at the merchant's own viewport before touching code, show a measured before and after, and pass a code review before it may close a ticket. The reviewers caught what the author did not. Before one release, five independent review passes each read the same changes through a different lens: money and orders, tenancy and security, performance, frontend, and contracts. Three of them separately found that a payment-link change reserved stock against the wrong product variant. It was a regression from combining two features that each worked on their own, and the fix put both code paths through one helper so they cannot drift apart again. More of these, from the open-source side, are in What my coding agents got wrong, and what caught it.

Where to start

If I were setting this up again tomorrow, I would not start with the instructions file. I would pick the one mistake that would cost the most if it shipped, make CI catch it for everyone, and write the instructions last, for what a machine cannot check. The longer version of that argument, with an example check, is in the post linked below. And I would decide on day one which areas get a full human read on every change. For me that is money, tenancy, authentication and the schema.

The open-source version

The whole setup, minus anything specific to one project, is a template you can copy: agent-ready-repo. It has an index-style AGENTS.md, the secret-read hook from layer 3 with tests that check it stays quiet on ordinary work, the tenant-check and ship-check skills, a starting permission policy, and CI. The gates from layer 2 are generalised and published as bouncer-gates. It runs as a CLI, a GitHub Action, an MCP server and a post-edit hook in Claude Code and Cursor, so the agent is told about a problem straight after writing the line, not after a pull request. It is on npm and in the official MCP Registry. The longer argument for why checks beat instructions is in Making a codebase safe for AI coding agents.