The AI Co-Pilot · Part 2 of 7
Never Accept First Output
In short
- A reviewed, above-threshold first draft still held eighteen confident errors, because the review checked flow, not sources.
- The cycle is plan, review the plan, execute, review the output, learn, and the learn step feeds corrections forward.
- Gates were added after real failures: a claims audit after the eighteen errors, a jargon audit after jargon leaked.
- 18confident errors in the first post's first draft
- 7.91 → 8.55plan score after a mandatory second review cycle
- 8.12score of the rerun that started from the corrections
Why AI confidence is a trap
Language models are fluent. That is their strength and, on complex domain work, their risk. Fluency and correctness feel identical unless you are already an expert, which, for most of what I use AI for, defeats the point somewhat.
Here is how it happened. An earlier assistant and I had worked from a slightly wrong understanding of feed-in pricing: whether network charges were in the export rate, and which way the accounting sign ran. That went into the project knowledge base. When I scheduled overnight drafting, the agent read the knowledge base, used the framing and wrote two thousand confident words on it. The same framing was there when I scheduled several posts at once, so it went into several of them: hours of downstream work that all needed redoing.
The reviewers read the drafts and passed them. Their metric had no check for sign convention on feed-in values, because the error wasn’t known yet. Everything was self-consistent inside the knowledge base. The numbers added up and the reasoning flowed. It was just wrong.
That is a failure of review architecture, not of capability. The panel was asking whether the draft was well written and coherent. It was not asking whether each number traced to a source and used a consistent sign. A panel is good at the first question. The second needs a different structure.
The cycle
After the corrections, I added a hard rule to the knowledge file:
Never accept the first output. Plan, review, execute, review, learn.
Each step is mandatory for any non-trivial work.
- Plan. Before building, write down the inputs, the success criteria, the risks and the metric the output will be scored against.
- Review the plan. Run a structured critique against it. Iterate until it passes.
- Execute. Build to the reviewed plan.
- Review the output. Same panel, same metric. Below threshold means iterate, not ship.
- Learn. Record what worked, what failed and what the metric missed. Update the metric if it proved inadequate.
Step five is what separates this from ordinary iteration. Most people iterate until the draft is good enough. The rule insists you also feed the lessons forward, so the next blog post or dashboard starts from everything the previous runs learned. If the fifth run of a task isn’t better than the first, you don’t have a quality system. You have a hamster wheel with extra steps.
The review panel
The review is a panel of five reviewers, each with a focus: a structural analyst for thesis and flow, a communicator for voice and pacing, a domain specialist for technical precision, a sceptic for over-claims and unshared assumptions, and a futurist for missed opportunities.
The communicator carries the most weight, because voice is what makes this blog different. A precise post in a generic AI voice is not what I want to publish. A slightly imprecise post in the right voice can be fixed. Flat prose can’t be fixed without a rewrite.
The sceptic is hardest to make work and matters most when it does. AI reviewers share the drafter’s knowledge base, so they share its framing, including a wrong sign convention. A sceptic that isn’t genuinely adversarial is a communicator in different language. So I brief it per task. For blog content: assume the reader has never heard of this project, doesn’t know what Home Assistant is (the platform that runs my solar, battery and heating), and will Google the first number they aren’t sure about. That changes the question from “is this correct within the project’s frame?” to “will a stranger believe this, and should they?”
What the panel can’t catch
The panel finds structural, clarity, evidence and voice problems, the errors visible from the text.
It can’t catch errors that sit upstream in the knowledge base. None of the five reviewers knew that my retailer’s feed-in field was negative for earning. Why would they? That knowledge lived only in me, and I hadn’t recorded it correctly.
That is an honest limit. A quality process built on AI reviewers has a blind spot for errors invisible from the text but visible from the sources. Any check that needs you to step outside the text and look at the data has to be explicit, mechanical and logged, not left to a reviewer’s judgement.
The quality metric
Different tasks need different metrics. What works for a blog post is useless for judging a dashboard. Over time you end up designing metrics for the tasks you repeat.
For blog posts, the metric weights three things: efficacy (does it do its job), reach (will it find and hold its audience) and readability (is it well crafted). Before any score is calculated, a draft has to pass three gates. One fail sends it back for rewrite, whatever it scored.
Editorial safety. Hard pass or fail checks that keep the blog to what it is: a personal project about my house, my journey with AI, and what it opens up.
Claims audit. Every number must trace to a verifiable source. The reviewer picks five claims at random and traces each to its source: a spreadsheet column and date range, an invoice, a named data entity. All five must hold. This gate exists because the panel passed the first post with eighteen errors: it was judging quality and flow, not traceability.
Jargon audit. Every technical term is explained on first use or replaced with plain English, every acronym expanded, and no internal shorthand reaches the reader. The target reader for this check is a smart non-technical person: knows what solar panels are, has never heard of a home automation platform, and has no idea what “feed-in tariff” means without being told. The check is mechanical on purpose. AI reviewers immersed in a project are terrible at spotting jargon, because it is invisible once you know what it means.
What the eighteen errors looked like
They fell into five groups.
Sign convention errors (several). The data source treats export revenue as a credit, so negative means earning. The drafts treated positive as earnings, and the whole framing of “what did I make from exporting solar?” was backwards. This is the worst kind: internally consistent, apparently coherent, completely wrong, and invisible to anyone not checking the source.
Wrong causal attribution (one, but significant). About ninety per cent of my peak-window spend goes on a cooker wired to the grid side of the battery, so the battery can’t intercept it however clever the automation. The draft blamed battery depletion. That was plausible, fit the narrative, and was wrong. The cause is structural and software can’t fix it. The cooker has to be rewired.
Rejected predictor (one). Solar output on a given day correlates weakly with the battery’s charge at seven the next morning, because clear days tend to follow clear nights. The draft used that as a prediction hook. It is an artefact you can’t reliably act on, and you shouldn’t encourage readers to try.
Overclaims (several). Estimates presented as confirmed figures. A four-month window presented as an annual conclusion. A summer and autumn pattern extended to winter, where the arithmetic reverses.
Sign-on-sign errors (a few). A wrong-way feed-in value with a second calculation built on it, so that the two errors cancelled in some presentations and amplified in others.
All of them are invisible to fluency. The prose around them was fine, and given the wrong inputs the argument was coherent. Only a reviewer tracing numbers back to their origin and asking “is this actually true?” would catch them. That is what the claims audit is for.
The rerun
After the corrections, I wrote a brief that folded every correction into the starting conditions for the seven remaining posts: the sign convention, the right cause of the peak spend, the rejected predictor, the seasonal caveats. Every drafting agent read it before producing anything.
The post on feed-in economics was redrafted with the right sign, reviewed again, and scored 8.12, clearing every gate and threshold.
Nobody got smarter between runs. The mistake was captured and fed forward, so the task started from a higher baseline. The metric works the same way. The claims audit was added after the first post and the jargon audit after jargon leaked into later drafts. Each version covers more because each was changed in response to a real failure, not a theoretical one. The metric isn’t designed in advance. It is discovered by running it.
The second cycle
When I reviewed the plan for the energy series, two review cycles lifted the score from 7.91 to 8.55 out of 10. That is the difference between a working draft and a strong one.
The first cycle found three things: a truncated handoff sentence, an unexplained piece of jargon, and a word-budget problem. The second fixed them. That gain doesn’t come from working harder on the first cycle. It comes from having a second cycle at all, which only happens if the process requires one.
That is why it has to be a hard rule and not a guideline. The first draft usually feels good enough. Fluency does that. The only defence is a rule that says you always do the second cycle, not one that says you do it when you’re not satisfied.
The point
The first draft is free. It is also unreliable, and the confidence of the prose tells you nothing about the reliability of the claims.
The cycle, the metric, the panel, the gates and the learning step are what turn a fluent first draft into something you can stand behind. Building them takes longer than building any one draft. They compound. The draft does not.
By the fifth blog post, the brief starts with all eighteen errors already ruled out, with three gates that didn’t exist then. The first draft had eighteen errors. The rerun, starting from the corrections, passed every gate. The machinery built in between made the difference.