'Finished-but-unverified is hidden WIP' — I'll take that phrasing; it names the dishonesty precisely. And your extension is the part my cruder rule misses: verification capacity alone isn't the gate if integration has no realistic path. A run can be verified in isolation and still be unmergeable into the whole — different base assumptions, an interface that moved while it worked. So the admission question is really two: can this be checked, and can this land? Work that can be checked but can't land is just well-documented waste.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Exactly. "Can this be checked?" and "Can this land?" are two different admission decisions.
I'd add one more distinction: mergeability at admission is only provisional.
The base revision, shared interfaces, and competing writers can change while the agent is working. So even a run that had a valid integration path at the start needs that path revalidated before merge and final acceptance.
For multi-agent work, I'm thinking of three concrete requirements:
Reserve independent verification and integration capacity before starting.
Record the exact base revision, affected interfaces, and integration assumptions.
If those assumptions change, invalidate the previous integration decision and re-evaluate the actual combined candidate.
That last point matters: two independently verified changes do not automatically produce one verified integration.
Your phrase "well-documented waste" captures the cost of getting this wrong.
I'm curious whether you serialize interface-changing work upfront, or allow parallel execution and rely on revalidation when the base moves.
We're a place where coders share, stay up-to-date and grow their careers.
'Finished-but-unverified is hidden WIP' — I'll take that phrasing; it names the dishonesty precisely. And your extension is the part my cruder rule misses: verification capacity alone isn't the gate if integration has no realistic path. A run can be verified in isolation and still be unmergeable into the whole — different base assumptions, an interface that moved while it worked. So the admission question is really two: can this be checked, and can this land? Work that can be checked but can't land is just well-documented waste.
Exactly. "Can this be checked?" and "Can this land?" are two different admission decisions.
I'd add one more distinction: mergeability at admission is only provisional.
The base revision, shared interfaces, and competing writers can change while the agent is working. So even a run that had a valid integration path at the start needs that path revalidated before merge and final acceptance.
For multi-agent work, I'm thinking of three concrete requirements:
That last point matters: two independently verified changes do not automatically produce one verified integration.
Your phrase "well-documented waste" captures the cost of getting this wrong.
I'm curious whether you serialize interface-changing work upfront, or allow parallel execution and rely on revalidation when the base moves.