A Trust-but-Verify Field Manual for AI-Assisted Development and AI-Native Application Design
Presented by Mnehmos, from The Mnemosyne Research Institute.
Vibe coding lowers the cost of generation. It does not lower the cost of responsibility.
This guide teaches one hierarchy-of-controls discipline for two jobs: building software with a model, and building software around one. Let models propose aggressively, then use tests, schemas, sandboxes, permissions, code review, CI, Git, and provenance to decide what becomes real — whether the output is a code diff headed for a merge or a runtime action headed for a database, a tool call, or a user's screen.
AI-assisted development treats the model as a faster way to write deterministic software. AI-native engineering treats deterministic software as the control structure that makes a stochastic model trustworthy.
Attention to detail was always a labor constraint. AI does not make detail unnecessary. AI makes detail affordable.
Trust AI to propose. Verify before commit.
Software engineering has always rewarded attention to detail, but detail is expensive. Good tests, clear documentation, structured handoffs, defensive design, code review, diagrams, reproducible builds, typed contracts, migration plans, threat models, and audit trails all take labor.
Traditional teams skip these things not because they are worthless, but because they are costly.
AI changes that equation.
AI makes it cheap to generate tests, docs, schemas, diagrams, checklists, scaffolds, issue maps, migration plans, and alternative implementations. But cheap generation creates a new danger: the system can now produce more code than the human can safely inspect.
Generation now happens at two levels, and they are two related control problems. At build time, the model helps construct software, and its output flows toward the repository — there is a diff and a review window. At runtime, the model runs inside the product, proposing actions, claims, tool calls, narration, and state transitions on every request — and there is no review window unless the architecture builds one. Same failure (a plausible falsehood accepted as truth), different clock.
The answer is not to abandon AI. The answer is to move from vibes-only generation to trust-but-verify architecture, at both boundaries.
Trust AI to propose. Verify before commit. Design systems where hallucination can exist, but cannot silently become truth.
- AI proposes.
- Systems verify.
- Commits are controlled.
- Prompting is PPE.
- Detail is now affordable.
- The repo is memory.
- Tests are reflexes.
- Schemas are contracts.
- Git is the time machine.
- The trace remembers.
- The model creates possibilities. Constraints decide which possibilities belong in the system.
- Probability is not authority.
- New builders who can now create software before they fully understand software engineering.
- Experienced developers who need a rigorous vocabulary for supervising AI-assisted work.
- Team leads and founders who need agentic development without AI slop.
- Builders putting a model inside a product, who need the runtime version of the same discipline: what the model may propose, what owns truth, and what guards every commit boundary.
This is not a prompt guide. Prompts matter, but prompts are not the safety system.
The book treats both disciplines as one control-design problem. The question is not just "how do I get the model to produce code?" The question is "what is allowed to become real?" — at the development commit boundary (merge, deploy, publish) and at the runtime commit boundary (database write, executed action, published claim, user-visible state).
| Control | AI-assisted development equivalent |
|---|---|
| Elimination | Remove access to secrets, production databases, destructive commands, and broad filesystem writes |
| Substitution | Replace raw access with typed tools, task runners, safe APIs, and dry-run commands |
| Engineering controls | Tests, schemas, type systems, CI, sandboxes, branch protection, permissions |
| Administrative controls | PR templates, checklists, review policy, issue discipline, release process |
| PPE | Prompt instructions, "be careful," manual vigilance, style preferences |
Intent
-> Proposal
-> Structured artifact
-> Validation
-> Commit
-> Trace
Generation-level hallucination is when the model emits something false. Commit-level hallucination is when the system accepts that false output as state.
The architecture attacks commit-level hallucination.
The canonical book source lives in manuscript/.
- Online: mnehmos.github.io/vibe-coders-bible — full manuscript, doctrine index, and search.
- Download: the latest release ships PDF, DOCX, and EPUB.
- Audiobook: narrated with OpenAI text-to-speech; scaffolded but not yet generated for a release. See publishing/audio/.
Build these yourself with scripts/build-all.ps1 — see publishing/README.md and publishing/audio/openai-tts-narration.md.
The book's discipline is available as a ready-to-use system prompt, not just prose. Clone this repo and drop claude-md-package/CLAUDE.md into your own project root as CLAUDE.md — it's a fully-authored master prompt encoding the hierarchy of controls, the propose/validate/commit loop, and the runtime-capability questions, ready for any AI coding agent to read on day one. See claude-md-package/README.md for install and customization.
The same discipline also ships as an installable agent skill. Copy .agents/skills/vibe-coders-bible/ into your own project's .agents/skills/ directory — or into ~/.agents/skills/ to carry it across every project — and the skill loads on everyday development work: building features, fixing bugs, refactoring, reviewing or committing generated code, designing a feature that calls a model at runtime. The skill holds the doctrine itself; references/ alongside it carries the per-task playbooks, the full hierarchy-of-controls checklist, the runtime design questions, and the failure-mode playbook, read on demand. The two distributions pair well: the CLAUDE.md package gives an agent standing orders in one project; the skill follows the doctrine into every session, in any project, without needing the repo at all.
The case studies are architecture evidence, not project anecdotes. Each one is a working AI-native system that answers the same questions differently: what the model may propose, what deterministic component owns truth, where randomness lives, and what guards the commit boundary.
- ProveCalc: the LLM never computes.
- RPG-MCP: the model narrates, the engine rules.
- LLM-Chess: mixed model output becomes typed artifacts.
- Clio: civic intelligence is rendered from validated state.
- Semantic Video Studio: state first, pixels second.
- ChatDB, Trace MCP, IndexFoundry, Synch MCP, and the multi-agent framework: reliability compounds in infrastructure.
Issues and PRs are welcome, especially concrete case studies of failures that escaped review and the controls that would have caught them.
Start with CONTRIBUTING.md and use the templates in .github/ISSUE_TEMPLATE/.
Text, documentation, and templates are licensed under CC BY 4.0. Future code examples or tooling may carry separate MIT license notices when appropriate.