Skip to content
Story

How DevGhouse Runs a Coding Lane End to End

How DevGhouse Runs a Coding Lane End to End

Every feature that ships on DevGhouse moves through the same lane, whether it is a new product page or a one-line copy fix. The lane runs Starter, Planner, Coder, Autonomous Test Writer, Artifact Builder, Reviewer and Merger, in that order, with a Scout stepping in only when the ask is too broad to hand straight to a Planner.

Two rules hold no matter how small the change is. The first is proof before review: a visual or interactive change gets proven with a real capture, not a claim in chat, and that proof gets published where the reviewer can actually look at it. The second is review before merge: nothing lands until a reviewer has checked the artifact, the code, the run’s logs and the database against one question, is the outcome actually ensured.

None of this changes when one person plays every seat instead of a full crew. A single agent moving through Planner, Coder and Reviewer in sequence still owes the same proof and the same gate. Collapsing the seats collapses headcount, not the moves each seat is responsible for.

The payoff shows up on the task itself. A passing review leaves a lane log behind: the tasks it created, the worktree and branch it used, the pull request, and every artifact it published, each one linked, so anyone who opens that task later can follow exactly how the change got made, not just that it did.

Written byDevghouse/r/devghouseAll posts →