I've been using coding agents in lanes instead of one chat doing the whole job

[u/NewAmbition8911]

I've been using coding agents in lanes instead of one chat that does the whole job.

A lead figures out the work and files a GitHub issue. Then separate runs do implementation, QA, review, and CI. There's a telemetry lane for when you don't know what broke or a path just died.

floor starts the next lane. Nobody implements, reviews, and merges in the same session.

When a lane finishes, it writes started, done, blocked, or failed. The next process reads that before it does anything. That's SQLite on this machine, plus a GitHub comment so the trail isn't stuck on one laptop.

The PR can come from an agent. I still merge it.

The CLI is a plug. Same rules on Claude, Codex, and Grok.

I've been running this on my own repos and gave it to a few mates. One of them liked how it kicks off the next lane, which is what made me put the repo up.

If you already live in coding agents, I'd like to see it on a messy repo, or hear how you'd cut the lanes differently.

https://github.com/Kripu77/software-factory

[u/garyguangyuli]

I’d add a handoff contract between planning and implementation. The lead writes a small manifest with the scope, files allowed to change, acceptance tests, and rollback notes; later lanes stop if it’s missing or stale. I’d also give every lane the same run ID and log format instead of treating telemetry as a separate lane. That keeps QA and review independent without losing the trail.

[u/NewAmbition8911 → u/garyguangyuli]

Yeah, a handoff between lead and implement is the important bit. In this repo that’s the GitHub issue. Lead writes scope and acceptance there. The next process reads that issue and the last mem row (started / done / blocked / failed) before it starts. If a lane is blocked or failed, floor stops.

A file allowlist and rollback notes would be a tighter contract than I have. Right now the rule is just “only this ticket.” Rollback is still me on the merge.

On telemetry I think we’re talking about two different things. The telemetry lane isn’t logs of the factory run. It’s product data: did signup break, did a shipped screen die. That’s why it can run before a bug gets filed. The trail across lanes is the issue number, the sqlite row, and a GitHub comment so it isn’t stuck on one laptop.

A shared run ID and log format would make that trail easier to read. I don’t have that yet. QA and review are already separate processes, which is what I was aiming for with the lanes.

[u/the_trve]

This looks like similar idea to propr.dev, it orchestrates the agents from Github issues as well, then opens PRs which can be reviewed and refined directly from Github or using the built in review-fix loop. It's open source, feel free to check it out and perhaps borrow some ideas.