What I mean by an AI coding pipeline
How a role-based coding pipeline separates implementation, review, and remote delivery authority.

Hanzup was coding itself when I took this screenshot. The terminal shows planner, builder, spec-reviewer, MR-manager, and fixer running in parallel windows of one tmux server, on a real repository, on an ordinary day.
The part actually worth worrying about in AI-assisted coding is not a model writing bad code. A reviewer catches bad code. It is a model deciding, on its own authority, that its own change is good enough to ship. No engineering team lets one person write, review, and merge their own change unsupervised. The interesting design question is what stops one agent from doing exactly that.
The roles in that screenshot do not just divide labor; they divide authority. The builder and the fixer may commit to a local checkout. Neither can push. Remote push and merge-request authority belong to one dedicated role, the merge-request manager — so the roles that write a change are never the role that ships it.
An AI coding pipeline is not a prompt wrapped around a coding model. It is the division of authority that holds even when a model reasons badly. Models are replaceable; the boundaries are what I trust.
Coding is cheap. Show me your pipeline.
If you’re building an AI-assisted coding workflow, reach out to me on LinkedIn.
Follow the work
Essays and field notes, as they’re published.
Read new posts through RSS, or follow the shorter notes on LinkedIn.