There is a moment in my workshops that I have learned to wait for.
I am showing something on screen, agents doing their thing, and somewhere in the middle of it I drop the line. Casually. The way you’d mention the weather: “…and then I usually tell it: when done, commit and push.”
And the room changes. You can watch it happen. Eyebrows go up. Somebody leans back and folds their arms. And there is always one guy – it’s always one guy – who asks out loud what the rest of them are already thinking.
“Push. To where, exactly?”
To master. Which hits the pipeline. Which, on most of my pipelines, means production.
And then the faces do that thing faces do when the room has decided you are a cowboy and is being polite about it.
Okay. Let’s have this out.
You’re right
Let me get this out of the way first, because I am not going to argue with you.
If you tell your agent to commit and push, and it lands in production, you are being reckless.
Not “it depends”. Not “there are pros and cons”. Reckless. I mean it, and I mean you specifically.
So we agree. Almost. Because I do it every day, and I sleep like a baby, and both of those things are true at the same time. The difference between you and me is not courage. It’s not that I have a better agent, or a secret prompt, or a model you don’t have access to.
It’s that I don’t trust it either.
The man they didn’t listen to
Let me borrow a guy who is smarter than both of us.
In 1950, an American statistician stood in front of a room of Japanese engineers and told them something that sounds obvious now and sounded insane then. “Quality cannot be inspected into a product,” he said. “It must be built into it.” Stop paying a guy at the end of the line to catch your defects, and go fix the process that produces them instead.
His name was W. Edwards Deming, and his own country had already shrugged him off. American industry had won a war and was selling everything it could stamp out; it did not need a statistician with opinions about variance. Japan, which had nothing, listened. They named a quality prize after him the following year.
Detroit finally got around to asking what happened roughly thirty years later, by which point the answer was parked in every fourth driveway in America.
Do the math on the squinting guy
Why? Because the guy at the end of the line squinting at every widget coming off the line is the worst quality system you can build.
Because he gets tired. Because widget number four hundred looks exactly like widget number three hundred ninety-nine, and by lunch he is not inspecting anything, he is moving his eyes across a shape and letting his hands say yes.
This is what Six Sigma is actually about. It’s a defect rate – about three escapes per million – and you do not climb it by hiring a more attentive guy. Each sigma is at least an order of magnitude fewer escapes, bought every single time by fixing the process so the defect cannot be produced. Never by squinting harder.
Now put yourself in the chair, because you are the squinting guy. “I review every diff my agent writes.”
Fine. Let’s count your opportunities. One diff a day, every day, no weekends, no holidays, no sick leave, is a million opportunities in about two thousand seven hundred years. So for six sigma, you sit in that chair from the Iron Age to this morning – through Babylon, Greece, and Rome, through every empire that ever rose and fell, and in all of that time you are allowed to wave through three bad diffs. Three. Total.
You did not make it through your first month.
And that’s the whole problem in one picture: you are a quality system with a defect rate that would embarrass a widget factory.
Be honest with me now. No, sorry, be honest with yourself. Three thousand lines of diff, at 17:40 on a Friday afternoon, your pals already holding your beer for you in the bar down the street. What are you actually doing when you scroll through that? You are pattern-matching for scary-looking things. You are checking that it looks like code you would have written. And then you approve, because it does look like that, because the model is very, very good at producing code that looks like code you would have written.
That’s not a quality gate. That’s a vibe.
The interesting half
My guy with the folded arms never gets to this part, because he is too busy with the wrong half of the question.
“Push – to where?” That’s the wrong half. To where is the boring half. Master, staging, production, the moon – a destination is just a place, and the least interesting thing about the whole trip. Nobody, not a single person in that room, has ever once asked me the interesting half.
Through what.
Through what does the code pass? What exactly happens between me telling the agent “go” and a paying customer clicking the thing? That’s the important part of the question.
For you, at 17:40, your beer warming up, your code passes through exactly one checkpoint on its way to your CI pipeline. It passes through you.
Let me show you what it passes through for me.
What I actually have
A short version is: a ton of orchestration – about fourteen hundred lines of it – and it is not a prompt. It’s a pipeline. It’s a carefully crafted and refined workflow – my code printing machine, if you want – that makes me trust my agents every time the way you would trust any senior on your team. Actually, a lot more than you can ever trust any human, senior or otherwise.
The long version has three acts, with a lot of devils in the details.
It refuses to start blind
It reads the spec and cuts it into units – the smallest pieces that can be built and tested alone – then lays them on a dependency graph, so whatever must exist first is built first and pieces that never touch build side by side. If the spec is too vague to become a test, it stops and tells me. It does not guess.
Then, before a line of real code exists, it settles the mocking strategy: for every piece, what gets mocked and where. That is the same thing as deciding, deliberately and up front, what can be tested in isolation and how – not something you improvise later, when a test turns out to be a pain to write. Only then does it write a skeleton: code with the exact right shape that does absolutely nothing – a remote control with every button already molded in, power, volume, channel, all of them labelled and in the right place, and nothing behind the plastic wired to anything yet. And before a single line of logic exists, it reviews that skeleton. Not just the two easy questions – is the shape clean, can the tests grab hold of it. The hard one: does this thing actually match the spec? Is it the right remote – every button the spec asked for, none it didn’t, each where it belongs, so that all that is left is to wire them up? Because a flawless skeleton of the wrong device is the most expensive kind of wrong: every test you then write sits on top of it, faithfully checking the wrong thing.
It builds, then re-proves everything
Now it builds, piece by piece, in the order the graph demands – and this is where “red then green” gets far too soft in most people’s hands.
Red first: write the test, run it, watch it fail. But not any failure will do. A lazy agent can turn a test red in one second – Assert.IsTrue(false, ''), done, it fails. Technically red. And utterly useless. It satisfies the letter of “red first” and murders the whole reason for it. My red has to fail for one exact reason – and “the behavior is not there” is far too lazy a way to say it. I want it far more precise.
Every honest test has three parts. GIVEN: the world as you set it up, before anything runs. THEN: what must be true once the thing under test has done its job. And those two are in tension: a gap between the world at GIVEN and the world at THEN. Exactly one thing is ever allowed to close that gap: the WHEN, the behavior itself, the button actually doing what it exists to do.
So point the test at the skeleton. GIVEN is set. The THEN waits, holding its assertion. The WHEN presses the power button – and on the skeleton that button is wired to nothing. The WHEN did nothing. The tension between GIVEN and THEN sits there untouched. And so the THEN fails on its assertion. Not on a crash. Not on a compile error. Not on a rigged false. On a real assertion, because the behavior that was supposed to close that gap never ran. That is the only red worth trusting.
A test that reaches red without a real GIVEN and a real THEN – one that just asserts false and goes home – is vacuous, and I trust it exactly as much as it deserves, which is not at all.
You could say “duh, Vjeko, this is obvious.” Fair enough. Now go back to your test suites, comment out all your WHENs, run all the tests, then come back and tell me how many of those tests still went happily green. All those tests that did are vacuous. They prove nothing at all.
And catching tests that fail on missing or wrong assertions is not left to my good faith. One step in this workflow is a sub-agent that does nothing else – a fresh reviewer, laser-focused on this single thing and blind to everything around it – whose whole job is to hunt the vacuous reds down, call out every one, and refuse to let the red stage pass until every test in the suite is failing for the right reason: on an assertion, because the behavior is genuinely missing.
Green next: write the smallest code that wires that one button up for real.
And the part I trust the most? It goes further than just a simple red-green. In the red stage the agent may touch the test and nothing else – the code under test is off-limits, frozen. In the green stage the agent may touch the functional code and nothing else – now the test is the frozen half. Neither is ever allowed to reach over and quietly adjust the other. So a green cannot have passed by softening the test, and a red cannot have failed by rigging the test to a wrong answer. I do not have to trust red on its own, and I do not have to trust green on its own. I trust the pair, precisely because each was built with the other half locked in a drawer.
Refactor: clean it up, behavior unchanged, still green.
It does not re-run the whole suite after every small change – that’s theatre, even at machine speed. It runs at strategic points, and in full before anything is allowed to call itself done, to prove what matters: not just that the new tests pass, but that every test that passed before still passes now.
And then the last proof: integration tests. Every mock that held a piece in isolation comes out, the real pieces are wired to each other, and they have to work together for real – because a hundred pieces that each pass alone can still lie to each other the second they are forced to talk.
It tries to prove itself wrong
Also, there is no one “review agent” in my workflow. There is a fleet of them, and every one is a fresh agent with an empty context – no memory of writing the code, no pride in it, no fatigue – each one pointed at exactly one thing and blind to everything else. One does nothing but check the code against the spec. One does nothing but check that the tests test what they claim. One cares only about coverage. One only hunts security holes. Each carries its own checklist and is sent in hell-bent on failing anything that does not truly satisfy it – adversarial on purpose, but honest, because its goal is not to fail code; its goal is the same as mine: to make sure the product is of high quality. Every complaint goes to a fixer, which makes the smallest change that resolves it. Then only what has to run, runs again: the fix, the tests that prove the code is still green, and eventually the full suite, to catch any regression the change could have set off somewhere else. Not the plan. Not the mocking strategy. Not a rebuild from the first line – none of that gets torn up over one finding. And then the reviewers come back for another look, because nothing here calls itself done until a whole round of them finds nothing left to fix. When even that cannot fix something after a fixed number of tries, it stops and involves me.
And probably the most important part about my reviewer panel is where it sits: not at the finish line, but scattered along the process, at the earliest place where a review makes sense, a line of checks that has been running the whole way down. Nothing here moves on until the stage before it has passed the necessary checks – the plan before anything is mocked, the strategy before anything is skeletoned, the skeleton before a single test is written, the vacuousness check before it is allowed to count as red. The ones that need real judgment rather than a compile are dedicated reviewers, fresh agents with nothing else to do: the skeleton has some, the red has some, the finished code has a whole panel. Review is not a phase that waits at the end. It is the mortar between every two bricks.
And every one of those checks is small on purpose. A fresh agent, a narrow prompt, the minimum it needs to judge its one thing and not a byte more. Sounds like it must burn a fortune in tokens – a dozen agents where the lazy way would use one. It does the opposite. A dozen sharp little prompts, each seeing only what its job requires, cost less and catch more than a single overloaded agent dragging the whole project through its context window until it fills up and starts quietly compressing away the exact detail the bug is hiding behind. Small and fresh beats big and drowning, every time.
That is the spine. Not one of those gates proves much on its own. A single passing test proves almost nothing. A clean skeleton review proves almost nothing. One reviewer’s thumbs-up proves almost nothing. I trust each of them only a little. But they do not fire sometimes, on a good day, when somebody remembers. They all fire, every time, in order, and each one lays its own thin layer of confidence on top of the one before. Thin layer on thin layer on thin layer, and what you finally get to stand on is thick. That is the whole difference between a machine and a vibe: one agent and a hopeful prompt gives you a feeling, and a hundred gates that all run every single time give you a floor.
Every stop is a sigma
None of this came from a whiteboard. Every rule in it was earned the same way: the machine hit a failure I had not foreseen, stopped, and made me look at it.
Early on, that enraged me. It would block on something small and hand me the fix in the same breath – one line, obvious – and I would sit there thinking: if you know how to fix it, then why do you involve me?
Then I understood what the stop was really telling me. Not “here is a bug” – half the time the agent could see the one-line fix as clearly as I could. The stop meant the machine had just produced a whole kind of failure it was never built to prevent. So I never encode “if you know how to fix it, just fix it” – that hands the agent a licence to paper over every future case with whatever it happens to guess. And I do not reach in and patch the one bug myself either, because fixing them one at a time is inspection by another name – the squinting guy again, catching defects instead of preventing them. I ask the only question that pays: why did the machine let this through at all? I find that root cause, and I change the machine so it can never produce that kind of failure again. Patch the instance, and you have fixed one thing. Kill the root cause, and you have fixed it forever, in every run still to come. That is a sigma. One more nine to the right.
So a stop, now, is the best thing that happens in my day. It does not mean something broke. It means the machine snagged on a class of problem I had never seen – the small stuff is all encoded and handled, so a stop that survives all of that is genuinely new. I do not sigh at it. I lean in. It is one more sigma waiting to be built, and once I build it, it never stops me again.
So, back to you
The push was never the risk. The risk is what is behind it, and when you review every diff by hand, there is nothing behind it. No pipeline, no gate, no rule that outlives your attention span. Your answer to “through what” is “through nothing” – just you, tired, standing at the end of the line. You are not being careful. You are squinting at widgets.
The cruel part is how much it feels like discipline. You looked, didn’t you. You read the diff. But looking is not a gate, and reading is not a rule, and a thing you do a little differently every time – depending on the hour – is not a process. It’s a ritual.
So here is the only question that counts. Go and look at the last diff you approved. Then name the rule you applied to it that made you approve it. Out loud, one sentence, the way you’d say it to a junior.
Can you name it? Good. Then why in the earth is it living in your head, where it gets tired at 17:40, instead of in your pipeline, where it never would?
And if you can’t name it – what exactly were you doing when you clicked approve? 🤔
