{"slug": "vibe-was-never-the-problem-but-the-missing-half-starts-before-the-build", "title": "Vibe Was Never the Problem. But the Missing Half Starts Before the Build.", "summary": "A developer argues that vibe coding's missing half comes before the build, not after it, proposing an expanded loop — Vibe → Spec → Break the Design → Build → Break the Build → Understand → Stabilize → Perfect — that adds a lightweight up-front spec and design review to Don Johnson's post-build Vibe → Build → Break → Understand → Stabilize → Perfect cycle. Drawing on experience leading testing for a cardiovascular device, where a test environment used water instead of blood, the developer contends that coding agents can generate twenty files, dependencies, migrations and auth logic in a single build step, so teams end up reverse-engineering their own systems when understanding arrives too late. The piece argues that breaking the model of the problem matters as much as breaking the code, especially for AI systems handling sensitive enterprise documents.", "body_md": "*Why vibe coding needs software engineering before we let the agents loose.*\n\nDon's loop gets the post-build part right.\n\nWith coding agents, though, I think a lot of the damage can happen before we ever get there.\n\nIn [Vibe Was Never the Problem: The Missing Half of Vibe Coding](https://dev.to/copyleftdev/vibe-was-never-the-problem-the-missing-half-of-vibe-coding-50mi), [Don Johnson](https://dev.to/copyleftdev) argues that intuition isn't what goes wrong in vibe coding. Stopping at intuition is.\n\nHis fix is a loop:\n\n**Vibe → Build → Break → Understand → Stabilize → Perfect**\n\nI agree with nearly all of it, especially the **Break → Understand → Stabilize** middle. That is exactly the part many AI-assisted projects skip.\n\nMy addition is about sequence.\n\nDon's loop eventually produces a spec. It appears during Stabilize, alongside tests, types, contracts, and other things that turn an experiment into something trustworthy.\n\nI think some version of that spec needs to exist **before the build too**, not only after it.\n\nMy version would be:\n\n**Vibe → Spec → Break the Design → Build → Break the Build → Understand → Stabilize → Perfect**\n\nThe difference looks small.\n\nI think it matters a lot.\n\nDon makes a good case for exploration before full understanding.\n\nA sculptor doesn't completely specify the statue before touching the clay. A musician doesn't prove a bassline before playing it.\n\nFor exploration, I agree.\n\nBut clay is cheap to reshape.\n\nAnd clay doesn't install twelve dependencies while you are getting coffee.\n\nA coding agent can.\n\nOne Build step today can produce twenty files, new packages, infrastructure configuration, a database migration, authentication logic, retries, background jobs, and, occasionally, an abstraction that apparently needed its own abstraction.\n\nWhen understanding comes after all of that, we are no longer simply reviewing generated code.\n\nWe are reverse-engineering our own system.\n\nA lightweight spec up front changes the division of labor.\n\nInstead of:\n\n**AI designs → AI builds → human discovers what happened**\n\nwe get:\n\n**Human defines intent and boundaries → AI builds → human verifies**\n\nWithout that step, we can now create architectural debt faster than we have ever created code.\n\nThis is where I think Don's **Break** step is necessary, but not sufficient.\n\nBreaking an implementation asks:\n\n**Does this thing fail?**\n\nA design review asks a different question:\n\n**Should we have built it this way at all?**\n\nI learned this lesson earlier in my career while leading testing for a cardiovascular device.\n\nWe had a test environment that could tell us whether the device behaved correctly under the conditions we had defined.\n\nThe problem was that one of those conditions was wrong.\n\nWe were using water where the real operating environment involved blood, which behaves differently.\n\nWe could have continued testing.\n\nWe could have generated more test cases.\n\nWe could have produced more data.\n\nAnd we would have become increasingly confident in a model of the system that did not adequately represent the real environment.\n\nThe important question had to come before the test:\n\n**Does this test environment actually represent the system we are designing for?**\n\nThat experience stayed with me because it showed how easily a team can validate an implementation while missing an assumption at the system level.\n\nSometimes the thing you need to break first is not the code.\n\n**It is the model of the problem.**\n\nThe same issue becomes even more important with AI systems.\n\nImagine an application handling sensitive enterprise documents.\n\nYou can fuzz the retrieval endpoints, run adversarial prompts, test latency, and achieve excellent coverage.\n\nNone of that fixes an architecture where sensitive documents should never have crossed a particular service boundary in the first place.\n\nIt doesn't fix authorization being copied into a second store when it should have been checked against the authoritative source.\n\nAnd it doesn't fix giving an agent a tool permission it never needed.\n\nSometimes the bug isn't in the code.\n\n**It's in the architecture.**\n\nSo I would break the system twice.\n\nDo it before implementation becomes expensive.\n\nAttack the assumptions.\n\nAsk:\n\nThis is the cheap Break.\n\nNothing exists yet.\n\nA bad answer might cost a whiteboard edit instead of a rewrite.\n\nThis is Don's step, and I would keep it.\n\nTest it.\n\nFuzz it.\n\nInject failures.\n\nAttack it.\n\nLoad-test it.\n\nTest the security boundaries.\n\nGive it malformed inputs.\n\nGive it adversarial inputs.\n\nAnd, of course, give it the user who pastes an emoji into the ZIP code field.\n\nThe two Break stages answer different questions:\n\n**Break the Design:** Is this the right system?\n\n**Break the Build:** Did we implement that system correctly?\n\nWe need both.\n\nNone of this means you cannot build before the spec.\n\nA throwaway spike can absolutely come first.\n\nBuild three versions in an afternoon if that is how you discover the shape of the problem.\n\nThat is one of the most exciting things coding agents give us.\n\nAI makes architectural experimentation dramatically cheaper.\n\nBut at some point the spike stops being an experiment and starts becoming something another person may have to **trust, operate, or maintain**.\n\nThat is where I want the spec.\n\nThe spec marks the transition from:\n\n**\"Let's see if this works.\"**\n\nto:\n\n**\"We may actually ship this.\"**\n\nWithout defined users, boundaries, requirements, and success criteria, five prototypes are still just five opinions.\n\nThere is an obvious danger in what I am proposing.\n\nIf every vibe needs a six-week architecture review, three governance committees, twelve Jira epics, and a 47-page design document before anyone can touch the keyboard, then congratulations:\n\nWe have solved vibe coding by making sure nobody codes.\n\nThat is not the proposal.\n\nFor many AI projects, the high-level spec can fit on one or two pages:\n\nThen review it.\n\nBut review it for **disagreement**, not ceremony.\n\nA good design review is not ten people saying, \"Looks good to me.\"\n\nIt is one person asking the uncomfortable question that makes everyone stare at the architecture diagram for thirty seconds.\n\nThose thirty seconds can save three months.\n\nThe spec also gives us something the build loop cannot provide by itself.\n\nThere are two fundamentally different questions in software engineering:\n\n**Did we build it right?**\n\nand\n\n**Did we build the right thing?**\n\nAI is becoming extraordinarily good at accelerating the first one.\n\nGenerate.\n\nTest.\n\nFix.\n\nRepeat.\n\nBut an AI agent can execute the wrong requirement with impressive efficiency.\n\nA beautifully engineered solution to the wrong problem is still the wrong solution.\n\nThe spec gives us something to evaluate the implementation against.\n\nThis may be the bigger shift behind vibe coding.\n\nWhen implementation was expensive, much of engineering naturally centered around:\n\n**Can we build this?**\n\nAI changes the economics of that question.\n\nIncreasingly, the harder questions move somewhere else:\n\n**Should we build this?**\n\n**What should the system boundary be?**\n\n**What should the model decide?**\n\n**What should remain deterministic?**\n\n**Where does a human need to stay in the loop?**\n\n**Where do we need a hard control instead of a prompt?**\n\n**What happens outside the happy path?**\n\nThose are engineering questions.\n\nThey are product questions.\n\nAnd increasingly, they are governance questions.\n\nThey are also questions a coding agent will happily answer on your behalf if you do not answer them first.\n\nThat is the part that concerns me.\n\nNot that AI can write code.\n\n**That it can quietly make architectural decisions while appearing to simply write code.**\n\nThis is where I strongly agree with Don.\n\nVibe coding versus software engineering is a false choice.\n\nVibe opens the loop.\n\nEngineering determines whether what comes out of that loop deserves to ship.\n\nI would only extend the argument one step further:\n\n**Engineering shouldn't wait for the vibe to finish. It should surround it.**\n\nBefore the prototype becomes a system, write down what you think you are building and try to prove the design wrong.\n\nThen build it.\n\nAnd try to prove the implementation wrong again.\n\nAI didn't make software engineering less important.\n\n**It made it possible to build the wrong thing much faster.**\n\nAnd perhaps that is the other missing half of vibe coding.\n\nNot less vibe.\n\n**More engineering around the vibe.**\n\n**Over to you:** Has a coding agent ever built you something that passed every test but still had the wrong boundary, assumption, or architecture? What would have caught it earlier?", "url": "https://wpnews.pro/news/vibe-was-never-the-problem-but-the-missing-half-starts-before-the-build", "canonical_source": "https://dev.to/maryam_zare_3fd580d8abbb1/vibe-was-never-the-problem-but-the-missing-half-starts-before-the-build-5m2", "published_at": "2026-09-29 21:41:23+00:00", "updated_at": "2026-09-29 21:46:37.307836+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-safety", "developer-tools"], "entities": ["Don Johnson", "dev.to"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/vibe-was-never-the-problem-but-the-missing-half-starts-before-the-build", "markdown": "https://wpnews.pro/news/vibe-was-never-the-problem-but-the-missing-half-starts-before-the-build.md", "text": "https://wpnews.pro/news/vibe-was-never-the-problem-but-the-missing-half-starts-before-the-build.txt", "jsonld": "https://wpnews.pro/news/vibe-was-never-the-problem-but-the-missing-half-starts-before-the-build.jsonld"}}