TL;DR
- Our old Claude Code workflow was built for models that don’t exist anymore: small context windows, lots of hand-holding, a dozen commands to remember. More than six thousand lines of it.
- I rebuilt it on evidence instead of habit: published measurements on reasoning effort, a thirty-turn argument I ran between two AI models, and a colleague’s map of where engineering attention pays back most.
- The new version is one loop with two front doors, two gates, reviewers that can’t edit code, and a config file the loop is not allowed to change. About 1,400 lines in total, the loop itself is a couple of hundred.
- The biggest lesson was not about prompts. A documentation page told me a key feature didn’t exist, and a two-minute test proved it did. Measure before you believe anything… the docs included.
We had a workflow we were proud of. We built it together, used it on real client projects for months, and it shipped real work. Then the models got better and the workflow didn’t… and one day I noticed we were spending more effort keeping the workflow happy than the workflow was saving us.
#What we had
On paper it was thorough. In practice it was ceremony built for a weaker model.
Six commands and an autopilot. One to create a prompt file, one to run it, one to save the session, one to load it, one to suggest what to do next, one to manage a feature list. The autopilot chewed through the prompt files on its own.
A complexity rubric. Five dimensions, each scored one to five, summed to twenty-five, with four threshold bands… all to decide if a task should be one prompt or several. Basically arithmetic to work around a small context window.
A save, clear, load ritual, repeated in six different files and triggered by a context monitor.
The monitor was wrong for two months. It assumed a 200,000 token window while the model had a million, so it reported roughly five times the real usage and told us to stop and save at about fifteen percent full. And we believed it :(
And when I finally audited the whole thing, some commands had their executable steps nested inside their output section, one command’s permissions forbade the exact writes it performed, and a generator had been producing agents with no configuration header at all. So none of them were even registered.
It worked, mostly, because the model was good enough to route around it. That’s not the same as the workflow being good. Patching a hand-holding workflow into an autonomous one usually leaves you with both, so I started over.
#Where the new idea came from
Effort doesn’t make the model smarter
The first input was a deep-dive from the Claude Code team on reasoning effort. Its main claim changed how I think about the whole thing: effort doesn’t make the model smarter. It changes how much the model checks its own work, and how many decisions it makes without asking you.
Pass rate, low effort to top effort
From the Claude Code team’s deep-dive on reasoning effort.
| Work | Low effort | Top effort |
|---|---|---|
| Security work | 64% | 87% |
| General software | 43% | 56% |
| Operations | 12% | 22% |
Top effort costs about three times the tokens, and on one task it took 33 minutes instead of 2. So effort is worth paying for exactly where checking pays off, and wasted everywhere else.
The number that stuck with me was a different one. A deliberately underspecified app took a minute and a half at low effort and 67 minutes at max. High effort on a vague brief doesn’t give you a better answer… it gives you a thoroughly verified version of the wrong thing, an hour later. So the first rule of the new workflow became: specification clarity decides effort, before anything else does.
Two models arguing with evidence
The second input was an experiment. I put two AI models in one shared file for thirty turns and made them argue about how they work, with strict rules: every claim needs a real incident or a runnable experiment, and every turn has to challenge the previous one.
Two findings changed the design.
The recurrence table. Five rules I had already written down were broken again by the same agent that wrote them. One of them eight times. Knowing the rule was never the problem, applying it at the moment of action was. So written rules alone were not going to save me.
The speed gap was a habit, not a personality. On the same ticket, one model got to the finish line in 15 minutes and the other in 33, with similar reading volume and identical step time. The faster one read the incident’s own evidence first. The slower one read the code first.
And one real bug turned up in already merged code, because one model challenged the other to actually run the tests instead of citing them :D
A map, and my own worries
The third input was a colleague’s map of where an hour of attention pays back most, in five tiers from the whole agentic system down to a single line of code. Higher tiers pay more and are more ambiguous. If you find yourself editing lines by hand, something higher up already failed.
I added my own worries to it. With agents I don’t read everything they produce anymore. I had lost track of what was actually in our database. And I wanted a human, not an agent, to decide before any table changes shape.
#The new flow
One loop, two front doors: a ticket, or a plain description of what you want. After the first step both paths are identical. These are the steps from the video at the top, in detail.
- Bearings. Take a lock so two sessions can’t run at once, read where work was left, read the knowledge index.
- Claim. Move the ticket to in-progress. That transition is the lock, so nobody else picks it up.
- Frame. Read the ticket’s comments before its description, because corrections arrive after the description is written. Then the relevant lessons, then a map of the database, then a search for what already exists. Only then decide if the brief is good enough to build from.
- Plan gate. Conditional. It fires on a thin brief, criteria the agent had to invent, any database change, a risky surface, something architecturally new, high effort, or a new project that hasn’t earned trust yet. It blocks the ticket, not the loop, so the queue keeps moving.
- Build. The plan is the contract. When reality contradicts it, the agent amends the plan with a reason instead of improvising.
- Review. Three reviewers that didn’t write the code: correctness, security, performance. Severity decides the fix loop, not a counter. A serious finding gets re-checked, a style nit is never fixed in the same pass.
- Confidence gate. Universal. A score plus a list of blockers no score can override.
- Ship and verify. Merge, wait for the deploy to actually go green, then check the result on the running system from the user’s side. Tests passing is not verification. A failure reverts.
- Hand over. A comment in two layers: plain language for product and QA first, technical detail second.
- Learn. A ticket bouncing back from QA is the highest-signal event in the system, because both gates passed and it was still wrong. That one always produces a lesson.
The two gates answer different questions. The plan gate removes uncertainty, the confidence gate removes risk. An approved plan clears the uncertainty blockers and never the risk ones… a plan approval is not a merge approval.
The two gates
| Plan gate | Confidence gate | |
|---|---|---|
| Removes | Uncertainty | Risk |
| Fires | On a thin brief, invented criteria, a database change, a risky surface, something architecturally new, high effort or a new project | On every ticket |
| Decides with | A person’s approval of the plan | A score, plus blockers no score can override |
| Blocks | That ticket; the queue keeps moving | The merge |
#Agents and effort
Effort is set per agent, so the loop picks the effort by picking which agent does the work. An explorer at low effort that can only read. A planner at high effort, aimed at edge cases and told explicitly to never answer its own questions about intent. An implementer at medium. And three reviewers at medium, high and max, all read-only. The security review goes up to max when a change touches authentication, secrets or payments, because that’s where the measurements say extra checking pays.
Who does what, at which effort
| Agent | Effort | Its job |
|---|---|---|
| Explorer | Low | Reads, never writes |
| Planner | High | Finds the edge cases; never answers its own questions about intent |
| Implementer | Medium | Writes the code and the tests |
| Three reviewers | Medium, high and max | Correctness, security and performance; read-only. Security goes to max for authentication, secrets or payments |
| Advisor | A second, different model | Consulted before a large plan, when an error repeats, and before a long task is called done |
Every reviewer is read-only. The most autonomous thing in the system, a max-effort reviewer, has a tool set that can’t change a single file.
On top of that sits an advisor: a second, different model, consulted before a large plan, when an error repeats, and before a long task is called done. The loop fires it on those conditions, not when the agent feels like it, because “is my plan big enough to need a second opinion?” is exactly the call an agent gets wrong about its own work.
#The scripts
An installer that delivers the parts that never change between projects, and refuses to overwrite a file someone has edited.
A database map generator that builds the map from the live schema, never from an agent’s memory, and labels anything it had to guess. A drift check fails loudly when the map goes stale.
A prompt hook that notices a ticket reference and reminds the agent to use the loop. It can only remind, it can’t refuse… and I’d rather say that plainly than oversell it.
A setup command that reads a project, labels every section of its instruction file before touching it, never deletes anything, trims advice about frameworks the project doesn’t use, proposes each correction as its own row, and waits for a human to approve.
#What goes in the instructions file
My first version of the instructions said where the loop lives and where plans are kept. An agent reads that, learns the tooling exists, and carries on working by hand lol. A reference card changes nothing. So I rewrote it as a trigger and a consequence: when you get a ticket, run the loop, because working by hand is the same work with the checks removed.
A few of the rules that made the cut:
Completion is verified, not reported. Name what had to be true and check it against something the code didn’t write itself.
Primary evidence first. Read the incident’s own logs before the code.
Carrier before prose. The second time a written rule is broken, stop rewording it and turn it into a test, a hook, or a default.
The loop can never edit its own configuration. A miscalibration becomes a proposal for a human.
You can’t approve your own plan. And an approval relayed by another agent is not an approval either.
#The lesson I didn’t expect
Late in the build I asked an agent to check the documentation for one detail: does that per-agent effort setting actually exist? It came back confident. Not a supported field. The whole effort ladder was probably decoration.
I almost ripped it out of every agent. Instead I ran a test that took two minutes: three agents identical except for that one line, then I read what level each one actually ran at. Low ran at low, medium at medium, max at max. The feature worked, the documentation was just incomplete.
The same week, the old context monitor told me a session was 246% full. A corrected reading of the same session said 52% 😁
Both times the description of the system was wrong and the measurement was right.
#My take here
The new workflow is a quarter of the size of the old one, and the loop itself is a couple of hundred lines. It’s also honest about what it hasn’t proven yet: zero minutes of speed shown so far. It’s on a trial and I’m measuring two things… time to the same finish line, and corrections after handoff. Will come back with the numbers, good or bad.
The change I like the most is where my attention goes. I read plans and I approve merges. I don’t watch work happen anymore.