Coherent main is the unsolved seam

Ask most teams what "green main" means and you get a clear answer: it compiles, the tests pass, the build is reproducible, and the pipeline is happy. That answer is correct, and it is also the easy half of the problem. Making a branch buildable is a solved, well-funded commodity. Continuous integration, hermetic build farms, and merge queues have industrialized it. You can buy it.

The half that stays open is quieter. When many changes land on one trunk, each of them individually correct, the combined tree can still stop meaning what everyone thought it meant. That is the seam we care about: not whether main builds, but whether main is coherent.

The part that's solved

Buildability is a mechanical property. A change either compiles against the tree it lands on or it doesn't. A test either passes or it fails. These are decidable, cheap to check, and easy to gate. The industry has spent a decade making them faster and more reliable, and that work paid off. A merge queue can rebase your change onto the latest trunk, run the suite, and refuse the merge if anything goes red. It is good at what it does.

Because it is decidable and buyable, buildable main is no longer where the risk lives. Treating it as the finish line is how teams convince themselves a release is safe when it isn't.

The part that isn't

Coherence is a semantic property, and it lives between changes rather than inside any one of them. A contract shifts on one side of the codebase while a caller on the other side keeps its old assumption. Two modules each redefine a shared term slightly differently. An invariant that three features quietly depended on is relaxed by a fourth. None of this shows up as a build error. Often it doesn't show up as a test failure either, because no single test was written to assert the thing that just stopped being true.

Main can be green and still be wrong about itself.

That gap is not exotic. It is the normal condition of any codebase where more than one person, or more than one agent, is changing things at once. The more parallel the work, the wider the seam.

Two correct changes, one broken whole

Picture two lanes of work. One tightens how an identifier is validated. The other adds a feature that generates identifiers the old way, trusting the old rules. Each lane builds. Each lane's tests pass, because each lane tested the world as it understood it. Merged together, the system now produces values it will later reject. Nobody wrote a bug. The bug is in the combination, and the combination is exactly what no lane owned.

This is why "just add more tests" doesn't close the seam. Tests assert what a change's author already thought to check. Coherence failures are, almost by definition, the things nobody thought to check because they emerged from a pairing that no author saw whole.

Why AI-assisted work sharpens it

When you put several AI coding agents to work in parallel, you get more of exactly the situation that exposes the seam: many plausible, individually buildable changes arriving fast, authored by workers that each see only their slice. The build stays green. The trunk drifts out of agreement with itself faster than a human reviewer can hold the whole picture in their head.

The reflex is to slow down — serialize the work, add gates, ask a person to read everything. That trades away the reason you reached for parallel agents in the first place. The better answer is to make coherence a checked property, the way buildability already is.

What we build against it

This is the ground AIGIS Workbench works on. We treat a proposed trunk not as a pile of green branches but as one integration tree that has to be coherent as a whole. Before changes combine, they are adjudicated against each other — across providers, so no single model's blind spot decides the outcome — for the contracts, assumptions, and invariants they share. Buildability is the floor, not the verdict.

We think this is the honest place to spend engineering discipline right now. The buildable-main problem is solved and commoditized; you should buy it and move on. The coherent-main problem is still open, and it is where governed, cross-checked integration earns its keep.

• Buildable main is decidable, cheap, and bought. Stop treating it as the goal line.
• Coherence lives between changes, not inside them. It is the property parallel work threatens first.
• More tests don't close it — they only assert what someone already thought to check.
• Make coherence a checked property of the combined tree, adjudicated across providers before merge.

Green is a good start. It is not the same as right. The work worth doing now is on the seam between them.