thisisfatih

The refactor-per-cycle fix lands in the right place. The harder problem shows up when EvanFlow forks into parallel coder/overseer mode: unit tests pass per agent, but the seams break at merge. Your note that "integration tests at touchpoints ARE the cohesion contract" is exactly right, but enforcement is what makes it stick. Each parallel branch needs its own failing test that can't be masked by another branch's green run. Worktree isolation handles this cleanly since each agent's environment is separate. Without that, vertical-slice TDD in parallel collapses to "tests pass somewhere."

On jtfrench's unanswered question about dumb zone evasion: context length is what drives the drift. Agents go off-track when a loop runs long enough that early design context falls out. Resetting at each RED-GREEN-REFACTOR boundary keeps cycles short enough to avoid it. The hard cap of 5 iterate rounds is the same instinct applied at the macro level.

We ran into the parallel integration seam problem building tonone, a 23-agent Claude Code plugin where each domain agent works in its own worktree and integration tests are the merge contract.

https://github.com/tonone-ai/tonone if curious.

Over the Easter holidays I hacked together an AI team. Gave each agent a name, a single hat, and told them to think like a founder in their domain.

Something clicked. Context size dropped, token consumption dropped, output quality went up. Noticeably. I put all this on Github and made it open source.

https://github.com/tonone-ai/tonone

I didn't stop there, ended up building a marketplace for all the agents and skills too.

https://second.tonone.ai

Curious if others get the same result. Very open to ideas on where to take this.

I currently built the engineering team and the product team. Both has the lead (head of) and they orchestrate the whole show with sub-agents.

My potential plan is that I extend this to whole company and we have a full AI team that works with 'The Founder'.

I feel like Tinder has similar issues with job seeking and employee finding

In fact after a second thought, its almost identical.

It actually works on both ends however recruiter way is prob the most expensive way for especially employers but also in some cases for job seekers. + I am not sure how scalable recruiter setup is.

+1 to everything you've mentioned, well said. These are I believe facts and it makes the solution nearly impossible but I really believe that there must be a solution to this setup.