Zero to One with Claude: How I Shipped a Product 0→1 with an AI Team in 2 Weeks

Two weeks ago, the repository was empty. Today it is a shipping product: a custom Raspberry Pi device that captures Wi-Fi handshakes for authorized security testing, learns a smarter scan policy on-device with reinforcement learning, and shows it all on a tiny animated e-ink face. I call it Kestrel. I built it with Claude — and by “with,” I mean Claude wrote most of the code while I did something closer to running a small engineering team than typing.

That distinction is the entire point of this post.

The usual pitch is that AI makes engineers faster. True, but it undersells what is happening. The real shift is that AI changes the unit of what one person can own. One person can now hold the whole thing at once — architecture, implementation, tests, releases, field debugging — at a pace that used to need a team and a quarter. But velocity alone does not ship a product. The system I built around the AI is what turned raw speed into something real, versioned, and running on hardware in my hand.

Here is what two weeks looked like.

None of that happened because the model is magic. It happened because of a handful of deliberate rules about how to work with it. Here they are.

One human, one coordinator, a swarm of threads

I did not sit in a single endless chat with an AI. That approach falls apart fast: context bloats, the model loses track of decisions it made an hour ago, and you spend your time re-explaining instead of building.

Instead, the work was shaped like an org chart. A coordinator held the big picture and talked to me. Every actual piece of work — a feature phase, a new plugin, a nasty bug, a release — got its own focused thread that owned exactly one job. Each thread started with tight, relevant context, did its work, pushed a branch, and handed back a result I could skim in a minute.

The payoff is the same reason human teams are structured this way. Context stays small and on-topic, so the AI makes fewer careless mistakes. Threads run in parallel, so progress is not bottlenecked on me reading one giant transcript. And when something goes sideways, the blast radius is one workstream, not the whole project.

My opinion, stated plainly: if you are still doing 0→1 work in one infinite chat window, you are leaving most of the leverage on the table. Treat the AI like a team you manage, not a genie you petition.

Rule #1: Design before code

Before any phase got written, the thread that owned it wrote a design note — and I read it before a single line of code existed.

This sounds like bureaucracy. It is the opposite. A design note is the cheapest possible place to catch an expensive mistake. Reading a page of prose and saying “no — the learning agent should pick the scan posture at launch time, not try to steer a capture that is already running” costs me five minutes. Catching that same decision after it is wired through the code costs a day.

Forcing the AI to think on paper first does three things. It turns a vague ask (“add a learning agent”) into a real spec with a defined interface and a versioned contract. It surfaces the assumptions the model would otherwise quietly bake into code. And it puts my judgment where it is worth the most — at the fork in the road, not after we have already driven a mile down one branch.

My opinion: the single highest-leverage habit in AI-assisted development is making the AI design before it builds. Speed without it is just a faster way to generate the wrong thing with great confidence.

The prompt that did it: “Before you write any code, write a design note for the learning agent — the observation and action contract, how it controls capture at launch time, and the failure modes. I’ll review it before we build anything.”

Rule #2: The human still clicks merge

The AI could do almost everything: design, write code, push branches, open pull requests, even watch its own CI and push a fix when a check went red. Exactly one thing it could not do was merge. A human — me — clicking the merge button stayed the single, non-negotiable gate.

The trick is to make that gate cheap instead of a bottleneck. If my review meant hand-reading every diff for typos and style, I would be the slow part of my own team. So the boring checks got automated: a pull-request template, a linter, and a test suite of nearly 700 cases that runs on every push and every pull request. By the time a change reached me, the machine had already proven it was internally consistent and nothing was obviously broken. My attention went to the part only a human can do — is this the right thing to build, and does it fit the product?

This is the balance I would hand anyone adopting AI on a real team: automate the checks, never the judgment. Let the AI drive right up to the edge of the irreversible step, and keep the irreversible step — merging, deploying, anything you cannot take back — in human hands. You get almost all of the speed and almost none of the terror.

The prompt that did it: “Set up a PR template and CI that runs the linter and the full test suite on every push and every pull request, so my review is about whether this is the right change — not whether it compiles.”

What one phase actually looked like

Abstract rules are easy to nod along to, so here is one phase in the concrete: the learning agent.

