Minions, Part 1: an affordable multi-agent SDLC that actually ships
How a tiny team ran an autonomous agent pipeline — ticket to merged PR — without the bill spiralling. The roster, the cost discipline, and what it took to make it real.
This writeup is in progress — what follows is the planned outline, not the finished piece.
First draft — Virgil, kept to the same level of detail already public on /work and /cv.
Pluma internals beyond that are still unreviewed for public disclosure, so this stays high-level
on purpose. Ruan’s to punch up into his voice and decide how much further to open it up.
The premise
Can a small team run an autonomous, agent-driven software pipeline — from ticket to merged PR — without the cost spiralling out of control? At Pluma the answer had to be yes, because the alternative wasn’t a cheaper pipeline, it was no pipeline at all: a small personal-finance fintech doesn’t get to hire its way out of a software backlog, so either the agents pay for themselves or the whole idea is a toy.
That constraint — cheap or nothing — turned out to be clarifying rather than limiting. A pipeline with an unlimited budget can paper over bad decomposition by just re-running everything until it passes. A pipeline that has to watch its spend can’t do that. It has to get the division of labor right the first time, because every retry is a line item.
The roster
The pipeline is a cooperation of specialized agents — implementer, reviewer, fixer, custodian — each with a narrow job, handing work across iterative rounds rather than one agent trying to do everything end to end.
The split isn’t arbitrary. Implementing and reviewing are different modes of attention — one is generative, one is adversarial — and running them as the same pass, in the same context, tends to produce an agent that’s gentle with its own work. Splitting them apart, with the reviewer never touching the code it’s reviewing, keeps that adversarial edge. The fixer exists because “review found problems” and “fix problems” are also different skills: a surgeon making a targeted patch on an existing branch is a narrower, cheaper job than an implementer building the thing from scratch. The custodian closes the loop — a PR isn’t done when the code is right, it’s done when CI is green and every review comment has actually been resolved, and that bookkeeping is its own job too.
Cost discipline, up front
Cost discipline here isn’t a single trick, it’s a handful of decisions that all point the same way: don’t let an agent redo work it’s already paid for. Containerized validation instead of blindly re-running the full suite after every change. Multi-model cross-review (more on that in Part 2) catching mistakes early, cheaply, instead of letting them survive to a slow and expensive human review cycle. Narrow, single-purpose agents instead of one generalist that reasons over everything every time — a narrower job needs less context, and context is most of the bill.
None of this is exotic. It’s closer to a staffing decision than an engineering one: hire specialists, give each one a small enough job that they can be fast at it, and don’t pay anyone to redo work that already happened.
Coming in Part 2
Failure modes, guardrails, and the multi-model cross-review (Claude + Gemini) that catches what a single model’s blind spots miss.
Comments
No comments yet — be the first.