AI Verifies, Humans Write: One Engineer Tested Both Directions

Four human reviewers, all experts in the system being described, read Colin Breck’s academic paper and missed a notation error in one paragraph. The AI he was using to check his paragraphs found it.

Breck, an engineer, describes the paper in a September 2026 post titled I Don’t Want to Read What You Didn’t Write. His summary is blunt: “I used AI extensively and it made the writing process faster and more enjoyable. But AI did not write a single line of the paper.”

The common default runs the other way: the model drafts and a person reviews. Breck ran both arrangements on the same material, and his report on the second one is the reason this post exists. Asking the AI to write a paragraph from the context he had provided “was never valuable. Not once. It was consistently unpleasant to read, and often inaccurate.”

One paper and one author is a small sample. He presents it as his own experience, with no rule for anyone else. The asymmetry is still sharp enough to act on.

Same context, two directions

The setup matters because thin context is an unlikely explanation for the drafting result. Breck gave the model a great deal of it: “the journal style guide and LaTeX template, all papers previously published in the journal, the source code for the software systems I was writing about, and the configuration, logs, and metrics for production deployments of the software.”

With that context loaded, he used the model as a checker. “After writing a paragraph, many times I would ask the AI to ensure what I had written was correct by referencing the source code or configuration, or examining production logs or metrics.” He kept writing while it worked, “often moving on to the next paragraph while the AI verified the previous one. It helped me spot important omissions and inaccuracies.”

Citations were handled the same way, as a mechanical task delegated with a placeholder. A footnote gives the pattern: “I would write: {TODO: reference the Amazon Aurora paper} and the AI would take care of the rest.”

Then he reversed the direction. With the context he had provided, the task became describing how something works from the source code. That is where the “not once” comes from.

He describes this as experience, not a controlled test. What makes it worth taking seriously is that he supplied the same context in both directions.

The exception that travels with the rule

Breck’s absolute sentence has a qualifier a few paragraphs later, in his own words. “What was the one thing the AI was incredibly good at writing? It wrote the abstract.” He calls it “the most terse, mechanical, inhuman part of the whole paper” and adds: “indeed, the most abstracted part. I included it entirely unchanged.”

So “not a single line” has an exception, and he names it himself. The practice he actually describes is narrower and more useful than the slogan. In his account, the model wrote the part that was already a summary of work he had done. The explanation that constitutes the work stayed his.

A policy built on his experience should carry that line. Summaries of human-authored material are fair game for generation. Original exposition is where drafting failed him every time he tried.

His blog follows the same division. “I also use AI as an editor for my blog. … But I only let AI identify errors or make suggestions. I don’t let it rewrite and change my voice or perspective.”

Why the drafts fail the reader

The piece’s underlying argument is about who holds the context. A generated paragraph can look useful to the person who prompted it, because that person assembled the source code, the logs and the intent behind the request. The reader assembled none of it. The words arrive without the understanding that made them feel right to the prompter.

My reading of why the checking direction works: verification inverts that flow. The human writes from understanding, and the model checks the claims against artifacts both of them can inspect: code, configuration, logs, metrics. A mismatch is a concrete finding, and the human decides what to do with it. The model never has to supply the understanding, only test the text against evidence.

This connects to an argument we made about verifiable AI output: output nobody can check shifts the burden onto whoever receives it. Breck’s arrangement keeps the checking inside the writing process, where the author can still act on it.

Oxide turned the preference into a gate

Breck’s post is descriptive. The one mandate on his page belongs to someone else. He reports that Bryan Cantrill “has gone so far as to mandate that all public writing at Oxide be reported by Pangram as human-authored.” Pangram is described on the page as “a model fine-tuned to detect AI writing.”

That is a control on output with an automated gate in front of publication. A writing preference becomes a check a document has to pass.

We have covered AI authorship as a measurable property, where detection served to count. Oxide’s rule uses detection as a condition for shipping. The page does not describe how the gate performs, what happens when a human-written draft is flagged, or how often that occurs, so those questions stay open. The structure is what matters here: a stated policy, a tool that enforces it, and a clear pass condition.

It also fits Breck’s split without contradiction. A team can let the model verify every paragraph, fix citations and find notation errors, and still require that the published prose read as human-authored. Verification, as he describes it, leaves the prose itself in human hands.

Where generation still has a place

Breck leaves room for generated text in one category. He names a controlled-language standard, ASD-STE100, and scopes it himself: it “isn’t appropriate for all AI-generated writing.” It “is specifically targeted at clear and easy-to-follow instruction manuals. I’m going to give it a try for installation instructions, runbooks, and similar documentation.”

That is a plan with no result yet. The category he picks is revealing. Installation steps and runbooks resemble the abstract more than the paper body: procedural, constrained and meant to be followed step by step. His exceptions cluster around text whose value lies in precision and brevity. His refusals cluster around text whose value lies in explanation.

For teams writing a policy, that gives two categories instead of one blanket rule. Software slop is what ships when the attention a piece of work needs is never spent on it. Generated exposition moves that deficit onto the reader.

Do this now

Pick one document type your team publishes externally and write down which direction AI is allowed to work in it.

For exposition (design documents, technical posts, papers, customer-facing explanations), make verification the default use. The author writes, then asks the model to check each section against the code, configuration, logs or metrics it describes. Record the omissions and inaccuracies it finds, since that record is the evidence the arrangement is paying off.

For summary and procedural text (abstracts, release-note digests, runbook steps), allow generation, and require that a human wrote the material being summarized.

Then decide whether the rule needs a gate. Oxide chose an automated one for all public writing. You may not need that, but you should know which of your documents would fail such a check today, and whether anyone would notice.

---

This analysis synthesizes I Don’t Want to Read What You Didn’t Write (Colin Breck, September 2026).

Victorino Group helps engineering teams set policy on where AI writes, where it verifies, and how that policy is enforced. Let’s talk.