How We Squeezed a 1998 VBA Codebase Into One AI Agent

I. The Problem With Throwing AI at Old Code

The naive approach — the approach our AI developers kept proposing — was context stuffing. Load the whole codebase into the model's context window and ask it to understand. Just give it everything and let it figure it out.

Here is what nobody tells you in the Medium articles about AI-powered code migration: even a 200,000-token context window is not the same as 200,000 tokens of useful context. Researchers studying what they now call the Maximum Effective Context Window (MECW) have found that effective performance often falls far below the advertised limit — by up to 99% on complex tasks. There is a phenomenon called "context rot": the model's attention degrades the further into a sequence you go. Important logic buried in the middle of a 50,000-line file is practically invisible to the model. It sees the beginning. It sees the end. The middle is where your business logic lives.

Add to this the nature of VBA code from the late 1990s. VBA from that era does not look like code. It looks like sediment. It is layers of decisions made by a dozen different programmers across a decade. Naming conventions shift mid-file. Comments are in three languages — two of them inconsistent. Framework artifacts, library imports, deprecated method calls, dead code that was never cleaned up because nobody was certain it was actually dead — all of it packed together like geological strata, impossible for a human to read quickly, and equally impossible for a model to parse cleanly.

We ran the experiments. We threw chunks of this code at every approach available to us. The AI developers had their turn. And one by one, the approaches failed or underdelivered.

II. How We Actually Communicate With AI: The Methods We Tested

Before we wrote a single line of transformation code, Max and Ezekiel — two engineers who share the trait of simply refusing to accept "it cannot be done" — spent months experimenting with how to communicate with the model effectively. Not what to ask. How to ask.

There are four primary strategies for getting knowledge in and out of a large language model. Each has a different cost profile, a different maintenance burden, and a different ceiling.

We discovered something in our experiments that is not talked about enough. Vector databases are not always the right answer for getting large amounts of data in and out of AI. Everyone defaults to RAG with a vector store as if it is the only option, but vector search optimizes for semantic similarity. What we needed in many parts of this codebase was not "find me something similar" — it was "give me exactly this, in this order, with this structure." For that, a well-indexed relational store or even a graph database communicates better with the model than a vector database does. The problem is not always retrieval. Sometimes the problem is representation.

III. The Limits Are Real. Here Is Why They Exist.

Context windows exist because of mathematics, not corporate restriction. The computational complexity of the attention mechanism that powers transformer models is quadratic — double the context length, quadruple the computational cost. This is not a policy choice. It is physics.

As of 2026, the largest context windows sit between 200,000 tokens (Claude 3.5 Sonnet) and 1 million tokens (Gemini 1.5 Pro). One million tokens sounds enormous — roughly 750,000 words. But a large enterprise codebase can contain tens of millions of lines of code across thousands of files. Even at one million tokens, you are seeing a fraction of a complex legacy system. And the tokens you do stuff in? The model attends to them unevenly. Recent tokens and first tokens get priority. Middle tokens get lost.

Here is a quick map of where each major model actually sits today:

Where will this go? The honest answer is: windows will keep expanding, but the effective ceiling will always lag the advertised one. Better architectures will reduce it. Sparse attention, memory compression, hierarchical context management — all of these help. But the fundamental tension between what is available in a codebase and what a model can genuinely attend to simultaneously will remain a real constraint for years.

The right question is never "how do I fit more into the model?" The right question is: how do I make what goes into the model maximally clean and maximally useful?

IV. Washing the Code

This is where Max and Ezekiel did what most people are not willing to do. They went back to basics. Not AI basics. Engineering basics.

Before any model saw a single line of this VBA codebase, the code had to be washed. Washed clean of everything that was not logic. That means:

• Stripping framework artifacts — the VBA runtime boilerplate that appears in every file regardless of what the file actually does
• Removing library import noise — the residue of third-party dependencies that have nothing to do with the business behavior
• Normalizing naming conventions — so that a variable called strCustomerName in 1998 style maps consistently to its semantic equivalent
• Isolating dead code — branches that can never be reached, conditions that can never be true, so the model reasons about live logic only
• Removing human style, keeping human intent — the single most important step, and the hardest to automate