It began, like everything, with a design note. Before any code, we pinned down the hard part — the contract between the agent and the device. What does it observe about its surroundings? What is the exact, closed set of actions it can take (which scan posture, for how long, whether to transmit)? And, most important, where is it allowed to act? We decided it would set the scan posture at launch time rather than try to re-steer a capture already in flight, because the second option was a nest of race conditions. That call took one paragraph to make and saved days of rework.

Then the build: the policy, the training loop, and the on-device inference, each with tests. The suite stubs out the heavy machine-learning libraries so it runs in seconds, not minutes — which is exactly what lets it gate every single push. Training happens offline; the device just runs the resulting policy, behind a gate that ships off by default. Design note to shipped, opt-in feature in a couple of days — and I reviewed exactly one thing that truly mattered, the contract, at the moment it was cheapest to change.

Guardrails are the accelerator, not the brake

Here is the counterintuitive part. The constraints I put on the system did not slow it down. They are the reason I could delegate so much, so fast.

Kestrel runs plugins, and that is a security minefield — plugin code running on a device built to capture wireless traffic. So the architecture has a hard boundary. Plugins run as an unprivileged user. Anything privileged goes through one small, audited helper that runs as root, never imports plugin code, and validates every request before doing the dangerous work itself. Above that sits a versioned hook API, so a plugin built against one version fails loudly instead of misbehaving silently against another — plus one blunt contract rule, “never block in the web request handler,” that stops a single slow plugin from freezing the whole dashboard.

None of that is glamorous. All of it is what let me say “yes, build the plugin system” without lying awake about it. Good fences are what make it safe to hand over more. The phased build worked the same way: every phase shipped something real and testable before the next began, so scope creep had nowhere to hide and I could have stopped at almost any release with a working device in hand.

The lesson for anyone leading this: the teams that move fastest with AI are not the ones with the fewest guardrails. They are the ones whose guardrails are good enough that saying “go” stops being a gamble.

The real world doesn’t read your code

Everything above is about moving fast on a screen. But Kestrel is hardware, and hardware is where confident code goes to die.

Plenty of changes looked flawless in review and then broke on the actual device. Bluetooth tethering to a phone silently lost its DNS until we added a fallback. The web dashboard could hang under real-world timing that no unit test had imagined. And the e-ink screen — the whole point of the product’s charm — shipped completely blank. The only way through was the loop: flash the image, run it on real hardware (a Raspberry Pi 5, an e-ink HAT, a GPS dongle, a battery HAT), pull diagnostics off the device, feed them back, fix, repeat.

The blank e-ink screen is my favorite failure, because it is so humbling. Everything pointed at hardware — the wiring, the SPI bus, the panel itself. Instead of guessing, we pulled diagnostics directly off the running device, and the real cause turned out to be gloriously mundane: the background service was running in a directory it was not allowed to write to, so the library that drives the screen’s pins silently failed to create a small file it needed at startup. Not the wiring. Not the panel. A working directory. No amount of re-reading the code would have found that — only running it on the real thing did.

One move in particular earned its keep. At one point I told the AI to stop building and instead attack its own work — to scan the web UI adversarially for every way it could possibly hang. It came back with a list of distinct failure scenarios I had not thought of, and we fixed them. That is a different and badly underused mode: “find everything wrong with this” is not the same prompt as “build this,” and the AI is startlingly effective as its own red team when you point it that way.

The prompt that did it: “Stop adding features. Attack the web UI instead — list every way it could hang, deadlock, or wedge under real-world timing, ranked by likelihood. Then we’ll fix them one by one.”

The honest caveat: AI compresses the write-and-reason half of the work enormously. It does not close the loop against physical reality for you. Someone still has to flash the card and watch the thing boot.

Shipping 0→1 means shipping updates, too

Something people forget about 0→1: the product is not the artifact you build once. It is that artifact plus everything that keeps it alive in the field. Over two weeks I cut 46 public releases. That number is only survivable if releasing itself is engineered.

So the AI built the release machinery as a first-class feature. Every release is classified as either a quick in-place update or a full re-flash, and devices already in the field update themselves in place when it is safe to do so. The on-device package auto-publishes. Release notes generate themselves from the commit history. Each release carries a manifest that states exactly how it should be applied. This is the unglamorous plumbing that humans skip under deadline pressure and regret six months later — and it is exactly the kind of thorough, patient work an AI does without complaint.

