AI Coding Assistants Don’t Just Need More Code. They Need Better Context.

Why I built ArchMind to help AI coding assistants understand codebases through structure and relationships.

AI coding assistants have become remarkably good at writing code.

They can generate API handlers, refactor functions, explain unfamiliar syntax, and help developers move through implementation tasks faster than ever. But as software projects grow, a different challenge becomes increasingly important:

How do we help AI understand a codebase, rather than just the code it can see?

A function rarely tells the whole story.

To understand what a function actually does within a system, we may need to know who calls it, which entry points lead to it, what services it depends on, and whether it participates in a database transaction or modifies application state.

That information is often distributed across multiple files and layers of an application.

An AI model may have access to the relevant source code and still lack a clear picture of how those pieces fit together.

This is the problem that led me to build ArchMind.

1. Code Is More Than Text

Imagine working on an unfamiliar backend service.

You find a function called UpdateBalance. Its implementation looks straightforward: update an account balance and return a result.

But before modifying it, you need to answer several questions:

• Which HTTP endpoints can reach this function?
• Is it also called by a background worker?
• Which services or repositories does it depend on?
• Does it execute within a database transaction?
• Could changing its behavior affect other parts of the system?

Reading the function alone may not answer these questions.

You need context about the function’s relationships with the rest of the application.

A developer can often reconstruct this information by navigating through files, searching for references, following function calls, and building a mental model of the system.

AI coding assistants need useful representations of these relationships, too, especially when the relevant context is not already available to them.

Understanding an individual code fragment is different from understanding its role in a software system.

The challenge is not simply finding code that looks relevant. It is identifying the structural relationships that make that code meaningful.

2. Why More Context Is Not Always Better

One intuitive solution is to give the model more source code.

If one file is insufficient, include five. If five are insufficient, include the entire module.

However, more context does not automatically produce better understanding.

Large codebases contain many details that are irrelevant to a particular task. Even when useful information is available, the model still needs to identify which parts matter and how they relate to one another.

Several problems can arise.

Irrelevant information. A large collection of files may contain the answer, but important details can be surrounded by unrelated implementation code.

Missing relationships. Individual source files show implementation details, but the connections between entry points, functions, services, and side effects may not be immediately obvious.

Limited context budgets. Supplying more information consumes tokens and can increase processing costs. Eventually, the system must decide what to include and what to leave out.

Incomplete structural understanding. Keyword search can locate a function without explaining how execution can reach it.

These challenges do not mean that larger context windows or retrieval-augmented generation are ineffective. They are useful techniques.

The question is whether we can improve the quality of the context before passing it to the model.

Instead of asking only:

Which code should we retrieve?

We can also ask:

What do we know about the structure of this codebase, and which relationships are important to the current task?

That question became a central idea behind ArchMind.

3. Introducing ArchMind

ArchMind is a code intelligence and context retrieval project designed to help AI coding assistants work with structured information about a software project.

Its core idea is straightforward:

Analyze the codebase, represent meaningful relationships, and use that structure to retrieve more relevant context.

At a high level, the workflow looks like this:

Source Code → Code Analysis → Code Graph → Context Retrieval → AI Coding Assistant

The analysis stage extracts information about the project and its components. The resulting graph represents relationships between code elements. A retrieval layer can then use this information to select context relevant to a particular request.

This approach shifts part of the work from asking an LLM to infer everything from raw text toward providing it with structured evidence about the codebase.

The goal is not to replace the model’s reasoning. It is to give that reasoning a more useful foundation.

[Insert the ArchMind architecture diagram here.]

The important part is not simply creating a graph.

A graph is useful only if it captures relationships that help answer real engineering questions.

Knowing that a function exists is one thing. Knowing which application entry points can reach it is another.

Similarly, finding a database-related function is not the same as understanding whether it is called within a transaction or whether it may have side effects beyond the database.

ArchMind explores how structural analysis can make these relationships available to downstream AI tools.

Its analysis capabilities vary by language and framework, so the available information depends on what the relevant parser and analysis components can resolve.

