Greenfield Is Easy, Brownfield Is the Business — Deterministic Maturity for Legacy Portfolios

Every agentic demo you have ever been impressed by was greenfield. A clean repository, a well-scoped problem, a fresh prompt, and an audience watching live. The agent writes the feature, the tests pass, the room nods. It is genuinely impressive, and it is genuinely easy. A capable model on an empty canvas with a human steering in real time is close to a solved problem.

That is not the problem you have.

The problem you have is a portfolio. A dozen applications. A CRM that three vendors have touched over eight years. Two marketing sites on different CMS versions. A data pipeline nobody fully remembers the shape of. Each one carries technical debt, undocumented business logic, and interdependencies that only reveal themselves when something breaks. The enterprise reality is, as vFunction puts it, "overwhelmingly brownfield: maintaining and continuously adding features to legacy applications, packed with technical debt, undocumented business logic, and complex interdependencies" (vFunction, 2025). The greenfield demo tells you almost nothing about whether you can make that portfolio agentically capable — reliably, comparably, and over and over.

This is the gap where most agentic initiatives die. Not in the demo. In the second, third, and twentieth application, where the magic doesn't reproduce because it was never a method in the first place. This piece is Facet's working answer to the brownfield problem: how we assess agentic maturity across a portfolio of existing systems without it becoming a one-off art project each time. The short version is one word — determinism — and most of this article is about what that word actually requires.

The greenfield-demo trap, and why brownfield breaks it

The greenfield demo works because three things are true at once: the problem is bounded, the context is small enough to fit in a human's head, and a person is in the loop catching errors as they happen. Remove any one and the result degrades. Brownfield removes all three.

The model that wrote a clean feature in the demo is the same model that, dropped into a legacy codebase, "lack[s] architectural context to understand the ripple effects of how changes impact the entire system" (vFunction, 2025). A change that looks locally optimal destabilizes something three modules away. The agent cannot see the blast radius because the blast radius is undocumented — it lives in the heads of people who left, or in nobody's head at all.

The org-level evidence agrees. The 2025 DORA report's central finding is that AI is "an amplifier, magnifying an organization's existing strengths and weaknesses," not a fix (Google Cloud / DORA, 2025). Point an amplifier at a clean greenfield repo and you amplify the cleanliness. Point it at a tangled portfolio and you amplify the tangle. And the tangle is already expensive before any agent shows up: in IBM's Institute for Business Value survey of senior AI decision-makers, 81% said technical debt is already constraining AI success, and 69% said it could render some initiatives financially untenable; companies that ignored the debt saw project returns drop by roughly 18% to 29% with timelines expanding by as much as 22% (IBM IBV, 2025).

So the real question is not "can an agent modernize this app?" The demo already answered that for the easy case. The real question is: across this whole portfolio, which systems are ready, which are not, and what specifically has to change in each one — answered the same way every time, so the answers are comparable? That is an assessment problem before it is an engineering problem. And assessment, done at portfolio scale, is where determinism stops being a nice-to-have.

Why portfolio scale demands determinism

A single assessment can be an art project. Forty assessments cannot. The moment you are evaluating system number two, you need the second answer to be comparable to the first — same lens, same questions, same scoring — or you have two opinions, not a portfolio view. Comparability is the whole point of doing this across a portfolio, and comparability requires that the process produce the same kind of answer regardless of who runs it or which codebase it meets.

This is the same discipline we describe in The Agentic Operating System — Deterministic Control on Non-Deterministic Foundations: you cannot make the model deterministic, so you wrap it in a system that is. A maturity assessment is exactly such a system. The model reads code and reasons about it — that part is probabilistic and always will be. The scaffolding around it — fixed questions, required coverage, a defined scoring rubric, a procedural workflow — is what makes the assessment reproducible even though the reasoner is not.

