Everyone is racing for smarter models. I went the other way. I made the environment so smart that a commodity model ships production code — and I shipped a full operating system, alone, in months. Here are the five techniques.
Bigger context windows. Bigger parameter counts. Bigger benchmarks. The assumption: if the model is smart enough, it figures out the project. The result: huge bills, drift, hallucination, and a junior engineer's worth of work for a senior engineer's worth of cost.
Make the project so well-structured that the model has almost nothing to decide. Specs are truth. The filesystem is the workflow engine. Templates make drift impossible. The model's job shrinks to "fill in the next blank." Smaller models. Less context. More throughput.
Most teams treat code as truth and docs as commentary. We invert it. Every component in amiaOS has a living JSON spec — the namesake — that describes what it is, what it does, where it lives, and how it integrates. Humans write intent in the spec. The AI reads the spec and writes code to match.
When the spec changes, the code follows. When the code changes, a daemon updates the spec back. They never disagree, because one is generated from the other.
No Jira. No Linear. No project management tool. Every component has four files. A daemon watches them with inotify. When one changes, the next one updates automatically. The AI reads one file — the master changelog — and knows everything that's live in the entire system.
When a new AI session opens, it reads the changelog. The changelog points to the active update. The update points to the spec. Within three file reads, the AI knows what to do, where the code lives, and how to verify the result. There is nothing for it to figure out.
Every spec has the same eight sections. Every ticket has the same shape. Every update has the same phased structure. There is no "creative way" to write a spec because there is nothing creative about it — the template enforces itself, and a daemon flags violations the moment they appear.
This is the move: remove the model's degrees of freedom. A small model can't go off-pattern when there's no pattern to invent. It just fills in the next field.
There are two AIs in this system. A project manager and an engineer. They never step on each other — not because they're polite, but because they're physically not allowed to read each other's files. The PM cannot read source code. The engineer cannot rewrite the plan. Each one's context window stays clean. Each one's decisions stay separated from the other's implementation.
The only channel between them is the ticket file. The engineer raises a question. The PM answers in the ticket. The PM never opens a code file. The engineer never invents a direction. The boundary holds because the tools enforce it.
The ticket file holds open tickets only. When a ticket is resolved, it gets deleted from the file — not archived, not preserved, not commented out. The same with the plan: when phases complete, the plan is overwritten by the next plan. There is no history section. There is no "deprecated" pile. There is no rot.
Git already solves the archive problem. Duplicating archival in working files is how stale references mislead future readers. The working file always shows current truth. Past truth lives in commits.