Claude-to-prod is a greenfield playbook.
Don’t try this on a legacy monolith.
Everything else on this site is about how to go from Claude to production responsibly. This page is about where that stops being true. If you take one thing from this site, it should be this page — because the failure mode isn't "AI writes bad code." It's someone reading the rest of this site, nodding along, and trying it on a ten-year-old system that was never built for it.
Why greenfield is different
On a new build, Claude has full context. It wrote every file. There's no hidden coupling, no "don't touch that, nobody knows why it's there" service, no business rule encoded only in a stored procedure from 2014.
The nightly verification job works because it's checking a small, known surface area. On a legacy app, the surface area is enormous and partially undocumented — even to the humans who work on it.
"Check the results, not the code" only works when you actually know what the correct result looks like. On a legacy system, correctness is often tribal knowledge, not a testable spec.
What actually breaks on legacy systems
- Undocumented business logic — the pricing edge case that only exists because of one client's contract from three years ago. Claude has no way to know that exists unless it's told, and it usually isn't in a legacy repo.
- Hidden coupling — a change that looks isolated actually breaks a batch job, a report, or an integration that reads the same table in an unexpected way.
- Data migration risk — legacy schemas accumulate years of exceptions. An AI agent making a "reasonable" schema assumption can silently corrupt data that doesn't fit the assumption.
- Partial context is worse than no context — Claude reading some of a large legacy codebase can be more dangerous than reading none, because it produces confident-sounding changes based on an incomplete picture.
- Nightly automated checks don't scale the same way — the pen-test and validation approach on this site works because the blast radius is small and known. On legacy systems the blast radius of a bad change is often invisible until it's already caused a problem downstream.
Where the line actually is
New product, new codebase, small team — this playbook applies well.
A well-isolated microservice or module inside a larger legacy system, with clear boundaries and its own tests — can work, with extra caution.
Core legacy business logic, shared databases, systems with unclear ownership or tribal knowledge — this playbook does not apply. Use Claude as a reviewed assistant here, not an autonomous committer.
The rest of this site is proof that Claude-to-prod can be done responsibly. This page is proof that "responsibly" has a boundary. Knowing where that boundary is isn't a weakness in the argument — it's the argument.