Beyond Vibe Coding: Context Engineering for Real
Vibe coding is fun right up until day three, when someone has to explain why the system does what it does.
I’m not against coding on pure feeling: for a throwaway prototype it’s the correct technique. The problem is that prototypes don’t die, they get deployed.
Vibe coding, defined without affection
Asking a model for things, accepting whatever comes out because it looks fine, and repeating. No contract, no verification, no memory between sessions. Every iteration starts from zero and the system’s state lives only in the accumulated diff.
It works while the project fits in the context window. Then the classic cycle begins: the model reintroduces the bug you fixed yesterday, invents a different convention in every file, and you become the memory system of your own project.
Context engineering: context is infrastructure
The alternative isn’t writing longer prompts. It’s treating context the way you treat a runtime environment: versioned, explicit, reviewable in a PR. Three pieces, in order of return on effort.
1. AGENTS.md — the house rules
A file in the repo with everything a new developer would take two weeks to learn the painful way: real commands, conventions, known traps, decisions made and why.
The test for whether yours is worth anything: does it contain something that can’t be deduced by reading the code? If it says “we use TypeScript”, you deleted that line correctly. If it says “margin utilities don’t work because there’s an unlayered reset in globals.css:38, spacing goes in scoped CSS”, that one’s worth its weight in hours.
A good AGENTS.md is a preventive postmortem: every line exists because somebody already lost an afternoon there.
2. MCP — tools instead of guesswork
The Model Context Protocol solves something boring and critical: giving the model access to the source of truth instead of to its recollection of the documentation. The real database schema, the real issue, the real log, the docs for the version you actually have installed.
A model with access to the schema doesn’t invent columns. One without access always invents the column that would make sense to exist, which is worse than inventing any old column, because it passes visual review.
And the flip side: every tool you connect is attack surface and context budget. Wiring up fourteen MCP servers “just in case” is the modern equivalent of installing the entire Google suite on a netbook.
3. Skills — procedures that don’t get renegotiated
What in a human team would be a runbook: how a release is cut, how a migration is added, how an incident is investigated. Written once, invoked the same way every time.
The advantage isn’t that the model does it better; it’s that it does it the same way every time. Consistency is half of quality, and it’s the half people underrate because it doesn’t show up in the demo.
The real cost
All of this is upfront work with no visible result. Nobody applauds an AGENTS.md. It’s the same category of effort as writing tests or setting up CI: invisible when it works, glaring when it’s missing.
The difference against vibe coding shows up in week three, when one of the two projects is still moving forward and the other is in an archaeology session figuring out why there are two functions doing the same thing under different names.
Spoiler: the same model wrote them, a week apart, with no memory of the first one.