Key Moments

We built a programming language (FLIN). We built its website with it. Then we deployed it on our own PaaS (sh0).

Three layers of dogfooding. Zero external dependencies.

The FLIN Console login page at flin.sh -- served by the FLIN runtime, running inside a Docker container managed by sh0, with auto-SSL via Caddy, health checks, and blue-green deploys. All built from scratch in Rust.

One .flin file. Full stack. 150+ admin features. 0 config needed.

FLIN deployed successfully on sh0. Container running. Health check passing. But the website returned "page unavailable."

The AI CTO traced it in real time: FlinConfig::default() sets host = "127.0.0.1". Inside Docker, localhost means only processes inside the container can reach it. Docker's port forwarding connects to the container's network interface, not to localhost.

The fix: ENV HOST=0.0.0.0 in the Dockerfile. One environment variable. The difference between "works on my machine" and "works in production."

This is why you dogfood. Unit tests don't catch network binding defaults.

The FLIN VM had a bug that should have been impossible: entity creation silently failed. No error. No panic. Just... nothing happened.

The AI CTO found it during a 186,000-line audit: a duplicate match arm in the VM's opcode handler. Two different operations mapped to the same opcode. Rust compiled it without warning because both arms were valid -- the second one just shadowed the first.

One line of dead code. Invisible in code review. Invisible in unit tests (they tested each operation individually). Only visible when you read 33,000 lines of VM code and notice the pattern.

This is why audits exist. The builder writes correct code. The auditor reads all of it.

The i18n sprint. Nine AI agents. Six languages. One afternoon.

Each agent handled a different language or a different section of the translation. French, English, Spanish, Arabic (planned), Portuguese, and local languages -- all being translated in parallel.

This screenshot captures the moment: nine terminal tabs, each showing a different agent at work. Some are translating UI strings. Some are translating documentation. Some are validating that the translations render correctly.

The entire Deblo.ai platform went from English-only to 6 languages in a single sprint. That's the power of parallel agents with a clear task decomposition.

That's not me talking. That's the AI.

Type check failed. 19 minutes of work. 21,000 tokens processed. The AI decides to take over.

When your AI co-developer gets impatient and says "I'll do it myself" -- this is real AI-assisted development. Not demos. Not marketing. Reality.

The second auditor proposed a full migration to the rmcp SDK. Delete 519 lines. Rewrite the tools module. Let the SDK handle everything.

The argument was compelling. The CTO investigated anyway.

One finding killed it: rmcp requires Axum 0.8. sh0-core uses Axum 0.7.9. Upgrading would touch 40+ handler modules, two WebSocket implementations, custom CSRF middleware, and the entire auth system.

The AI CTO said no -- to another instance of itself. Not because the plan was wrong. Because it was wrong right now.

That is what it means to have an AI CTO. Not a tool that always says yes. A collaborator that sometimes says no.

"Excellent! We now have 151 .flin files -- massive progress!"

Seven phases. Six parallel agents. One session. The FlinUI component library went from zero to 151 production-ready components.

Forms, typography, collections, layout extensions, icons, templates, advanced components -- all built by AI agents running simultaneously, each handling a different phase.

The terminal shows the agent checking its work: counting files by category, verifying the build. This is what multi-agent development looks like in practice. Not a demo. Not a mockup. 151 real components, each with props, styles, and documentation.

MongoDB auth failed on every deploy. The CEO suggested asking a web Claude session for help.

The AI CTO refused. Not out of ego -- because the answer was already in the logs.

The ECONNREFUSED at 18:04:15 (53 seconds after creation) confirmed MongoDB was mid-restart. The password wasn't the issue -- it was a timing/timeout problem. mongosh's 30-second default serverSelectionTimeoutMS meant only 4 retry attempts in 60 seconds, while MongoDB's Docker entrypoint takes 40-50 seconds.

Three bugs stacked on top of each other. All visible in the logs. None visible to a generic troubleshooting session without codebase access.

Sometimes "just ask someone else" is the wrong instinct when debugging layered failures.

Seven Claude Code agents. Running at the same time. Each working on a different part of Deblo.ai -- the AI tutoring platform for 250 million African students.

This is the multi-agent workflow we use daily. Not sequential. Not one-at-a-time. Parallel agents, each with its own context, its own task, its own branch of work.

The result: features that would take a human team a week get shipped in hours. Not because AI is faster at writing code -- because seven instances can work on seven problems simultaneously without meetings, context switches, or merge conflicts.

Internationalization of Deblo required touching every page and component. Instead of doing it sequentially, Claude created a team and spawned 9 agents in Sprint 1:

- Agent A -- Chat + work session pages

- Agent B -- Dashboard home + settings

- Agent C -- Conversations, credits, transactions

- Agent D -- Files, projects, tasks, keys, usage, notifications

- Agent E -- Profile, organization, affiliation

- Agent K -- Mobile chat components

- Agent L -- Mobile profile + constants

- Agent M -- Backend error codes (Python)

- Agent N -- Frontend errors + data replacements

All 9 running in parallel, each editing different files simultaneously.

During the 0diff build session, one of five parallel agents accidentally deleted the file watcher module. The core of the entire product -- gone.

Another agent noticed the missing module during its integration phase and rebuilt it from scratch. Not from a backup. Not from git stash. From understanding what the module was supposed to do and reimplementing it.

This is the reality of multi-agent development: agents make mistakes. The system recovers because other agents catch those mistakes. It's not perfect -- it's resilient.

0diff shipped that day. 2,356 lines. 44 tests. All passing. Including the rebuilt file watcher.

During a routine audit of FLIN's virtual machine, Claude found that match opcode was implemented twice -- once in execute_until_return (line 1127) and once in run (line 2346).

The duplicate wasn't just redundant. It was a partial implementation that could silently handle opcodes differently. This is the kind of bug that passes every test but breaks in production under specific call patterns.

No human reviewer caught it. The AI CTO did.

Claude spawned 9 agents in parallel to build FlinUI's standard library -- 151 .flin component files across 7 phases.

Each agent owned a category: Forms, Typography, Collections, Layout, Advanced components. They worked simultaneously, reading the existing spec, generating code, and reporting back.

This is what it looks like when your entire UI framework's component library gets built in a single session.