Part 10 of Building My Agentic Workflow in Public, and Part A of a two-part story. Part 9 ended with a tease: one short prompt, four and a half hours, and a result that surprised me. This is that story. Part B lands after retro 5 runs on a real epic.
Start with what I found when I came back
In early September I typed one prompt into my pipeline and went to live my life. Four hours and thirty-six minutes later, one session had planned and built a seven-feature epic on my observability project. It asked me exactly zero questions while doing it.
What it left me instead was a ledger: every decision it had taken, sorted by how hard each one is to undo. Here are the three real rows from the hardest-to-undo end, as written:
| The decision it took | Why it sits at the top |
|---|---|
| “The config format is TOML, not the YAML the brief’s own Stack table named” | Files in that format start existing the moment anyone uses this |
| The package gets its first new dependency since February, a TOML parser for older Pythons | A dependency is a promise to everyone who installs you |
| An environment variable “is not a security boundary, and is documented as not being one” | A security-posture statement, made without me |
I read those three carefully and accepted all three the next morning. The rest of the ledger, 35 recorded decisions across three lists, I skimmed and accepted over the following weeks. And the session knew its limits: four calls it refused to make and returned to me, one of them a security decision it explicitly would not pick on my behalf.
That is the whole idea of this post. The questions from Part 9 did not disappear. They were relocated. Instead of interrupting me 21 times during the build, the session decided, wrote each decision down with its reasoning, and let me review after, starting with the few that would be expensive to reverse. Same authority, different timing, a fraction of the cost.
How it earned the right to decide
Two habits made the ledger trustworthy enough to review instead of dread.
It measured before it designed. One feature depended on a hook file that Python runs at every startup. A decision we had already ratified assumed the program’s command line would be readable at that moment. Instead of building on that assumption, the session planted a throwaway probe and ran it under six different kinds of process first. The probe proved the assumption false: by the time the hook runs, the command line as Python reports it is not reliable. The original, as the operating system recorded it, is. The design changed before a single line of real code existed. No question to me, no bug three weeks later. A claim got a receipt, and the receipt rewrote the plan.
It engineered reversibility instead of asking for taste. The config format was a genuinely debatable call, and our own planning table had said YAML. The session did not put that question to me. It chose TOML and put all the parsing behind one small module, so if I ever disagree, the switch costs one file’s refactor instead of a rebuild. The cost of that insurance: one conditional dependency, expected to be deletable in a few years. It converted a preference question into a cost question, and the cost was small enough to answer itself. That decision is the first row of the ledger above, which is exactly where it belongs.
What’s bottled so far
The run had one weakness, and its own record states it plainly: the implementer was each feature’s only reviewer. Bottling this run’s shape meant fixing that first, and that part is already live, not planned.
A second reviewer from a different company. Every build now gets evaluated twice: once by a Claude evaluator, once by a GPT-family seat, wired through the same role definition. Its sharpest trick is the deliberate-break pass: after the tests go green, it breaks the code on purpose, dozens of small sabotages, and reports which breaks no test noticed. Last feature: 64 deliberate breaks, 54 caught by the suite, 10 that slipped through, and each of those 10 got a failing test written before the fix. A green suite stops being a feeling and becomes a measured number. Noise from the second seat started at one finding in eight on the pilot and has been near zero since.
The four-line questions from Part 9 are still the format for anything that does reach me, and a hook still physically rejects anything malformed.
Two-way Slack. When a question is worth asking, it lands on my phone, and my reply lands back in the waiting session. The pipeline no longer needs me at a desk to keep moving.
One honest limit. The ledger shape fits code decisions, where reasoning can be written down and checked. It does not fit screens. This month’s epic on my second project put it plainly: the session stopped and asked “should runtime arrows be on when you open the map?” and marked its own confidence as medium, “it’s your taste.” It was right to ask. No document rules on what a screen should feel like, so UI decisions still arrive as questions, one at a time, and I think that line stays human for a long while.
The receipts, in one line
Four hours thirty-six minutes, seven features, 7.25 million tokens, 23 agent invocations (11 new, 12 resumed), Python tests 1,080 to 1,376 plus 159 to 307 on the browser side, seven real defects caught by execution before anything shipped, 35 recorded decisions across three veto lists, zero questions mid-run.
Before you quote these numbers anywhere, let me tell you what they are not. They are not science. This is one developer, me, and one run. And the models themselves got smarter during these same weeks, so part of the gain is theirs, not my workflow’s. I cannot cleanly split the two, and I would rather say that in every post than let you find it out later.
Part B is the other half of the story, and it exists because this run has a rival.
The same month, my second project ran the opposite shape: five stages, a human testing gate between each, me testing against my real data before the next stage began. Slower, and dearer per feature. But the gates earned their cost: my own hands-on testing caught three real defects at the gates, and nothing got past them.
So I now have two builds that disagree. One says let it run and review the ledger after. The other says stop at every stage and put human hands on it. Part B puts the two side by side with their full bills, and lands on the shape I am actually adopting: autonomous within a stage, human gates between.
It also names the number I have to beat. In one 36-hour stretch, the pipeline stopped me 45 times for yes/no record-keeping answers it was already confident about. Retro 5’s changes exist to kill that number, and Part B reports whether they did.
And one more relocation is coming: the tests get generated from the ledger and the hand-test list, so the record of what was decided becomes the proof it still holds, and a second model, not the one that built the code, judges the failures.
The design is written. The receipts are not in yet. When they are, you will read them here.
Vibe Code and Prosper.