That limitation matters: static analysis does not automatically reveal every possible runtime behavior. The objective is to provide useful structural evidence, not to claim perfect understanding of every program.

4. A Practical Example: Tracing a Go Function Back to Its Entry Point

Let’s make this idea more concrete.

Consider a simplified Go backend that exposes an endpoint for updating an account balance.

The following code is illustrative. It demonstrates the kind of relationship ArchMind’s Go symbol-context analysis is designed to investigate; it is not a claim that these exact functions exist in the ArchMind repository.

func (h *AccountHandler) UpdateBalance(c *gin.Context) {
    accountID := c.Param("id")

    if err := h.service.UpdateBalance(c, accountID); err != nil {
        c.JSON(500, gin.H{"error": err.Error()})
        return
    }
    c.JSON(200, gin.H{"status": "updated"})
}

The handler delegates the operation to a service:

func (s *AccountService) UpdateBalance(
    ctx context.Context,
    accountID string,
) error {
    return s.db.Transaction(func(tx *gorm.DB) error {
        if err := tx.Model(&Account{}).
            Where("id = ?", accountID).
            Update("balance", gorm.Expr("balance + ?", 100)).
            Error; err != nil {
            return err
        }

        return nil
    })
}

Suppose a developer asks an AI assistant:

Where is AccountService.UpdateBalance used, and what should I understand before changing it?

A basic code search might return the service function and perhaps a few matching references.

That is a starting point, but it may not reveal the full execution context.

A structural analysis can approach the question differently.

Step 1: Locate the symbol

The analysis identifies the target function and its source location.

Get Kidkender’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This gives the AI a concrete starting point rather than relying only on a text search result.

Step 2: Trace relationships backward

The analyzer investigates which project entry points can reach the target function.

In this illustrative example, the relationship is:

HTTP Request
    |
    v
AccountHandler.UpdateBalance
    |
    v
AccountService.UpdateBalance
    |
    v
Database Transaction
    |
    v
Account Balance Update

This is more informative than knowing that the handler and service happen to exist in the same project.

It expresses a relationship between the application’s external entry point and the operation being investigated.

For a real codebase, there may be multiple routes, additional service layers, background workers, or indirect calls. The analysis can only report relationships it can resolve.

Step 3: Inspect the transaction context

The target function opens a database transaction and performs a database update inside its callback.

That gives the AI additional context for questions about transaction boundaries and database changes.

But there is an important distinction here.

The fact that a function participates in a transaction does not, by itself, prove that the operation is correct or incorrect. A deeper investigation may need to examine error handling, transaction boundaries, external side effects, concurrency, and the behavior of other functions.

Structural analysis provides evidence that helps guide that investigation. It does not replace it.

Step 4: Return focused context

Instead of supplying an unfiltered collection of source files, an integration can provide a compact summary of the relevant symbol and its relationships.

For example, the conceptual output might look like this:

Symbol:
  AccountService.UpdateBalance

Reachable from:
  HTTP route -> AccountHandler.UpdateBalance
Relevant context:
  Opens a database transaction
  Updates account balance
  Called through AccountService
Investigation points:
  Transaction error handling
  Other callers of the service method
  Potential side effects outside the database

This is a simplified illustration of the information a developer might want. It is not a literal output sample from ArchMind.

The distinction is important: the goal is not to invent findings, but to organize the evidence that the analyzer can actually establish.

What changes for the AI assistant?

The model still needs to reason about the code.

It still needs to interpret the implementation, understand the developer’s intent, and determine whether a proposed change is appropriate.

What changes is the information available at the start of that reasoning process.

Instead of seeing only a function definition, the assistant can receive additional evidence about where the function fits into the application’s execution structure.

The improvement is not necessarily more code in the prompt. It is more meaningful relationships in the context.

That is the idea behind ArchMind’s Go symbol-context capability, exposed through archmind_symbol_context.

5. The Engineering Challenge: Useful Structure Without Excessive Complexity

Building code intelligence tooling introduces its own set of challenges.

A simple parser can identify functions and classes, but understanding how those elements relate requires more work.

