Grounding AI Coding Assistants in a Legacy Estate
Coding assistants connected through Model Context Protocol servers to live schemas, prior scripts, change history, orchestration templates and run monitoring: read only, under each engineer's own permissions, with conventions in version control.
- AI Engineering
- Model Context Protocol
- Legacy Modernization
- Engineering Delivery
- Halved
- Engineering time attributable to the toolingA customer onboarding went from about two months to about one month once the tooling was grounded in the estate, and the further reduction to about two weeks came from reference build reuse rather than from the tooling. Observed across a series of deliveries by the team that did the work, not a controlled experiment.
Overview
You rolled out AI coding assistants. Your engineers liked them. Adoption was fine. Then somebody asked what actually changed, and the answer was uncomfortable, because nothing measurable did.
The usual conclusion is that the models are not good enough yet. That conclusion is wrong and it is expensive, because it leads organizations to wait for a better model instead of fixing the thing that was actually missing. A general purpose assistant can write correct code for a problem you have fully described to it. That is not the work. The work is knowing which of several hundred components encodes the behavior you are about to change, what depends on it, how the equivalent problem was solved the last three times, and why a piece of logic was written the way it was by someone who has since left.
We ran this on our own delivery first, on a platform that is unforgiving about being wrong.
The Context
The estate is a regulated multi-customer data platform: isolated environments per customer, more than a hundred transformation procedures in each, orchestration pipelines with enforced execution order, and a small team responsible for all of it. The client is not named.
We publish our own numbers here rather than a client's because they are the ones we can stand behind completely, and because a firm that has not done this to itself is guessing when it proposes it to you.
The Challenge
The gap is not model capability. It is context, and closing it is engineering work rather than a licensing decision. Five things a general purpose assistant cannot see, each of which matters more than model quality.
- Your schemas and structures, live and current and different from whatever is in the documentation
- Prior work: how this exact problem was solved before, the highest value information available and the least accessible
- Change history: what moved, when, and what depended on it
- Conventions: naming, execution order, what is safe to parallelize. Violating them produces plausible code that fails in production
- Operational telemetry: run history and failure detail, which is the difference between diagnosing from evidence and guessing from a symptom
Most organizations have spent twenty years building a genuine knowledge asset and have no way to read it. The interesting use of AI in engineering is not writing new code. It is making the accumulated work legible at the moment somebody needs it.
What Was at Stake
Two or three engineers remain the bottleneck on anything touching the core platform, because only they hold the context. New engineers take months to become useful and nobody can shorten it. When something breaks in production, diagnosis depends on who is available rather than on what is wrong.
That is not a productivity problem. It is key person risk, and for most organizations it is easier to get funded on those terms than as an efficiency case.
Our Role
This was our own delivery, run on a client estate, and it is the same capability we build inside client estates.
- AI engineering: Model Context Protocol server design and production deployment, grounding across schema, prior work, templates and run monitoring, and instruction files encoding team conventions
- Systems engineering: deep knowledge of the estate the tooling reasons over, because grounding is only as good as the understanding of what is worth grounding in
- Security: read only enforcement, identity inherited access, enterprise terms, and separation by function so access boundaries stay visible and reviewable
- Delivery judgment: working out which parts of the work were actually slow, which is the step most AI tooling programs skip and the reason most of them underdeliver
Where You Would Start
Not with a model evaluation. The models are good enough already, which is precisely why swapping them has not helped.
Find out where the time actually goes
Two to three weeks, using your own recent work rather than a survey. Take the last ten pieces of work that took longer than expected and ask, for each one, whether the delay was writing something or finding something out. In most engineering organizations the split is not close, and the answer tells you exactly where tooling should be pointed.
Ground the tooling in your systems, not your documentation
Live structure, prior work, change history, run telemetry. Grounding in what exists rather than in what was written about it is the entire difference between a modest speedup and a measurable one.
Settle the access model before deployment
Read only, caller inherited permissions, separation by function. Far easier to establish at the start than to retrofit once engineers depend on it, and it is what makes the security conversation short.
Write the conventions down and version them
This is how tribal knowledge becomes something the tooling applies consistently, and how it keeps improving without anybody retraining a model.
If it turns out your engineering time is going somewhere else entirely, that is a useful thing to learn in three weeks rather than after a program.
What the Tooling Is Grounded In
Internal assistants connected, through Model Context Protocol servers, to the things an experienced engineer consults before writing anything.
Live database schemas
The real structure across the estate, queried rather than recalled, so generated work references things that actually exist rather than a remembered approximation of them.
Prior scripts and procedures
How the same problem was solved at previous customers. The highest value information in the set and the least accessible without a way to reach it.
Schema and change history
How structures changed over time and what depended on them, which is the question that decides whether a change is safe.
Orchestration templates
Pipeline definitions and the conventions they follow, including execution order and what is safe to run in parallel.
Run monitoring
Execution history and failure detail, so a failing pipeline is interrogated against its own run history instead of reconstructed from memory by whoever happens to be available.
Versioned instruction files
Where team conventions stop being tribal knowledge. They live in version control, they get reviewed, and anyone who notices a gap can close it. That is how the tooling keeps improving without a retraining cycle, and it is the closest thing we have found to institutional memory that does not walk out of the building.
The Access Model
The first thing a security team asks about, and the part most teams get wrong. Each of these is enforced at the connection rather than trusted to behavior.
Read only, always
There is no write path. Nothing generated can alter data, configuration or state.
The caller's own permissions
The connection operates under the permissions of the engineer using it. Broader rights give broader read access, narrower rights give narrower read access. The AI layer introduces no access that an authorized engineer did not already have.
Separate servers per function
Different teams legitimately have different access. Separate servers keep that boundary visible rather than collapsing it into one connection everyone shares.
Enterprise terms
Data is excluded from model training under the agreement the tooling runs on.
Conventions in version control
Instruction files are reviewed like code, so what the tooling applies is inspectable and improvable by anyone on the team.
Contrast that with the implementation most teams reach for first: a single assistant holding one privileged connection shared by everyone. It is faster to stand up and it creates a permanent, invisible privilege escalation path that nothing in your access review will show.
Outcomes
One figure is published, and only the part attributable to the tooling. A customer onboarding went from about two months to about one month with the tooling in place. The further reduction to about two weeks came from reference build reuse and accumulated familiarity, not from the tooling. We could claim the whole reduction and it would be easy to get away with, and we would rather you trusted the number that is real.
- Used every day, heaviest on debugging, where the value is reaching evidence quickly rather than generating code
- Knowledge that existed only in a few people and in prior work nobody had time to read became reachable at the moment of need
- A failing pipeline is interrogated against its own run history rather than reconstructed from memory
The measurement is coarse. Two months to one month is an observed change across a series of deliveries, not a controlled experiment. It is an honest estimate from the people who did the work, and it is described that way wherever it appears.
What This Page Does Not Cover
Published in anonymized form, and the limits here are mostly about what the tooling does not do. The timeline figures are observed estimates from the delivery team rather than instrumented measurements.
- It does not replace understanding the domain. It shortens the path to the relevant information and supplies no judgment about whether a definition is right
- It does not remove the discovery loop. Each iteration gets faster; the iterations remain
- It is not a license purchase. The work is in the grounding, the access model and the conventions, and organizations that buy tools and skip that arrive back where they started
- Read only prevents damage. It does not prevent an engineer reading records they are already entitled to read during debugging, which is governed by permissions, training and access review rather than by an automated egress control
- Client identity, the assistants and models used, and the contents of the instruction files
Related Capabilities
The disciplines this engagement drew on, and where each is described in full.
AI Engineering
Grounding a model in live systems rather than in documentation, and the access model that has to be settled before engineers depend on it.
AI engineering for production systemsEngineering Teams & Managed Delivery
Reducing key person dependency on a platform where two or three people hold the context for everything that matters.
Engineering teams and managed deliveryDevOps & Automation
Run telemetry, orchestration templates and change history, which is the material the tooling reasons over in the first place.
Engineering the path from code to production