AI in Samanvay : How we actually build and run the Avni platform now

Yes, we use AI for basically everything. No, it hasn't replaced anyone. What follows is the honest, occasionally funny version — the commands we run, and the humans who still make the calls.

We build and run Avni — open-source software 70+ organisations use to reach over a million people. We can't hire an engineer when a bunch of NGOs show up. So this year we handed AI the boring 80% of every job and kept the 20% that actually needs to be owned by a human.

Here's the whole thing on one screen. Then the receipts.

The whole thing : on one screen

Stage	The command	What AI does	Who decides
Scope	/analyse	maps what the NGO needs, splits config vs code, estimates	a person
Design	/spec · /spec-review	reads the live code, drafts the spec, checks it against reality	a person
Build	/implement · /code-review	plans, writes the code + tests, reviews the diff	a person
Release & QA	/test-charter · /capture-bug	ranks what's risky, writes and fixes the tests, files the bug	QA (the boss)
Support	/triage · /datafix	reads the ticket, drafts the reply, writes the fix	a person
Orchestrate	conductor	pulls every open thread into one prioritised list	a person

Every row ends the same way: AI drafts, a human decides. That last column never changes. That's the whole trick.

Scope : what does this NGO even need

An NGO turns up wanting Avni for, say, a maternal-health programme. Before anyone writes a line of code, /analyse maps what they need onto what Avni already does — who gets tracked, the forms, the workflows, the rules — and sorts each piece into "just configuration" or "actually needs code." /impl-scope turns that into a scoped estimate, calibrated against the fifty-odd setups we've already done instead of a number pulled from the sky.

If we're not sure something's even possible, we build a throwaway prototype before we promise anyone a date. We decide what's in.

Design : read the code, then write the spec

Here's the unglamorous secret: the spec is written from the code, not from memory. /spec has AI read the live codebase first — does the data model actually work the way we assume, does it sync the way similar features already do, what are we forgetting — and only then drafts the spec. /spec-review checks that draft back against real code across our repos: invented endpoints, missing pieces, will-it-survive-a-big-org. /story cuts it into work small enough that someone who's never seen Avni could pick it up.

Boring? Extremely. It's also exactly why the next stage is fast. We sign it off.

Build : straight to master, no ceremony

A story lands. /implement plans the change, writes the code and the tests against that plan, and the developer runs the thing to confirm it actually works — revolutionary, I know.

Then the part people get weird about: we stopped reading diffs line by line. Every change gets an AI /code-review pass — the author runs it, a peer runs it again — and we argue with what it flags. We didn't fire the reviewers. We fired the ritual where a human squints at 400 lines at 6pm pretending to catch a race condition. Straight to master, no pull requests. The seatbelt isn't a merge gate — it's a design we agreed up front, plus a few reviews on every change after a compulsive shake-up, and finally a dummy test the developer runs themselves. A person still owns what lands.

Release & QA : test what's scary, skip what's not

In our QA repo, AI wrote the tests — Maestro flows for the Android app, Playwright for the web console — and, more usefully, it validates them against the live app and fixes them when they break, telling a real regression apart from a flaky script. One of those harnesses drove the real web console against production, tailed the server log (read-only) alongside, and caught a template action that blew up with an HTTP 500 nobody had managed to reproduce. When something breaks in the field, /capture-bug turns "sync spins forever, here's a screenshot" into a proper report with the suspect commit already named, and /diagnose chases the root cause. verify_release.py then does the unglamorous border check: is every story really done, did the code actually land on the release branch, did anything sneak in that belongs to next month. QA calls what ships.

Support : a ticket, minus the busywork

A support ticket lands. /triage reads it, works out whether it's a settings mix-up, a data problem, or a real bug, and drafts the reply in plain language — no jargon, no internal IDs, no personal data. /report drafts read-only analytics and never touches a live dashboard. And /datafix, the one place data actually gets corrected, only ever writes a SQL file for a human to review and run — there is no write connection to any database in that workspace at all.

AI does the reading and the drafting. A human hits send, and a human runs the fix.

Orchestrate : the part that runs the humans

This is the one that surprises people — and honestly the heaviest AI use of the lot.

Running a platform this size, the work never arrives in one place. A request shows up on a task board, another in email, a third in a chat message, a fourth in some checklist nobody's opened in a month. Just keeping track of it all is a full-time job on its own.

So we don't. conductor is an AI that reads every one of those places for us, spots when the same thing is sitting in four of them, and hands back a single ranked list: here's what's genuinely urgent, here's what only feels urgent, here's what can wait. Then conductor-execute takes the items that are really just "go write something" — an estimate, a short analysis, a reply — and drafts them ahead of time, with a second AI checking the first one's work, so we start from a draft instead of a blank page.

The catch is the whole point: it never actually decides anything. The moment it can't tell whose job something is, it stops and asks. The human is the only thing that decides.

What it looks like : a normal afternoon

Four kinds of work at once — scoping, building, testing, triaging — a person on the end of every one.

The honest part : what's still hard

None of this comes for free, and the failure we watch for hardest is our own. AI writes a spec that reads beautifully and is quietly wrong, and a confident, fluent answer is the easiest kind to wave through. The review gates exist for exactly that — us trusting good writing too fast.

It's also brilliant where there's a pattern to copy and merely okay where there isn't. Give it a feature with close cousins already in the codebase and it flies; ask for something genuinely new, or the estimate that rides on it, and the judgement is still ours. And the lesson we paid for: it has to work from the real code, not from memory. Left to recall how the system behaves, it will tell you confidently, and be wrong.

The Q&A : what people actually ask

Did you fire everyone and let a robot do it? No. We fired the boring parts. The people are all still here, doing the 20% that needed them the whole time.

When does it screw up? Constantly, confidently. It'll write a spec that reads great and is wrong, or a fix that's subtly off. That's the entire reason nothing ships on the AI's say-so.

Honestly, how much of this is you and how much is the AI? The typing is mostly AI. The judgement is mostly us. Turns out the second one was the actual job all along.

Under the hood : the tooling

For the people who scrolled straight here — the stack:

• The code is open source across roughly ten repos at github.com/avniproject: the Android app, the server, the web console, the reporting pipeline, the rules and the infra.
• The agent is Claude Code (Anthropic), on Opus and Sonnet, working straight against those repos.
• The commands above — /analyse, /implement, /triage, conductor and friends — are our own reusable skills and multi-agent workflows: the pipeline, written down, so anyone on the team is one word away from it. For the engineering habits underneath, we lean on the open-source superpowers toolkit rather than reinventing them.
• The reach is via MCP — the agent talks to GitHub, Google Workspace, a real browser for testing, and read-only production data. Never a write connection where it shouldn't have one.

Most of it is public. The ops repos that run our day-to-day (avni-product-ops, avni-support-ops, avni-qa) are a mix of public and private, but the working style is identical: written down, versioned, reviewed before it runs. If any of it's useful to your team, get in touch — we're glad to share how it works.

---

DISCLAIMER : This blog was written using AI, inspired by Kevin Hart. If you got any problems with that, you know where to find me.