Open a repository six months after a feature shipped and you can reconstruct a lot. You can trace the architecture, inspect the schema, read the tests, and see exactly which lines changed.
What you usually cannot reconstruct is the conversation that made those lines necessary.
The code will not tell you that a validation rule exists because one customer sends malformed exports. It will not explain that a strange retry policy prevents duplicate transactions in a downstream system. It will not show that the cleaner interface was rejected after an accessibility test, or that a service boundary reflects a contractual restriction rather than an engineering preference.
Git is excellent at preserving code history. It preserves intent only when a team deliberately writes that intent down and keeps it connected to the implementation.
That gap has always been part of software engineering. AI coding tools make it more visible. A system can read every file in a repository, follow every symbol, and generate a technically convincing patch while still solving the wrong problem.
The problem is not that the code is misleading. The code is answering a narrower question.
Five layers of engineering truth
Most meaningful software changes depend on five different layers of evidence.
- Intent — What outcome is the user, customer, or business asking for? This may live in a specification, ticket, support conversation, or meeting note.
- Constraints — What must not break? Compatibility promises, security boundaries, regulations, contracts, budgets, and deadlines often sit outside the repository.
- Implementation — How does the system work today? The code, tests, schemas, dependencies, and deployment configuration provide this layer.
- Runtime evidence — What is happening in the real system? Logs, traces, metrics, production data, and incident reports can contradict assumptions that look reasonable in code.
- Decision history — Why was the current approach chosen? Pull requests, design discussions, rejected alternatives, and previous incidents hold the answer.
The repository is strongest in the third layer. It contains parts of the others, but rarely enough to represent them completely.
This matters because software failures often appear at the boundaries between layers. The implementation matches an outdated specification. The fix satisfies the ticket but violates an operational constraint. The tests pass because they encode yesterday’s assumptions. The code is internally consistent while production data follows a pattern nobody documented.
A locally correct patch can still be the wrong change.
What the repository cannot answer by itself
Consider a user who edits a document and then searches for the updated sentence, only to see the old version in the results. “Make search update immediately” sounds like a clear request. The repository reveals several possible places to begin, but it cannot define the correct fix on its own.
| Question | Likely source |
|---|---|
| Which version of the document is authoritative? | Source document and revision history |
| Where does the old text remain? | Sync logs, extraction output, search index, or cache |
| What does “immediately” mean for this product? | Product promise or service objective |
| Did the document's permissions change with its content? | Source permissions and audit history |
| Is the stale result limited to one user, source, or region? | Request traces and production metrics |
The search code may explain how results are returned. It cannot tell you whether the real defect is synchronization delay, stale extraction, cache invalidation, permission propagation, or an expectation the product never defined.
This distinction becomes even more important in mature systems. A field that looks obsolete may still support a legacy client. A duplicate-looking service may separate data with different permission requirements. An apparently excessive check may be the only code-level trace of a production incident the current team never saw.
Deleting complexity is valuable. Deleting history disguised as complexity is expensive.
More context can still produce the wrong answer
The obvious solution is to give the AI more material: the whole repository, every ticket, every document, every message, and every log.
That creates access, not understanding.
Sources can be stale, contradictory, speculative, or written for different audiences. A brainstorm should not outrank an approved specification. A six-month-old requirement should not silently override yesterday’s product decision. A production log should be tied to the release, environment, and code path that produced it. A customer request should not be treated as a universal requirement without checking scope.
A serious context system therefore needs more than retrieval. It needs a way to reason about:
- Authority: Which source is allowed to define the requirement?
- Recency: Which information is current, and what has been superseded?
- Provenance: Where did each claim, constraint, or conclusion come from?
- Relationships: Which issue, release, customer, dataset, and code path belong together?
- Permissions: Which sources may be used for this task and shown to this person?
Context is not a pile of tokens. It is a graph with time, authority, and boundaries.
More context should produce more evidence, not more confidence without evidence.
The real unit of work is the change
Editors and coding tools are organized around files because files are what we modify. Engineering teams are organized around changes.
A change starts with a reason. It becomes a requirement, touches code and data, passes through review, reaches production, and creates new evidence. If those stages remain disconnected, every future task begins with another round of archaeology.
An AI system working on real software should follow that lifecycle.
Before implementation, it should identify the request, the relevant constraints, and any conflicting sources. It should know whether it is fixing a defect, changing expected behavior, or introducing a new contract.
During implementation, it should connect each meaningful choice to evidence. Why this module? Why this migration strategy? Why preserve this branch? The explanation should survive beyond the chat that produced the code.
After implementation, it should attach verification results, review decisions, and newly discovered constraints to the change. Otherwise the next person—or the next AI session—will have to rediscover them.
This is the difference between a tool that can edit a repository and a system that can participate in engineering work.
AI should reduce reconstruction, not remove judgment
Better context is sometimes presented as a path to autonomous software development. The immediate value is less dramatic and more useful: reducing the cost of reconstructing reality before making a change.
AI can bring the original requirement next to the relevant code. It can surface the incident that explains an unusual safeguard. It can connect a failing metric to the release that changed it. It can show that two authoritative sources disagree before implementation begins.
Those capabilities do not remove engineering judgment. They make judgment better informed.
A person still has to decide which tradeoff is acceptable, whether a requirement is complete, and how much risk a release can carry. The system should make the evidence visible and the reasoning inspectable. It should not hide uncertainty behind a polished patch.
The standard is not “can it generate code?”
The standard is “can it explain why this is the right change now?”
From repository-aware to work-aware
Coding assistants first became useful by understanding the file in front of the developer. Repository awareness was the next major step: finding related code, following symbols, and applying changes across a project.
The next step is awareness of the work around the repository.
That means connecting code to the specification that requested it, the conversation that clarified it, the production evidence that challenged it, and the decision that should be remembered afterward. It also means excluding context that is irrelevant, outdated, or outside the user’s permissions.
While building Dvina, this is one of the ideas we keep returning to. Work does not happen inside a single file, application, or conversation. Meaning lives in the connections between them and in how those connections change over time.
The repository remains essential. It is the executable source of truth for system behavior. It is simply not the complete source of truth for product intent, operational reality, or organizational memory.
The whole story changes what gets built
With only the code, the natural question is:
What change fits this system?
With the wider context, the question becomes:
What change fits this system, this requirement, this history, and this moment?
That second question catches constraints before they become regressions. It gives reviewers the reasoning behind the implementation. It helps new team members understand why the system looks the way it does. It gives AI a grounded role: not an oracle inside the editor, but a participant that can assemble evidence across the work.
Your repo was never the whole story.
The opportunity is to build systems that can read the rest of it—and show their work.
