Jacek Labuda
·
Head of R&D
·
July 3, 2026
·
12
 min read

AI agents on mature codebases: understand first, then change

Thousands of guides on agentic coding show a greenfield demo. Real software house work starts from a system already in production. Here is what working with AI on mature codebases actually looks like - and where it genuinely helps.

Three men brainstorming in a room with a whiteboard and graffiti art on the walls.

There are thousands of articles about agentic coding, and most of them follow the same script: an empty folder, "build me an app", a working demo in a few minutes. It looks impressive and, to be fair, it is genuinely useful. The catch is that most real work does not start from an empty folder.

In the day-to-day work of a software house, the starting point is rarely greenfield. It is usually a system already running in production - maintained for years, wrapped in integrations, with real users and real consequences when something breaks. And that is exactly where most guides on AI agents stop. Not because AI does not work there, it does, just differently than in a polished demo. That difference is where the real work lives.

A demo is not production

An agent that spins up an app from scratch in a minute, and the same agent let loose on a mature system, are two very different stories. In a greenfield project there is nothing to break: no users, no contracts, no hidden assumptions. In a mature system all of these exist, but usually they live nowhere except in the team's heads.

This is not an argument "against AI". It is a distinction that most writing on the topic misses: a tool that shines on greenfield needs a different discipline on mature code. Without it, you easily end up with code that looks fine, passes locally, and breaks something nobody saw coming.

What the numbers say, and how to read them

The data is worth a look, but with care, because it circulates online in a simplified form.

The best-known example: in the METR randomised controlled trial, experienced developers on mature, demanding projects were on average about 19% slower with AI assistance, even though they felt about 20% faster. Across the industry, those figures gave sceptics a ready argument that "AI slows you down". But that is an over-reading: the result depends heavily on context (early models, a particular kind of high-standard project), and the authors themselves later added important methodological caveats. We do not read it as a verdict on AI, but as a signal: on mature code the speed-up is not automatic, and the cost moves elsewhere.

And it moves fairly consistently, towards review and integration:

AI speeds up generation, but the bottleneck moves to review, integration and stability. On a greenfield project you do not see it. On a mature one, that is the heart of the job.

Where AI genuinely helps on mature code

The examples above are not the full picture. On existing systems AI can add real value, just in different places than "write it for me from scratch":

  • Understanding and onboarding. The agent explains an unfamiliar module, shows how data flows, points out where something is used, and walks a new joiner through the code. That cuts the time to get into a project from days to hours.
  • Navigating a large codebase. A quick "where and why" instead of digging through hundreds of files by hand.
  • Faster testing of hypotheses. Instead of weeks of speculation, quick prototypes and alternative approaches you can judge on something concrete. We test the direction before committing to a full implementation.
  • Deeper analysis, a better diagnosis. More paths and dependencies examined means a sharper answer on which way to go and which changes are safe - the risk moves from "we think so" to "we checked".
  • Characterisation tests and documentation. The agent is well suited to pinning down a system's current behaviour before we touch it.
  • Well-scoped, repetitive changes. Mechanical migrations, updates, small refactors, all under supervision and behind a quality gate.

A pattern shows through: the most value comes where AI helps a person understand and prepare, not where it is meant to deliver a critical change on its own. There is a human side to this too. The open questions - "will this work", "which way should we go" - get addressed early, on prototypes and analysis, and the client can take part in that instead of waiting for a finished result.

Confidentiality and the real role of a local model

On mature client projects there is one more non-negotiable layer: code confidentiality and compliance. For a bank, the public sector or healthcare, sending code to a cloud outside the EU is often simply off the table - data residency, the EU AI Act and GDPR all matter. That is when a model run locally or on-premise comes into play.

But beware a common mistake: a local LLM is not the place where you "dump the legacy system" and tell it to implement changes. Local models are weaker than the leading cloud ones, and the gap between understanding code and writing it reliably on a real system is wide - LLMs are far better at analysing and explaining than at implementing correctly on their own.

So in practice it usually looks like this:

  • Analysis and understanding - usually local. A private "read this, explain it, map the dependencies, help me get into the code", without it leaving the client's infrastructure. The bar for correctness here is lower (we are assisting a person, not shipping autonomously to production), so a weaker local model is often perfectly enough.
  • Implementing critical changes - the strongest model available, full quality gates, a human in the loop. And not every case is even suited to implementation by a local LLM - sometimes the deliberate choice is to do it without one.

So we separate two decisions: whether the cloud is on the table at all (a matter of confidentiality) and what we are asking the AI for, understanding or delivery. A local model works best where confidentiality matters and the task is to understand.

How we approach this at i4B

We approach mature systems the way a mature team does: we start from what has been agreed with the client, and we choose tools deliberately, to fit the specific task and its risk.

  • Compliance and the terms of engagement first. We start from what we have agreed with the client and what the law requires: the contract, confidentiality, data protection (GDPR, the EU AI Act), and the limits of what may leave the client's infrastructure. Only within those bounds do we reach for AI, and only where it is safe.
  • We pick the model to suit the case, not personal preference. Local or on-premise where confidentiality demands it, and usually for analysis and understanding. The cloud where it is allowed and where implementation needs the extra capability.
  • Understand first, then change. Characterisation tests and a dependency map before we touch the code - the cheapest insurance against regressions.
  • We describe a single change, not the whole system. From the current state, through the invariants, to its scope. Instead of "rewrite everything", we work in small, testable steps.
  • Hard quality gates - build, tests, types, lint, security scan. No pass, no merge, however good the code looks.
  • Independent verification - a human reviews, or a separate agent on different terms, never "AI rubber-stamping AI". A model is not a reliable reviewer of its own work.
  • A human at the irreversible points. The API contract, data migrations, merges and deployment stay a human decision.
  • Realism about scale - a handful of agents at once, not dozens. Because the bottleneck is our review capacity, not compute.

And the most important part: "done" means the whole system around the model, not the model alone - the runtime environment, a sandbox, evaluation, monitoring and the ability to roll changes back. The model on its own is roughly half of being ready.

Maturity is the advantage

The excitement around agents is deserved - on greenfield projects and well-specified tasks they give a real speed-up, and on mature code they can be an excellent partner for understanding and preparing changes. But for a client whose system already runs and earns money, the value is not in the fastest demo. It is in getting the change in without regressions, without leaking confidential data, and without debt that comes back in three months.

This is exactly the work you do not see in the tutorials, and exactly the work where an experienced team makes the difference. We know when to reach for an agent, when for a local model to analyse, and when to leave it and do something by hand. Whether and how we use AI stays within the bounds set for each project, and often the best answer is to use it sparingly or not at all. And that knowledge is what gives us our edge.