← back to the skyAnsh Chaturmohta
14h06m −56°

Dev Pipeline

An autonomous dev assistant I built at work. Hand it a task, it plans, reads the code, and comes back with a pull request.

Plan · explore · edit · PR
what one task actually runs
Docker on a VM
where the work happens
My team
now trialling it
PythonDockerLLM agentsMCPGitHubJiraChat ops

What it does

You describe a task in chat. It writes a plan, explores the repository, edits the code, runs what it needs to run, and hands back a pull request or a design document. You can read the plan before it starts, watch each step as it goes, and steer it mid run when it is heading somewhere you did not intend.

What it is not allowed to do

On its own machine it can do almost anything: clone the repo, read it, edit it, run the tests, draft the write up. What it cannot do is touch the outside world. No pushing a branch, no opening a pull request, no publishing a document, no filing a ticket.

Each of those comes back to me instead, as a queued action I run on my own machine with my own credentials. So the agent never holds write access to anything that matters, and every change that actually lands has a person's name against it. That one rule shaped the entire design, and it is the part I would defend in a review.

Why I built it

A good half of engineering is well specified and dull: find the file, wire the boilerplate, write the migration, update the tests, open the PR. I wanted to know how much of that could be handed off without handing over anything dangerous, and the only way to find out was to build it and then use it on my own tickets first.

Where it is now

It is on trial with my team, and a standup bot grew out of the same system. The engineering was the easy half. Getting people to actually change how they work is the hard one, and it is where I am learning the most right now.