Humans Architect The System, AI Writes The Code

I have not written a line of code at work since the end of January. That is not a claim about where every team should be tomorrow. It is the way we work, and it has changed what I spend my time on.

The distinction I wanted to make in my talk, "The Humans Architect the System, the AI Writes the Code," is between writing code and building the machine that writes code. In the AI era, that distinction matters. People call this software factories, dark factories, agentic workflows, or something else. The useful part is simpler: humans need to design the process that turns intent into reliable software.

At System Initiative, and in the new company we spun out of that work, this became very concrete. We spent years building a beautifully architected Rust system. At the end of January, we threw the code away because the product itself needed to be rethought for an AI-native world. Five of us stayed behind, started from a Miro board, and rebuilt the way we work around agents from the beginning.

That is the story I wanted to share. Not a recommendation that everybody should ban themselves from typing code, but a concrete example of what changes when you take the idea seriously.

Use this talk as agent context

Tessl has turned my AI DevCon talk into a skill your agent can use as context. You can also watch the full recording.

Why did I stop writing code?

The honest answer is that I had already fallen out of love with writing code line by line.

One of the moments I described was sitting on a call where people were discussing naming conventions for NATS queues. The people on the call cared deeply about getting it right. I understand why. Those details matter in a system. But for me, that was no longer the work I wanted to spend most of my energy on.

What I care about now is architecture, design, constraints, invariants, and the coherence of the product over time. If agents can do more of the implementation, then the human work moves up a level. The question becomes: what does this system have to mean, how should it behave, what must never be violated, and how do we make those expectations executable?

That is why I said the vibes do not scale. A one-line prompt may get you somewhere on a small task. It may even feel impressive. But if there is no explicit idea of what the system is supposed to become, the output will not stay coherent. You can spend a lot of tokens and still end up with a product that has no architectural spine.

We do not accept human-written pull requests

Our rule is blunt: agents write every line of code.

That is not a preference or a guideline. If someone opens a pull request written by a human, we do not merge it. The reason is not that human-written code is bad. The reason is that we are trying to protect the integrity of the system we are building. If the system depends on agents producing the implementation, then the process, constraints, checks, and feedback loops have to be designed around that fact.

The same rule affects open source contribution. We do not accept external pull requests with code. We do accept issues, feature requests, ideas, design proposals, and evidence that something is wrong. That might sound harsh, but in an AI-generated-code world, open source maintainers are already dealing with huge volumes of plausible patches. Some are helpful. Some are careless. Some may be supply-chain attacks.

If I cannot reliably distinguish a well-formed agent-generated contribution from a hostile one, then I do not want that attack surface in the code path. The way to contribute is to help us improve the product and the specification of the work. The agents can then implement it inside the process we control.

The process is a state machine

The important part of the system is not that an agent writes code. The important part is the lifecycle around the work.

Our flow starts with an issue or feature request. The issue is triaged and classified. Then the system generates a plan. That plan goes through an adversarial review loop. One agent proposes the plan, while another challenges it, looking for security problems, architectural holes, missing requirements, and places where the plan does not match the constraints of the system.

That loop is bounded. We allow up to five rounds. If the agents cannot agree, a human becomes the arbiter. The human is not dropped into a vague mess. The disagreements are captured as structured data, so we can ask what the agents agree on, what they disagree on, and why the plan is blocked.

Once the plan is good enough, implementation starts. If it is a bug, the system tries to reproduce and verify it. If it is a feature, the path continues into a pull request. From there, the work moves through review gates, UAT, release, and notification back to the person who requested it.

This is not a pile of shell scripts. It is a state machine inside a skill, backed by a CLI. That makes it maintainable and extendable. The agent is not just improvising. It is moving through a designed workflow.

CLAUDE.md is the executable contract

For us, CLAUDE.md is the center of gravity. It is not passive documentation. It is an executable contract with the agent.

The file contains the constraints that matter in our codebase. TypeScript must be strict. We do not use any. We use named exports. Files carry the right AGPL copyright. We do not fire and forget promises. Endpoints return JSON. Implementation details do not leak into public surfaces.

Those may look like coding standards, but in an agentic workflow they become much more important. They are the rules the agent reads before it acts. If they are vague, stale, or incomplete, the system behaves inconsistently. If they are precise and maintained, they let the team improve the generator instead of repeatedly fixing the output by hand.

The last line matters too. If the agent hits a non-obvious problem that will trip up future sessions, it should record it and propose an update. That is how the system learns from failure. A mistake should become a better constraint, not just a one-off correction.

Tests and gates carry the trust

Trust in this workflow does not come from trusting the model. It comes from trusting the gates.

We run unit tests, integration tests, contract tests, property tests, and architectural tests. After a binary is built, we ship it into a different repository and run it as a user. That user acceptance testing is a release gate. A merged pull request does not automatically mean the code reaches an end user.

We also run adversarial tests. The system tries to inject input, kill processes, remove data, and do the kinds of things real users and broken environments do. Failures get fed back into the process.

Our CI has five merge gates: code review, adversarial review, user experience review, CI security review, and skill checks. The skill checks matter because our product is designed to be driven by agents. If the skill content, format, triggers, or agent experience regress, that is a real product regression.

When every gate passes, the pull request can merge itself. That is only credible because the release path is still constrained by evidence.

The numbers are a result of the loop

The numbers I showed were not there to prove that everyone should copy us exactly. They were there to show what a bounded process can make possible.

In the previous 30 days, 295 issues had been opened. We shipped 217 of them and closed 81 as duplicates or things we were not going to do. Median time to triage was 4.6 elapsed hours. From triage to ship, including the gates, the median was 1.6 elapsed hours.

There are five people in the company. Each of us has a Claude Max Pro subscription, and we spend roughly $1,500 to $2,000 a month on CI review processes, around $3,000 a month in total for this way of working. For us, that is a very different cost profile from the way we used to build software.

But the bottleneck did not disappear. In the Q&A, I said the bottleneck is now deciding what to build. If I can spin up ten agents but point them at the wrong features, I can generate a very fast mess. The human work becomes intent, product judgement, and architecture.

Start with one constraint

If you want to experiment with this pattern, do not point an agent at the whole organization and hope for the best.

Start by turning conventions into constraints. Write down the thing your repository assumes but never says. Encode one piece of knowledge that only one person in the organization seems to know. Run one workflow from issue to plan to review to implementation to verification. Then look at where it breaks and add the next constraint.

That is the smallest useful loop. The point is not to build our whole process on day one. The point is to stop treating agent failures as isolated incidents and start improving the system that caused them.

I ended the talk with the idea that intent is the new architecture. That is where I think the human role is moving. Agents can write more of the code only when humans make the system's intent explicit enough to execute, review, test, and improve.

The full version of this argument was presented at AI DevCon London. To go deeper, watch the full recording.