Part 1 of The Brownfield Problem — a series for enterprises whose AI investment isn’t yet showing up in delivery speed or cost, on the heavily customised platforms that run the business. Not prompts. Not tips. The real infrastructure — built from the inside out.
The slide goes up and Marcus feels it before he processes it.
Not the numbers — the room.
The particular quality of silence that settles when a slide lands badly. The CFO’s hand moving to her coffee cup, lifting it, setting it down again without drinking. The way the Head of Product suddenly finds something interesting in his notepad. Marcus has been in enough of these rooms to read the temperature without looking at the thermometer.
The slide shows a competitor. Smaller company. Half the engineering headcount. Shipping at a pace that makes the chart look almost accusatory — a line climbing steadily upward while Marcus’s line does something more complicated. Something that requires explanation.
He gives the explanation.
It’s a good explanation. Accurate. He’s rehearsed the shape of it, the language that makes the complexity legible without sounding like an excuse. He talks about the platform. The years of customisation. The architectural decisions that were the right calls at the time and are now the walls everything else is built against.
The CFO nods.
Not the nod that means I understand. The other one. The slow, considered nod that means I’m filing this away.
“And the AI tools?” she asks. “We’ve made a significant investment there.”
“We have,” Marcus says. “The team is using them.”
He doesn’t say the rest. Not here, not in this room. The rest is for the drive home, for the particular darkness of the car at 11 pm when the day has finally run out of demands and there’s nothing left but the honest version.
The tools are running. The output looks right. It just doesn’t work.
Picture the codebase Marcus is responsible for.
Not the clean version from the architecture diagram on the wiki — the real one. The one that exists in production, that has been live for years, that has absorbed the decisions of every team that touched it before his. Some of those decisions were elegant. Some were made at 2 am before a launch. Some were workarounds that became permanent because permanent was faster than right, and then the person who knew they were workarounds left, and now they’re just the way things work.
This is a brownfield system. Most enterprise systems are. The term sounds clinical but the reality is deeply human — it’s what happens when software lives long enough to accumulate history.
His platform is a major enterprise SaaS product. Solid foundation. Heavily extended. Customised at every layer by teams who understood their piece of it, working at the speed that business demanded. The kind of system where you learn not to touch something without first understanding why it exists.
Now add AI coding assistants.
The tools arrive with encyclopaedic knowledge of the base platform. They know the APIs, the extension patterns, the architectural principles. In a demo environment, on a clean instance, they’re remarkable. A developer describes what they need and the AI produces code that looks exactly right. Fast. Confident. Apparently competent.
The first few weeks feel like the turning point everyone said was coming.
Then the PRs start landing.
A senior engineer opens one and goes quiet for a moment. Then types a comment — the kind that’s carefully worded because the author is a junior developer, and what it’s really saying is:
This is in the wrong place. And I need you to understand why without feeling like you failed.
The AI has written to the base layer — the read-only foundation that vendor upgrades will silently overwrite. The code is syntactically perfect. Architecturally, it’s a time bomb with a very clean detonator.
Another PR. Different problem, same shape. The AI has overridden an entire module when it needed to change one function — copying the whole file rather than extending it, which means any changes the base makes to the other functions will never reach this version. The code works today. It will drift quietly out of sync with the platform it’s supposed to extend.
Marcus’s senior engineers — the ones who carry the most context about how this system actually works — are now spending their afternoons reviewing AI output for problems that aren’t visible until you already know what to look for.
Think about what that costs.
The people who understand the system deeply enough to catch subtle architectural errors are also the people who are supposed to be building the next thing. They’re now a quality gate for a tool that was supposed to make quality easier. The juniors who could benefit most from AI assistance can’t always tell when the output is subtly wrong. And subtly wrong in a system with this much layered history is a specific kind of expensive — the kind that surfaces three months later, during a platform upgrade, at the worst possible moment.
Here’s what Marcus’s instinct says. It’s the same instinct most engineering leaders reach for first.
Better prompts. More documentation. Training sessions on how to use the tools correctly.
It’s a reasonable instinct. It’s also pointing at the wrong problem.
The AI doesn’t need better prompts from individual developers. It needs something more fundamental.
Sit with this distinction for a moment, because it’s the hinge the whole problem turns on.
Platform knowledge is what the AI arrives with. It knows the base product — the APIs, the extension model, the patterns documented in the official guides and discussed in every forum thread and Stack Overflow answer ever written about the platform. This knowledge is generic. It applies to every team running this system, everywhere in the world. The AI has it. It’s not the gap.
Project knowledge is what the AI is missing. It doesn’t know your system. It doesn’t know which directories are read-only and which aren’t. It doesn’t know whether your team overrides by extending the base module or by replacing it entirely — and why, and when each approach is correct. It doesn’t know your test naming convention, your branch strategy, the module map that evolved over years to reflect the specific shape of your business. This knowledge lives in the people who’ve been here long enough to absorb it. It isn’t written down anywhere the AI can find.
When you ask an AI to write code in a system it knows in the abstract but not in the specific, it fills the gaps with its best guess. Its best guess is always the simplest, most generic approach — the one that works on a clean implementation, not on yours.
That’s not a tool problem. It’s a context problem.
And context problems require context infrastructure to solve them.
Marcus’s senior engineers weren’t being resistant when they flagged these failures.
They were being precise.
“The AI doesn’t know our override pattern.” Precise. “It keeps writing to the wrong layer.” Precise. “I’d spend less time doing this myself.” Precise, and worth listening to.
The developers flagging AI failures in your team are not the obstacle to transformation. They’re the most accurate diagnostic instrument you have. They can see exactly where the gap is because they live inside it every day.
The gap is not capability. The AI is capable.
The gap is context. And the organisation hasn’t built the infrastructure to deliver it.
This is the problem I spent time living inside — not as an outside consultant looking in, but as someone embedded in the work, in the weeds, feeling the same pressure Marcus feels on the drive home.
What came out of that time was a framework. Six layers. Each one teaching the AI something it cannot infer on its own — built in a specific order, because the order matters as much as the layers themselves.
The first layer tells the AI what it must never touch, and exactly how to override things correctly. Without this, everything else is built on sand.
The second — and this was the surprise — turns out to be the highest-leverage file in the entire system. Not platform documentation. Not API references. Project conventions. The specific decisions your team has made about how work gets done here.
The third layer configures what the AI can do without interrupting you, and what always needs a human in the loop. The fourth handles the operations that happen once a quarter and have no margin for error. The fifth encodes what “done” means — the team’s definition of quality, made legible to the AI. The sixth gives the AI continuity across sessions, so it starts a new conversation already carrying the context it built up in the last one.
None of these are prompts. They’re files. Committed to the repository, version-controlled, living next to the code they govern.
The total upfront investment to build all six is roughly one day. One focused day to construct the skeleton. After that, the system accumulates context naturally as you work. And the AI — the same AI that was producing plausible-looking code in the wrong place — starts producing output that fits. That respects the architecture. That your senior engineers can review in minutes rather than hours.
Velocity compounds. Not because the tool improved. Because you gave it what it needed.
Back in the car, in the dark, Marcus asks himself a different question.
Not the one he’s been asking —
Why isn’t this working the way it’s supposed to?
The one underneath it.
What does the AI actually need from us that we haven’t given it yet?
It’s a small shift in language. It’s a significant shift in posture. It moves the problem from the tool’s shortcomings to the environment the tool is operating in. And once you make that move, the path forward becomes clearer — not easy, not instant, but clear.
You stop waiting for the AI to figure out your codebase.
You start building the infrastructure that lets it.
That’s what this series is.
In Part 2: Layer 1 — the single most important constraint in the system. The one rule that, if the AI breaks, creates work another developer has to find and undo. What it is, what it contains, and the exact test that tells you whether it’s working.
Subscribe to get each part as it lands. If you’ve been following the LinkedIn series on AI on customised enterprise platforms, this is where the framework gets the depth the LinkedIn format wouldn’t allow.
If you’re navigating this on a heavily customised platform right now and want to talk it through, email contact@brownfieldai.dev or message me on LinkedIn. I’m always up for a direct conversation.
Kinnaree Patel is the founder of Brownfield AI, which helps enterprises get AI delivering real business results on the platforms they already run. She writes from live experience inside an enterprise AI transformation. Want to talk it through? Email contact@brownfieldai.dev or visit brownfieldai.dev.