The model was never the hard part.
Two people ship and operate a production app on iOS and Android. The thing that made that possible was not a better prompt. It was two years of building the structure around the agent — the standards it reads, the gates it cannot talk its way past, and the memory that stops it relearning the codebase every morning.
What is actually running
Four layers. None of them are novel on their own. The work was deciding where each one has to be strict and where being strict just slows everything down.
The fleet
Five specialised roles rather than one general agent: explore the codebase, write the spec, plan the work, implement it, then inspect what came back. Each role gets its own instructions and its own tools. Splitting them was the change that made long jobs survivable. A single agent asked to do all five drifts by the third one.
The gates
Nothing merges unless every check passes, including a custom static analyzer I wrote for my state-management rules and published to PyPI. Roughly 200 architecture decisions are written down as standards the agents read before they touch anything. A hook blocks the session if the work tries to finish without a self-review.
The tools
About forty command-line harnesses wrapping the services I actually depend on: Supabase, Stripe, RevenueCat, App Store Connect, Google Play, Cloudflare, Sentry. An agent operates the real system instead of describing what it would do. Each one is permissioned, logged, and safe to run twice.
The watch
Every agent session reports to a local OpenTelemetry collector with a live view of what is running, what it cost, and where it stalled. Orchestration is an always-on daemon that wakes the model per event. Models are the expensive part; you do not want one minding the clock.
Verification means trying to prove it wrong
An agent asked "is this correct?" will tell you yes. So findings get handed to independent reviewers whose instructions are to refute them, and a finding only survives if the attempt fails. When several reviewers are worth running, they get different lenses rather than the same one repeated: correctness, security, whether it reproduces at all.
That one change caught more real defects than any amount of prompt tuning did.
A consumer app across six sports on iOS and Android, built and maintained by two people. A thousand users in the first two months with nothing spent on advertising.
Privacy and compliance work spanning four jurisdictions, including COPPA and the UK Children's Code, because the app holds photographs of children and that is not a thing to improvise.
This was proven at two people, not two thousand.
I have not run this inside a large engineering organisation, and I am not going to pretend the politics of one are the same problem. What I can say is that the parts that carry the weight are portable, because none of them depend on trust. A gate that a machine checks does not care how many teams are behind it, and a standard written down is a standard whether one person reads it or forty do.
The part that would not survive the move is the part I would want to talk about first: who inside the company owns it after I stop pushing.
Written out at length, free, no email wall.
The environment is the leverage is the full account of the method: the standards, the gates, the memory, and what each one was worth. About sixteen minutes.
Incentives are the architecture is the other half: why a system's structure decides its behaviour more reliably than anyone's intentions do.
If you want the teaching version of this for your own team, that is DayLight AI. If you want it built, start here.