Coupling: Keeping Pieces Independent | Vibe Coding with Confidence

Your agent ships fast, and then a one-line change to how orders are priced breaks the invoice screen and the email receipt too. That happens when your modules reach into each other instead of talking at arm's length. This chapter gets you the two words that name the problem, and how to point your agent at looser seams.

3.3.1Coupling and cohesion, defined

Coupling is how much one module depends on the inner workings of another. Two modules are tightly coupled when changing one forces you to change the other; loosely coupled when each can change on its own.

Cohesion is how focused a single module is. A cohesive module does one clear job and holds only the things that job needs, instead of being a junk drawer of unrelated code.

A cohesive Orders module holds only order work, not a junk drawer of extras.

3.3.2Keep a change from spreading

Tight coupling is why a small edit ripples into code you never opened. When one module knows how another stores its data, that knowledge is a wire, and every wire is a path for a change to travel down.

Loose coupling caps the blast radius. Cut the wires and a change stays where you made it, which is the whole reason you can move fast without holding the entire app in your head. The worst wire runs both directions: a circular dependency, where A depends on B and B depends back on A, so neither one can change or be understood alone.

With tight coupling, one pricing change ripples into unrelated screens.

3.3.3Talk through interfaces, not internals

The fix is to make each module expose an interface, the short list of things it promises to do, and keep everything else private. Callers use the promise; they never reach past it.

// Reaching into internals: the caller knows how an Order // stores its lines, and breaks the day that changes. let total = 0; for (const line of order.items) { total += line.price * line.qty; } // Talking through the interface: the caller just asks. // Order owns how it adds up; change it freely. const total = order.total();

Because a caller depends on the promise and not the parts behind it, you can hand a module what it needs from the outside instead of letting it reach for its own. That is dependency injection, and it is what lets a test pass in a fake service where the real one normally sits. Push it one step further and both sides depend on the interface in the middle rather than on each other's guts, which is dependency inversion.

Rule of thumb: if a module reads another's fields to do its work, it is reaching through the wall. Ask for a method that does the job instead.

The caller uses the promise; the internals stay hidden behind it.

3.3.4High cohesion, low coupling

The target is both at once: each module does one job well, and modules stay at arm's length from each other's insides. Your agent will not aim for this unless you ask, so ask.

Ready prompt

Act as a senior engineer auditing one module for coupling and cohesion. Read my spec and the module boundaries I already drew, so you judge this module against the split I chose, not a generic one. Coupling: list every place this module reaches into another module's internals (reads its fields, knows how it stores data, depends on its private shape). For each, propose a method or interface to call instead, so the two can change independently. Cohesion: name this module's one job, in the words my spec uses. Flag anything inside it that belongs to a different job and should move out. If the honest fix means changing a boundary I already set, say so and why. Propose first, rewrite nothing. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/architect/coupling-and-cohesion The module I'm worried about:

Do this now: paste the prompt, name one module you keep breaking by accident, and have your agent map its wires before you cut them.

3.3.1Coupling and cohesion, definedAdd note

3.3.2Keep a change from spreadingAdd note

3.3.3Talk through interfaces, not internalsAdd note

3.3.4High cohesion, low couplingAdd note

3.3.1Coupling and cohesion, defined

3.3.2Keep a change from spreading

3.3.3Talk through interfaces, not internals

3.3.4High cohesion, low coupling