How Aigarth is built: the 90/10 split

We want to be honest about how Aigarth is built. Not the marketing version. The real one.

The number

By content volume, about 90% of what we ship is generated by AI. By decisions, about 90% is human. The two numbers do not add to 100% on purpose. They measure different things. The first is who typed the words. The second is who decided what to build and what to throw away.

Most of the time, both numbers are right at the same time. The agent is typing. The team is deciding. They are not the same job.

What the AI actually does

It writes the code. All of it. Concretely:

• The 12 services that run in production (identity, qubic, compute, gateway, billing, ann, marketplace, tissue, dataset, economy, training, and the new work runtime).
• The 30K+ lines of TypeScript. The Drizzle schemas. The Postgres migrations. The vitest cases.
• The Next.js pages, the API routes, the marketing copy.
• The blog posts, the ADRs, the research audits, the closeout reports. Including this one.

It also does the build orchestration. When we want to ship a phase, we write a one-paragraph brief. The agent reads the relevant docs, drafts a build plan, ships the code, runs the typechecker and the tests, and reports back with a diff. We review. Accept, reject, or steer.

It does the verification. Every wave gets verified end to end before we sign it off.

What we actually do

Four things, in this order of how often we do them.

• We write the briefs. Most of them are one paragraph. Some are one sentence. The brief for the v0.2 evolution was: "Here is the 7-primitive thesis, here is the 10-task list, here is the Falsification Audit. Make this moment a checkpoint and ship the engineering."
• We make the calls. "Accept both, document." "Do not run pnpm dev." "Use plain English, no 'Subscribe to intelligence.'" "The Work Runtime is a separate service, not a sidecar in tissue." These are 10-second decisions that shape 10-hour builds.
• We write the copy voice rules. Not the copy itself. The rules. Plain English. No abstract nouns. Em-dashes become colons. Small uppercase labels under plain-English headlines. Then the agent writes everything inside those rules.
• We decide what to ship and what to throw away. There are 30 phases on the roadmap. We shipped 27. The 3 we did not ship (ZK proofs, TEE attestation, Neuraxon) are explicitly named as deferred. The decision to defer is a product call, not an engineering call.

A typical afternoon

We open the laptop. We want to ship Phase 28 (federated workers). Here is what happens.

• We write a one-paragraph brief. The contract is in ADR 006. Build it.
• The agent reads the ADR, drafts a build plan, ships the first cut. About 40 minutes.
• We review the diff. We find three things we do not like. We steer with one paragraph each.
• The agent revises. About 15 minutes.
• We accept. Phase 28 ships.

Total wall clock: about 90 minutes for a 2 SP piece of work. By a single developer, that would be 2 to 3 days of coding. With a junior engineer, about 1 to 2 days. With a senior engineer, about 1 day. The pattern is faster than any of those, with a different mix of who does what.

What this means if you want to try it

Four things we learned the hard way.

• The AI is good at execution. Bad at taste. It can write 10 versions of a sentence in 5 seconds. It cannot tell you which one sounds like a person. That is your job.
• The founder is the editor, not the author. The founder spends maybe 10% of their time typing and 90% reviewing. The reviewing is the work. The typing is free.
• The pattern only works if you have a strong point of view. If you do not know what your product is for, the agent cannot help. It will produce a lot of code, a lot of documentation, and a lot of nothing. The point of view comes first. The agent executes against it.
• Copy voice rules force the agent to write things you would actually say. Without rules, the agent drifts into "intelligence for everyone" and "subscribe to the future." With rules, the agent writes sentences you would write yourself.

What is next in this series

This is post 01 of the Build in Public series. Future posts will cover:

• The 7 primitives and why each one is its own service.
• How we test a 12-service platform with 600+ tests and a 4-minute CI loop.
• The Falsification Audit: how we decide what is shipped and what is thrown away.
• The cost model: what it actually costs to run an Organism through a Work Runtime cycle.

If you want to follow along, the roadmap is on the site. The blog updates when there is something honest to say.