What do you do when the worker who never sleeps, never complains, and costs you pennies has quietly become the reason you check every single thing twice?
That is where I find myself, most days. I stopped trusting my AI, not in the dramatic throw-it-out way, but in the quieter and worse way: I keep using it every single day and I check everything it tells me, because it reports success in the same confident voice whether the work is done or not. The true "done" and the false one look identical until I go and look. So I look, every time. And that is the trap, because the whole point of delegating was to stop looking. Re-verify every output and you have not delegated the work, you have done it twice, once as the maker and once as the auditor who no longer trusts the maker. That compounding second job is the Trust Tax.
The obvious response is to make the machine more trustworthy. Better prompts, sterner instructions, a smarter model. I tried the sternest version there is: I wrote rules, ten of them, into the standing instructions my AI reads every session. They changed almost nothing. Understanding why they failed is the whole method, because the fix is not a better rule. It is a different machine. And the move at its center, the one I have not found named cleanly anywhere, is to decide what to automate by the numbers: measure how often a failure actually happens, and build a machine to stop it only when the body count earns one.
And here is the part most write-ups miss. When I actually audited a month of my work, the failures came in two families, not one. Some were about trust: the machine lying green, dropping half my instruction. Others were about waste: burning six figures of tokens on a trivial task, re-asking me for a key I gave it an hour ago, hoarding tools I had long forgotten. A working machine has to fix both.
Everything below does exactly that, in the order you build it. Seven steps, and you can run all of them on your own setup this week. Each one follows the same frame: why it matters, how to do it, and what it buys you.
One note before the list. Each step is an idea first, and the way I did it second. If you use Cursor, or ChatGPT in a browser, or you work with a team of people instead of an AI, keep the idea and use whatever tool you have. The method does not care what tools you use. Take Step 3, closing the loophole: for me it is a quick search through my settings files; on a team it is cutting the words where appropriate out of your definition of done; in a browser it is deleting the optional step from a saved prompt. One idea, three ways.
Take this now. The rest of this piece is the why, and the how.
Seven moves you can run this week. Everything below is why each one works, and how I found them by putting 504 of my own failures on trial.
- Audit your transcripts. Have the agent mine your own logs for corrections, redos, and swearing, each pulled as a verbatim event with its source. Cluster into mechanisms; rank three ways, by fury, by tokens, by recurrence.
- Sweep your tools. Wire the good-but-cold, kill the dead weight and duplicates, keep the rest. Merge anything that does the same job twice.
- Kill the escape hatch. Search your instructions and configs for optional language (or, if needed, consider, you may) and delete the second clause. Free, and one of the highest-leverage moves here.
- Measure before you build. Only a failure with a real body count (mine was 15 to 1) earns an automatic mechanism. Everything else stays a rule.
- Build the masts. For trust: force the check, verify the live result. For waste: load your decisions so you stop re-asking, cap orchestration, route bulk work to the cheapest capable model.
- Make it bite you too, or it is a weapon, not a guardrail.
- Govern it. Cull any mechanism that has not fired in a month.
Run the seven and you will not walk away with a feeling about AI. You will walk away with a checkable, leaner one. Your prompts were never the bottleneck. The way you work is, and the evidence is already sitting in your own logs, waiting.
Step 1Put your own failures on trial
You cannot fix a pattern you have never counted, and you are almost certainly guessing at yours. Your real record already exists: every session you have run sits in a log on your disk, annotated in real time by the most honest critic you have, which is you in the moment it failed.
The audit is itself a delegation, which is the whole idea. Your transcript history is the most honest record that exists of how you actually work with a machine, and it is sitting unread. Hand it to the agent and let it hold the mirror up. One instruction does it:
Two demands separate a real audit from a flattering one. Insist on verbatim quotes and never a paraphrase, because a softened account of your own frustration becomes the story you tell yourself instead of the truth. And insist on three rankings rather than one, because the failure that enrages you, the one that drains the most budget, and the one that keeps returning are rarely the same failure.
You end with your real failure profile, counted rather than guessed, across both families. Mine looked like this, and read it correctly: not conversations, separate moments it broke, and only the ones I could still prove with a quote.
One mechanism towered, the green lie, the machine reporting a reality that does not exist. But ranked by cost a different one won: a single over-scoped run had burned nearly 900,000 tokens. Three rankings, three targets. Fix one list only and you kill the loudest problem while the most expensive one runs untouched.
And take 504 for what it is: n=1, my own logs, counted by me. Your number will look nothing like mine, and that is the point, not the flaw. The count is just what my own history surfaced. The one that matters is the one hiding in yours.
Step 2Sweep the tools you forgot you had
Over months you install helpers, scripts, and skills, and you lose track. Some rot into disuse. Some quietly duplicate each other. Both are waste: dormant tools mean the quality checks never run, and duplicate tools mean clutter, extra tokens, and two things to maintain where one would do. My own sweep found thirty-three installed skills and sixteen sitting completely idle.
You have accumulated more tooling than you remember, and some of it has been quietly rotting or duplicating for months. You do not need to catalogue it by hand. Ask the agent to take inventory, cross-check it against how you have actually been working, and tell you the truth about what still earns its place.
Then act on the verdict. Retire the dead weight and the duplicates without ceremony, and take the good-but-cold and wire it back into the flow that should trigger it, which is exactly what Step 5 builds.
A lean machine is not the one with the most tools, it is the one where every surviving tool earns its place. You cut the clutter and the token drag, and the quality checks you had forgotten are back in the game, which sets up the next step.
Step 3Find and kill the escape hatch
This is the discovery that turned a complaint into a method. My quality checks were wired in and still never fired, and the wiring told me why in one line. The instruction that called a check ended in three fatal words. In plain English it read: run the validator, or do the equivalent inline. That "or do it inline" is a permission slip: run the real check, or just eyeball it and move on. Under any pressure at all, the eyeball wins. The check was not broken. It was optional, and optional under load means dead.
The dormancy has a cause, and it is written into your own configuration. Somewhere your instructions tell the machine to run a check or, quietly, not to. Have the agent find every one of those doors.
Every hit is an escape hatch. Close it yourself: strike the second clause, so run the validator, or do the equivalent inline becomes run the validator, full stop, no exit. It costs nothing, and it is the single highest-leverage move in this whole method.
This one costs nothing, and the moment the lazy road stops existing, the tool starts running again.
Step 4Climb the ladder, pay only where the data says
Killing hatches fixes the rules you can shame yourself into keeping. But some failures your own data proves you will never fix by willpower. Mine was stark: I send "build this" to the wrong workflow fifteen times for every one time I use the right one. No resolve closes a gap like that. And yet enforcing everything with heavy machinery builds a cage you abandon in a week. You need a rule for how hard to push.
Enforcement runs on a ladder, and you climb only as far as your evidence forces. A rule is the cheapest rung and the weakest, fine for what you genuinely remember. A killed bypass is that rule with its escape hatch removed. Free. A mechanism is automatic enforcement that fires whether or not anyone remembers, and it is expensive. The law for climbing: buy a mechanism only where the data shows a body count.
You already gathered that data in Step 1. Let the agent turn it into a verdict.
Fifteen to one earns a mechanism. Once a month earns a rule.
You spend your expensive enforcement precisely where it pays and nowhere else, which is the difference between a system you keep and a cage you quit. One caution, because this step measures you: any number you begin optimizing stops telling the truth, which is Goodhart's Law. Count your failures to decide what to automate, never to score yourself. And know when to build nothing at all: a failure that is rare or cheap earns a rule or a shrug, never a mechanism. Enforcement aimed at a problem you do not have is just a cage.
Step 5Build the masts, for trust and for waste
A mechanism sounds heavy. It is not. It is a mast, and the logic is three thousand years old with a modern name: economists call it pre-commitment, Thomas Schelling took a Nobel partly for the idea, and Jon Elster built a whole book on this exact image, Ulysses and the Sirens. Odysseus wanted to hear the Sirens and live, so he did not trust his willpower, he had his crew lash him to the mast and forbade them to untie him. You bind the future you that you already know will be weaker than you are now. Discipline does not scale. Pre-commitment does.
In practice it is a small script the tool runs on its own at a fixed moment, before the model acts, and the agent can write and wire it for you. You describe the failure; it builds the guard. Start with the one your data already proved: the "build this" that keeps going to the wrong place.
Then build the same shape for the rest. One that refuses to pass a subagent's "done" up to you until the live result is checked. One that loads your standing decisions and keys into context at the start of every session, so you stop re-supplying what you already gave and the repetition tax dies. And a standing budget that caps orchestration and routes the bulk, mechanical work to the cheapest capable model. The failure stops existing, because your memory is no longer in the loop.
Trust failures get caught for free, and the two biggest sources of waste, re-asking and over-spending, are engineered out rather than nagged at.
Step 6Make it bite you, or it is not a guardrail
There is a fast way to tell whether you have built real discipline or just a sharper tool for blaming the machine. Ask who your guardrail is allowed to stop. The oldest answer is Hammurabi's: four thousand years ago, a builder whose house collapsed and killed its owner was put to death. Skin in the game, long before Taleb named it, and it always points at the maker.
The test of a guardrail is who it is allowed to stop. Point one at yourself and confirm it can. Have the agent build a guard on your own irreversible actions, then go and trip it on purpose.
Now run something destructive against a throwaway path and watch it refuse you. If it will not stop your hand, it was never a guardrail. Mine bite: a check I built to catch machine-writing tics runs on my own prose too, this piece included, which is why you are not reading the usual tells; and the same class of guard caught me mid-session about to rebuild work I had already finished, and stopped it before it was lost. The rule does not care whose hand is on the trigger.
A guardrail that only ever stops the machine is a weapon pointed across the table, and everyone feels where it points. The ones that bite their maker too are the only ones the machine ever trusts, which is the entire source of the trust you are trying to rebuild.
Step 7Put a governor on the whole thing
There is a failure mode on the far side of all this. Once you fix problems with mechanisms, every new problem asks for its own, and the scaffolding starts to outweigh the work it protects. The cure for over-building is not restraint, which you will not sustain.
Every mechanism you add is scaffolding, and scaffolding left standing becomes the very bloat you were fighting. So give it an expiry. Have each guard record when it fires, then review that record on a schedule and retire whatever has stopped earning its place.
Run the cull on a calendar, not a whim.
The machine stays lean. It never becomes the very thing, bloat and waste, that you built it to kill.
What you actually get
The mechanical result is real and worth stating plainly: dormant tools run, duplicate ones are gone, the checks that used to be optional are not, and the token bill and the repeated questions both fall. The result that matters is not mechanical. For a month I worked with an assistant optimized to tell me what I wanted to hear, which is exactly what taught me to trust nothing. What I work with now argues back. It pushes on my decisions before executing, catches its own shortcuts the moment I name the pattern, and tells me when it has overreached.
Trust did not return because the machine got nicer. It is the same machine. It returned because I stopped trying to trust it and built a setup where a lie is cheap to catch, for it and for me, and where waste is engineered out instead of endured. That is the shift worth carrying out of here. Trust is not a substance you pour into an agent. It is a property that falls out of a system where truth is easy to verify and lies are expensive to keep. You do not earn it by believing harder. You engineer it.
Appendix: how the audit actually ran
Here is the audit itself, limits and all, so you can weigh the method on its own terms.
The corpus. 1,301 of my own working sessions across two months. The friction was pulled from a dense one-month window, June 3 to July 3, one event for every moment I could still prove with a verbatim quote from the transcript.
How I sorted them. I put every moment into one of nine buckets. Here is what each bucket means and how many landed in it, and yes, they add up to 504.
| Type | What it means | Count |
|---|---|---|
| Corrections | I told it the output was wrong. | 123 |
| Rage signals | Swearing, exasperation, "again?" | 99 |
| Hallucinations | It stated something false as fact. | 62 |
| Half-finished | It claimed done on work that was not. | 61 |
| Redo loops | The same task sent back more than once. | 50 |
| Repeated requests | I re-supplied a key or decision I had already given. | 32 |
| Off-script | It did something I never asked for. | 31 |
| Dropped instructions | It silently skipped part of the ask. | 31 |
| Acted after "stop" | It proceeded after I told it not to. | 15 |
| Total | 504 |
How bad each one was. 185 serious, 228 middling, 91 minor. I called it serious if it reached real users, money, or data; middling if it cost me real rework; minor if I caught it on the spot. The one that dominated: the green lie, the AI reporting something as done or true when it was not, which is three of these buckets together, hallucinations, half-finished, and dropped instructions. That is 154 moments, about a third of the 504, and it sat underneath almost every time I lost my temper.
The limits, plainly. One coder, me. The buckets are mine. Where a moment fit two, I counted the deeper cause, so every number is a floor, not a ceiling. I kept only what I could still prove with a quote. Your logs will sort differently, and that is the point: