Skip to content
>devspeak
← glossary
patternCommunication Patterns

Isolate the failing component

Ask the agent to narrow down exactly which piece of the app is broken, by checking the pieces separately, before changing anything.

a bit more technical

Narrow a failure to one module, service, or step by testing parts independently: calling an API directly, feeding in known-good inputs, or disabling pieces one at a time until the fault is contained to a single component.

picture it

When a string of holiday lights goes dark, you test the bulbs one at a time until you find the dead one, instead of buying all new lights.

✗ instead of
the sales chart is blank, something's broken somewhere, fix it
✓ try
The sales chart is blank. Isolate the failing component: check the API response, the data conversion, and the chart separately, and report which one is broken before fixing anything.
why it matters

When a feature spans the screen, the server, the database, and outside services, "it's broken" could mean any of them. Isolating the failure keeps your agent from changing four places to fix one.

what your agent might say
agent
I isolated the failure: the API returns correct data, and the chart draws sample data fine. The bug is in the date formatting between them.
how you might use it
you → your agent
The sales chart is empty. Isolate the failing component first: check the API response, the data conversion, and the chart separately, and tell me which one is broken.
common mistake

Changing several things at once to see if the problem goes away. Even if it does, you won't know which change fixed it.

builds on