Abstraction-layer drift
Patching at the wrong layer. Fixing a data-shape bug in CSS, swallowing a logic error in a try/catch, regex-fixing a parser problem.
What it is
A change that addresses a symptom at a level downstream of where the actual problem lives: CSS overrides for a state-management bug, a try/catch that hides a logic error, prop-drilling around a missing context, a regex tweak compensating for a malformed parser, validation in the form layer for a constraint that belongs in the schema. The fix often works locally; the architecture absorbs the drift and gets harder to reason about.
Why models do it (first principles)
The model is heavily biased toward the layer the user pasted in. If the visible code is a stylesheet, the proposed fix is a stylesheet change; if the visible code is a component, the proposed fix is a component change. Tracing the problem upstream to its actual layer requires holding the system in mind beyond the snippet, which the training distribution rarely demands. Local edits also score well as 'minimal changes' even when minimal-at-this-layer is maximal-elsewhere.
How to think about it
Every system has a layer where each kind of problem belongs. Fixing a problem at the wrong layer is not just inelegant. It loads the wrong layer with logic it was not designed to carry, and the next person debugging that layer has to discover the displaced concern by surprise. The fix works by accident of where the symptom surfaced, not by understanding of where the cause lives. The cost compounds: every later change at the correct layer now has to account for the displaced patch, and every later change at the patched layer has to preserve it without knowing why it's there.
Examples
The list is rendering duplicates — add `:nth-child` CSS to hide every other one.
The list is rendering duplicates because the upstream query returns duplicate rows. Dedupe at the data layer (DISTINCT in the query, or a Set keyed by id when transforming the response) so every consumer of this data sees it correctly.
The function sometimes throws — wrap the call site in try/catch and return `null`.
Find why it throws. If it's a contract violation (bad input), validate at the boundary; if it's an expected condition (not-found), return a Result type from the function itself. A try/catch that swallows the error hides the actual failure and shifts the cost of debugging it to whoever sees the silent `null` next.
Fix prompt
Fix problems at the layer they belong to, not at the layer where they happen to surface. A symptom appearing in CSS, in a component, or at a call site is information about where you noticed the problem, not necessarily where it lives. And patching at the wrong layer loads that layer with logic it was not designed to carry, leaving the next reader to discover the displaced concern by surprise. Trace the symptom upstream until you find the layer where the concern actually belongs, and fix it there; if you must patch at the wrong layer for a real reason, name the reason in the change.
Watch for
Concrete phrasings this pattern usually shows up as. These are not part of the copyable prompt. The prompt teaches the principle so the model can recognize the move even when the exact phrasing differs. Use this list to self-audit your own writing or to test a model.
- CSS overrides used to compensate for component state bugs
- try/catch that returns a default instead of handling the actual failure
- regex patches over malformed-parser output
- validation in the UI for constraints that belong in the schema
- prop-drilling around a missing context
- config flags added to work around a design problem