Three specialists reviewed the same documents. Each found a different problem.

#ai #productivity #writing #codequality

Three specialists reviewed the same documents. Each found a
If you use an AI assistant for work that matters, you have probably noticed the review problem: the model that just wrote the thing is not well placed to tell you what is missing from it. Asking it to "check your work" tends to return the same reasoning a second time, in a more confident voice.

Here is a concrete alternative, from a real review inside our own project.

The setup

We had just finished three operational documents — the specs that govern our project's content, metrics, and monitoring work. They looked finished. Instead of accepting them on that impression, we ran a panel: the same three documents, read separately by three different personas, each with its own written specification and its own lens, each returning scored findings and an overall confidence. Recommendations only — the decision stayed with the human.

A persona here is not a costume. It is a written specification — role, expertise, explicit boundaries, communication patterns — that the assistant loads before it reads anything. Pointing three different specifications at one artifact is what produces three different kinds of attention.

Catch one — the rule that was never enforced

Fernand, the validator. His lens: does this artifact actually enforce what the standards claim? Top finding, scored 95.

We have a standing rule that public content must not name a specific framework recipe unless the workflow has verified that recipe ships in the current public download. The newly built content workflow did not contradict the rule. It just never implemented the check. Intention with no enforcement point.

If you write software, this is a familiar shape: the policy exists in the README, and nothing in CI asserts it. The fix was to put the gate inside the workflow itself.

Catch two — the reconciliation with one side

Cat, the orchestrator. Her lens: does the process hold together end to end? Finding scored 82.

Our weekly reliability review compares what the automation actually did against the expected schedule. Nothing anywhere wrote the expectation down. One side of the comparison lived on disk; the other lived in somebody's memory. A scheduled task that silently stopped running could therefore pass the review by simply not showing up — absence read as nothing-to-see.

The fix: write the expectations file at planning time, so the check reconciles two artifacts instead of an artifact and a recollection.

Catch three — the class that did not exist yet

Elena, the standards reader. Her lens: does this fit the framework's own taxonomy, and will it make sense to whoever opens it next? Her catch was categorical, not mechanical.

The three documents belonged to no existing class in our standard — they were a new, fourth kind — and they lacked the structural anatomy every other class carries. Each one then got the full skeleton: license header, index, manifest, and its own seeded lessons section.

No individual line was wrong. What was missing was an answer to "what is this document?" — which a mechanics-focused review is not looking up to see.

The part worth stealing

Three catches, three shapes: a rule with no enforcement point, a check with one side only remembered, and a document with no class. Each reviewer surfaced something the other two did not — which is what you would expect when each is looking for something different.

That is the argument for a panel over a careful reviewer. Thoroughness tends to give you one kind of care, repeated. Separate specifications give you separate blind spots — which is the point.

You do not need our framework to try it. Write down three short reviewer briefs, each with one job and one explicit boundary, and run them as separate passes over the same draft. Score the findings so you can weigh them, and keep the decision yours.

What the framework adds, if you want it later, is the boring part: the briefs are written specifications you reuse across projects instead of retyping, the scoring scale is fixed at 0-100 so findings from different reviewers are comparable, and the review is a recipe you invoke by name rather than a habit you have to remember. The technique above is the whole idea. The framework is the version that survives you forgetting about it for a month.

Honest bounds

CRAFT for Claude Cowork is in beta and we say so plainly. A persona is structured instruction and review discipline — AI can still make mistakes. A panel with confidence scores exists to catch more of them before they ship, and the final call stays with you.

If you want the framework itself: it is free and ungated during the beta, and it runs on Claude Cowork — so you need Cowork available in your Claude plan. CRAFT adds no cost, account, or gate on top of that.