The same confidence showed up in the genuinely scary changes. Midway through, the entire project got renamed — 163 files touched on a single branch. That is the sort of change a solo builder usually dreads and defers forever. Here it was scoped, done on a branch, gated by the same lint and tests as everything else, and signed off with one human review. Large, mechanical, and reversible-until-merged is the exact shape of change AI is best at — worth leaning into rather than avoiding.

The economics just moved

Let me put a number on it, since that is the question underneath all of this. A product like Kestrel — a custom Linux image, an on-device service, a web dashboard, a plugin system, a reinforcement-learning agent, and the release machinery to keep it all updated — is normally a small team for a few months. Not because any single piece is exotic, but because there is so much of it, spanning firmware, backend, frontend, ML, and ops. That breadth is exactly what used to force you to hire.

Here it was one person and about two weeks, because the AI collapsed the breadth. I did not need to be equally fluent in e-ink drivers and RL training loops and systemd units. I needed to make good decisions about each, and let the AI carry the fluency. That is the shift worth underlining for anyone allocating capital or headcount: the binding constraint on 0→1 is sliding away from how many skilled hands you can hire, toward how well one person can direct them. The building was never the hard part. The judgment was.

What sped things up, and what still needed a human

If you want the compressed version of two weeks, it is a short ledger. The left column is where the AI gave me leverage. The right column is where a human was still the point of the exercise — and always will be.

Notice the split. The AI took over the work that is large, mechanical, or tireless. The human kept the work that is about judgment, taste, and consequences. That division did not happen by accident — it is the whole design.

The prompts that did the heavy lifting

If you take nothing else from this, take these. Five instructions — lightly paraphrased from the real ones — carried most of the weight:

1. Design first: “Before any code, write a design note for X — interface, data contract, failure modes. I’ll review before we build.”
2. Red-team on command: “Don’t add features. Attack this. List every way it can fail under real conditions, ranked by likelihood.”
3. Automate the checks: “Add a PR template and CI that runs lint and the full test suite on every push, so I review intent, not correctness.”
4. Fence the danger: “Design this so untrusted code runs unprivileged, and every privileged action goes through one audited helper that never imports it.”
5. Big moves, safely: “Do this rename across the whole repo on a branch. Keep lint and tests green. Change nothing else.”

Notice that none of these is “write my app.” They are instructions about how to work — and that is where the leverage actually lives.

If you want to try this on Monday

Concrete, for the engineers in the room — five moves you can start with no new tooling:

1. Split the work. Give each workstream its own thread or session with tight, relevant context. Stop pushing everything through one endless chat.
2. Demand a design note. Make the AI write the plan before the code, and review the plan, not just the diff.
3. Make CI the gate. Wire lint and a real test suite to run on every push, so your review is about intent rather than correctness.
4. Keep merge human. Let the AI do everything up to the irreversible step — and own that step yourself.
5. Schedule an attack. Once a week, tell the AI to stop building and try to break its own work, then fix what it finds.

None of it needs a platform or a budget. It needs you to treat the AI like a team you manage.

The takeaway

Two weeks, one person, a working hardware product with a learning agent and a face. The temptation is to read that as a story about how powerful the model is. It is not. It is a story about a system.

AI collapsed the distance between an idea and a working, shippable version of it. That is real, and it is enormous. But the model did not supply the engineering judgment — the design-first discipline, the phased delivery, the merge gate, the test suite, the hours spent watching a device boot. Those are what turned raw speed into a product instead of a pile of impressive-looking code. The leverage is real; the system is what makes it safe to use.

Two audiences have been reading over my shoulder this whole time. To the engineers: the question is not whether your team should use AI, but whether you have built the system — the guardrails, the gates, the automated checks — that lets them say “go” without it being a gamble. To the investors: the moat is quietly shifting from “can you build it” toward “what system do you build it inside of.” Same lesson, said twice.

Kestrel is open source — browse the code and the 46 releases here. I write about building things like this; follow along and connect with me on LinkedIn.

And the question I will leave you with, because I genuinely want the answer: if one person can now own a product end to end, what is the right size for a team?