Where it comes from
Each component maps to failures I watched happen, not to a syllabus. Across two industry-scale case studies, every documented breakdown traced back to one of these five being missing. The framework is what's left when you ask, for each failure, the smallest piece of understanding that would have caught it.
The failure modes it catches
| Failure mode | What it looks like | Caught by |
|---|---|---|
| Configuration blindness | Generated code assumes infrastructure that was never provisioned | Configuration |
| Permissions mismatch | Functional features with broken access boundaries at the edge cases | Architecture |
| Data boundary violations | Systems lose track of what data belongs where, or to whom | Safety, architecture |
| Dependency drift | A change to one component quietly breaks another | Systems thinking |
| Overconfident unsafe defaults | Dangerous configurations accepted without warning | Safety |
| Regeneration problems | Broad fix requests rebuild whole components, trading old bugs for new | Error |
The six modes get their own treatment in the six ways vibe-coding breaks.
What it deliberately is not
It is not "learn to code, but less". None of the five components involves writing syntax. They're judgement capabilities: knowing what to ask, what to check, and when to stop. The depth required is also adaptive rather than fixed; a tool you build for yourself and a multi-user deployment with real people's data don't need the same floor.
Status
Version one of the framework comes from the case-study work and is written up in a draft paper. Two participant studies through 2026 test whether it holds for practitioners who aren't me: single-session first encounters, then 8–10 weeks of learning trajectories. The framework sits inside the wider question of the compression gap; the full programme is on the research page.