AI Doesn't Understand Your Team's Knowledge: The Context Gap in Development Collaboration

Why AI Coding Assistants Don't "Get" Your Project

When you join a new software team, you get access to the GitHub repository, Jira tickets, documentation, and Slack. Everything is technically within reach.

But you still don't know why the architecture looks the way it does, why a certain approach was rejected, what went wrong in the last release, or which decisions are still unresolved. So you start asking people. The problem: the answers are scattered across months of conversations, PRs, tickets, and documents—and the people who know the history are busy building something else.

This isn't just an onboarding problem. The same thing happens whenever someone joins a project, switches teams, revisits old decisions, or takes over work from another engineer.

This problem is amplified in the age of AI-assisted development. AI coding assistants are becoming more capable, but they can only use the context available to them. Your coding assistant may understand the code in front of it, but it doesn't know why your team made a particular decision six months ago; it may see a bug report, but not the discussion that led to the current implementation; it may suggest an approach, unaware that the team already tried and rejected it.

The real challenge isn't always making AI smarter—it's giving AI access to the right knowledge.

Knowledge Silos: The Hidden Cost in the AI Era

Most engineering teams' knowledge is spread across four types of systems: code repositories hold the final implementation, ticketing systems record task assignments and status transitions, design documents capture initial proposals, and instant messaging tools accumulate the most critical discussions and decision-making processes. These four types of information are independent of each other, lacking effective mechanisms to connect them.

When a developer asks a question like: "Why did we choose this authentication flow? What alternatives were rejected? What still needs fixing?"—the answer might involve a PR, a Jira ticket, a design document, and an old team discussion all at once. Today, someone might need to find all four sources and then manually reconstruct the entire story.

The cost of this process is hidden—it doesn't show up in lines of code or deployment frequency, but it directly consumes engineers' most valuable attention. Worse, when the people who know the history leave, that context may be permanently lost.

Retrieval-Augmented Generation (RAG) and Context Supply

Understanding why AI coding assistants don't "get" a project requires distinguishing two types of context supply. One is placing materials like code and documents directly into the model's context window—limited by window length, it can't cover months or even years of team history. The other is retrieval-augmented generation (RAG)—splitting enterprise knowledge into fragments stored in a vector database or index, retrieving the most relevant fragments when a question is asked, then handing them to the model to answer. RAG lets AI avoid having to "remember" all history, instead calling it up on demand. But RAG's effectiveness depends heavily on retrieval quality: if decision reasoning only exists in Slack conversations and isn't indexed, or if PR descriptions are vague, retrieval can't surface the key fragments, and the model can only offer seemingly reasonable suggestions based on incomplete context—suggestions that retread old ground. This is precisely the technical necessity behind the article's emphasis on "connecting information across systems."

LISA's Approach: Making Knowledge Traceable and Verifiable

Developers are building LISA, with the goal of helping companies make their existing knowledge useful to employees and AI tools. The core idea is to connect information across enterprise systems, helping people find answers without manually searching multiple tools, understand the history behind project decisions, keep up with ongoing work and unresolved issues, preserve context during team changes and project handoffs, and verify answers against the company's underlying sources.

This vision goes beyond search itself. The goal is to keep company knowledge useful even when the people who originally created it can no longer explain it.

Taking the authentication flow as an example, LISA aims to let developers get comprehensive answers from PRs, tickets, design documents, and team discussions in a single query—answers that are well-sourced and governed by company permissions. Achieving this requires four key attributes: knowledge must be accessible, contextual, verifiable, and controlled by the organization.

Knowledge Graphs and Entity Linking

Connecting PRs, tickets, design documents, and discussion threads into a complete story is essentially a knowledge graph problem: each PR, ticket, document, and message is a node, and the relationships between them—"references," "resolves," "rejects," "replaces"—are edges. Traditional search matches isolated documents by keyword, while a knowledge graph can traverse edges, linking the PR related to "authentication flow" with the conversation that originally discussed it and ultimately rejected an alternative. For enterprise scenarios, the graph can also carry permission metadata, so different roles can only see the nodes they're authorized to access—providing context while meeting compliance requirements. What LISA pursues as "verifiable" depends largely on this kind of explicit entity-linking structure, rather than letting the model infer relationships between documents out of thin air.

Three Real Questions for Team Knowledge Management

This direction raises questions worth considering for every engineering team.

How does your team preserve the reasoning behind technical decisions? Code comments and documentation usually only record "what was done," not "why it was done." Rejected alternatives, the details of trade-offs, the constraints at the time—these often exist only in the memories of the people involved.

When new developers join a project, can they discover on their own why things work the way they do, or do they have to ask whoever was there at the time? If the answer is the latter, the team is suffering an unnecessary knowledge-transfer bottleneck.

When an AI assistant makes a suggestion, how do you know whether it's aware of approaches the team has already tried and rejected? Without the support of an enterprise knowledge base, AI's code suggestions may repeat detours the team has already taken.

The common thread running through these questions: as AI-assisted development becomes increasingly widespread, the way enterprise knowledge is organized needs to shift from "people finding information" to "information flowing with people." Connecting context scattered across systems so that AI and humans share the same verifiable knowledge foundation may be the key prerequisite for unlocking AI coding's true potential.

Architecture Decision Records (ADRs) and Decision Trails

The article repeatedly mentions how hard it is to preserve "why it was done this way." The industry has a dedicated practice for this: Architecture Decision Records (ADRs). In short document form, an ADR records the context, alternatives, final choice, and rationale for each significant technical decision, version-controlled alongside the codebase. The value of ADRs lies in making implicit reasoning explicit, so that someone six months later—or an AI assistant—can read "why alternative B was rejected at the time." However, ADRs typically only cover formally recognized architecture-level decisions; day-to-day trade-offs and temporary compromises still scatter across PR comments and chats. ADRs are therefore necessary but not sufficient—truly complete context still requires integration with ticketing, discussions, and other systems, echoing LISA's direction of consolidating multi-source information.

One-line Summary

AI coding assistants are limited by context; enterprises need to break down knowledge silos so AI and humans share a verifiable knowledge foundation.

Paragraph Summary

The article points out that while AI coding assistants can understand the code in front of them, they can't know the reasoning behind a team's decisions from months ago, the alternatives that were rejected, or unresolved issues—because these are scattered across four mutually isolated systems: code repositories, ticketing systems, design documents, and instant messaging tools. This problem isn't limited to onboarding; it recurs during team changes, decision reviews, and project handoffs, bringing hidden costs—consuming engineers' attention and potentially losing context permanently when key people leave. To address this, developers are building LISA, attempting to connect information across enterprise systems to make knowledge accessible, contextual, verifiable, and permission-controlled. The article thus prompts teams to reflect on how to preserve decision reasoning, break through knowledge-transfer bottlenecks, and shift from "people finding information" to "information flowing with people."