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.

4.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.

4.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, so you can swap one payment or email provider for another without the rest of the app noticing, 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.

4.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.

4.6.4Ask 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 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. 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.

4.6.1A pattern is a proven shapeAdd note

4.6.2The handful you'll actually meetAdd note

4.6.3Patterns are a shared languageAdd note

4.6.4Ask the agent to use the right oneAdd note

4.6.1A pattern is a proven shape

4.6.2The handful you'll actually meet

4.6.3Patterns are a shared language

4.6.4Ask the agent to use the right one