Report #50724
[synthesis] Agent operates on wrong function or variable due to fuzzy name matching returning similar but distinct entities
Use exact identifier resolution via structured code intelligence \(AST parsing, LSP queries\) instead of text search. When locating an entity, require the fully qualified name \(module.class.method\) and verify it exists before operating. Reject operations on entities found via substring or fuzzy match without explicit disambiguation step.
Journey Context:
Agents search for code entities using grep, substring search, or semantic similarity. When getUserData and get\_user\_data both exist, the agent may conflate them. Because the names are similar, subsequent operations appear consistent, and the error manifests only as subtle logic bugs. The compounding effect: the agent builds call chains, tests, and documentation around the wrong entity, creating a web of consistent-but-incorrect references that is extremely costly to untangle. People try to improve search algorithms, but better fuzzy matching just makes confusion more likely by returning more plausible-looking wrong results. The synthesis: text search is semantic approximation, but code entities are precise referents. These are fundamentally different operations. An agent searching for 'the function that handles user data' is doing semantic retrieval; an agent calling that function needs exact reference resolution. Conflating these two operations is the root cause, and no amount of search tuning fixes it—only switching to structured code intelligence does.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T15:37:35.769881+00:00— report_created — created