The Problem
Your agent cannot see all the code it depends on
Your repository is only part of the application
Your agent can inspect the files in your repository.
But much of the application’s behavior comes from public frameworks, SDKs, libraries, and transitive dependencies. When the answer lives inside one of those packages, searching the local repository often stops at the import or API call.
The agent can see how your application uses the package. It cannot necessarily see what the package does.
Documentation may describe a different version
Search results and documentation often describe the latest release. Your project may use an older one.
Between versions, method names change. Configuration options move. Defaults, callback arguments, and lifecycle behavior can change too.
Without the source and documentation for the version in use, an agent may combine information from several releases into an answer that was never correct for any one of them.
A plausible change can still be wrong
A generated change may look natural while relying on an incorrect assumption about a dependency.
It might use an option that no longer exists, miss a required initialization step, misunderstand when a hook runs, or depend on behavior that changed between releases.
The mistake may be obvious immediately. It may also appear later, when a particular request, state transition, or edge case reaches that code.
The agent has to recover the missing information
When the agent cannot verify how a dependency works, it has to find another route.
It may search the web, inspect an installed package, clone another repository, try several changes, or ask the developer for help. Any of these can work, but the same investigation must be repeated for each package and version.
- Repeated searches for the same dependency behavior.
- Changes based on stale or mismatched documentation.
- More review to separate verified facts from assumptions.
- More time and model context spent before reaching the actual fix.