Spec the invariants, vibe the rest
A thread on Hacker News this week split into two camps that both think they are describing the same job. One side argued that the people worth hiring now are the ones who can move inside ambiguity, ship without waiting for a finished spec, and find the shape of the thing while building it. The other side argued the reverse, that the value is shifting toward trust, security, and controlled workflows, the unglamorous discipline that keeps an AI-built system from quietly breaking in production. Reading it, I kept landing on the same reaction: both camps are right, and they are fighting over a strawman.
The strawman is the perfect spec. The spec-first versus ship-fast argument that vibe coding keeps reigniting always gets framed as a choice between writing a complete blueprint before you touch anything and just vibing forward and accepting whatever comes back. Almost nobody works at either pole. The useful question is narrower: which parts do you spec, and which parts do you let move?
the part that cannot drift, and the part that can
On this project the rule is close to mechanical. Spec the invariants. Vibe the rest. An invariant is anything that, if it drifts, breaks something you cannot easily take back: a name that must never appear in public, a vendor reference that belongs in one surface and not another, a cap on how much ships in a day, the contract a payment flow has to honor. Those get written down before anything gets built, in plain language, with the failure they prevent named right next to them. Everything else, the wording, the layout, the order you build the pieces in, the hundred small calls that are cheap to change later, moves fast and stays unspecified.
That split is the whole methodology, and it inverts how most people read the word spec. A spec is not a plan for everything. It is a fence around the few things that are expensive to get wrong. Inside the fence you move at whatever speed you want, because the fence is what makes the speed safe.
the receipt is the post you are reading
This is a vibe coded site, and the writing on it is the proof. Posts here draft, take an SEO pass and a revision pass, and ship to production with no human reading them in between. That sounds reckless until you see what is specified underneath. A pre-commit hook refuses any post that carries a forbidden name or puts a vendor reference in a surface it does not belong in. A schema validator rejects any post whose metadata violates the contract. A daily cap refuses to let more than a set number of posts ship. None of that is vibe. All of it was specified once, encoded as a check, and now runs on every commit without getting tired.
A few weeks ago this pipeline required three separate operator reviews before a post went live. Now it requires none before and one revert after, in case something lands wrong. Read in the worst light, that is the move that breaks things: drop the review, trust the output, let volume win. The reason it holds is the fence. The reviews that got removed were checking things a hook and a validator now check deterministically, at a cost that does not climb when volume climbs. I did not remove review. I moved it to a layer that enforces the spec'd invariants on every change, which is the only kind of review that keeps pace with an AI that writes faster than any person can read. I wrote up the longer version of that trade in what vibe coding owes the commons it runs on.
why the perfect spec is the wrong target
A complete spec ages badly. The moment you try to specify everything, you are writing fiction about decisions you have not made yet, and the spec rots the first time the build teaches you something. It also hands you a false sense of safety. A thorough-looking document makes people stop checking, so the parts that actually mattered get the same shrug as the parts that never did. A thin spec on the invariants does the opposite. It is short enough to keep current, and it points all of the discipline at the few places where drift is costly.
The failure mode to watch is specifying the wrong layer. If you write three pages on the visual design and one line on the code that handles money, you have a spec that looks rigorous and protects nothing. The test is the one I use for every gate: name the specific failure the spec prevents, then ask whether that failure is expensive and hard to reverse. If yes, spec it and enforce it. If no, let it move. This is the same discipline I described when the agent started writing the orchestration itself: once the tooling can generate the workflow, the operator's leverage moves up to the spec and the acceptance gate. And it is the flip side of the day a gate passed without actually running: a spec'd invariant only protects you if the check behind it really executes.
what this buys a vibe coder
For a vibe coder, this is the move that keeps the speed without the dread. You stop treating planning and improvising as opposites you have to ration between, and start sorting your build into two bins: the lines that cannot drift, and everything else. AI orchestration at production scale lives or dies on getting that sort right. SpecMesh, the discipline this whole project runs on, is just this idea made repeatable: capture the invariants as a spec before the build, encode them as checks, and let the checks carry the load a person cannot carry at machine speed. The vibe coded surface stays fast. The invariants underneath stay still. Both are real, and they are not in tension once you know which is which.
when you are not sure which line is the invariant
If your AI build keeps breaking in ways you did not see coming, the usual cause is that the invariants were never named, so nothing underneath is guarding them, and the spec you do have is fencing the wrong field. Send the build and the place it tends to fall apart. I can scope a working session to find the lines that actually cannot drift, a spec-first rebuild of the orchestration layer around them, or a standing set of gates that enforces those invariants on every change so the rest of your build is free to move fast. Work with VibeKoded.
The two camps on that thread were arguing about the wrong axis. The choice was never spec everything or spec nothing. Spec the few things that cannot drift. Vibe the rest. The discipline and the speed stop fighting the moment you draw the line in the right place.