Building liz — the AI agent fleet that ships Waafir

• Engineering
• AI

Most teams talk about using AI to write code. We built a system that lets a fleet of AI agents do it in parallel, on our production codebase, without losing the plot. We call it liz, and large parts of Waafir were shipped through it.

This post is the engineering story: what liz actually does, the principle that keeps it safe, and why we built our own harness instead of waiting for one.

One agent, one issue, end to end

Work enters liz the same way it enters any engineering team: as a GitHub issue. You enrol an issue, and a worker agent picks it up and owns it from start to finish through four phases — plan, implement, self-review, and fix. It writes a structured plan, implements against that plan, adversarially reviews its own diff, fixes what the review (or CI) turns up, and opens a pull request.

The unit of ownership matters. One agent owns one issue for the whole of its life, holding a claim on it so two agents never trample the same work. That is what lets the fleet run many issues at once: throughput stops being capped by one human's attention, because a dozen agents can each be mid-issue simultaneously.

The discipline: agents propose, humans decide

The interesting problem in AI-assisted development isn't whether an agent can write code — it's how you keep dozens of in-flight agent runs from collapsing into a mess no one can review. Our answer is a hard split of responsibility.

Every agent's output lands as a normal pull request — subject to exactly the same review, test, and merge gates as a human's. Nothing an agent does ships because it decided so. The genuinely consequential moments stay human: an operator approves a plan before implementation begins, merges a PR after CI is green, and promotes a finished epic to the main branch. Risky work waits for a person; routine work flows.

To keep large features coherent, related issues collect on a shared epic integration branch and are promoted to the main line in a single, deliberate human decision — so a multi-part feature arrives as one reviewed change, not a drizzle of half-finished commits.

Why it stays legible

The principle underneath all of this is simple to state and load-bearing in practice: probabilistic agents do the engineering; deterministic infrastructure makes the system observable and controllable.

The agents are flexible and creative — which is exactly what makes them useful, and exactly why they can't be trusted to drive the control plane. So they don't. As agents work, they write their progress to GitHub — comments, labels, a plan, a PR — in a fixed, machine-readable shape. A separate, deliberately dumb monitor reads that journal and renders a dashboard: what is every agent doing, and which ones need you right now? The monitor never dispatches agents and never invents state. If something looks wrong on the dashboard, you go read GitHub directly — there is no hidden machinery to second-guess.

That separation is what makes a fleet of non-deterministic workers auditable. The creative part can be as clever as it likes, because the control surface around it is small, deterministic, and reviewable.

Why we built our own

We could have waited for an off-the-shelf agent platform. We didn't, for the same reason we build the rest of Waafir's core ourselves: the hard part isn't the model, it's the operating model around it — parallelism, review discipline, visibility, and recovery when an agent stalls or goes off-script. Owning that harness means our velocity and our rigor scale together instead of trading off.

liz is how a small team ships like a large one without giving up the review gates that make software trustworthy. It is also, quietly, the clearest statement of how we think about AI generally: let it do the work, keep the judgement with people, and make the whole thing legible enough that you can always check.