PilotOS · Wings · CodePilot

The first wing
being shipped
to build the rest.

CodePilot is the 5th wing of PilotOS and the first one live. The recursive wing — the one that builds the others. Plain-English request → autonomous coding loop → real GitHub PR with receipts.

Live · cockpit.pilotos.dev · First customer: PilotOS itself · ~5 min read

1 / 5

wings live
(of 5 planned)

customer today
(the founder)

repo wired
(pilotos itself)

∞

wings unlocked
by this one

The recursive bet.

There are five PilotOS wings on the roadmap. AdPilot runs ad campaigns. AppPilot ships apps. DocPilot drafts company docs. WebPilot ships sites and landing pages. CodePilot writes code.

All five run on the same four foundations (Atlas / Compass / Rennick / Nexus). All five share the same cockpit shell. All five are real future products.

But they don’t ship at the same time. CodePilot ships first — and not because it’s the easiest wing or the most important. It ships first because building any of the other four requires it.

The recursive bet

CodePilot is not just one of five wings.
CodePilot is the wing that builds wings.

The agent driving CodePilot today is the same agent who will draft the AdPilot campaign-launcher logic, the AppPilot scaffolding flow, the DocPilot template engine, the WebPilot site-deploy hooks. CodePilot ships first so the rest of the roadmap can compound through the same surface that delivered it.

That’s the bet. Build CodePilot to a real, gated, production-grade cockpit; then use it to build the other four. Each wing AdPilot ships through CodePilot is one less custom build. Each fix landed via CodePilot teaches the system what shipping inside this codebase looks like.

Who CodePilot is for, today and tomorrow.

Today, CodePilot is for one person: the PilotOS founder, doing dev work for Iron City Deals against the PilotOS repo itself. That’s the only customer. By design.

The expansion is built in. CodePilot was shipped on a 7-day cookie + page-gate auth pattern that scales to N operators trivially. Every PR it produces lands as a normal GitHub PR — no proprietary review surface, no lock-in, just code in a repo. The day a portfolio company hires a developer is the day that developer plugs in.

The audience expands as portfolio companies grow technical capacity. SMBs with one developer get a structured workflow they didn’t have time to build. Solo founders who code get a cockpit that knows their repo. Agencies running custom integrations get the same shell, scoped per client. None of these audiences need a separate product from PilotOS — they need the wing inside their existing cockpit to come online.

How a CodePilot run actually works.

CodePilot’s interface is the same Compass-aesthetic cockpit pattern as the rest of PilotOS — left rail, compose surface, run lifecycle, inspector. What’s different is what the operator types and what comes back.

1.Compose. Type a plain-English request: “Add a `last_seen` column to the customers table and ship it.” Click Send.

2.Resolve. The autonomous loop reads the request, picks a target file (heuristic + LLM resolver), checks repo state, drafts a bounded plan.

3.Approve. The cockpit shows the plan inline. You approve or push back. No code lands without your nod — the BLOCKED_OPERATOR state is real.

4.Run. The loop writes the change, runs validation (typecheck / lint / tests), commits to a branch named for the run.

5.Receipt. A real GitHub PR opens with a description that reads in plain English. Atlas attests the change. Compass logs the cost-of-work.

6.Review. You read the PR like any other PR — same diff view, same approve/merge buttons. The loop sits behind the same gate any human PR would.

Every step has a receipt. If a run fails halfway, the cockpit shows where and why — structured OUTCOME / PROOF / NEXT / STOP REASON / OWNER rows, not a stack trace dumped to console.

The five wings, in order.

Honest sequencing: when each wing ships, why CodePilot ships first.

Wing	Status	What it does
CodePilot	Live · 2026-05-04	Plain-English request → autonomous coding loop → real GitHub PR. The wing that builds the other four.
WebPilot	Next	Sites, landing pages, content updates, SEO, page-level analytics. First wing built through CodePilot.
AdPilot	Queued	Plan, launch, optimize paid ad campaigns across Google, Meta, Reddit. Compass already feeds it.
DocPilot	Queued	Workflow documents, runbooks, SOPs, contracts. Rennick drafts in your voice; Atlas remembers what worked.
AppPilot	Queued	Spec, build, ship apps end-to-end. The Lovable / v0 / Bolt category, with Atlas memory + Compass feedback compounding every release.

Sequencing isn’t arbitrary. CodePilot ships first because every wing after needs to be coded. WebPilot is next because sites are the cheapest demonstrable user-facing surface and the operator audience is broadest. AdPilot follows because Compass already detects ad anomalies — the wing turns those signals into action. DocPilot and AppPilot wait until at least one paying customer has shaped what they should look like.

What CodePilot shares with everything else.

CodePilot uses the same four foundations every other wing will:

Atlas for attestations — every PR carries a signed envelope of the work that produced it. The change isn’t real until Atlas says so.
Compass for cost-of-work — how many tokens, how many minutes, how many runs to land that PR. Surfaces in the same dashboard that surfaces ad spend or pipeline value.
Rennick for the conversation around the work — if a CRM customer needs to know about a change, Rennick drafts the message in your voice.
Nexus for execution — the run queue at /nexus in the cockpit shows CodePilot’s runs alongside any other Nexus runs (ad pauses, retention cohort exports, etc.). One queue.

Live receipts, today.

CodePilot is the only wing in production as of 2026-05-04. Receipts:

Operator surface: cockpit.pilotos.dev — auth-gated (cookie + API header), dark Compass aesthetic, operator-grade rail.
Mock surface: /codepilot-console — the same shell, fictional data, no auth. The investor-grade demo.
First customer: the founder, doing dev work for Iron City Deals against the PilotOS repo itself.
Engine: /api/command/self-build-loop, with bounded plan + LLM resolver + deterministic fallback.
Approve gate: nothing lands without operatorApprovalAcknowledged on the run.
State backend: ephemeral on Vercel today; Supabase migration is the next-up.
Documented audit: /proof includes the cockpit ship as memo #3 in the same-day three-memo arc.