The market is full of maturity models that miss this. Gartner publishes a five-level model across seven pillars; MIT CISR offers a four-stage framework; consultancies ship their own. They are useful as vocabularies. But a vocabulary is not an instrument. The proof is in the aggregate numbers: ServiceNow's 2025 Enterprise AI Maturity Index reported global maturity scores dropping year over year, with very few organizations scoring near the top (ServiceNow, 2025). When everyone has a model and almost nobody scores well, the bottleneck is not the model — it is the repeatable, evidence-based measurement that turns the model into a number you can trust across many systems. That measurement is the thing we build.

LLM-based codebase evals as the maturity instrument

The instrument we reach for first is an LLM-based eval of the codebase itself. Not the agent's output — the underlying system. We use a language model, under controlled prompts and a fixed rubric, to read a codebase and judge it: how legible is it, how testable, how well-bounded are its modules, how much undocumented business logic is load-bearing, how safely could an agent operate inside it. The academic ground here is real and maturing fast — "LLM-as-a-judge" evaluation of code quality, maintainability, and structure is an active research area, with systems like NeurIPS-2025's Code Quality Score work formalizing automated, actionable code-quality scoring for large codebases (OpenReview, 2025).

Two design choices make an eval an instrument rather than an opinion:

• It scores against a fixed rubric, not an open prompt. "Rate this codebase's agentic readiness, 0–100, on these named dimensions, with evidence for each score" produces a comparable number. "What do you think of this codebase?" produces an essay. We only ship the former.

It reports variance, not just a verdict. Because the model is non-deterministic, we run the eval more than once and look at the spread. A dimension that scores 71, 73, 70 across runs is a measurement. A dimension that scores 40, 78, 55 is telling you the rubric is underspecified for this system — which is itself a finding. This is the same posture we take on the tool side in Benchmarking the Bleeding Edge: How We Score New AI Tools on a Real Test Bench: report the variance alongside the mean, because a mean without a spread is a number you cannot govern.

The output is a maturity reading for one system — defensible, evidenced, and on the same scale as every other system in the portfolio. That last clause is what makes it portfolio-grade.

Plain-language procedural workflows as the portable framework

An eval scores a codebase. It does not, by itself, tell you what the business is trying to make that codebase do. For that we write the target workflow down — in plain language.

This is a deliberate and slightly counterintuitive move. We describe the process the system is supposed to support — "a lead comes in, sales qualifies it, it routes to the right owner, the CRM updates, a follow-up fires" — in procedurally correct prose, not in a formal technical specification. The discipline is that the description be procedurally correct (the steps, the order, the decision points, the hand-offs are all right) even where it is not formally technical (no schemas, no sequence diagrams required to start).

The reason is portability. A plain-language procedural description is a framework that survives contact with the next codebase. The same described workflow — "this is what good looks like for lead routing" — can be held up against a Salesforce org, a Drupal-plus-custom-CRM stack, and a homegrown app, and in each case it surfaces the same kind of question: where does this system already support the procedure, where does it not, and what would have to change to make it agentically capable? Encode the target as a formal spec tied to one platform and you have to rebuild it for the next platform. Encode it in correct plain language and the evaluation framework travels. The model is fluent in prose; prose is the portable interface between "what the business wants" and "what this particular codebase does."

So the assessment of any one system is the intersection of two things: the LLM eval (how good and how agent-ready is this codebase, objectively) and the plain-language workflow (what is this codebase for, and how far is it from supporting that procedurally). Run both against every system and the portfolio view assembles itself on a common scale.

The deterministic move: coverage first, inference second

Here is the discipline that separates a repeatable assessment from a clever one-off, and it is the most important paragraph in this piece.

The tempting thing — the thing the demo trains you to do — is to ask the model the open question: "What does this system need to do to become agentically mature?" It will answer. The answer will sound great. And it will be non-reproducible, non-comparable, and quietly different every time you ask, because an open-ended question samples a different path through the model's reasoning on every run. You have outsourced both the questions and the judgment to a non-deterministic component. At portfolio scale, that is how you end up with twenty assessments that cannot be compared to each other.

