< My AI Coding Workflow (Revisited)

I wrote a snapshot of my AI coding workflow back in February, as part of the push to 100 PRs a day. It was explicitly point-in-time, so nine months on, here's the next one. Since then I've hit the hundred, and 200 in a day is now a normal day.

The core aim hasn't moved: reduce "touches", the number of times I have to pick up a change before it ships.

What I didn't cover in February was how the day itself is structured, and that has changed more than the flow has.

The day. Half of it goes to delivering and half to the harness: prompts, skills, lint rules, CI, the tooling around the agents. That half lives on the Axe Branch, and it is where the touch count actually comes down. Overnight is for long-running tasks that can burn quota without my attention.

Concurrency, with a cap. I run a lot of tasks at once, around twenty, but only five to ten epics, so most context switches land somewhere I've just been[2]. The new part is a hard limit on open PRs. Once the queue is full the agents wait for me rather than the other way around, which is the backpressure I didn't have in February. When I find myself re-reading a PR, the rule is now "never pick it up twice": something upstream needs fixing, so stop and fix it.

Self-sufficient agents. A growing number of processes run without me at all. Support documentation is one, patching is another, and it now stretches to fixing customer-reported bugs. That is a big topic, so I'll only touch on it here and write it up properly soon.

The flow itself, right now:

  1. Start every task in Claude Code/Web/Desktop, with images and annotated screenshots. No plan mode, no swarms; the "axe" work goes into making the first prompt land[3]. Smaller PRs are the other unlock, since the hard part of many streams at once is managing the context.

  2. A dashboard "bot" gathers everything about each PR: CI/CD status, whether there are comments and which are resolved, and the types and directories the change touches.

  3. I've pushed the coding agent hard to produce PRs that are either straight-through or very easy to review. Screenshots, a short video of the feature end-to-end, a testing script, whatever is needed is added. All of it is one click away in the dashboard.

  4. Another agent assesses each new PR. Simple ones are marked "Merge When Green" and go live when CI/CD passes. The rest get a review from one or two separate agents.

  5. Claude or Codex responds to that feedback and resolves the comments it can. Anything it can't stays open and I'm notified.

  6. Once every comment is resolved, the assessment runs again: can it be "Merge When Green" now?

  7. If all else fails, I review. For a visual change that might be a glance in the dashboard. Sometimes I read the diff. For the complex cases I pull it down and review locally.

Where are we at? I regularly merge 170+ PRs a day. When I hit 100, the automerge PRs were about 25%, now it's closer to 60%.

Also read: My Current AI Coding Workflow, What does it take to build towards 100 PRs/day per engineer?, One Hundred, and Fifty, and Never Pick It Up Twice.

Discuss and share via the meta page . Filed under AI, Code, Productivity, and 100PR.

Footnotes

  1. The risk tiers are described in the original 100 PRs post. The first PR that merged with nobody reading it was a patch bump. ↩

  2. Little's Law is unforgiving here, as I footnoted in No Agents, No Plan: hold throughput constant and more WIP just means longer lead times. ↩

  3. Why I stopped using plan mode and swarms. Every nudge is a touch and every handoff between agents is a chance to drift. ↩