Agentic development infrastructure

A lot of my attention in that role went to agents. Not to using them, which anybody can pick up in an afternoon, but to the infrastructure that decides whether the rest of a team can.

The distinction matters because the failure is so common and looks so much like success. One engineer gets good at prompting. That engineer gets faster. Nothing about how the team works changes, and when they leave, none of it stays. The individual gain is real and it is not infrastructure. Infrastructure is the part that works for somebody who did not build it and was not there when it was built.

So the target was never my own throughput. It was whether an engineer who is skeptical of all of this, and a designer who has no reason to care how the repository is laid out, would both end up working inside it by default.

Two things stop a team adopting this, and neither of them is model capability.

The first is context. An agent knows the language and nothing about your project: why a module is split the way it is, what has to happen before a release, which convention is load-bearing and which one is just a habit somebody picked up one afternoon. All of that exists already, in a reviewer's head and in the shape of the code, and none of it is written down anywhere a machine can read it.

The second is trust, and it is much harder.

An agent whose output has to be checked line by line has not saved anybody anything. Reading a change closely costs about what writing it did.

An engineer will try it once. If what comes back needs a full read before it can be believed, they will not try it twice, and they will be right not to. Every adoption argument that skips this and talks about speed is arguing with somebody who already agrees that it is fast.

Build the thing the team works inside, not the thing I work inside. That came to five pieces.

• Instruction architecture. The project, written down, so an agent starts where a new engineer starts: structure, commands, conventions, how work moves through the repository. This is the least interesting piece and everything else stands on it.
• A custom skills library. The workflows a team genuinely repeats, encoded once instead of re-derived in a prompt every time: planning, code review, root cause analysis, releases.
• Autonomous issue-driven development loops. The unit of work is a ticket, not a conversation. That choice is what makes the output reviewable, because a ticket carries an acceptance condition and a chat does not.
• MCP integration, so design context is read rather than described. A description of a design is a lossy copy of it, maintained by hand, going stale from the moment it is written.
• AI-in-the-loop render verification, wired into the definition of done. A change is not finished because the tests are green. It is finished when the thing it renders has actually been checked.

The last one is the argument and the other four are logistics. Verification is what turns an agent from something you supervise into something you can hand work to, because it moves the checking from the reviewer's eyes to the pipeline. Put it in the definition of done and it stops being a thing a careful person remembers to do.

That is also the general instinct underneath all five, and it is the rule I build my own things on: if it can be a rule, it is a rule, and judgment only gets spent on what rules cannot cover. Equity Agent is where I wrote that one down.

Instructions are a second codebase and they rot like one. A convention that changed and an instruction that did not is worse than no instruction at all, because the agent follows the stale one confidently and the person reviewing the result assumes it knew something they did not. Keeping them true is ongoing work that never feels urgent on any particular day.

Verification in the definition of done is a tax on every change. Most changes did not need it. Which ones needed it was not knowable in advance, which is precisely why it could not be optional, and that is a genuinely annoying property to defend to somebody in a hurry.

Adoption is people work rather than engineering work, and I underestimated how much of it there would be. It is sitting with somebody whose first attempt produced nonsense and finding the missing instruction together. Almost nobody who tries this once and gets a bad result comes back on their own, so the first bad result is the whole ballgame, and none of that time shows up anywhere you could point at later.

And the honest one: I cannot show you a number for this. There is no clean measurement of what the infrastructure was worth, I did not manufacture one, and I am suspicious of the ones I see other people produce. What I have instead is who used it.

Engineers used it. Designers used it too, and that second sentence is the one I would put weight on.

A designer picking up an engineering workflow means the workflow stopped requiring an engineer's tolerance for rough edges. Engineers will push through a bad tool if it is fast, which makes engineer adoption a weak signal. Designers will not, so it is a much better test of whether the thing actually works.

The piece that outlasts any of the tooling is the definition of done. Tools get adopted or they get abandoned, and either way it is a decision somebody makes each morning. A change to what the team believes counts as finished is not a decision anybody re-makes.

If I had to compress the whole thing: the tooling is the easy half. Getting other people to trust it is the work, and verification is the only argument that ever moved anybody.