Real codebases contain interfaces, callbacks, method receivers, asynchronous execution, framework conventions, and indirect dependencies. Different languages also expose different information through their syntax and type systems.

Even when a relationship can be identified, the next challenge is deciding whether it is useful for a particular query.

A retrieval system that returns every connected node may produce an enormous amount of context. A system that returns too little may omit a critical dependency.

This creates a trade-off between coverage, relevance, and context size.

For ArchMind, I have been exploring how structured representations and focused retrieval can help navigate that trade-off.

The objective is not to expose the entire internal graph to an AI model for every request. It is to select a useful subset of the available information.

There is also an important distinction between different kinds of evidence.

A source-level call relationship is not the same as a runtime trace. A transaction-related pattern is not necessarily proof of a production bug. A static analyzer may identify a potential issue that requires further investigation.

Keeping these distinctions clear is essential if code intelligence tools are going to be useful in real engineering workflows.

I believe this is one of the most interesting parts of the problem: building a system that provides richer context without overstating what its analysis can prove.

6. Connecting Code Intelligence to AI Workflows

Structural analysis becomes more useful when it can be consumed by the tools developers already use.

ArchMind includes MCP integration so compatible AI clients can access code intelligence capabilities through a standardized tool interface.

This creates a bridge between two different responsibilities:

• Code intelligence tooling analyzes the project and exposes structured information.
• The AI assistant uses that information as part of its broader reasoning and interaction with the developer.

Rather than requiring every AI client to independently implement the same source-analysis logic, a dedicated tool can provide a reusable way to retrieve information about the codebase.

The model can then use that information alongside source code, user instructions, and other available context.

This does not guarantee that every answer will be correct. The quality of the result still depends on the analysis, the retrieved evidence, the model, and the task itself.

But it provides a practical direction for improving how AI systems interact with complex software projects.

7. A Small External Milestone

Recently, I received a message from Ivan, founder of XERJ, explaining that the archmind_symbol_context implementation in ArchMind had been selected for inclusion in the public XERJ Corpus Hub, with attribution under the MIT license.

I appreciate the recognition.

For me, this is a welcome milestone for one part of the project, particularly because it relates to a concrete engineering capability rather than just a high-level product idea.

It also reinforces why I enjoy working on this problem: there is room to combine static analysis, software architecture, retrieval, and AI tooling into something that addresses a practical developer need.

The work is still evolving, and there is much more to explore.

8. What I Want to Explore Next

I see code intelligence as a useful layer between raw source code and AI-assisted software development.

There are several questions I want to keep exploring.

How can we improve retrieval precision? A structurally connected piece of code is not always relevant to the current task. Better selection is just as important as better analysis.

How should static and runtime information complement each other? Static analysis can reveal potential relationships across a codebase, while runtime observations can provide evidence about what happened during a particular execution.

How can we make findings more explainable? When a tool returns a relationship or flags a potential issue, developers should be able to inspect the evidence behind that result.

How can the same approach support different languages and frameworks? Each ecosystem has different conventions and analysis challenges. Reusable representations and language-specific analysis will both matter.

These are not problems that can be solved by adding an LLM call to every step. They require careful engineering, explicit trade-offs, and a clear understanding of what each component can and cannot establish.

That is what makes this project interesting to me.

Conclusion: Better Context for Better Engineering

AI coding assistants are becoming increasingly capable, but working with a complex codebase requires more than access to source text.

It requires understanding relationships: how functions connect, how execution flows through a system, and where a piece of code fits into the broader architecture.

ArchMind is my exploration of how structural code analysis and relationship-aware retrieval can help provide that context.

The ambition is not to make AI understand every codebase perfectly. It is to make useful information about a codebase easier to discover, inspect, and provide to AI tools.

I believe the future of AI-assisted software development will depend not only on more capable models, but also on the quality of the engineering systems around them.

Sometimes, the next improvement does not come from giving the model more code.

It comes from helping it see how the code fits together.

Explore ArchMind

GitHub: https://github.com/Kidkender/archMind

I welcome feedback, technical discussion, and contributions from developers interested in code intelligence, static analysis, and AI-assisted software engineering.