Beyond vibecoding
An agent will write the code. It will not tell you the code is wrong in a way that matters six months from now — because it does not carry the consequences, and you do.
The gap is not prompting. It is the knowledge that lets you judge output you did not write.
What you still have to know
Systems. Why this service talks to that one, where state lives, what happens when the network partitions. An agent produces a working call between two services and has no opinion about whether they should be two services.
Data. Schema design, indexes, what a migration costs on a table with 40 million rows, why that query is slow. The most expensive agent-written code in production is usually a query that was fine on the dev dataset.
Security. Trust boundaries, authz, what an attacker actually does. An agent writes code that passes your tests, and your tests were written by someone who was not thinking like an attacker.
Operations. What breaks at 3am and how you find out. Agents write no alerting, choose no SLO, and will happily produce a service with no way to know it is down.
The domain. Why the business needs it this way. This is the part no model has, and the part that decides whether correct code is also right.
The asymmetry
Agents are fastest at exactly the work that is cheapest to fix — boilerplate, CRUD, tests, renames. They are weakest at the work that is most expensive to fix — schema, service boundaries, trust boundaries, data lifecycle.
So the time you save on volume should go into the decisions, not into producing more volume. That is the whole argument for planning before building, and for planning before building at all.
Review is the skill
Reading code you did not write, quickly, and finding what is wrong with it is now the core competency. It was always valuable; it used to be occasional.
Which means: if you cannot review it, do not ship it. "The agent wrote it and the tests pass" is not a standard — the tests were also written by the agent, from the same misunderstanding.
Verify, do not trust
- Completion is measured against wired, tested code, never against a status
doc or a checkbox count (
verified-progress-signal). - A green type-check does not prove the app boots. Nor that validation runs,
nor that a response is not leaking internal fields (
self-review-before-done). - A green exit code proves execution, not safety — the devops version of the
same idea (
plan-before-operational-change).
The honest summary
Vibecoding works right up until it does not, and the moment it stops working is the moment you need everything it let you skip. The tooling in this kit exists to make the gap visible early — gates, verification skills, hooks that block — rather than at 3am.