The Data
Between February 21 and June 7, 2026, across 107 days, I created 17 new repositories on GitHub: 14 substantial projects plus 3 single-commit utilities. 1,221 commits in total (1,185 under my own name), 953 of them (78%) carrying a Co-Authored-By line for Claude. Roughly 157,000 lines of source code (excluding generated code and vendored code), across seven languages: Rust, Swift, Zig, Dart, Kotlin, TypeScript, Python. 78 of those 107 days had commits, and on 50 of them I was pushing two or more repositories at once, six in a single day at the peak.
The biggest of them, the meow family (Rust core + iOS + Android, 92,000 lines together), went from a blank slate to usable on all three platforms in three and a half months, and still accounts for only a bit more than half of the output over the same period. Going by my past decade and a half of maintaining open source projects on the side, this is a multi-year amount of work.
Three Sources of Speed
Language Is No Barrier
My main languages over the past decade-plus were C, Scala and Kotlin. This year's 17 repositories span 7 languages, and I had never written production code in Zig, Dart or Swift before.
The extreme case is gterm: it needed a fork of ghostty plus a new passthru backend inside its Zig termio layer (iOS does not allow fork/exec of a local shell, so the terminal has to be driven by an SSH stream). That means understanding the IO architecture of a 300,000-line Zig project and then making invasive changes to it, in a language I had never written before.
Agents did not shorten "how long it takes to learn a language". They made the question itself stop mattering: the human bottleneck moves from "can I write it" to "can I read and review it", and reading is an order of magnitude easier than writing. Judging whether the memory ownership in a piece of Zig code is correct does not require being able to write Zig syntax from memory.
Months to Days
gterm went from its first commit to an installable TestFlight build in 5 active days (May 29 to June 5, 64 commits), and along the way it got:
- a passthru termio backend for ghostty (Zig, invasive upstream changes)
- libghostty cross-compiled into an iOS XCFramework
- swift-nio-ssh integration: password and public key auth, PTY, window size sync
- a custom on-screen keyboard (esc/ctrl/alt/arrow keys, sticky modifiers)
- Keychain storage, TOFU host keys, Ed25519/ECDSA key import
- a fastlane + TestFlight release pipeline
A project of this shape, a GPU-rendered terminal plus an SSH stack plus iOS app work, was the kind of side project you measured in quarters back before agents. Every one of those items on its own used to start with a few days of reading documentation.
Parallel by Default
On 50 of the 78 active days I had two or more repositories moving at once, peaking at 6 in a day. Take the week starting May 29: gterm went from forking ghostty and starting the project to an installable TestFlight build across 64 commits, subtitle_anywhere took 54 in a concentrated refactor, and trans_proxy, two stock dashboards, meow-rs, meow-ios and runse-mac each moved forward. 9 repositories, 174 commits, 8 days.
There is a limit to how much code a person can write at once, but most of the code was not written by a person anyway. Long agent tasks (porting a module, a bulk refactor, fixing an entire test suite) run from tens of minutes to hours, and during that stretch the human is idle. Switch to another project, hand out a task or review a result, and that is where the parallelism comes from.
A Fragmented-Time Workflow
These numbers say the workflow changed: each human intervention is 10–30 minutes of "review and redirect", and no longer needs several continuous hours of "writing". A whole free afternoon is not enough to write a TCP stack, but 15 minutes is enough to read a diff, run the tests, and point at the next step.
From Notes to Plans
This workflow starts the moment the idea shows up. My old habit was to drop ideas into Notion: one sentence, a few keywords, to be expanded when I had time. The result was that most ideas died in the list. "When I have time" means a whole free afternoon, and a whole free afternoon never gets down to the idea sitting in 20th place.
Now when an idea shows up (on the commute, over lunch, after running into a related project), I open the Claude app, start a new project, dictate the idea, and have it produce a plan document on the spot: goals and non-goals, technology choices, milestone breakdown, what the first verifiable minimal version looks like. This step happens on the phone and costs the same few minutes that writing a note used to, but the artifact goes from "a one-line reminder" to "a spec you can start building from".
Then after work or on a weekend, sitting down at the computer no longer means starting a project from zero. Open the existing plan document, let the agent work from it, watch the diffs go by, correct course at the important points. The 7K PLAN.md in the gterm repository came from exactly this: it existed before any code, and 5 active days later the app was installable from TestFlight.
The difference between the two ways of recording is obvious: a sentence in a note has to be expanded by a future version of me, while a plan document does the expanding while the idea is still warm, leaving nothing but a wait for a free slice of time.
Four Prerequisites
A few engineering prerequisites make this pattern work:
Keep project state in the file system, not in your head. Every project maintains a CLAUDE.md (build commands, architecture skeleton, extension points) and a PLAN.md or roadmap (current state, next step). What kills fragmented time is the cost of restoring context. If sitting down means spending ten minutes remembering where you left off, fragmented time is unusable. Documents let both the human and the agent cold start. I went into how to write them in the post on the mihomo-rust port.
Verification infrastructure before features. CI and tests are the only reliable signal for the quality of agent output. Fragmented time is not enough to hand-verify 1,200 commits line by line, but it is enough to glance at whether CI is red or green and to spot-check which edge cases the tests cover. meow-rs got its 619 test functions and 5 CI pipelines built up front, precisely so that "78% of commits done in collaboration with an agent" would not run out of control.
Hand out tasks at the granularity of a verifiable goal. "Implement the VLESS protocol" is a failing prompt. "Implement the VLESS handshake and pass the 12 test cases listed in the spec" works. Too coarse, and the cost of the agent going off the rails is paid out of your fragmented time; too fine, and the human becomes the bottleneck.
Cost. The entire cash outlay for this process: a model subscription (Claude Max, $100–200 a month), an Apple developer account ($99 a year), a few domains and one VPS. Spread across 17 repositories, the marginal cost per project is close to zero.
All Software Free?
The price of tool software rests on implementation cost and scarcity. When an engineer with the ability to review code can reproduce a tool using fragmented time and a subscription of one or two hundred dollars a month, pricing power for pure implementation software keeps leaking away.
A good share of this year's projects map directly onto software I used to pay for, or considered paying for:
| What I wrote | The commercial category it replaces | Typical price |
|---|---|---|
| gterm | subscription iOS SSH terminals | $5–10/month |
| the meow family | paid proxy clients (Surge $49.99, Shadowrocket $2.99, etc.) | $3–50 |
| runse / runse-mac | paid text polishing and AI writing tools | $5–20/month |
| subtitle_anywhere | metered transcription and subtitle services | ~$10 per hour of audio |
| trans_proxy, sshttp, macmtr | assorted network utilities | $5–30 |
So why open source them instead of shipping at $2.99? Because charging has fixed costs: store review, support, refunds, tax compliance. Those costs do not fall as the price falls, and in the low price band they eat the entire margin. And when the development cost is just fragmented time plus a model subscription you were paying for anyway, software goes back from being a product to being a byproduct. For a byproduct, the returns from open sourcing (issue reports, PRs, reputation) are the better deal.
The Long Tail
Replacing paid software is only the surface. The more substantial change is the projects that would never get a commercial version. taiwan-strait-monitor (open source intelligence aggregation), fof-quant (fund-of-funds analysis), bangumi-downloader (anime torrent aggregation): needs like these might have a few hundred users worldwide, and in the past they would not have been built at all, because the development cost far exceeded any plausible return. Now "worth it just for myself" clears the bar, and open sourcing is incidental. The coverage density of the software long tail should rise noticeably, and the long tail was never within range of commercial software to begin with.
What Stays Paid
This line of reasoning has limits.
Running costs do not disappear. runse is free, but the LLM API it calls bills per token; subtitle_anywhere is free, but it needs an Apple Silicon machine to run MLX Whisper. The marginal cost of implementing software going to zero does not mean the marginal cost of compute and data sources goes to zero. Products that depend on an ongoing service can still charge, they just charge a service fee rather than a software fee.
Distribution and trust are still scarce. The star counts on these projects make the point: of 17 repositories, only meow-rs (262) and meow-ios (102) are above a hundred. Once code stops being scarce, what is scarce is getting a stranger to trust it: signing and notarization, store channels, a reputation for continued maintenance. Apple's $99 a year buys the right to distribute, not the toolchain.
Maintenance commitments were not automated. Most of my 17 repositories promise no maintenance. Within what commercial software sells, the SLA share will keep growing and the code share will keep shrinking. That pulls software pricing back toward its real cost structure.
"Free" transfers the cost, it does not remove it. Users get gterm for free, but I paid the model subscription. Pull the view back: the money funding this round of free tool software is the subscription revenue of the model vendors. Software fees concentrating into model fees is the same structural shift as desktop software fees concentrating into cloud service fees years ago.
Auditing: Open Source Required
There is a question people usually raise from the opposite direction: nearly 160,000 lines of code, 78% of commits done in collaboration with an agent, who guarantees the quality?
That question points at why open source is actually necessary. With closed source software that AI was deeply involved in, the author may not have read every line either, and outsiders have no way to audit it at all. Open source lets auditing happen, and auditing itself gets stronger with agents: having an agent with a clean context do an adversarial review costs about as little as writing the code. That goes double for networking and security tools. Weaknesses in a protocol implementation only get found and fixed on an ongoing basis when anyone can inspect the code. Now that AI has lowered the bar for writing code, the value of that public inspection goes up rather than down.
A Checklist
Compressing the practice into a few actionable points:
- Choose projects on personal need rather than market size. Once the marginal cost is near zero, writing it for yourself is reason enough
- Spend the first active day on verification infrastructure: CI, a test skeleton, CLAUDE.md. This determines how usable all the later fragmented time is
- Put project state in the file system so that every 15-minute slice can cold start
- Run several projects in parallel, using the time an agent spends on a long task to switch over and review another project. Serial development wastes exactly that time
- An unfamiliar language or domain is no longer a reason to give up, as long as you can review the output: read the diff, read the tests
- Open source by default. A byproduct cannot recover the fixed costs of charging, but it can recover reputation and collaboration
Once implementation ability stops being scarce, an indie developer's output ceiling depends only on review ability and fragmented time. Software is going back to the shape it had before commercialization: write it, put it out there, and the people who need it will come find it.
