Every conversation about AI-assisted development starts in the same place: a clean editor, a blank file, and a prompt that says build me something.
That's Greenfield. And almost everything written about spec-driven development, red-green-refactor loops, and AI coding agents assumes you live there — that you have the luxury of defining done before you start, that your spec is honest because you wrote it ten minutes ago. Most engineering teams don't live there.
Three Fields, Three Realities
The field you're in determines everything — what "spec" even means, what a test can tell you, and whether an AI agent is a force multiplier or a liability.
Greenfield is what the demos show. Net new. You define intent, the agent builds toward it, and tests verify arrival. Red-green-refactor works perfectly here because the test fails before anything is built. Every AI coding tool is optimized for this world.
Brownfield is where most teams actually work. Existing codebase, still evolving. Tests exist, but coverage is uneven. Documentation is chasing the code, not leading it. Intent is partially recoverable if you're willing to do the archaeology.
Blackfield is something different. Legacy systems under high load, often on a deprecation path everyone agrees on, and nobody has time to execute. Features are still being bolted on because the business can't wait for the rewrite. Original authors gone. Tests, if they exist, describe the system as it was. Documentation, if it exists, lies.
Blackfield isn't just a brownfield with worse docs. It's a different engineering posture. In a brownfield, you're trying to improve something. In blackfield you're trying not to break something while slowly walking away from it. AI agents — trained to build forward, iterate toward green — are carrying the wrong assumptions into that room.
The Spec Problem Nobody Admits
Spec-driven development has a hidden premise: you know what your system is supposed to do.
In Greenfield, true. In a brownfield, partially true. In Blackfield, false.
Blackfield systems accumulate behavior nobody planned. Business rules encoded in conditionals that outlived everyone who understood them. The spec was never written, or was written and then made irrelevant by a decade of undocumented decisions.
When you ask an agent to work in a blackfield system without a spec, you haven't freed it from needing one. You've made the spec implicit. The agent infers it from code shape, variable names, recognizable patterns — and that inferred spec will be wrong in ways that are hard to detect and expensive to discover.
The spec problem isn't solved by better prompts. It's solved by better sources of truth. And in Blackfield systems, most sources of truth have already rotted.
The problems harness engineering is trying to solve aren't new. The legacy code community worked out most of the answers before the term existed.
Michael Feathers' Working Effectively with Legacy Code introduced characterization tests — written not to verify correct behavior, but to document current behavior. You capture what the system does so that when you change something, you can see what moved. The test suite becomes a behavioral snapshot, not a correctness assertion. A failing test doesn't mean the system is wrong. It means something changed that you didn't anticipate. Not a goalpost. A tripwire.
The strangler fig, contract testing, traffic shadowing, canary analysis — all answers to the same question: how do you gain confidence in a system you can't fully read? You don't read the system. You observe it.
System Tests as Archaeology
Black box system tests — validating end-user behavior without caring about implementation — survive the decay that kills everything else. Documentation goes stale. Unit tests shatter on refactors. Integration tests break on dependency upgrades. But a test that says "a user can log in, submit a form, and receive a confirmation email" stays honest as long as the feature exists. It's anchored to behavior users depend on, not to code structure. Writing system tests before any agent-assisted work isn't testing hygiene. It's archaeology — encoding what the system has promised its users in machine-checkable form. That's a behavioral spec an agent can actually work against.
Except: what if the system tests aren't maintained either?
Tests written five years ago may pass while describing a system that no longer exists the way they think it does. A green test suite on a blackfield system isn't confidence. It might be a fossil record.
Production Telemetry Is the Spec That Survived
When everything else rots — the documentation, the tests, the original ticket— one thing doesn't lie. Users kept showing up.
They kept logging in, hitting endpoints, triggering workflows. In doing so, they voted continuously on what the system actually does. Traffic patterns show which features matter. Error rates show where the system is already silently failing. Usage paths reveal workflows nobody documented. Latency distributions show where the invisible complexity lives.
Charity Majors has argued for years that production is where you find out how your system actually behaves. Her framing is forward-looking — instrument as you build, observe as you deploy. But the same logic applies backward, to systems that nobody instrumented properly when they were young.
The production telemetry of a system isn't just operational data. It's the accumulated record of what the system has been asked to do and how it responded. The spec that survived. Every other artifact decayed. The telemetry kept accumulating.
What This Means for Agents
Current AI coding agents can read code, tests, documentation, and Markdown specs. They're good at working within the context they're given.
What they can't do is read production. They can't look at years of request patterns and understand which code paths are load-bearing in ways the code itself doesn't reveal. They can't distinguish a dead-edge case handler from one that runs for 0.01% of users who'd notice immediately if it disappeared. They can't see the ghost constraints — compliance requirements, business rules — encoded in production behavior but nowhere in the codebase as explicit logic.
An agent working on a system sees the code but not the contract. It sees the tests but not whether those tests still describe reality. The result is confident-sounding output that violates constraints nobody told it about — not because it coded badly, but because the spec it was given is incomplete in ways invisible from inside the codebase.
The Honest Sequence
For non-greenfield systems, the sequence isn't: Write a spec → generate code → run tests
It's: Observe production → extract behavioral contracts → encode as system tests → use those as the spec → then bring the agent in
The tools already exist. Characterization tests. Approval tests. Contract testing. Traffic shadowing. Canary analysis. These aren't new ideas — they're what software engineering found before AI entered the picture. The AI conversation needs to inherit them rather than pretend the problem is solved by better prompt templates.
We have handed agents the codebase, the tests, the docs, the specs, the commit history.
We haven't handed them the one artifact that actually survived — the record of what users have been asking the system to do, every day, for years.
Until agents can read that layer — not as log lines, but as behavioral contracts, as the accumulated promise a system has made to the people who depend on it — harness engineering in brownfield and blackfield will remain a fundamentally human problem with an AI assistant bolted on.
What would it mean to make production telemetry queryable as a spec? Not as a dashboard. Not as an alert. As a source of truth, an agent could consult before touching anything. That's the gap. And it's bigger than the tooling conversation has admitted yet.
Originally published on LinkedIn.