On weekends I don’t build with a single coding agent. I run several — a planner, a couple of builders, a reviewer whose only job is to try to break the others’ work — the way you’d run a small, disciplined team. When people ask what made the biggest difference to how much I ship, they expect the answer to be a model: which one, how big, how new. It isn’t. The productivity didn’t come from a smarter model. It came from process. The same unglamorous things that make a human team fast — clear roles, written standards, real gates, short feedback loops — turn out to be exactly what makes a team of coding agents fast too. This is how I’ve set mine up, and the agility lessons I keep relearning underneath it.
A team, not a genius
The first instinct with coding agents is to find the smartest one and ask it to do everything. That ceiling is low. What actually scales is division of labour. I give the work roles: a planner that reads the real code and writes down the plan before anything gets touched; builders that each take an independent slice and run in parallel; an adversarial reviewer whose entire mandate is to poke holes — to assume the change is wrong and go looking for how. No single agent is brilliant. The arrangement is.
The lesson generalises directly to how leaders should think about adopting these tools. Agility isn’t one super-capable actor moving fast; it’s several competent actors moving in parallel with a clear contract between them. The moment work can be split and checked independently, throughput stops being bounded by any one agent’s cleverness. You get leverage from the org chart, not the IQ.
Skills are the team’s memory
Early on I was re-explaining my standards on every task — how I want changes reviewed, what “done” means, the discipline to run before opening anything up. That doesn’t scale, and it drifts: the standard is whatever I remembered to say that day. So I stopped explaining and started encoding. My house rules now live as reusable playbooks — a review checklist, a pre-flight discipline, the definition of a good change — that any agent loads on demand. I write the judgment down once; every agent applies it the same way, every time.
This is the single highest-leverage move, and it’s the one most teams skip. The knowledge that makes your engineers good — the review instincts, the “we don’t ship it like that here” — usually lives as tribal memory in a few senior heads. Coding agents force you to make it explicit and executable, because an agent can only apply a standard you’ve actually written down. Do that, and the standard stops depending on who showed up. Codified judgment compounds; tribal knowledge evaporates.
Gates, not vibes
The fear with fast-moving agents is that speed means sloppiness. The fix isn’t to slow down — it’s to make correctness mechanical instead of heroic. Every change I accept has to pass through a gate. The most important one: a change ships with a behavioural test that fails if you revert the fix. Not “the existing tests still pass” — a new test that proves the specific thing actually changed. If reverting the code leaves the test green, the test was theatre and the work isn’t done.
Around that sit the rest of the gates: a reviewer that blocks on real issues rather than nodding them through, and a hard rule against bypassing checks — no quietly skipping the hooks to force something in. This sounds like friction, and it’s the opposite. The reason I can let agents move fast is that I trust the gates. Agility isn’t the freedom to skip verification; it’s the confidence, earned from good gates, that you don’t have to babysit every step. Make the floor mechanical and you can raise the ceiling on speed.
Plan first, verify always
Two habits do more for reliability than any model upgrade. The first: plan before you touch anything. Read the actual code — not the doc that describes it, not last month’s memory of it, the code as it is right now — write the plan, and update it after every change. The source of truth is the system, not the story about the system. The second: treat every handed-over “diagnosis” as a hypothesis, not a fact. When an agent (or a human) hands me “the bug is X,” the next step is to reproduce X and read the real file, not to act on the claim. A filename is not its contents; an assertion is not evidence.
Both habits point at the same truth about agility. Speed doesn’t come from typing — or generating — faster. It comes from short, verified loops: small step, check it against reality, next step. The teams that feel slow with AI are usually the ones taking big unverified leaps and then spending days untangling which leap was wrong. Verify small and often and you almost never have to backtrack far.
Build so you’re never blocked
The last piece is the least glamorous and, on a busy weekend, the one I feel most. A lot of my time was being eaten not by thinking but by waiting — a heavy build chewing up the machine, or two services drifting out of sync because a setting lived in three places. So I moved the heavy work off to dedicated build machines that run to the side while I keep going, and I pulled configuration back to a single source of truth so nothing silently disagrees with anything else. Neither is clever. Both remove a stall.
The general point: the constraint on an agentic workflow is rarely the model. It’s the wait, the drift, and the blocked loop. Frontier capability doesn’t help if your agents are idling on a build or chasing a config that means one thing here and another thing there. Agility is as much about removing stalls as it is about raw speed — the fastest actor in the world is slow if it spends half its time waiting.
What actually changed
Strip it all back and the learnings are less about AI than about how good work has always gotten done:
- The model is the smallest part. Leverage lives in the process around it — a point I keep hitting from every angle (it’s not just LLMs and tokens).
- Run agents like a team. Roles, parallelism, and a review culture beat one genius agent every time.
- Codify judgment into reusable skills. Written, executable standards compound; tribal knowledge doesn’t.
- Make correctness mechanical. Gates and tests that fail on revert let you move fast because you’re not the safety net.
- Agility is short verified loops. Plan first, verify against reality, never take a big unchecked leap.
- Trust is earned, not assumed. A diagnosis is a hypothesis; a claim is not evidence; check the real surface.
- Remove the stalls. Never-blocked infrastructure and single-source config are agility, not overhead.
The durable part
Models will keep leapfrogging each other, and every few weeks something will make my current setup look quaint. That’s fine — because the part that made the difference isn’t the model, and it doesn’t expire when the next one lands. Roles, playbooks, gates, verified loops, a workflow with no stalls in it: that’s the harness, and the harness is the part that’s actually mine. I built it on weekends around a hobby, but it’s the same shape that decides whether a real team gets faster or just noisier when they hand work to agents.
Agility was never the speed of producing code. It’s the speed of a safe loop. The organisations that win with coding agents won’t be the ones with the best model — that’s a component everyone can rent. They’ll be the ones with the best process wrapped around it. Give your agents a process, and the process is the thing you get to keep.
Companion piece: Agentic AI Is Not Just LLMs and Tokens — the same idea from the engineering side.
Part of the Agentic AI series
- Agents Eat the Stack Top-Down
- The Substrate War
- Buy, Build, or Orchestrate
- Service-as-Software
- The Frontier Labs Are in the Squeezed Middle of Their Own Stack
Companions: Who Advises the Disrupted? · Agentic AI Is Not Just LLMs and Tokens · A Product Playbook for Agentic AI · Why Agentic AI Transformation Is Hard · Give Your Coding Agents a Process — you are here · A Longer Leash.
Part of a personal DIY hobby, tinkered together on weekends. The coding setup here is my own personal practice, built around open-source tooling.
Leave a Reply