We do the opposite. We fix the question set in advance. A predefined list of questions every system must be made to answer — Is there meaningful test coverage? Is the business logic documented or load-bearing-and-implicit? Are the integration points typed and observable? Can an agent act here behind a deterministic gate, or only behind a human? — dozens of them, the same for every codebase. Then we run a defined procedure that forces an answer to every question, and we verify coverage before we infer anything. Only once every predefined question has a backed answer do we let the model take the second step: infer the strategic action plan from the completed answer set.

Coverage first. Inference second. The sequence is the whole game.

That ordering is what converts a non-deterministic reasoner into a deterministic assessment. The open-ended version asks the model to invent the questions and answer them and synthesize a plan, all in one probabilistic pass — three places for the result to drift. Our version pins the questions (fully deterministic), forces coverage across all of them (a checkable, deterministic gate — every question answered or the run is incomplete), and only then permits inference, now constrained to operate over a complete, comparable evidence set. The model still does the reasoning. It no longer chooses the shape of the problem. That is the difference between an instrument and an oracle — and it is the same "deterministic control on a non-deterministic core" pattern, applied to assessment instead of to runtime.

It also fails loudly in the right way. If a system cannot produce a backed answer to a predefined question, that gap is the finding. The open-ended approach hides exactly this — it confidently fills silence with plausible prose. Forced coverage surfaces the silence and makes it actionable.

Facet's point of view

We did not arrive at this by theory. We arrived at it the way most durable methods arrive — by watching the greenfield trick fail on the second client and refusing to re-improvise the assessment a third time. The pattern across medspas, law firms, property managers, and tech-forward SMBs is the same: the demo is never the hard part. The hard part is doing the demo's worth of work reliably, comparably, across a portfolio of systems nobody fully documented, without it becoming a fresh adventure each time.

So our point of view is narrow and we will defend it:

• Greenfield agentic capability is close to free; brownfield agentic capability is the entire business. Anyone selling you the demo is selling you the easy 5%.
• Assessment precedes engineering. You cannot modernize a portfolio you cannot measure on a common scale. Build the instrument before you build the agents.
• Determinism is a process property, not a model property. You will not make the model reproducible. You make the assessment reproducible by fixing the questions, forcing coverage, and inferring last.
• Open-ended "what should I do?" is the anti-pattern. It feels like leverage and it destroys comparability. Predefined questions plus coverage-before-inference is the version that scales past system number one.

This is also, deliberately, a methodology we can hand over. For the enterprise team that wants to build this internally rather than rent it — the question set, the eval rubric, the coverage gate, the plain-language workflow library — the deliverable is the instrument, not a dependency on us. That is the point of making it deterministic in the first place: a method you can teach is a method that was never magic.

If you have a portfolio and a stalled agentic initiative, the diagnosis is usually the same. You have a great greenfield demo and no repeatable way to assess everything else. The fix is not a better demo. It is an instrument. That is what we build, and it is the unglamorous discipline that makes the glamorous part reliable.

Facet Interactive is a boutique systems integrator and agentic operating partner. We build the deterministic assessment and engineering scaffolding that turns AI from a demo into a portfolio-grade operating capability. If you are staring at a backlog of legacy systems and a mandate to make them agentic, that is the conversation we have every week. Schedule a conversation of your own.

External sources

vFunction, "The AI revolution in application modernization" (2025) — brownfield prevalence and AI agents' lack of architectural context. https://vfunction.com/blog/ai-app-modernization-strategy/

IBM Institute for Business Value, "The tech debt reckoning" (2025) — technical debt constraining AI success (81% / 69%; 18–29% return drop; up-to-22% timeline expansion). https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/tec...

Google Cloud / DORA, 2025 State of DevOps Report — AI as amplifier, not fix. https://dora.dev/dora-report-2025/

ServiceNow, 2025 Enterprise AI Maturity Index — declining global maturity scores. https://www.servicenow.com/now-platform/enterprise-ai-maturity-index.html

OpenReview / NeurIPS 2025, "A Note on the Code Quality Score System: LLMs for Maintainable Large Codebases" — automated LLM-based code-quality scoring. https://openreview.net/forum?id=9HgWk7tKPi