The full primer, with working skills you can copy, is on GitHub: github.com\/shiranjit\/agentic-primer<\/a>. This is the short version of that story.<\/em><\/p>\n\n\n\n Before any of this, I was a skeptic with receipts.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n 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 \u2014 the same one I had been working with Copilot \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The project found me. Picking up my car from the garage \u2014 the same shop I have been going to for twenty years \u2014 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.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n The answer to the first two questions: yes, and roughly 65 hours over a week and a half. The app is called Curoo \u2014 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.<\/p>\n\n\n\n The answer to the third question is the interesting part, and it is what the rest of this post is about.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n I started as a tool user \u2014 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 \u2014 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.<\/p>\n\n\n\n Then the ceremony fell away \u2014 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 \u2014 on my actual phone.<\/p>\n\n\n\n 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 \u2014 with scoped, least-privilege tokens from a password manager, and with me remaining the human approval at every gate.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n About a week in, I showed the app to my mechanic. He got excited \u2014 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 \u2014 server, database, login, security.<\/p>\n\n\n\n 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 \u2014 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 \u2014 ios_car_agent on the Mac, ubuntu_car_agent on my Ubuntu box \u2014 each with its own machine, repo, and jurisdiction.<\/p>\n\n\n\n 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 \u2014 what it needs from the backend \u2014 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 \u2014 I sequence and gate.<\/p>\n\n\n\n Later I got them talking directly: a Slack channel called #all_agents, a simple message convention (From: ios_car_agent, To: ubuntu_car_agent \u2014 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 \u2014 that is the whole multi-agent infrastructure.<\/p>\n\n\n\n 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 \u2014 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.<\/p>\n\n\n\n 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” \u2014 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 \u2014 supervision that does not need me in the room.<\/p>\n\n\n\n There were also moments that floored me. The agents built an ephemeral test-database harness \u2014 create a fresh database per test run, load a maintained golden dataset, run everything, scrub \u2014 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.<\/p>\n\n\n\n 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 \u2014 the typing, the building, the test-writing \u2014 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.<\/p>\n\n\n\n I have been practicing what the industry now calls the Product\u2013Platform\u2013Service 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 \u2014 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.<\/p>\n\n\n\n The full story \u2014 the agent setup, the handoff protocol, the deployment gates, the enterprise guardrails checklist, and the working skills you can drop into your own project \u2014 is in the primer: github.com\/shiranjit\/agentic-primer<\/a><\/strong>. Take it, adapt it, and build your own.<\/p>\nYou grow into agentic development \u2014 you do not start there<\/h2>\n\n\n\n
Two agents, one product, and a handoff through git<\/h2>\n\n\n\n
The honest parts<\/h2>\n\n\n\n
What actually changed<\/h2>\n\n\n\n