Vibe Coding vs. Software Architecture: Why Governance and Taste Matter More

Vibe coding describes a working style where you describe an outcome and let the model produce the code — without reading it line by line. For prototypes, internal tools and throwaway scripts this is an enormous gain. In mature product systems the same style quickly turns against you.

The reason is unspectacular: a model optimises for the task in its context window, not for the structure of the overall system. It delivers something that works. Whether it belongs where it landed is not its decision.

---

1) What Goes Wrong in Practice

Public accounts from product teams — including around work on Basecamp products, where DHH and team discuss AI-assisted development openly — name recurring patterns. Regardless of the specific project, we see the same four:

• Duplicated logic. The agent builds a new helper because the existing one was not in context. Weeks later the same rule lives in four places — with three deviations.
• Broken layer boundaries. Data access ends up in the presentation layer because that was the shortest path. It works — and makes every later change expensive.
• Tests that mirror the implementation. The agent writes tests that check exactly what it built. They turn green and prove nothing about the requirement.
• Silent dependencies. Extra libraries for trivia, with nobody assessing maintenance, licence and security posture.

None of this shows up on day one. All four surface when a restructuring becomes necessary.

---

2) Why "Taste" Is Suddenly a Production Factor

When code generation becomes cheap, selection becomes the bottleneck. And selection requires judgement that is not in the code: does this model fit the domain? Will this abstraction still be understandable in a year? Is the simpler variant the better one despite less flexibility?

That is what developers mean by taste: not decoration, but the ability to recognise the durable solution among several working ones. The glossary describes exactly this capability as Differential Evaluation — trainable, but not delegable.

---

3) Guardrails That Actually Hold in AI-Assisted Development

A) Make Architecture Explicit

What lives in a senior engineer's head is invisible to an agent. Layers, permitted dependency directions, naming conventions, ownership per module belong in the repository in writing — short, current and machine-readable. That is not bureaucracy, it is context.

B) Enforce Rules Automatically

Anything a linter, an architecture test or a schema check can enforce belongs there. Human reviews should decide on design and appropriateness, not on import paths.

C) Test Against Requirements, Not Implementation

The rule: the test is written from the requirement before the agent implements — or at minimum reviewed independently of the generated code. Green tests produced by the same run are not evidence.

D) Cap Change Size

Small, thematically coherent changes are reviewable. A proposal spanning thirty files effectively goes unread. Using agents therefore requires stricter size rules than before, not looser ones.

E) Anchor Product Understanding in Review

The key review question is not "does it run?" but "is it the right thing?". Only someone who knows the product, the users and the next two quarters can answer that.

---

4) Where Vibe Coding Is Exactly Right

The criticism targets the location, not the style. It clearly fits:

• prototypes for feasibility checks that are discarded afterwards
• internal tools with read access and a small user group
• one-off data preparation and analysis
• throwaway automations for a single campaign

That pattern is precisely what the term Malleable Software describes: short-lived tools whose rebuild costs less than their upkeep. The line is drawn where code runs permanently, processes real data or creates commitments to customers.

---

5) Governance That Does Not Slow You Down

Three decisions suffice to start:

1. Define zones. Which parts of the codebase may be changed agentically, and which only with review by a named person?
2. Separate permissions. Agents propose, humans adopt. Direct write access to production stays an exception with a justified case.
3. Keep the trail. Mandate, produced change, review, decision — documented. That is simultaneously the basis for audits and for team learning.

---

Conclusion

AI-assisted development shifts effort from typing to deciding. That does not make architecture less important; it makes it the decisive guardrail — the context without which an agent inevitably optimises locally. Put structure in writing, enforce rules automatically and aim reviews at appropriateness rather than syntax, and you can move fast without damaging the foundation.

Further reading: why the bottleneck afterwards sits in vision rather than implementation is covered in The New Bottleneck in IT Organisations.