← All articles

Opinion · · 3 min

Why every vibe-coded app looks the same

The sameness is not a model limitation. It is what happens when nobody supplies a point of view.


Open ten apps built with an AI agent last month and you will recognise nine of them instantly. The same centred hero with a soft radial glow. The same three feature cards. The same violet-to-indigo gradient. The same testimonial section with three invented people. It reads as a model problem — as if the tools are simply not good enough yet.

They are good enough. The sameness has a much more boring cause.

Generation without constraint converges on the average

A model asked for "a clean modern landing page" answers with the centre of mass of every clean modern landing page it has seen. That is not a failure of the model; it is the correct response to the question. You asked for the generic thing and you received it, rendered competently.

This is the same phenomenon as regression toward the mean: absent a force pushing in a specific direction, repeated draws cluster around the average. Every unconstrained prompt is another draw. The distinctiveness you want lives in the tails, and nothing in "clean and modern" tells the model which tail.

Notice what this implies. Adding more adjectives does not help much, because adjectives are themselves averages. "Minimal" is a region of the distribution, not a point in it. "Warm" narrows it slightly. "Clean, modern, minimal and warm" describes a few million pages, and you will get the middle of those.

Specificity is the entire job

What actually moves output is information the model could not have guessed:

  • A named customer instead of "users". Dana, who runs operations at a forty-person logistics firm and distrusts anything calling itself a platform, produces different copy than "users" does — different vocabulary, different lengths, different reassurances. This is worth doing properly; see write your UI copy for one named customer.
  • A typeface you chose for a reason. Not "a modern sans" but a specific face, with the sizes it owns and the ones it is banned from. Choosing type pairings for product UI covers how to pick two that survive a real product.
  • A palette with jobs attached. One accent that means "act here" and nothing else. Building a colour palette you can defend makes the case.
  • Negative constraints. "Never a gradient hero, never violet, never emoji in UI copy" removes three of the highest-probability moves in one line. Negative constraints are underrated precisely because they are boring to write.

None of this is difficult. It is all decisions you have already half-made. The problem is that they live in your head, or in a chat log from three weeks ago, and not anywhere the agent can reach at the moment it is generating.

The uncomfortable part

There is a version of this complaint that is really a complaint about effort. Supplying a point of view means having one, and having one means making choices you can be wrong about. "Clean and modern" is safe because it commits to nothing. It is also why the output is forgettable.

The work of design was never the rendering. Rendering is the part that got automated. What did not get automated is deciding what the thing should be — and that gap is exactly where the sameness comes from. An agent will execute a strong opinion faithfully and it will execute the absence of one just as faithfully.

A test

Delete your logo and your product name from a screenshot. Show it to someone who knows your product. Ask them whose it is.

If they cannot tell, the missing input is not a better model or a longer prompt. It is a point of view, written down somewhere the agent reads before it starts — which is the argument in how to teach a coding agent your design taste, and the reason MCP matters more to designers than its plumbing suggests.

The tools are not making everything look the same. They are making it obvious who had decided what their product should look like and who had not.

Further reading

Keep reading