The Mnemosyne Research Institute
The Vibe Coder's Bible
A trust-but-verify field manual for AI-assisted development and AI-native application design.
Vibe coding is real. So is the responsibility that comes with it. This book teaches one discipline for two jobs: building software with a model, and building software around one. Let models propose aggressively — then use tests, schemas, sandboxes, permissions, CI, Git, and provenance to decide what becomes real, whether the output is a code diff or a live runtime action.
Core Doctrine
Vibe coding lowers the cost of generation. It does not lower the cost of responsibility.
AI does not make detail unnecessary. AI makes detail affordable.
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.
Trust AI to propose. Verify before commit.
The model creates possibilities. Constraints decide which possibilities belong in the system.
Mixed output must be routed.
The repo is the memory.
Tests are reflexes. Schemas are contracts. Git is the time machine.
Probability is not authority. Plausibility is not admission.
Design systems where hallucination can exist, but cannot silently become truth.
Manuscript
42/42 chapters writtenPart I — The New Discipline
Vibe coding lowers the cost of generation. It does not lower the cost of responsibility.
AI does not remove the need for careful engineering. It makes careful engineering cheaper.
AI gives you more attempts. It does not tell you which attempt deserves to become real.
Part II — Trust, But Verify
The model is allowed to be creative before the gate. It is not allowed to be authoritative after the gate.
Hallucination is inevitable. Silent commit is optional.
Mixed output must be routed. Treating the whole answer as equally trustworthy is the original sin of vibe coding.
Part III — The Hierarchy Of AI Controls
A better prompt is not a substitute for a safer system.
Remove the hazard before teaching the agent to tiptoe around it.
Do not give the agent a chainsaw when a socket wrench will do.
A reflex is a validation step that fires before the system has to think.
Process is not the safety system. Process is how humans remember to use the safety system.
Prompt discipline improves behavior. It does not enforce behavior.
Part IV — The Propose / Validate / Commit Loop
Intent becomes real only after it crosses the commit boundary.
If the next agent needs to know it, put it in the repo.
Every bug fixed without a test is a lesson the next agent can forget.
A schema is a boundary the model cannot argue with.
Every AI session that modifies code should run on a branch, not main.
Part V — AI-Assisted Development Workflows
The first commit should be the safety system, not the feature.
Do not ask the agent to build a feature until the feature has a shape.
Never let the agent fix a bug it cannot reproduce.
The safer the test harness, the more aggressive the refactor can be.
Docs that lie are worse than no docs, because they replace the silence that forces investigation with the confidence that prevents it.
Do not deploy what you cannot roll back.
Part VI — AI-Native Case Studies From The Mnehmos Ecosystem
The model may explain the math. The math engine owns the answer.
The model narrates the world. The engine decides what is true.
Mixed output becomes useful when it is typed. Typed output can be routed. Routed output can be validated. Validated output can be published.
Narration explains the civic state; it does not create the civic state.
Pixels are output. State is the product.
The best agent systems remember, validate, route, and trace before they improvise.
Part VII — Failure Modes
AI slop is what happens when generation crosses the commit boundary without earning trust.
Plausible is not the same as true.
Untrusted context must not become trusted instruction.
The agent earns autonomy by passing controls, not by sounding confident.
Part VIII — The Field Manual
Do not start with a blank chat. Start with a repo that knows how to be helped.
Velocity comes from repeating a small disciplined loop, not from trusting a large unreviewed leap.
Write the handoff as if the next agent has never heard of this project.
Start with hazards removed. End with attention deployed. Never reverse that order.
Prompts matter when they produce artifacts the system can verify.
Review the system, not the prose.
Done means owned, tested, understood, and recoverable. Not just passing.
Part IX — The Production System
Part X — The Presentation Layer
Hierarchy of AI Controls
| Control | Build-Time and Runtime Equivalent |
|---|---|
| Elimination | Remove access to secrets, production databases, destructive commands, model-owned computation |
| Substitution | Replace raw access with typed tools, task runners, safe APIs, bounded action vocabularies |
| Engineering controls | Tests, schemas, type systems, CI, sandboxes — and runtime validators, permission checks, legality engines |
| Administrative controls | PR templates, checklists, review policy, release process, incident and rejection review |
| PPE | Prompt instructions, manual vigilance, style preferences |