How we built a desktop app in three days with AI agents

On Thursday Kadmo Desktop was a sentence; by Saturday night all thirteen stories were merged. What the agents did, what a person did, and the numbers.

Max SvistunovCTPO, Kadmo

Published 2 Nov 2026

Reading time 10 min

Two rising step curves on a dark ground, from Thursday noon to Monday noon, the lines added to main and the words the agents posted on the tickets, with the thirteen stories merged along the lines curve in two days, eighty-three thousand lines and forty-five thousand words by Saturday night, and the first lead on Monday at ten.

On this page 8 sections

In short

Thursday: one requirements document, written from the code of five repositories, every open question answered in one line.
Friday and Saturday: thirteen stories in four lanes, ten agents on one playbook, forty-six pull requests, all merged.
The numbers against published averages, with the caveats. Decisions, hardware and the demo stay a person’s job.

On Thursday morning Kadmo Desktop did not exist: no repository, no design, one sentence of direction. By Saturday night all thirteen of its stories were merged, with their tests. This is how it went, where a person was still needed, and how the numbers compare with what developers ship.

What we built

Kadmo Desktop is the Kadmo app and its agents on your own computer, in one app for macOS and Windows. At the first start it downloads the Kadmo VM, a small Linux machine of its own that carries the same images the cloud runs: the app, the database, the orchestration, and the agent image with Claude Code and Chrome. Nothing else is installed first. The first run names your account, recommends Claude Code on your own Claude plan, installs the default skill packs and starts one agent. No Kadmo account, no bill, no telemetry.

One rule sat behind every ticket: the desktop app builds no page of the app. It owns only what a browser cannot give: the system check, the download, the tray, Settings, Doctor, a newer build over the old one.

Thursday: a document, not a prototype

I wrote one sentence: Kadmo Desktop is the way to run the app and its agents locally, a local cell, with the cloud-only parts left out, built for an easy onboarding and a fast start.

A Claude Code session read the code of five repositories and wrote the requirements as an inventory: what exists, with the file that proves it; the options and the one to take; the first run as a sequence with a target time per step; the requirements, numbered; the risks; and a proposed epic with sizes and a dependency graph.

Then the questions, answered in one line each, in four rounds between Thursday evening and Friday morning: Electron, not a PWA. A Linux VM of its own, Lima on macOS and WSL2 on Windows. Claude Code on the owner’s plan, local models on demand. Chrome unmodified, the Kadmo extension from the store by policy. A dev build shared privately first.

This is the part I would not skip. The document is what every agent reads, and every ticket points at its sections by number. A ticket that says “see KDM-S1 and T-2” is a ticket an agent can plan from without asking.

Friday and Saturday: thirteen stories and a fleet

Friday at noon the repository existed; after lunch the thirteen stories were in Jira, filed from the document’s table: the problem as it stands in the code, the fix as a list, a definition of done a reviewer can check, and the two lines that matter most, Owns, the files this ticket alone edits, and Not in this ticket. Four lanes, so no two agents edit the same files on the same afternoon.

I imported the epic as a goal in Kadmo, and the agents pulled the tasks: ten agents, up to four stories in flight at once, every one on the same agentic playbook. A planning pass, read-only, that names the commits it read, lists the decisions it would take with their defaults and writes acceptance criteria. Build passes that open stacked pull requests and, when the session’s budget ends, write a handoff on the ticket: what is built, what remains, where to continue. A review pass that checks each line of the definition of done against the code, runs the gates and merges. A gate after each.

Thirteen stories in the order they merged, a row each, with the passes on the ticket, the words the agents wrote there, the lines added to main and the hours from filing to merged as bars — Every pass is a comment on the ticket: the plan, each build pass with its handoff, the review. Sixty-three of them hold 45,073 words, a median of six hundred per pass: what was read, what was decided, what remains, how to verify.

The tickets carry the whole story in the agents’ own words. The plans and handoffs add up to more words than a novella, and that is the point: the next session reads the ticket and goes on from the branch, and a reviewer reads it and knows what to check.

The lines added to main and the agents’ words on the tickets from Thursday noon to Sunday as two step curves, with the thirteen stories marked where they merged in two days, and the lines curve orange while the VM story needed six decisions — Thursday noon to Sunday, Berlin time: in teal the lines added to main, from git; in violet the words the agents posted on the tickets. Teal dots are the thirteen stories where they merged, all within two days. The orange part is the VM story waiting for six decisions.

One ticket overnight: the first run’s plan late on Friday, six build passes through the night, the end-to-end suite and the merge of seven pull requests on Saturday morning — The first run, DK-6: seven passes by one agent through the night, then the review pass. Each pass ends with a handoff on the ticket.

The first run is the best example. One agent took it late on Friday and worked through the night in seven passes, one stacked pull request each, a handoff after each. Its end-to-end suite found a bug in the sign-in step and fixed it on the branch. By the time I woke up, the review pass had merged the stack of seven.

