Justin Jorgensen
The Debrief

The Debrief · Build

AI Output Is Cheap. Proof Is Expensive.

Generating text is nearly free now. Trusting it is the part that costs you. Lessons from rebuilding WriteAssist around the question almost nobody asks: did anyone check the AI?

An old balance scale in a dark library, one pan heaped with loose pages, the other holding a single sheet that weighs more.

Right now, somewhere near you, an AI is writing something that may well ship without anyone checking it.

A function. A contract summary. A board update. A chapter. The writing got cheap, and somewhere in that drop the checking quietly fell off the table. That is the real risk of this moment, and I walked straight into it with my own tool.

WriteAssist made one promise louder than the rest. An em dash could not reach the page. The tool would physically stop it, no polite line in a prompt that the model forgets by the next paragraph. I believed that promise. I had written it myself. Then I ran a test built to break it, and there it sat in the file, one em dash, calm as you like.

The enforcement was on the wrong hook. It ran after the write had already landed on disk, so it was writing up the damage after the fact, a guard posted one step past the door he was meant to block. I moved it to the event that fires before the write executes and added a second scanner for writes that come in through the shell. It blocks both ways now, and I have the runs that show the block landing.

That small bug is the whole point. I am careful. I test things for a living. And I still shipped a guarantee that was quietly false, and I only found out because I went looking. Most of the AI-assisted work I have seen ships without a test like that ever being run. So the question worth your time is not whether the AI is good. It is how you make AI work you can actually trust, and what that trust costs you. Rebuilding WriteAssist from a writing helper into a real platform on Claude Code taught me five answers, and they carry over to anything you build with these tools.

The first is to put the rules you care about into the tooling, where the model can't reach them. WriteAssist runs its rules as hooks now, firing before a write, after a write, and on every prompt, so the constraints stay in front of the model the whole way through. Policy says don't. A hook says can't. A rule you type into a prompt is a request the model can argue its way out of on the next pass. A rule wired into the harness is one it cannot cross. A hook is blunt, though. It matches characters and paths and banned words. It goes quiet the moment the problem is a sentence that is fluent and wrong, and for that you need the other four.

The second is to give every agent the least it needs and nothing more. WriteAssist reviews each chapter with a panel of critics, one for continuity, one for voice, one for pacing, one for the rules, and every one of them is locked to read-only. A critic that can quietly rewrite what it reviews is no longer a critic. Same reason the auditor doesn't sign the checks. The moment one agent both does the work and blesses the work, you have no review, just a nice story about one.

The third is the one most people skip. Verify against reality, not against the agent's report of itself. When I wanted to know whether a critic actually stayed read-only, I checked what it was allowed to touch. A model will happily tell you it followed the rules. The filesystem just shows you the truth. If a claim matters, look at the thing itself instead of taking the summary.

The fourth is to point something adversarial at your own claims before the world does it for you. I handed the whole architecture to Codex, OpenAI's GPT-5.5, and told it to tear my claims apart. It found four places where I had said the system did more than it actually did. I fixed all four before any of it shipped. A reviewer whose only job is to catch you being generous with yourself is worth a lot, and a rival model has no stake in your ego.

The fifth came out of the fourth. Cut your own marketing language the second it outruns the truth. I had been calling a file "unwritable." After testing, that became a narrower, precise guarantee I can defend in a room full of skeptics. The loud version felt better and was slightly false, and slightly false is exactly the thing that gets you caught later.

None of this is free, and pretending otherwise would be its own unchecked claim. Verification is slow and it is not cheap. On a short demo chapter, a full pass put about a dozen agents over the text and burned roughly 170,000 tokens in about three minutes. A real chapter runs several times longer and costs more, so you don't run this on every keystroke, you run it at the gates that matter. The hooks catch the mechanical and miss the meaning. The critics raise false alarms you clear by hand. And none of it removes the human. The whole apparatus does one job. It narrows where you have to look, from the entire draft down to the handful of places something actually went wrong. That is the real product. Not certainty. A much shorter list of things to check yourself.

Once those five were working, I pointed the platform at the problem people actually have. Most writers are not stuck at a blank page. They are stuck halfway, with a draft that has started to fight itself. The first time I turned the review panel loose on my own book, it taught me this the hard way. It kept failing chapters that were perfectly fine. My old story notes said the family had left the city and never come back. The prose said they stayed through every flood. The panel was dutifully grading good chapters against bad notes and crying foul. It was right that something was wrong and wrong about what. That false alarm is the reason the import feature exists. It reads a half-finished draft, reconciles the facts across every chapter, and when the draft fights itself or fights your old notes, it surfaces the conflict and asks you which version is true, with the options laid out. It never silently picks.

I tested it the only honest way I could. I built a small three-chapter draft and planted four contradictions in it: a brother who is there in chapter one and gone by chapter two, eyes that change color between chapters, a family that flees the city in one and weathers every flood in another, and a fact that directly fought the old notes. It caught all four, and it surfaced two more I had written by accident and forgotten. It also over-counted once, splitting a single question into two separate flags, even labeling them entangled before listing both anyway. That is one rigged test on a draft built to be caught, not a proof, and I would not sell it as one. It still misses what a careful reader catches. What it does reliably is find the seams, and on a book-length project, finding the seams is most of the work.

The model is the easy part. It gets better on its own every few months, free, while I sleep. The checking never does. The discipline of making the work prove itself is human, it is slow, and it is the whole difference between AI output you can stand behind and AI output that embarrasses you three weeks later in front of the one person who read it closely. That holds for a chapter, for a deploy script, and for this article. The value was never that a machine could produce it. The value is that someone made it prove itself before it reached you.

WriteAssist is public and MIT licensed. Around 5,500 lines, 16 tool-isolated agents, 9 skills, 5 dynamic workflows, 6 hook events. It's the platform behind a book I almost didn't write, and the story of why I built it at all is a different one.

Justin Jorgensen

Infrastructure and operations leader with 25+ years across government, financial services, and construction. I write about judgment, AI, and building things that last.