Every stage of building an Avni implementation now starts the same way: an agent produces a first draft, and a human decides whether it's right. That's the entire method. The typing is mostly AI; the judgement is entirely ours — and it turns out the judgement was the actual job all along.
Avni is an open-source platform that 70+ organisations use to run field programmes for millions of people. Taking one NGO from a programme spec to a working, field-ready app used to be weeks of specialised manual work at every step. We didn't delete the steps — we handed an agent the routine 80% of each one and kept a human on the 20% that actually needs a decision.
One rule, repeated six times
The lifecycle has six stages. What changes between them is the work; what stays constant is the contract — AI drafts, a human decides. Each stage is a Claude Code command that produces something reviewable, and a person who owns the call.
Walking the lifecycle
- ▸Scope —
/analyse. The agent maps an NGO's requirements, separates what's configuration from what needs code, and estimates against the fifty-odd setups we've already shipped instead of guessing. A human decides what's in scope. - ▸Design —
/spec. Before it writes a line of spec, the agent reads the live codebase — data models, sync patterns, the gaps — so the design is grounded in what's actually there, not what it remembers. A human signs off on the spec. - ▸Build —
/implement. Planning, code, and tests come from the agent. We retired the 6pm ritual of squinting at a 400-line diff and moved the rigor to where it pays: agree the design up front, review the commit after. A human owns what lands on master. - ▸Release & QA —
/test-charter. The agent writes and maintains the test harnesses — Maestro on Android, Playwright on web — runs them against the live app, and tells a real regression apart from a flaky script. QA approves the release. - ▸Support —
/triage,/datafix. This stage is mine end to end./triageclassifies a ticket and drafts a plain-language reply;/datafixwrites a SQL file it is structurally incapable of running — there is no write connection to production anywhere in the workspace. A human sends the reply and executes the fix. It cut resolution time 60%. - ▸Orchestrate —
conductor. Work scatters across boards, email, and chat. The agent aggregates it, kills duplicates, ranks by real urgency versus loud urgency, and pre-drafts the routine items. A human makes every discretionary call.
The fastest version of every one of these stages is also the safest one — where the model does the drafting and a person keeps the decision. Speed and trust usually trade off. Here they don't.
Where AI earns its keep — and where it doesn't
Being honest about the failure modes is what makes this safe to run across 70+ live deployments. Three of them shape how the whole system is built:
- ▸Fluent answers are the dangerous ones. A spec can read beautifully and be subtly wrong, and a well-written draft is the easiest thing to wave through. The human decision point exists precisely because good prose lowers your guard.
- ▸Novel work degrades. The agent is excellent when there's a close cousin in the codebase to pattern-match against, and noticeably weaker when there genuinely isn't. Knowing which situation you're in is part of the job.
- ▸Memory lies; live code doesn't. The biggest single jump in quality came from forcing the agent to read the real codebase before acting, instead of working from a confident memory of how things 'usually' look.
None of this is 'AI writes the software.' It's a system where AI does the drafting and a human keeps every decision that's expensive to get wrong — and the entire toolkit I build around it, cost caps, tool-gates, real-LLM evals, and read-only production, exists to make that second half real. The typing got cheap. The judgement is still the job.