The first run’s agent step in the Kadmo app: Start your first agent, the agent’s name prefilled, the roles PM, SE and QA, the workspace, and the two buttons Start at least one agent and Later — Step four of the first run, as the agent captured it in its own test run that night.

Saturday was the desktop app’s own day: the Kadmo VM with its image build and two drivers, the first start’s screens, the shell with its menus and tray, Settings, Doctor and logs, local models on demand, and care: a newer build with the data kept, back up and restore, Bring a project. The last story merged before ten in the evening.

The Create Agent wizard on This computer: three agents named, the build sheet with Claude Code on the subscription, no machine cost, and a warning that three agents at four gigabytes each is more memory than this computer has — This computer in the Create Agent wizard: no cloud, no command to copy, and an honest word about memory.

Where a person was still needed

The agents halted four times, and each time the halt was right.

Decisions. The VM story stopped on Friday evening with the verdict BLOCKED and six decisions for me, each with a recommended default. I answered on Saturday in one comment of ninety-three words, and the story merged within the hour. A halted gate costs minutes; a guessed decision costs a rework.
Hardware. The agent image has to boot to Online on amd64 and on Apple Silicon. The agents run as hosted agents on Linux VMs with no Docker and no arm64 host, so the agent pushed its pull requests and said BLOCKED instead of pretending. The proof moved to a session on my PC.
My own mistake. The fourteen design boards never reached the remote. Every planning pass noticed, said so, and built from the ticket’s words, with copy and measures kept in one file for a board pass later.
Merging. One agent noted that the repository’s rules say never to merge and that its job’s policy says to merge, chose the job, and wrote both down on the ticket. That is the note I want to find there.

The numbers

The three days in numbers: thirteen stories, forty-six pull requests, eighty-three thousand lines, forty-five thousand words on the tickets, seven hundred tests, thirty-four hours; and three dot plots against a developer without AI tools, a developer with AI tools and Claude Code’s creator: pull requests merged in two working days, lines added in two working days, lines per pull request — The three days in numbers, and the agents against published averages. Developers: Jellyfish and OpenAI’s weekly averages across more than five hundred companies, scaled to two working days. Claude Code’s creator: Boris Cherny’s thirty days of December, scaled to two days. Kadmo: git and Jira, ten agents, Friday afternoon to Saturday night. Log scales.

For comparison: Jellyfish and OpenAI measured, across more than five hundred companies, 1.36 pull requests per engineer and week without AI tools and 2.90 at full adoption, with 75 and 88 lines added per pull request. Anthropic reports 67 percent more merged pull requests per engineer and day after Claude Code. Boris Cherny, who created Claude Code, landed 259 pull requests and 40,000 lines in thirty days, every line by Claude Code. LinearB’s elite tier merges more than two pull requests per developer and week, each under a hundred lines.

In two days one Kadmo agent merged 4.6 pull requests and 8,300 lines: four times the developer with AI tools on pull requests and eighty times on lines; a quarter of Claude Code’s creator on pull requests and three times on lines. The fleet of ten merged forty-six and 83,000, and wrote 45,000 words on the tickets while doing it.

Three caveats. The lines include tests, documentation and a scaffold, and a new repository grows faster than an old one. Our pull requests are twenty times the size of a developer’s, which is a risk; the review pass and the test suites are the answer we have. And throughput is not quality: the drill on four clean machines is the measure that counts.

What we would do again

Write the document before the first ticket, from the code, with every requirement numbered. Tickets point at numbers, not at opinions.
Give every ticket its Owns line and a lane. Parallel agents fail on shared files, not on hard problems.
Let a gate say BLOCKED. The agents that stopped for a decision or a machine were the cheapest ones that day.
Expect handoffs. A session ends, the ticket keeps the state, the next session continues on the branch. One story ran seven passes overnight that way.
Keep the boards on the remote. The one thing the agents could not read was the one thing I had not pushed.

What is next

Sunday is the second epic: the build lane and the private link for the dev build, then the drill on four clean machines, timed from the first start to the first agent Online.

If your team has a product that should run on a laptop, or a backlog that would take a quarter, this is what AI coding agents on an agentic playbook do on your own codebase.

What would your backlog look like on Monday if you filed it on Friday at lunch?

Sources

https://jellyfish.co/blog/jellyfish-openai-team-up-to-measure-impact-of-ai-coding-tools/
https://jellyfish.co/blog/ai-assisted-pull-requests-are-18-larger/
https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
https://news.ycombinator.com/item?id=46407967
https://linearb.io/library/engineering-benchmarks-and-research
https://docs.rancherdesktop.io/references/architecture/
https://lima-vm.io/docs/config/vmtype/
https://code.claude.com/docs/en/legal-and-compliance