AI coding with large codebases – What Role Does SOFEEi Play?

In Part 1, we looked at why an AI coding agent’s token usage can increase so quickly, and why the number of questions is not necessarily the real problem.

In Part 2, we explored how too much low-relevance information affects both cost and answer quality, and why targeted context works better.

In Part 3, we showed why access to the code alone is not enough if the AI cannot see the dependencies, business rules and the knowledge behind the system.

What SOFEEi is – and what it is not

SOFEEi is not a coding agent, and it does not claim to automatically “understand the entire company”.

SOFEEi is a structured enterprise code and business memory and search layer for AI coding agents.

It helps make a company’s own system knowledge searchable and retrievable: source code, documentation, relationships, dependencies and the context behind business rules. In practice, this means the agent does not have to rely only on the prompt or try to work everything out from an entire codebase before starting a task.

SOFEEi helps the coding agent find:

• the relevant code;
• related programs and components;
• dependencies;
• related documentation;
• the business context needed for a specific change.

Important!

Retrieved context does not replace developer review. But it can provide more sources and a better starting point for analysis, impact assessment and preparing a change. This means developers and AI agents can spend less time manually piecing information together from multiple repositories, documents and expert explanations.

One distinction is especially important:

• Repository access is not the same as structured enterprise memory.
• A large context window is not the same as relevant context.

SOFEEi’s goal is to make enterprise code and business knowledge searchable and available to AI agents and developers, especially in complex, business-critical enterprise environments such as IBM i, RPG, COBOL and Java.

How Can a Team Get Started?

You can measure the difference even without SOFEEi.

In other words, simply trying to solve the problem by “giving the LLM as many documents as possible” is usually not a good approach. It tends to be expensive and difficult to maintain.

A good starting point is one specific development task:

1. Choose a recurring question or type of change. For example, assessing the impact of changing a business rule.
2. Next, look at how the team currently finds the information needed for that task. Which programs, documents and expert conversations contain the answer?
3. Then identify which pieces of context are actually necessary – not for the whole system, but for that specific task.
4. Measure the token usage of the AI workflow. How much is spent on producing a genuinely useful answer, and how much is spent on helping the agent find information it ideally should already have access to? The answers – and the measurements – can be very convincing.
5. In the long term, the goal is to build a retrievable enterprise memory for code and business rules.

Every Token Counts – But Context Matters Even More

Some AI costs are unavoidable: models need to process questions and generate answers. But unnecessary token usage is often a sign that the AI has to spend too much time searching, figuring things out and asking again before it can understand the company’s own system.

A coding agent understands programming, but it does not automatically know your environment, your enterprise dependencies, the reasons behind old decisions or the business rules hidden in the code. Finding the relevant context is therefore not just a minor technical detail. It is one of the things that makes AI use more cost-aware, faster and more responsible from a business perspective.

Can your AI coding agent find the right code and business rule in your system – or do you keep giving it more and more tokens so it can try to work them out?

Read the full series