DEV 0.0.1 8/20/26, 4:18 PM EDT Admin

Vibecoding Is Not Just Prompting: What Serious AI Development Requires.

Vibecoding Is Not Just Prompting: What Serious AI Development Requires

There is a cottage industry built on the premise that the secret to AI development is the perfect prompt. Buy the right template, memorize the magic phrases, whisper the incantation just so, and flawless software shall appear. It is a comforting story, and it is mostly wrong.

We will grant that prompt quality matters at the margins. A vague request gets a vague answer; that is not a deep insight, it is a conversation. But once your prompts are merely competent—clear intent, relevant context, explicit constraints—the returns on further prompt-polishing fall off a cliff. The teams shipping reliable software with AI are not winning on wording. They are winning on everything that surrounds the wording. The prompt is the tip of the iceberg, and, as icebergs go, it is not the part that sinks ships.

The workflow, not the wording, decides the outcome.

— Chapter Two, AI-native software development

The prompt is the smallest variable

Consider what actually happens when a coding agent does good work. It reads your request, yes. But it also reads your repository: the existing patterns, the file structure, the naming conventions, the tests already in place, the configuration, the comments that explain why something strange is the way it is. It draws on whatever standing instructions you have given it about how this project works. It operates inside a workflow that decides what it is allowed to touch and how its output gets checked.

Change the prompt and you nudge one input. Change the repository, the instructions, and the workflow, and you change the entire probability distribution of what the model produces. A brilliant prompt aimed at a chaotic, undocumented codebase yields confident nonsense. A modest prompt aimed at a well-prepared repository with clear conventions yields code that fits. We have watched the same model, given essentially the same instruction, behave like a thoughtful senior engineer in one repo and a caffeinated intern in another. The variable was never the prompt.

Repository readiness is the real leverage

If prompts are the tip, repository readiness is the mass under the waterline. An AI agent is, functionally, a very fast new team member with no institutional memory and a tendency to pattern-match on whatever it sees first. The quality of its work is bounded by the quality of the environment you drop it into.

A repository that is ready for agents has legible structure—a newcomer, human or model, can infer where things go. It has consistent conventions, so the agent extends existing patterns instead of inventing new ones beside them. It has tests that actually assert behavior, so there is something to check the work against. It has the context that usually lives only in senior engineers' heads written down somewhere the model can reach. In our own work, preparing a codebase for AI collaboration—cleaning up structure, documenting the non-obvious, making the implicit explicit—consistently pays off more than any prompt engineering ever has. It is unglamorous. It is also where the leverage lives.

The pleasant side effect is that a repository legible to a machine is usually more legible to humans too. Time spent making your codebase agent-friendly is rarely wasted on the humans who have to live in it.

Standing instructions beat clever one-liners

The prompt-obsessed treat every interaction as a fresh negotiation. Serious teams encode the things they would otherwise repeat into standing instructions the agent reads every time—the equivalent of onboarding documentation for a colleague who onboards on every single task.

These instructions carry the durable rules: the architectural boundaries not to cross, the security requirements that are non-negotiable, the libraries you prefer and the ones you have banned for good reasons, the definition of "done" on this team. Tools like Cursor's coding agents and the broader Claude tooling are built around exactly this idea—persistent guidance that shapes behavior across many tasks, so you are not re-explaining your own standards at the start of every session. Get the instructions right once and every subsequent prompt inherits that quality for free. That compounds; a clever one-off prompt does not.

Verification is a first-class part of the workflow

Here is the part the prompt-template crowd almost never mentions, because it is not fun: generating code is the easy half. Knowing whether the generated code is any good is the hard half, and it is where serious AI development actually lives.

The workflow that works separates concerns cleanly. There is planning—deciding what to build and how. There is building—generating the code, which is increasingly the agent's job. And there is verification—independently checking that the work is correct, which must not be done by the same actor that produced it, whether that actor is a model or a person. We are firm on this point: a builder marking its own work "complete" is not verification, it is optimism with a checkbox. Independent review, automated tests, and evidence that the acceptance criteria are genuinely met are what turn a plausible-looking diff into something you can ship.

This is why the industry has invested so heavily in evaluation practices. When output is probabilistic and confident, the only defense is systematic checking. You do not trust the model because it sounds sure; you trust the result because it passed the gauntlet. The gauntlet is the product.

Our point of view at Chapter Two

We tell clients this plainly: if you are trying to improve your AI development by writing better prompts, you are optimizing the cheapest, most replaceable part of the system. It is like tuning the radio in a car with no engine.

The durable investments are the boring ones. Prepare your repositories so agents produce work that fits. Write the standing instructions that encode your standards. Build verification into the workflow so nothing ships on vibes and a good feeling. Route work deliberately—a hard architectural problem and a routine refactor do not deserve the same treatment, and pretending otherwise wastes money on one and quality on the other. Prompts sit on top of all of that. They matter, in the way that the last coat of paint matters: only after the house is built correctly.

What This Looks Like in Practice

When we set a team up to work with agents, the prompt is nearly the last thing we touch. We start with the repository—structure, conventions, tests, the written-down context that was previously tribal knowledge. We establish standing instructions so the agent knows the rules of this particular house before it does anything. We define the workflow gates: what gets planned, what gets built by the agent, and what independent check has to pass before anything is considered done.

Only then does prompting matter, and by that point good prompts are almost automatic, because the hard thinking already happened. A team member describes intent, the agent produces work that fits the established patterns, and the verification layer catches what slips through. The magic, such as it is, was front-loaded into the environment. The moment-to-moment interaction feels almost boring—which, for production software, is exactly the feeling you want.

Common Mistakes

  • Optimizing prompts while ignoring the repository. The environment shapes output far more than wording does.
  • Re-explaining your standards every session. Encode them once as standing instructions and stop repeating yourself.
  • Letting the builder grade its own homework. Verification has to be independent to mean anything.
  • Treating "the code was generated" as "the work is done." Generation is the start of the process, not the end.
  • Buying prompt templates instead of building workflow. The template is the cheap part; the workflow is the expensive, valuable part.

Once you accept that the workflow, not the wording, decides the outcome, an uncomfortable question follows: even with a great repository and disciplined review, how much should you actually trust the code an AI produces? The honest answer is less flattering than the marketing suggests. In the next article, we say the quiet part out loud.