Syntax over semantics (orphan-blaming)
Proposing a locally-correct fix without tracing the call path. Pattern-matching the shape of a solution and skipping the data-flow audit.
What it is
A response. Usually about code, but the shape generalizes. That fixes the visible symbol without verifying whether the symbol is actually reached, what calls it, what it returns into, and whether the change propagates correctly. The fix is syntactically valid and locally plausible; it just doesn't sit in the system the way the writer assumes.
Why models do it (first principles)
Code in the training data overwhelmingly appears as snippets, not as traced call graphs. The model has very strong priors over 'what a fix to this kind of expression looks like' and very weak priors over 'what this expression's call path actually is in this specific codebase'. It is much cheaper to produce the locally-correct shape than to trace the data flow, and the local shape gets reinforced by every snippet-shaped example in the training set.
How to think about it
Syntax is the shape; semantics is what the shape does once it's wired in. Fixing the shape without auditing the wiring produces solutions that read as competent at the line level and fail at the system level. The orphan symbol gets blamed before the actual fault is located. The deeper move is the same as in prose slop: pattern-matching the silhouette of a correct response without doing the underlying reasoning that would have produced it. Code without a proven call path is debt; the debt just compounds invisibly until something downstream breaks.
Examples
The function isn't returning the right value — change `return data` to `return data.value` and that should fix it.
Before changing the return shape, trace one call site: what is the caller doing with the returned value? If the caller already does `.value`, your fix will break it. The bug might be at the call site, not the function.
This component isn't rendering — wrap it in a useEffect.
First confirm the component is actually mounting. Add a console.log at the top of the body. If it never logs, the problem is upstream (parent isn't rendering it, route isn't matching). useEffect doesn't fix a component that isn't being called.
Fix prompt
Treat syntax as subordinate to semantics. Before proposing a code fix, trace the data flow: what reaches this code, what does this code reach, and what would change downstream if you altered it. A locally-correct change applied without that trace is pattern-matching the shape of a fix while skipping the reasoning that would justify it. Neither you nor the reader can tell the difference until something downstream breaks. When the call path is not visible to you, say so and name the next thing you would check (which file, which caller, which value at runtime) instead of confidently editing the symbol in front of you. A symbol that looks unused, broken, or wrong in isolation is not evidence of the fault. It is a prompt to go locate the fault.
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.
- just change X to Y and that should fix it
- wrap it in useEffect / try-catch / a memo
- add a null check there
- this should work — try it
- I don't see it being used, so just remove it