Can AI agents work on an existing codebase?

Yes, and brownfield is where the discipline shows. How a factory reads an existing architecture, works inside its conventions, and what to do first when the system is legacy and has no tests.

The demos are always greenfield. The real question, for any team with a system in production, is whether AI agents can work inside an existing codebase, with its history, its conventions, and its debt. The answer is yes, and brownfield work is precisely where a factory's discipline shows, because the cost of a change landing in the wrong place is real.

Reading the architecture before touching it

The AI Software Factory reads your architecture before producing anything. The change lands in the right layer of your system, where your team would have put it, following your conventions. On an existing codebase that constraint is the whole game: a correct change in the wrong place is a future incident.

The legacy case: when the system has no tests

Many production systems carry years of value and no test suite. Teams live with manual regression on every release, zero coverage, or a dead suite that went flaky and stopped being maintained. Working on such a system with AI, or with anyone, starts by building the safety net: end-to-end suites that run in your CI, checking real behavior rather than that a page opened, living in your repository in Playwright and TypeScript, written and repaired by AI with engineers defining what correct means and approving what lands.

Making the codebase easier for agents to work in

Beyond tests, there is preparation: structure, conventions, and documentation that make a codebase legible, for new engineers and for AI agents alike. That is its own line of work (AI-ready codebase), and for older systems, legacy modernization tackles the parts whose shape blocks progress. The order matters: safety net first, then legibility, then throughput.

The same controls, everywhere

Whether the codebase is two years old or fifteen, every factory change ships with tests derived from the acceptance criteria, an independent check against weakened tests, a traceability record, and a human gate inside your existing pull request process. Old systems do not get a lower standard; they are exactly where the standard pays.

Frequently asked questions

Can AI agents modify a legacy system safely?

Safely means with a safety net: an end-to-end test suite checking real behavior in CI, built first if it does not exist, plus verification and human approval on every change. With that structure, agents work on legacy systems the way careful engineers do, with evidence.

What should a team do first: modernize or add tests?

Tests first. A suite that checks real behavior makes every later step, modernization included, verifiable. Modernizing without a safety net converts unknown risk into changes nobody can validate.

How does the factory learn my codebase's conventions?

The pipeline reads your architecture before touching it, and produces changes in the layer and pattern your team would have used. The engineer at the human gate confirms exactly that before anything merges.

Does this work only for new projects?

The factory is built for your architecture, existing systems included. Brownfield work is where the controls (tests from criteria, independent check, traceability, human gate) matter most.