Hello Devs 👋
One thing I have noticed with AI coding agents is that they are very good at working inside the repository you give them.
You ask the agent to change an API, update a database model, add a field, modify a service, or change some business logic. It searches the code, finds the relevant files, makes the changes, runs some tests, and gives you a result.
For a small application, that might be enough. But real systems are rarely that isolated.
A change in one repository can affect another service, a shared API contract, a frontend application, an SDK, a background worker, or some internal tool that lives somewhere else. The code you are looking at might only be one part of the actual change.
This is where I think AI coding agents still have an interesting problem to solve.
Understanding the repository is not always the same as understanding the system.
The repository in front of the agent is only part of the picture
Imagine you have three repositories.
payments-service
customer-api
checkout-web
The checkout application calls customer-api, and customer-api communicates with payments-service.
Now someone asks an AI coding agent:
Update the payment response to include the transaction status.
- The agent opens
payments-service. - It finds the response model.
- It adds the field.
- The tests pass.
At first glance, everything looks fine.
But what if another repository depends on the exact shape of that response?
- Maybe
customer-apitransforms the response before sending it to the frontend. - Maybe
checkout-webhas its own TypeScript interface. - Maybe an internal reporting service expects a particular field to have a specific value.
The change might still be perfectly valid inside payments-service.
The problem is that the agent may not know what happens outside that repository.
This is one of those things that is easy for a developer who has worked on the system for a few years. You remember that the payment service is connected to another service. You remember an old migration that changed the API contract. You might even remember the pull request where the current behavior was introduced.
An AI agent does not automatically have that memory.
Searching the code is not the same as understanding dependencies
This is why I don't think simply giving an agent a better search tool completely solves the problem.
The agent can search for:
TransactionStatus
- It can find references in the current repository.
- It can search for API routes.
- It can inspect imports.
- It can look through tests.
All of that is useful.
But there is a difference between asking:
Where is this function used?
and asking:
What systems depend on the behavior I'm about to change?
The second question requires more context.
Sometimes that context is spread across repositories. Sometimes it is in pull request history. Sometimes it is in specifications or documentation. Sometimes the reason behind a strange piece of code is buried in an old engineering decision.
That history matters more than we sometimes realize.
The weird code might have a reason
I've seen this happen many times in normal development.
You open a piece of code and think:
Why are we doing this?
This looks unnecessary.
Then someone points you to an old pull request.
And suddenly the code makes sense.
- Maybe the service used to return a different value.
- Maybe another system had a compatibility problem.
- Maybe a customer integration depended on the current behavior.
- Maybe someone intentionally avoided a seemingly cleaner implementation because it caused a production issue.
Without that history, an AI coding agent can make a change that looks better locally but removes an important compatibility decision.
This is one reason codebase context should include more than the current files.
The history of the code can be part of the context too.
This becomes more important with AI-generated changes
Before AI coding agents became common, a developer usually had to spend some time understanding the change before making it.
That did not make developers perfect. We still missed dependencies and introduced bugs.
But there was a natural amount of friction in the process.
- You had to find the repository.
- You had to understand the service.
- You had to search for usages.
- You had to talk to another developer.
- You might look through old pull requests.
Now an AI agent can make a surprisingly large change in a short amount of time.
That is useful.
But it also means the cost of skipping context can become easier to overlook.
If an agent can modify 20 files in a few minutes, we need better ways to answer a simple question:
What else could this change affect?
This is where cross-repository context becomes useful
Qodo has been working on this problem through its Context Engine.
The idea is not just to search the repository where the agent is currently working. Qodo's tooling can use repository relationships, pull request history, specifications, and live Git state to help understand how a change fits into the wider system. Its Agentic Toolbox brings that capability directly into coding-agent workflows.
For example, imagine the developer asks:
Change the customer ID format in the payments service.
Instead of immediately editing the model, a context-aware workflow could first investigate questions such as:
Which repositories consume this value?
Where is the API contract defined?
Are there related pull requests?
Does another service transform this ID?
Are there tests in another repository?
Has this field caused compatibility issues before?
Those questions are much closer to how an experienced engineer would approach the change.
The important part is that the developer doesn't have to manually discover every connection first.
A practical example
Let's say your company has this setup:
checkout-web
↓
order-api
↓
payment-service
↓
payment-provider
You ask your coding agent to change the payment timeout from 10 seconds to 30 seconds.
Inside payment-service, the change is tiny.
10 seconds → 30 seconds
The tests pass. But there might be a timeout in order-api that is still set to 15 seconds.
So the payment service can wait for 30 seconds, but the API sitting in front of it will give up after 15.
The code change is correct inside one repository. The system behavior is still wrong.
This is the kind of problem that is difficult to catch if your review only looks at the changed repository.
A cross-repository view can surface the mismatch before the change reaches production.
AI agents need context before they start coding
There is another part of this that I find important.
We often think about AI review as something that happens after the code is written.
The agent generates the code. Then another tool reviews it.That is useful, but there is also value in giving the agent better context before implementation starts.
Suppose the agent discovers:
The timeout in payment-service is 30 seconds,
but order-api currently has a 15 second timeout.
The existing timeout was introduced in PR #482
because requests longer than 15 seconds were considered failed
by the checkout workflow.
That changes the implementation conversation.
The agent might now ask whether the upstream timeout should also change instead of blindly modifying one number.
That is a much better use of AI than simply asking it to generate code faster.
The agent is helping you understand the system before changing it.
This is also where independent review helps
Even with good context, I wouldn't assume the coding agent will always make the right decision.
The same agent that writes the code is still working toward the requested task.
Having an independent review step gives you another perspective.
Qodo's Agentic Toolbox includes a qodo-review skill that can review committed and uncommitted local changes before a pull request is opened. The review can be run inside the coding-agent workflow rather than waiting until the PR already exists.
So the workflow can become something like:
Developer describes the change
↓
Agent investigates the wider system
↓
Agent checks related history and dependencies
↓
Agent implements the change
↓
Tests run
↓
Independent review
↓
Agent investigates findings
↓
Developer reviews the remaining decisions
↓
Pull request
I like this workflow because it doesn't try to remove the developer from the process.
The agent handles more of the investigation and implementation work, while the developer still makes the decisions that require actual system knowledge.
The biggest change is not faster coding
It is tempting to measure AI coding agents by how quickly they produce code.
How many files can they modify?
How quickly can they finish a task?
How many tests can they generate?
Those are useful measurements, but they don't tell the whole story.
If the agent changes one repository in five minutes but misses an important dependency in another repository, the speed doesn't really help.
The more useful question is:
Can the agent understand enough of the system to make a safe change?
That changes how I think about AI coding tools.
The goal isn't simply to give an agent access to more code.
The goal is to give it the right context for the change it is making.
You don't need every repository connected to everything
There is also a practical limit here.
I don't think the answer is to dump your entire company's source code into every AI coding session.
That would create its own problems.
Most tasks only need a relevant slice of the system.
If you're changing the payment API, you probably need the services that consume that API, the relevant specifications, related tests, and some history around the behavior.
You probably don't need every unrelated repository in the organization.
That is why dependency mapping and contextual retrieval are interesting. The useful question is not:
Give the agent all our code.
It is:
Show the agent the parts of the system that matter for this change.
That is a much more practical approach.
What I would check before trusting an AI agent with cross-repo changes
If your team is starting to use AI agents for larger changes, I would test this with a few real tasks rather than judging the tool from a simple CRUD example.
Give the agent a change that crosses a service boundary.
Ask it to identify affected repositories before writing code.
See whether it finds the relevant API consumers.
Check whether it can find previous decisions from pull request history.
Then intentionally give it a task where changing one repository without changing another would create a problem.
That will tell you much more about the quality of its context than a simple code-generation benchmark.
I would also check whether the tool clearly explains why it thinks another repository is affected. Developers need to be able to verify the reasoning instead of simply trusting a list of files produced by an agent.
Final Thoughts
AI coding agents are getting very good at working inside a repository.
The next problem is understanding what that repository is connected to.
A small change can cross service boundaries, API contracts, shared libraries, databases, and old compatibility decisions. Those relationships are often not obvious from the files that the developer has open.
That's why I think context is becoming just as important as code generation.
Qodo's current Agentic Toolbox is an example of this direction. It brings cross-repository context, pull request history, specifications, organizational rules, and independent review into the coding-agent workflow.
For me, the interesting question is no longer only:
"Can the AI write this code?"
It is:
"Does the AI understand enough of the system to know what this change might break?"
That is a much harder problem, and probably a more important one as coding agents start handling larger engineering tasks.
👨💻 TL;DR
AI coding agents can understand the repository they're working in, but real applications often span multiple repositories and services.
A safe agentic workflow needs more than file search. It needs relevant dependencies, API relationships, previous decisions, specifications, and the ability to review the actual change before it reaches a pull request.
The direction is moving from:
"AI writes code."
to:
"AI understands the system, writes the change, checks the impact, and gets another review before we merge it."
Thank You!!🙏
Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖
Top comments (1)