2024 – 2025
~40
commits / month
For engineering teams already shipping with AI
Writing the code was the craft. It's also the bit that got automated first. What's left is the reviewing — more pull requests than before, every one of them plausible, none of them yours. The queue never empties.
It doesn't have to be like that.
For a long time you made the thing yourself, start to finish. You knew every joint in it. At the end of a day you could stand back and see exactly what you had made — and that was the good part, the part nobody says out loud in standup.
Now there is a factory floor where the workshop used to be, and the line runs faster than any of us ever could. So we stand at the end of it, checking furniture we did not make.
The mistake is thinking the pride is gone. It moved. It belongs to the line now — to the system you designed, the jigs that make a bad cut impossible, the throughput you can finally measure and improve. That is still a craft. It is a bigger one, and a better thing to be proud of than any single table.
I help teams make that move: from making every piece by hand to designing the thing that turns them out — and taking the same pride in that.
2024 – 2025
~40
commits / month
2026 to date
~130
commits / month
Same team. Same review standards. The difference is the system around them.
Measured at Bright Energy, where I built this workflow and still run it every day.
The mental load goes down, not up. Small and medium issues never reach them. The reviews that do arrive are small, ordered by what matters, and already checked — so the day goes on the problems that are genuinely interesting, which is why they took the job in the first place.
Features and fixes move in days rather than sprints, because the gap between "decided" and "shipped" stopped being where everything went to wait.
Monitoring catches the error and the fix is waiting for approval before anyone thinks to report it. Meanwhile the features they asked for arrive while they still care about them. Fewer things going wrong, and less waiting for the things going right.
Linting and hooks that run on every action and refuse — deterministic, not advisory. The category of mistake that used to cost you an afternoon and a postmortem stops being available at all. Instructions are probabilistic; enforcement is not.
A message, a design handoff, or an error your monitoring just caught — one step turns any of them into a well-formed issue with the right context already attached. This is the part teams skip, and it is the part that decides everything downstream: a thin issue produces a confident, plausible mess, just faster than before. Your integrations do the fetching, not your developers.
Issues get picked up and carried through — branch, implementation, pull request, its own CI failures repaired, its own review comments answered. Nothing merges without a human approving it.
This is the one that decides whether any of the rest matters. Small stacked pull requests instead of one enormous diff. A queue that tells you what needs your eyes first and what does not need them at all. An automated pass that finds its own problems and fixes them, so you review the end state instead of watching a machine correct itself in public.
That is the loop — not a step in the list, but the whole thing turning. Faster review means faster releases; more releases mean production has more to tell you; and what it tells you becomes the next issue, already written. Every turn feeds the next one, and your developers spend their time on the decisions only they can make.
Nobody goes from struggling to a full loop in one jump. It is a ladder, and every rung is worth something on its own — stop after two and you are still better off than you are today.
Linting and hooks make the expensive mistakes impossible — deterministic checks that run on every action, instead of conventions in a document the agent half-follows. Nothing else is safe to build until this holds.
Raising work becomes one step from wherever it surfaces — a message, a design, a production error — and the issue arrives with the right context already attached.
Smaller stacked pull requests, ordered so you know what needs you — and an automated pass handling what does not.
Work gets picked up and carried through on its own. Production errors feed straight back in. A human still approves what ships.
Someone on your team extends it without me as the codebase changes. A system you cannot grow yourself is just another dependency.
Tell me what your workflow looks like today — in plain language, no brief required. I will tell you honestly whether this helps, and if it does not, I will say that instead.