Jun 8, 2026·Ideas
Why Hasn't Anyone Solved the Context Gap in the SDLC Yet?
Coop·6 min read
The tools engineering teams use every day generate enormous amounts of institutional knowledge. Almost none of it reaches the editor.
Engineering teams have never had more AI tooling at their fingertips. Copilot, Cursor, Cline, Continue. The list grows every quarter. And most of these tools are genuinely impressive at what they do inside the codebase. But across the largest and most complex engineering organizations in the world, a problem persists that none of them have fully solved.
Context.
Not the codebase context these tools are built around. The other kind. The kind that answers questions like why a service was built the way it was, who made the architectural calls that shaped it, and what was discussed, debated, and decided before a single line of code was written.
That context does not live in the repo. It never did.
What changed
For most of software engineering's history, the context gap was a productivity tax. Engineers spent time reconstructing decisions, tracking down owners, and piecing together architectural history that existed somewhere in the organization but not anywhere useful. The cost was real but diffuse, spread across thousands of small delays that rarely surfaced in a postmortem.
The shift toward agent-assisted development has made the gap structural rather than incidental. As agents take on more of the code generation work, the engineer's role has moved toward review, evaluation, and judgment. That work is harder to do well without deep context. When an agent produces a change to payments-orchestrator, the engineer reviewing it needs to know why that service is structured the way it is, which downstream systems depend on it, what constraints shaped its original design, and who owns it today. The codebase can answer some of those questions. The rest of the answer is scattered across a Slack thread from fourteen months ago, a Jira ticket that was closed without comment, and a Notion doc that three people contributed to during a planning sprint and nobody has opened since.
The current generation of AI coding tools handles the code layer well. They can tell you what a service does. They have no way to tell you why it was built that way, or what was decided and rejected before the implementation you are looking at now.
The questions that go unanswered
The gap shows up most clearly in the questions engineers ask regularly that take far longer to answer than they should.
"What is the blast radius if I make changes to payments-orchestrator? Which downstream services will be affected and which repos do I need to flag?"
"Can you trace back every owner of auth-service across version history and show me when significant changes were made?"
"Summarize infra-provisioning-core for me. Who originally built it, what was the design intent, how has it evolved, and who should I talk to before making a significant change?"
These are not edge cases. They are the standard work of maintaining and extending software at scale. Right now, answering them requires leaving the editor, searching across multiple systems, and assembling a picture manually. That process is slow, error-prone, and entirely dependent on whether the right information was captured in the first place and whether the person who captured it still works there.
Why the problem compounds at enterprise scale
On a small team, institutional memory lives in people. The same engineers were in the room for most of the decisions that matter, and a question like "why is this service structured this way" has an obvious answer: ask whoever built it.
At two hundred engineers, five hundred, a thousand, that breaks down. Specialization and organizational structure mean that no single person carries the full picture of any significant system. When people leave, which happens continuously, the context they carried leaves with them. There is no system that catches it reliably, and the codebase alone cannot reconstruct what was intended versus what was merely implemented.
There is also a direct cost to getting this wrong that tends to be underweighted. The quality of a response from a large language model is directly proportional to the quality of the context it receives. Engineers working with incomplete context are not just slower. They are generating worse prompts, receiving less useful responses, and spending more tokens on follow-up exchanges to compensate. At enterprise scale, that inefficiency compounds into a meaningful cost.
Why connecting tools has not solved it
The infrastructure for integration exists. MCP servers make it easier than ever to pipe data between systems. Retrieval pipelines can index Slack and Confluence. APIs expose most of what engineering teams produce.
The problem is that access to information and delivery of context are not the same thing.
Most approaches that exist today require engineers to leave the editor, navigate to a separate tool, construct a query, and assemble an answer from whatever comes back. That is not context delivery. That is search with extra steps, and it puts the assembly burden back on the engineer at exactly the moment they can least afford it.
Useful context has three properties that most current approaches do not satisfy simultaneously: it is relevant to what the engineer is looking at right now, it is precise enough to be actionable, and it arrives in the flow of actual work without requiring the engineer to go looking for it.
What Coop does differently
Coop is an enterprise AI coding assistant for VS Code built around a single architectural premise: the codebase is the foundation, but institutional context lives everywhere, and engineers should not have to leave their editor to access it.
Coop connects to your code hosts, your Slack, your Jira, your Notion, your Confluence, and your Google Docs. It indexes that content and makes it available inside VS Code, tied to the specific code, service, or repo the engineer is working with. When an engineer asks about the blast radius of a change to payments-orchestrator, Coop surfaces the downstream dependency graph alongside the Slack threads and Jira history that explain why those dependencies exist. When they ask for the ownership history of auth-service, they get a complete picture across version history without leaving the editor.
For enterprise teams, Coop includes SAML 2.0 SSO, admin controls, multi-repo collection management, and SOC2-ready audit logging. It supports GitHub, GitLab, and Bitbucket. The install experience is intentional: no local tooling requirements, no configuration overhead. You install it and it works.
The context gap is not inevitable. It is an engineering problem, and it has a solution.
Join the waitlist
We are opening early access to engineering teams now. If your organization is spending engineering cycles reconstructing context that already exists somewhere in your stack, we would like to talk to you.