Tell someone you built a Mac menu bar app in a day and a half and released it as free, open source software, and they assume a weekend toy. Tinystat, our menu bar monitor for CPU, memory, GPU, disk, and network, was written almost entirely by Claude. We made the architecture calls, reviewed the code, and tested it.
So how much of an app can an AI coding agent write? On Tinystat, nearly all of the code. What it could not supply was the judgment that decided whether the code was right, and that judgment took most of the day and a half.
We build agentic delivery pipelines against production systems for clients, which makes it hard to show a client's codebase as evidence of how the work goes. Tinystat let us run the same practice on a project where nothing was at stake but our own time, and watch where the effort went.
What Tinystat is
Tinystat is a native macOS app, written in Swift, that shows CPU, memory, GPU, and disk usage as a compact readout in the menu bar. The dropdown adds per-core detail, network and disk throughput, and an on-demand internet speed test. The design brief was one number: under 0.1 percent sustained CPU. We wanted something lighter than the commercial alternatives, doing less and staying out of the way. It is free and open source on GitHub under the MIT license, and it installs with Homebrew.
What does the developer do when an agent writes the code?
The developer does the judgment work, and on Tinystat that was most of the effort. A coding agent is a model that writes, runs, and edits code in a loop toward a goal you set. Claude wrote nearly all of the Swift. We kept three jobs:
- Deciding what to measure. We chose what the app should measure and how.
- Reading every diff. No change went in until we had read it.
- Running it on a real machine. We checked that the app behaved the way the diff said it would.
None of that shows up in a line count. All of it decided whether the app was any good. It is the split we described in our post on agentic coding in production: generation stopped being the bottleneck, and verification is where senior time goes. That is true for a team of ten on a client system and for one person on a weekend, and it is why review is now the bottleneck most teams have not staffed for.
The catch we missed and Claude flagged
The original design ran the internet speed test automatically, every 30 minutes, to keep the readout fresh. During implementation, Claude flagged the problem. An active speed test saturates the network link while it runs. A monitor meant to sit quietly in the background would have choked, on a timer, the connection it was reporting on. We had not caught it.
The fix made the test manual. Tinystat runs Apple's networkQuality tool once per click of "Test Now," never on a schedule, and stops it when you quit the app. The README states the reason plainly: the test "saturates the link for 10-40 seconds per run, so nothing triggers it but you." That decision looked fine in a spec. It only showed its cost once something was running.
What this means for scoping AI coding work
For well-specified, bounded work, an agent cuts the cost of the first draft fast enough that estimates built on hours of typing are already out of date. The judgment that decides whether the output is correct does not get cheaper. Tinystat took a day and a half, and most of that went to architecture decisions, review, and testing, not typing. A client engagement that goes well has the same shape at a larger size, so the estimate belongs in the review and testing, because that is where the hours go.
We released Tinystat publicly because a private internal tool proves nothing to anyone outside the building. A free app anyone can install, with its speed-test decision written into its own README, answers "how do you actually use these things" better than a case study can. If you want the same practice pointed at your production system, our AI implementation framework is where it starts. AI that ships, not AI that demos.