Greenfield vs Brownfield: How Your Codebase Changes AI-Assisted Build and Maintenance Costs

One of the most common assumptions about AI coding agents is that they make codebase age and size irrelevant — that an agent can just "figure it out" regardless of what it's working in. In practice, the legacy-code tax doesn't disappear with AI agents. It just gets paid in a different currency: tokens, context window, and review time, instead of pure developer-hours.

Four codebase types, four baselines

• New project. No existing code to understand. Agents work fastest and most predictably here — every file they touch, they wrote.
• Existing, small. A modest existing codebase with conventions an agent can learn quickly. Some overhead to understand structure, but manageable.
• Existing, medium.Enough surface area that an agent regularly needs to search for relevant files, cross-reference conventions, and avoid breaking things it can't see in its current context window.
• Existing, large/legacy. Significant size, inconsistent patterns, or outdated dependencies. Agents spend a large share of their token budget just building enough context to make a safe change — and still need more human review per change.

The same feature — say, "add a CSV export endpoint" — might take an agent a handful of tool calls in a new project, and a much longer exploration-and-verification loop in a large legacy codebase, simply to find where similar exports are implemented, match existing patterns, and avoid duplicating logic that already exists somewhere else in the repo.

Rework expectation: the tax AI agents pay for not knowing your codebase

"Rework expectation" — low, medium, or high — captures how often an agent's first-pass output needs significant revision before it's usable. In a clean, well-conventioned codebase, rework is low: most generated code fits in with minor edits. In a codebase with inconsistent patterns, missing documentation, or implicit conventions, rework is high: the agent's first attempt often technically works but doesn't match how the rest of the codebase does things, and gets redone. Every redo is tokens spent twice — once on the version that gets discarded, and again on the corrected version.

Testing and deployment complexity add their own layers

Two more dimensions stack on top of codebase type:

• Testing expectation— from minimal, through normal coverage, to strong test suites, up to enterprise-grade testing requirements. Higher expectations mean an agent writes and maintains more test code per feature, which is build cost that doesn't show up in the feature itself.
• Deployment complexity — from a single simple deployment target, to standard CI/CD, to multi-service architectures, up to enterprise/regulated environments with their own review and compliance steps. Each step up adds coordination work that AI agents can assist with but rarely fully automate.

Maintenance looks different in legacy codebases too

The same dynamic carries into the maintenance budget. A "low" maintenance intensity on a new, small codebase might mean a few hours of AI-assisted bug fixes per month at minimal token cost. The same "low" intensity label on a large legacy codebase still involves more context-gathering per fix, which shows up as a higher baseline maintenance AI cost even when the volume of changes is similar. Production support level (none, basic, standard, or high-SLA) compounds this further — higher support commitments mean an AI-assisted on-call workflow needs to be fast and careful, which tends to favor more capable, more expensive models for maintenance work.

Whether you're scoping a greenfield build or budgeting AI-assisted work on an existing codebase, get a range that accounts for it.