Shared code knowledge for an engineering team
A queryable map of services and dependencies gives engineers and their assistants scoped context for planning and reviewing changes.
Results
- lower model cost per question on the main product repository
- 27%
- assistant turns per question, down from 13
- 8
- to set up the graph and the gateway on a new repository
- Under 10 minutes
- of model requests carry a key tied to a person or a service, with a budget
- 100%
Cost and turns were measured on a fixed question set in real assistant sessions, one run per configuration, during the first two months.
Two graph queries replace most of the file reads, so the question is answered in 8 turns instead of 13 and the billed cost is 27% lower on the main repository.
The problem
Cross-service changes needed context from several repositories. Engineers were collecting that context manually and reconstructing dependencies during review.
A change that touched three services needed context from three repositories. An engineer opened each one, searched for the interfaces, read the callers and pasted what they found into the assistant's prompt. The assistant then searched and read the same files again.
That showed up as cost. On the main product repository a structural question took about 13 assistant turns, most of them file reads, before an answer appeared. Nobody could say what the team spent on models per person, because the provider keys sat on laptops.
The project created a shared, queryable model of services and relationships so engineers and assistants could retrieve context for the task. It also gave the team one place to see model spend.
What we built
The shared context layer exposes services, interfaces and relationships for scoped retrieval and change planning.
- Retrieve relevant services and interfaces for a task.
- Inspect dependencies before planning a cross-service change.
- Use the dependency map to identify areas that need testing.
- Prepare release notes from the changes for engineer review.
How we built it
- Indexed each repository into a local code graph of definitions, calls and dependencies, refreshed by a hook after every change.
- Exposed the graph to the assistants as a tool, so a question about callers or dependencies is answered from the index instead of a search across files.
- Put every model request behind one gateway. Each engineer and each service has its own key with a budget, and provider keys stay off laptops.
- Added a console that shows spend per person, team and model, and which sessions used the graph.
- Wrote a benchmark: a fixed set of questions run through real assistant sessions with and without the graph, recording billed cost and turns.
What changed
The team has a common starting point for change planning, dependency review and release preparation. Retrieved context still needs checking against current code and tests; it is not a guarantee that a proposed change is safe.
An engineer planning a cross-service change asks the assistant which services call an interface and gets the list from the graph. Release notes are prepared from the changes and checked by an engineer. Nothing in the graph replaces reading the current code or running the tests.
The saving depends on the question. Discovery-heavy questions across many files got cheaper. On a 134,000-line repository the difference was within run-to-run noise, and a task that already names the exact file gains nothing.
We underestimated how much the gateway would matter on its own. Seeing spend per person for the first time changed model choices more than the graph did in the first month.
How the workflow fits together
What we measured and how
Each figure in the results block comes from one of these measurements.
| What we measured | How | Result |
|---|---|---|
| Model cost per question | Billed cost from real assistant sessions on a fixed question set, run with and without the graph. | 27% lower on the main product repository, 15% lower on a small one |
| Assistant turns per question | Counted from the session records of the same runs. | 7.8, from 13.2 |
| Setup time | Timed on new repositories, from install to a passing health check. | Under 10 minutes |
| Spend attribution | Gateway records: every request carries a key tied to a person or a service. | 100% of requests |
Planning a similar project
These are questions to resolve with your team before implementing a similar workflow.
| Decision | What to establish |
|---|---|
| Context freshness | Which repositories and revisions does the map represent? Make stale or missing context visible before an assistant uses it to propose a change. |
| Access scope | Which engineers and assistants may retrieve each repository or service? Apply the project's access boundaries to retrieval as well as to direct source access. |
| Evidence of value | Can you compare cost, turns and review effort for the same questions with and without the map? Count incorrect retrievals and rework as well, because fewer tokens alone is not enough evidence. |
Questions about this workflow
Does a dependency map prove a change is safe?
No. It helps identify the relevant services, interfaces and areas to test. Engineers still read the current code, review the proposed change and run the tests.
What context do engineers and assistants retrieve?
The layer exposes services, interfaces and relationships for scoped retrieval. A task can pull the relevant context instead of someone assembling a whole-codebase prompt each time.
How should a team evaluate the cost of code-context retrieval?
Run the same questions with and without the graph in real sessions and compare billed cost, turns and rework. Keep model choice and pricing fixed across the comparison. The figures on this page came from one run per configuration, so treat them as the direction and measure your own repository before relying on them.
Discuss your workflow.
Tell us which systems your team uses and where the work gets stuck.