Tell someone you built a Mac menu bar app in a day and a half and shipped it as free, open source software, and the assumption is a toy weekend project. Tinystat, our menu bar monitor for CPU, memory, GPU, disk, and network, was written almost entirely by Claude. We did the architecture calls, the code review, and the testing. That combination is not a toy. It is roughly the same practice we run on client engagements, pointed at something small enough to talk about in public.
We build agentic delivery pipelines against production systems and legacy estates for a living, which makes it hard to show a client's codebase as evidence of how that actually works. Tinystat let us run the identical practice against a project with nothing at stake but our own attention, and watch exactly where the effort went.
What shipped
Tinystat is a native macOS app that sits in the menu bar and shows CPU, memory, GPU, and disk usage as a compact readout, with per core detail, network and disk throughput, and an on demand internet speed test available in the dropdown. It targets under 0.1 percent sustained CPU, which was the entire design brief: something lighter than the commercial alternatives, doing less, doing it honestly. It is free and open source on GitHub under the MIT license, installable via Homebrew.
What we actually did while it wrote itself
Claude wrote nearly all of the Swift. What stayed ours was judgment work: deciding what the app should measure and how, reading every diff before accepting it, and running the thing on an actual machine to see whether it behaved the way the diff implied. None of that shows up as a line count, and all of it decided whether the app was any good. It is the same split we described when we wrote about agentic coding in production: generation stopped being the bottleneck a while ago, and verification is where the senior time actually goes, whether the team is ten people on a client estate or one person on a weekend.
The catch that mattered
The original design ran the internet speed test automatically, every 30 minutes, to keep the readout fresh. Claude flagged the design during implementation: an active speed test saturates the local network link for the duration of the run, which meant a monitoring tool meant to sit quietly in the background would periodically choke the connection it was supposed to be reporting on. We had not caught it. The fix was to make the speed test something the user triggers with a click, capped and terminated on quit, never on a timer. That is now called out explicitly in Tinystat's own documentation, because it is exactly the kind of decision that looks fine in a spec and only announces itself once something is actually running.
What this means for how we scope client work
The lesson we keep relearning: for well specified, bounded work, an agent lowers the cost of the first draft fast enough that pricing built around hours-to-type is already out of date. What does not get cheaper is the judgment that decides whether the output is correct. Tinystat took a day and a half; most of that day and a half was architecture decisions, review, and QA, not typing. That is the same shape a client engagement takes when it goes well, just compressed into a project small enough to open source.
We shipped Tinystat publicly because a private internal tool proves nothing to anyone outside the building. A free app anyone can install, with a design decision it got wrong documented in its own README, is a more honest answer to "how do you actually use these things" than a case study ever is. AI that ships, not AI that demos, holds up the same way at this scale as it does on a production AI implementation.