This took months. Real, deep, careful engineering work. Not prompt writing. Not infrastructure configuration. Reading code, understanding it, and making decisions about what it actually means versus what it literally says. That distinction — between what code means and what it says — is the entire problem in legacy system modernization, and no model can resolve it on your behalf.

V. Breaking It Into Categories, Not Chunks

The instinct, when you have a large codebase and a context window limitation, is to break the code into chunks. Slice it into segments that fit the window. Process each chunk. Reassemble. This is the approach the AI developers wanted to take. It is also, for complex business systems, deeply wrong.

You cannot chunk a business system by lines of code. You have to chunk it by logic type.

We divided the washed codebase into categories before any AI touched it:

VBA Codebase (washed)
│
├── Features (known)        → Agent A: cross-reference with documentation
├── Features (undocumented) → Agent B: extract and name from behavior
├── Business Logic          → Agent C: pure rule extraction, no UI concern
├── Data Transformations    → Agent D: structural mapping and formatting rules
└── Infrastructure Concerns → Agent E: config, connection, environment

Each agent was given clean input, a narrow task, and a constrained output format. It was not asked to understand everything. It was asked to understand one thing well.

This is real engineering. This is what software architecture has always been about, even before AI entered the conversation. Separation of concerns. Single responsibility. Narrow interfaces. The principles that make code maintainable for humans make it processable by models.

VI. What We Can Do Now That We Could Not Before

We know this codebase. Not in the way the original developers knew it — through years of proximity and tribal memory. We know it in a different way, perhaps a clearer way. We know the database structure. We know every piece of business logic. We know every feature, including the ones that were never documented.

That knowledge, extracted and structured through months of careful engineering work, now powers something the client never thought possible. We are not recoding the system. We are building it new. Not a migration — a rebirth. The same business logic, expressed in microservices that scale. The same features, now testable, maintainable, and understandable by any developer who joins the team.

The VBA system from 1998 will not be fixed. It will be made unnecessary.

And the reason we can do that is not AI. The reason is that we understand the system completely. AI is the tool that transforms that understanding into new code faster than any team could write it manually. But the understanding itself? That came from engineers who rolled up their sleeves, read the sediment, and refused to stop until they could explain every line.

VII. What Real Engineering Looks Like in 2026

I have watched the industry develop a strange relationship with AI capability. There is a kind of magical thinking — the belief that a sufficiently large model, given a sufficiently well-written prompt, can bypass the foundational work of software engineering. I have hired people who carry that belief. Some of them were technically impressive. None of them delivered what Max and Ezekiel delivered.

Real engineering means making something difficult possible by reducing its complexity — not by hoping the tool is powerful enough to ignore the complexity.

The AI developers wanted to pour a complex system into a model and pull a solution out the other side. Max and Ezekiel spent months making the system simple enough that the model could handle it. The first approach is a bet on the tool. The second approach is engineering.

As you think about your own legacy systems — and you have them, every organization of more than ten years has them — the question worth asking is not "which AI tool should we use?" The question is: do we understand the system we are trying to modernize? Not at a high level. At the level of every rule, every edge case, every undocumented behavior that only shows up in production once every eighteen months.

If you do not understand it, no model will understand it for you. It will generate plausible-looking output that misses the edge cases, and you will not know until something breaks in production. If you do understand it — truly, deeply, in writing — then AI becomes what it should be: an extraordinary force multiplier for engineers who have already done the hard intellectual work.

The VBA project taught us that. It cost us months and a few good nights of sleep. But standing where we stand now, with complete knowledge of a system that nobody had fully understood in two decades, the work was worth every hour of it.

Go back to basics. Wash the code. Understand before you generate. The AI will be ready when you are.

Further reading on application modernization services and legacy code:

• martinfowler.com — Architecture patterns and modernization thinking
• InfoQ.com — Engineering culture and practice
• Thoughtworks.com — Technology radar and transformation
• DZone.com — Practitioner-level technical depth
• stackoverflow.blog — Where engineers write honestly

Kodebaze Engineering Leadership · Written for CTOs building serious technology in serious conditions · April 2026