Patterns: The Names Worth Knowing | Vibe Coding with Confidence

Open a file your agent wrote and you will see the same shapes repeat: a piece that routes requests, a piece that talks to the database, a piece that holds the rules. These are not the agent's invention. They are named, proven solutions that engineers reach for over and over. Learn the names and two things happen: you recognize what you are looking at, and you can ask your agent for the right shape by name.

5.6.1A pattern is a proven shape

A design pattern is a reusable solution to a problem that comes up again and again, packaged under a name everyone knows. Someone hit the problem years ago, found a clean answer, and the answer stuck.

You do not memorize patterns or learn to build them from scratch. Your agent already knows dozens. Your job is lighter: recognize a few by sight, so the code stops looking like an undifferentiated wall.

5.6.2The handful you'll actually meet

A handful of names cover most of what you will see in a typical app:

MVC splits a feature into three parts: the data (model), the screen (view), and the glue between them (controller).
Middleware is a checkpoint every request passes through, for things like login checks or logging.
A factory is one function whose job is to build and hand back an object, so the rest of the code never builds it by hand.
A repository is the one place that talks to the database, so nothing else has to know how data is stored.
A service layer holds the business rules, sitting between the request and the repository.
An adapter is a thin wrapper around an outside service. Swap one payment or email provider for another and the rest of the app never notices, which keeps coupling loose and the code easy to change.

A repository, for instance, is often just this shape:

const userRepository = { findById: (id) => db.users.find(id), save: (user) => db.users.insert(user), }

Everything else in the app asks userRepository for a user and never touches the database directly.

A request passes through middleware, then the service layer, then the repository to the database.

5.6.3Patterns are a shared language

The real value of the names is precision. "Put the database calls behind a repository" is one clear instruction; describing that same shape in your own words takes a paragraph and still leaves room to be misread.

The names are a language you and your agent already share. Using them, you say exactly what you mean in three words, and the agent builds exactly the shape you pictured.

5.6.4No pattern is also an answer

Knowing the names creates a new risk: asking for them everywhere. A pattern earns its place when there are two real callers, or a real reason to swap the thing behind it later. When neither is true, a plain function is the better answer.

A factory that builds exactly one object, or an interface with a single implementation, is a pattern applied for its own sake. That is an anti-pattern: a shape that looks professional and makes the code harder to change. Ask for the pattern when you can name what it buys you, not because it sounds senior.

5.6.5Ask the agent to use the right one

You can point at code and ask which patterns are in it, or ask the agent to reshape a tangled feature into the right one. Either way you lead with the name.

Ready prompt

Act as a senior engineer. First read my rules file and the architecture map in it, so you judge this code against my own conventions and layers, not a generic ideal. Then read the code below and name the design patterns already in it, one line each, in plain words a newcomer would follow. Then tell me whether the right patterns are being used for this feature. If a cleaner, more standard shape fits (repository, service layer, factory, middleware, adapter, MVC), name it, say why, and show the smallest change toward it. Flag the reverse too: any pattern here that has one caller or one implementation and should collapse back to a plain function. If the better shape would contradict my architecture map, say so and what the map would have to change to, rather than quietly diverging from it. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/read/patterns The code and what the feature does:

Do this now: paste the prompt over one feature your agent built, and have it name the patterns already there and flag any place a more standard shape would fit.

5.6.1A pattern is a proven shapeAdd note

5.6.2The handful you'll actually meetAdd note

5.6.3Patterns are a shared languageAdd note

5.6.4No pattern is also an answerAdd note

5.6.5Ask the agent to use the right oneAdd note

5.6.1A pattern is a proven shape

5.6.2The handful you'll actually meet

5.6.3Patterns are a shared language

5.6.4No pattern is also an answer

5.6.5Ask the agent to use the right one