Coding agents are getting much better at reading software.
They can inspect a repository, understand functions, trace dependencies, write tests and change several files at once.
But there is a problem.
The code does not contain everything an engineer needs to know.
A repository may show that an API exists.
It may not show that the company has decided to stop using it.
It may show two customer tables.
It may not show which one the business actually trusts.
It may show how a service is deployed.
It may not show that another team must approve production changes.
That creates an important difference:
A coding agent can understand the code and still make the wrong decision because it does not understand how the company works.
Accessible text alternative for this figure
Two columns. What the repository shows, which is visible to the agent: source code, tests, APIs and configuration. What the company may also know, which is often outside the repository: service ownership, approved systems and data, security rules and production state.
Imagine a simple production problem
Suppose a developer asks a coding agent:
Fix the checkout service timeout.
The agent opens the repository.
It finds the checkout service.
It finds the slow call.
It identifies a possible fix.
From the code alone, the answer may look correct.
But an experienced engineer may know something the agent does not.
Perhaps that service depends on an API that is being retired.
Perhaps another team owns the dependency.
Perhaps a security rule prevents one type of change.
Perhaps there is already a runbook describing the problem.
Perhaps production changes to checkout require additional approval.
None of those facts necessarily appear in the source code.
The agent may therefore produce a technically correct change that is wrong for the company.
This problem is bigger than coding
Human engineers rarely work from source code alone.
They also use:
- team knowledge
- architecture rules
- documentation
- tickets
- monitoring
- deployment procedures
- security policies
- conversations with other teams.
Over time, engineers learn things such as:
Do not use this API for new work.
This dataset looks newer, but use the validated one.
Payments owns this service.
This production change needs approval.
This failure usually means another system is unavailable.
That knowledge helps them make the right decision.
A coding agent needs some of that information too.
The database example
Consider a simple example.
A coding agent needs customer data.
It finds two tables:
customer_master_v2
and
gold_customer_view
The first one sounds newer.
An agent looking only at names and schemas may decide to use it.
But the company’s data team may know that gold_customer_view is the approved source because it has completed validation.
The SQL written by the agent may be perfectly correct.
The program may run.
The data may even look reasonable.
But the agent still chose the wrong source.
The problem was not poor coding.
The problem was missing company knowledge.
This is why coding assistants are starting to look outside the repository
The major coding platforms are beginning to address this.
GitHub Copilot allows companies and repositories to provide instructions about how work should be done.
Google’s Data Agent Kit helps coding agents access information about a company’s data environment.
OpenAI and Anthropic provide ways for coding agents to use company instructions and connect to other tools and systems.
The products are different, but the direction is similar.
Coding agents are being given information that does not naturally live in source code.
This might include:
- which system should be used
- who owns a service
- how testing should be done
- which data source is approved
- what is happening in production right now.
The important development is not the name of the tool.
It is that the repository is no longer enough.
But giving the agent everything is not the answer
There is an obvious solution:
Give the coding agent access to all company information.
That creates a different problem.
A company may have thousands of documents, tickets, messages and policies.
Some will be old.
Some will conflict.
Some will be irrelevant.
Some will contain sensitive information.
If all of that is given to the agent, the agent may become more confused rather than more capable.
So the goal should not be:
Give the agent everything we know.
A better goal is:
Give the agent the right information for the task.
If the agent is fixing checkout, it may need the checkout runbook, service ownership information and current production alerts.
It probably does not need HR documents or unrelated customer records.
The information also needs to be trustworthy
There is another issue.
Suppose an old document says one thing and a current security policy says another.
Which one should the agent follow?
Human engineers often resolve this through experience.
They know which document is current.
They know which team has authority.
They know which rules are mandatory.
An AI agent may not know that unless the company makes it clear.
This means organizations need to think not only about:
What information can the agent access?
but also:
Which information should the agent trust?
That may become increasingly important as agents are allowed to make larger changes.
Start with one practical question
Companies do not need to build a huge AI knowledge system immediately.
A much simpler starting point is available.
Take one task that coding agents already perform and ask:
What would an experienced engineer need to know that is not in the repository?
For a production fix, that may include:
- service ownership
- deployment rules
- security restrictions
- the current incident status.
For a data task, it may include:
- the approved dataset
- business definitions
- data-quality rules.
For a new feature, it may include:
- architectural decisions
- approved libraries
- product requirements.
Then ask:
Where does that information live today?
That question is useful even if the company never adopts coding agents.
If the answer is:
Only one engineer knows it.
then the company already has a knowledge problem.
Coding agents may expose an old engineering problem
This may be one of the more interesting consequences of coding agents.
Companies have always had important knowledge spread across:
- repositories
- documents
- tickets
- dashboards
- team conversations
- people’s memory.
Humans became good at joining those pieces together.
Coding agents make that fragmentation more visible.
If an agent cannot safely complete a task because essential knowledge is missing, a new AI problem may not be the real issue.
The organization may simply never have made that knowledge clear in the first place.
Perspective
Coding agents are becoming better at understanding software.
But understanding software is not the same as understanding the company that operates it.
The repository can tell an agent what the code does.
It may not tell the agent:
- which system the company trusts
- which team owns the service
- which rule takes priority
- which change is allowed
- what is happening right now.
That is why the next stage of coding-agent development may depend as much on context as on better models.
Before asking:
How powerful is our coding agent?
there may be a more useful question:
Does the agent know enough about how our company works to make the right decision?
If the answer is no, giving it a stronger model may not solve the problem.
Giving it the right information might.
Related reading: AI Agents Need Identities, Not API Keys looks at how an agent proves who it is, and MCP, A2A and WebMCP: Three Connections an AI Agent May Need looks at how agents connect to other tools and systems.
Sources and Further Reading
Source review: 5 October 2026.
- GitHub Docs — Custom instructions for GitHub Copilot. Repository-wide, path-specific, agent and organization instructions, and the order in which they apply.
- GitHub Docs — Adding organization custom instructions for GitHub Copilot. How organization owners set instructions that apply to members across the organization.
- GitHub Docs — Managing custom properties for repositories in your organization. Structured metadata fields that describe repositories, such as ownership or criticality.
- Google Cloud — Data Agent Kit overview. How coding agents can work with Google Cloud data services from the development environment.
- OpenAI Developer Documentation — Agent Skills for Codex. Task-specific instructions packaged for Codex. The companion guide on AGENTS.md is at ChatGPT Learn.
- OpenAI Developer Blog — Shell, Skills and Compaction. OpenAI’s guidance on packaging repeatable procedures as skills.
- Anthropic — Connect Claude Code to tools via MCP. How Claude Code connects to remote tools and data sources.
- Anthropic — Claude Code managed settings. Organization-level controls for Claude Code, including which tool connections are allowed.