# Non-Engineer's Analog of Throwaway Verification Code

#query

**Question asked:** What is the non-engineer's analog of throwaway verification code ([[make-more-cheap-code]])?

**Asked:** 2026-07-24 · **Status:** synthesis from existing pages (no new source)

## Answer

**The analog is disposable AI work whose only purpose is to attack, misread, and simulate your real deliverable before a human sees it — generated *checks*, not generated *content*.**

Theo's engineer version: for every line that ships, generate 100–10,000 lines of never-shipped code that verifies it. The non-engineer's deliverables are documents and decisions — job descriptions, candidate profiles, specs, outreach emails, offer terms — so the analog is: **for every document you ship, generate several documents you never ship, whose job is to find out where the shipped one fails.** The webinar audience mostly uses AI on the *production* side (draft it for me); this points the same firehose at the *verification* side.

Theo's concrete patterns map one-to-one onto the vault's HR/BA use cases:

| Theo's engineer move ([[2026-07-24-youre-reading-way-too-much-code]]) | Non-engineer analog (grounded in corpus use cases) |
|---|---|
| Dumb-model agents try to build on your API — their failures are UX bugs in the API | Give your job description or spec to a **fresh agent with zero context** and ask it to restate who is being sought / what is being built. Where its naive reading diverges from your intent, the document is ambiguous. This is [[leave-less-room-for-imagination]] inverted: the AI's "fantasy" becomes an **ambiguity detector** — drift as diagnostic, safe because it happens in a throwaway sandbox instead of your deliverable. |
| Test 3 theories of an ambiguous PR in parallel | Ambiguous stakeholder ask → have the agent draft **3 divergent interpretations** cheaply and compare them, instead of committing to one reading. (Directly serves Larysa's BA work — [[2026-07-21-larysa-interview]].) |
| Generate a custom lint rule for a bug pattern you just found | Every recurring caught mistake (AI-sounding language, tone, missing salary band, unverifiable spec claim) becomes a **checker skill** that reviews future drafts. Allie's anti-AI-language skill is literally this ([[personal-ai-operating-system]]). |
| Load-test rigs; stress the system with throwaway infrastructure | **Simulate before real users arrive:** run 10 synthetic candidate profiles through a new screening process; query the candidate knowledge base ([[2026-07-14-yulia-interview]]) with naive questions to test whether profiles are standardized enough to be findable. |
| Red-team the sacred core with slop | Spawn an agent playing the **skeptical reader** — the picky hiring manager, the candidate deciding whether to reply, the developer misreading the spec — and let it generate the 20 objections before a human raises them. |
| Read every signature/API; skim bodies; agent-summarize diffs | Read the **boundaries**: names, numbers, dates, commitments — the document's "signatures" — by hand; let AI cross-check the body. |
| AI reviews code before humans do | AI reviews the document before your team/candidate does — a pre-human review step, same as Theo's. |

**The method already exists in the vault — it just runs in one direction.** [[solve-first-then-skillify]] freezes proven *production* workflows into skills. This query adds the second species: **checker skills** — the correction loop you just went through (per Eugene's ~3-message heuristic) is not only a producer skill waiting to be frozen, it is also a *verifier* skill: "here is the mistake pattern; check every future draft for it." That gives the [[levels-of-ai-usage]] skills rung a dual population, producers and checkers, at zero extra conceptual cost for the audience.

**What does not map.** Engineers verify against ground truth (tests pass or fail); a non-engineer's verification bottoms out in **human judgment** — there is no fuzzer for "is this offer fair." So tier D stays irreducibly human: offer terms, rejection communications, anything compliance-adjacent gets read line-by-line, exactly as Theo keeps hand-verification of shipped code. And Theo's "there's always another layer" still holds in weakened form: if you don't trust AI review of the document, have AI generate the **checklist you apply yourself**.

**One-line webinar version:** *AI's first job isn't writing your document — it's breaking your document before a person does. What you ship, you still read; what checks it, you never read.*

## Evidence trail

- Engineer-side concept and all mapped patterns — [[make-more-cheap-code]], [[2026-07-24-youre-reading-way-too-much-code]]
- Non-engineer use cases (job descriptions, profiles, sourcing, candidate KB) — [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]]
- BA/spec ambiguity and invisible drift — [[2026-07-21-larysa-interview]], [[leave-less-room-for-imagination]]
- Checker-skill precedent (anti-AI-language) — [[personal-ai-operating-system]], [[2026-07-14-gap-between-ai-users-irreversible]]
- Method being extended — [[solve-first-then-skillify]], [[levels-of-ai-usage]]

## Follow-up questions

- Does a "checker skill" need its own rung in the webinar ladder, or is it a footnote on the skills rung?
- Nina's finding that *the transcript matters more than the summary* cuts against agent-summary review — for non-engineers, when is the raw artifact (transcript, full document) the only safe thing to read? (Cousin of the Theo/Dax-vs-Eugene tension logged in [[leave-less-room-for-imagination]].)
- Is there a measurable claim for the webinar — e.g., "one fresh-agent misread test catches X% of spec ambiguities"? Currently pure assertion by analogy. Status: tentative.

## Changed existing pages?

Yes — light pointers only: [[make-more-cheap-code]] (next-question answered with link here), [[leave-less-room-for-imagination]] (drift-as-diagnostic inversion noted in Next Questions), plus `index.md` and `log.md`.