I Built a Commercial App in 65 Hours Without Writing a Line of Code

The full primer, with working skills you can copy, is on GitHub: github.com/shiranjit/agentic-primer. This is the short version of that story.

Before any of this, I was a skeptic with receipts.

I had been using GitHub Copilot for about six months. Everyone kept saying AI can code now, and I kept not seeing it. A colleague at work showed me a small app he built with it — working, real. I tried and tried and could not reproduce whatever he had unlocked. What I did not know at the time: behind the Copilot interface, he had selected Claude as the model doing the work. Same facade, different engine. I was concluding “AI can’t build apps” from an experiment where I did not know which AI I was testing.

The correction came over a beer. A college buddy was raving about Claude writing whole features for him. I told him, now I must try it. I went home, bought a subscription, and set up the fairest test I could think of: my own existing codebase — the same one I had been working with Copilot — as the baseline. I spent that entire Saturday validating his claim. It held. Claude Code did, on my own code, what six months of Copilot had not done for me.

Once it held, my natural question was: what is the art of the possible? I did not want to keep testing on code that already existed. I wanted to know what an agent could do from zero, hands-free, on a clock.

The project found me. Picking up my car from the garage — the same shop I have been going to for twenty years — my mechanic was complaining about writing invoices. How long it took, how it ate his day. I said, let me see what I can do. It was an honest offer: I have hung around that shop enough to know the workflow at the counter, and I helped with their website, so I knew how the money and paperwork moved. Two decades of that adds up to something no market research buys.

So the experiment had three questions. Can an agent build a complete commercial application with me writing zero code? How fast, honestly counted? And what is agent-based coding really like day to day — because part of my professional role is designing engineering guardrails for a large enterprise, and you cannot design honest guardrails for agentic development from conference talks.

The answer to the first two questions: yes, and roughly 65 hours over a week and a half. The app is called Curoo — an iPhone-first shop management app, SwiftUI front end, Python and Postgres backend. It is live today, in beta, running in a real garage. The first customer is the shop it was built for. I never wrote a line of code by hand.

The answer to the third question is the interesting part, and it is what the rest of this post is about.

You grow into agentic development — you do not start there

I did not arrive at a fully agentic workflow. I grew into one, mostly by accident, and every bit of autonomy the agent got was earned by the step before it going well. Looking back, there were five distinct rungs.

I started as a tool user — small asks in the Xcode plugin, reviewing everything. Then a supervised planner: Claude Code in the terminal, formal plan mode, me approving every plan and then every single command. Slow to the point of tedium, and the most important stretch of the whole project — because that is where the alignment happened. Every plan I corrected taught the agent my conventions, and the corrections accreted into its standing memory. Watching every command taught me its habits and failure patterns. We were onboarding each other.

Then the ceremony fell away — I could just say “go plan this and come back to me” in conversation. Then, about a week in, I discovered auto mode, and it changed my life for that stretch: I would approve the plan and walk away. Claude wrote the code, built it, tested it, fixed its own compile errors, driving Xcode from the command line. I would come back and judge the feature the only way that matters — on my actual phone.

And finally, the agent took over the process itself: creating branches, opening pull requests, promoting code through a full Gitflow pipeline via the GitHub and Bitbucket APIs — with scoped, least-privilege tokens from a password manager, and with me remaining the human approval at every gate.

Here is the thing: auto mode on day one would have produced confident garbage. It worked in week two because a week of supervised plans had aligned us. The feature did not make the workflow trustworthy. The history did.

One more honest note about how this felt. Most of those rungs were climbed in ten- and fifteen-minute fragments, squeezed between the rest of my life. That is the real promise of this way of working — not that it turns you into a machine for 65 straight hours, but that it makes small fragments of attention count, because the agent holds the state between your visits.

Two agents, one product, and a handoff through git

About a week in, I showed the app to my mechanic. He got excited — not polite-excited, “I want this now” excited. Which meant the honest conversation: everything he saw lived on one phone. Before he could run his shop on it, I needed a real backend — server, database, login, security.

So I asked the agent that had built the iOS app to design and write the backend, in a separate repo, with explicit architecture and style parameters. In under an hour it implemented the full thing — Python services, Postgres schema, well documented. Then it tried to install Postgres on my Mac, which is not where the backend would ever live. That was my cue to make the topology explicit. I named the agents — ios_car_agent on the Mac, ubuntu_car_agent on my Ubuntu box — each with its own machine, repo, and jurisdiction.

How do two agents on two machines build one product? Not with an orchestration framework. With a discipline we came to call the handoff. The iOS agent builds a feature fully on the phone side, then writes a request document — what it needs from the backend — directly into the backend repo. The Ubuntu agent reviews that handoff, and here is what surprised me: it does not just take the order. It enhances the plan with the server-side realities the frontend could not know. It implements with TDD, deploys to local dev, and writes a handoff back describing what now exists. The iOS agent consumes it, wires the API calls, tests end to end, and ships. The requirements travel through git, not through my memory. I never translate between the agents — I sequence and gate.

Later I got them talking directly: a Slack channel called #all_agents, a simple message convention (From: ios_car_agent, To: ubuntu_car_agent — and To: Leader when they need my approval). Detailed handoffs still live in the repos; Slack carries the coordination. Two terminals, git, and a chat channel — that is the whole multi-agent infrastructure.

The honest parts

The agents periodically introduced bugs. Sometimes they broke the app outright. Sometimes the fix took one prompt; sometimes several rounds. This is a collaboration between a human and an AI agent, not a vending machine — the agent writes essentially all the code, and the human supplies the judgment: noticing what broke, holding the quality bar, testing on the real device. TDD with full coverage and hard Gitflow gates are what made the slips affordable. The 65 hours include every round of “you broke it, fix it.” That is not overhead on the method. That is the method.

And one warning from scar tissue: AI agents like to clean everything and start over, and they are very good at it. I once watched an agent decide to wipe and recreate a database, and I could not stop it in time. When my agents later touched a shared production Kubernetes cluster, they started back at “write out every command and wait for approval” — with a hard rule: no deletes, no removes. Autonomy is earned per-domain, never granted for life. Eventually that gate became a skill of its own, enforced by an advisor agent with go/no-go authority — supervision that does not need me in the room.

There were also moments that floored me. The agents built an ephemeral test-database harness — create a fresh database per test run, load a maintained golden dataset, run everything, scrub — a discipline I learned at MIT Lincoln Laboratory, reached for unprompted. And when my colleague pushed a known-good deployment config to a branch, the Ubuntu agent pulled it, recognized what it was, diffed it against its own YAML, and reported that its own file was incomplete. Nobody asked it to audit itself. I took a picture of the terminal and texted it to him. Trust is not built by flawlessness. It is built by honest diffs.

What actually changed

My hours now concentrate at the two ends: product definition before the agents move, and QA with the app in my hand after they finish. The middle — the typing, the building, the test-writing — is where I now spend the least. Twenty-five years in, I have come to believe those two ends were always the parts that mattered most.

I have been practicing what the industry now calls the Product–Platform–Service model for twenty years: build the framework once, harden it, then build features fast on top. The agent version is the same idea one level up. The skills carry the methodology, the memory carries the conventions, the harness carries the quality floor, the gates carry the release path — and my prompts only have to carry intent. Two or three lines per feature. The brevity is not laziness; it is the methodology paying out.

The full story — the agent setup, the handoff protocol, the deployment gates, the enterprise guardrails checklist, and the working skills you can drop into your own project — is in the primer: github.com/shiranjit/agentic-primer. Take it, adapt it, and build your own.