Eleven releases in five days: what building with an AI teammate actually looks like

In a little over five days, a personal project I build on nights and weekends went from version 1.0.0 to 1.0.10. That's eleven stable releases and nineteen betas, built from 90 reviewed pull requests, and the automated test count went up by more than half. The last release alone went through three betas, each checked on real hardware, in about eighteen hours.

I didn't do that by putting in more hours; I had nights and weekends, like any side project. I did it with Claude (Anthropic's AI model, working in my terminal through Claude Code) as a full-time engineering teammate.

This post is for three groups of people I talk to a lot: business leaders who want to know what AI changes about building software, engineering leaders who want to know whether the result is any good, and investors trying to price what one experienced builder can now do. The short answer for all three: the speed is real, the quality can be too, and the difference between the two is the experience of the person steering.

A word on where I'm coming from. By day I'm a VP leading an 80+ person data, analytics and data science organization. Before that I was a CTO who built a 30-person engineering and data organization from zero, spent nearly five years at Amazon, and co-founded a venture-backed startup.

Kestrel is not that job. It's a personal project, built entirely on nights and weekends, on my own time and my own hardware, with no connection to my employer. That's part of why the numbers below surprised me: this wasn't a funded team working full days, it was one person's evenings with an AI teammate. It also made it a clean experiment, where I could watch every step myself. The views here are my own.

The project, in one paragraph

Kestrel is a build-it-yourself Raspberry Pi device for studying Wi-Fi security: it listens to the networks around it, collects the data researchers use to test password strength, and uses a small machine-learning agent to decide where to listen next. It has a web dashboard for your phone, an optional e-ink "face" that shows its mood, and support for add-on screens, GPS and battery packs. It's for authorized testing only, and that rule is built into the product: capture ships switched off, and nothing that sends data anywhere turns on without an explicit "I'm authorized" confirmation. It's open source.

For business leaders: what actually changed

What changed is not that software writes itself. It's that one experienced person can now run the whole loop a small team used to run: design, build, test, document, release, verify, support.

Three things made that work, and none of them is about the AI being clever:

• The rules were written down before the work started. The project has an operating manual the AI reads at the start of every session: never put real personal data in the code, never weaken the safety confirmations, how releases are numbered, what counts as a breaking change. It's the same thing you'd hand a new senior hire, just more explicit. The AI follows it, and when a request would break it, it stops and says so.
• Decisions stayed with me. Claude proposed, built and tested; I decided. In this release that meant calls like renaming two features whose names had become ambiguous, keeping the old names working until a later release, and adding a third test round when a change touched hardware, instead of shipping straight to customers. I've long believed that conviction without evidence is just attachment; the third beta was me asking for evidence before shipping. Claude never merges its own work and never publishes a release on its own initiative.
• Every step leaves a paper trail. Each change is a pull request with a standard checklist (tests, privacy, safety, release impact). Each beta has a public checklist, ticked item by item from a check that runs on the real device. That's the kind of audit trail compliance teams ask for, and it cost almost nothing to keep.

Having built and run engineering organizations, I recognized the shape of this immediately. The work that made my best teams fast (clear standards, documentation people actually use, a release process nobody argues with) is exactly the work that makes an AI teammate fast. The leadership lesson is an old one: speed comes from clarity. Clear rules, clear ownership of decisions and a fast feedback loop. AI didn't change that. It removed the cost of execution that used to sit between a clear decision and a shipped result.

For engineering leaders: did quality survive?

This is the part I care most about, so here is how it was kept honest.

Design before code. Anything bigger than a bug fix started as a short design document, reviewed and argued over before a line was written. For this release that included a plan to move code shared by several hardware add-ons into small versioned libraries, so supporting a new screen or battery board is mostly one file instead of a copy of an old one. The libraries declare an API version that's checked before they run, and a mismatched major version is refused.

Refactors you can prove. When the face-drawing code moved into a shared library, we rendered every screen state before and after and compared them byte for byte: dozens of frames, identical. When two features were renamed, the old and new versions are checked by a test that compares their code structure, so a fix to one can't silently miss the other.

Tests and checks that run every time. Every pull request runs linting and more than 1,400 automated test cases, plus a scanner that fails the build if anything resembling real personal data, keys or captured data shows up. A pre-commit hook runs the same scanner, so it can't be skipped by accident.

Verified on the real device, not just in CI. Each beta ships with a read-only check script that runs on actual hardware, redacts anything personal before it leaves the device, and produces a report that's used to tick the beta's public checklist, item by item. In this cycle, the second beta's check turned up a conflict when two display add-ons were enabled at once. That became a fix, a third beta and a confirmed pass on the device before the stable release.

And yes, the AI made mistakes. It once chained a lint run and a commit so the commit went through before the lint result was visible. It once forgot to attach a beta's check scripts to its checklist until I asked. While publishing the user guide, a heading with a dot in it ("2.13-inch") broke a link because our tool and the blog engine disagreed on one character. Each was caught by the process (a check, a review, a warning) and fixed within minutes, and the fix usually became a permanent test. That's the point: you don't need a teammate who never makes mistakes; you need a system that catches them.

What I'd tell another CTO: the AI is at its best when the codebase already has strong opinions. Conventions, tests, a release process, written rules. It amplifies the engineering culture you give it. If that culture is thin, it will amplify that too.

For investors: what the numbers mean

Here's the five-day picture, measured from the project's own history:

• 11 stable releases and 19 betas from 1.0.0 to 1.0.10.
• 90 merged pull requests, each with tests and a release-impact note.
• Automated test functions up from 711 to 1,282, and about 23,000 lines of Python added, tests included.
• The latest release: 23 pull requests, six new hardware plugins (two of them clearer names for existing ones), five shared libraries and three hardware-verified betas, in about eighteen hours.

For perspective: as an entrepreneur in residence at a startup studio, I once took an idea to a working MVP in six weeks, tested it with real users, and stopped it when the data said to. That was fast at the time. This week, one release cycle of a mature product (new features, three hardware-verified betas, documentation and a stable release) went from first change to stable release in about eighteen hours of elapsed time, worked around a day job.

The economics are simple to state and hard to overstate: the cost of execution has collapsed for experienced builders. In my experience, work that used to need a small team and a quarter now needs a person with judgment and a week. That moves where the value is:

• Judgment becomes the scarce input. Knowing what to build, what to refuse, when a change needs another test round and when it can ship. Those calls were mine in every case above, and they're the ones that decide whether speed turns into a product or into debt.
• Engineering discipline becomes a multiplier. The same AI in a codebase without tests, conventions or written rules would have produced the same speed and far more risk. Teams that already work this way get the biggest return.
• Small, senior teams look different now. When you evaluate one, ask how they verify, not just how fast they ship. The ones who can show you the checklist, the tests and the audit trail are the ones whose speed will hold.

What didn't change

The fundamentals. Talk to users, decide carefully, test what matters, keep a record, and own the result. AI made the distance from decision to shipped result very short. It didn't make the decisions, and it shouldn't.

If you lead a team, I'd love to hear how you're thinking about this: where are you seeing the bottleneck move? And if you're building something similar, what guardrails have worked for you? 🪶

Kestrel is a personal, open-source project built on nights and weekends, unaffiliated with my employer, and for authorized testing only. The user guide and source are public.