6.2 KiB
Non-Engineer's Analog of Throwaway Verification Code
#query
Carried forward as thesis T6a in 2026-07-28-webinar-theses — "ask for checks, not just work." That refresh flags the absence of any verification beat in the current webinar script as the talk's biggest gap, since "can I trust it?" is the audience's first question.
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.