Covers December 2025 - January 2026.
In January, one application went from an empty repository to 106 of 106 features passing in a single day - ten domain models, CRUD APIs, a dashboard, the works. That was the result that settled the “is this real?” question for me.
When I wrote part one of this series at the end of November, I had a proven template, six apps riding it, and a backlog growing faster than I could type. The obvious next move was pointing AI coding agents at that backlog. Actually doing it meant figuring out how to keep an unattended agent honest and how to tell when it was stuck. December was spent learning that the expensive way.
Three wrappers
In mid-December, I built three separate CLI wrappers - aidd-c for Claude Code, aidd-k for KiloCode, aidd-o for OpenCode - instead of one abstraction. (Two of them had actually been started back in October as side experiments.) It felt like a detour at the time. Each AI coding tool has its own CLI, output format, and ways of failing, and I was pretty sure that abstracting before I understood those differences would leave me with a leaky mess.
KiloCode was the hardest to drive headlessly - it took several rounds of session management, transcript capture, and error recovery before it behaved. Claude Code needed less work, which included the first idle-timeout detection. OpenCode barely needed any. Seeing the same wrapper logic three times revealed how much they shared - most of it, really. It also highlighted the provider-specific seams.
On December 29, all three were renamed under one brand and gained a .aidd metadata directory holding structured feature definitions, so the project carries its own contract for how an agent works on it. I kept that directory when the wrappers merged.
On January 8, the three wrappers merged into aidd. The director shipped as v0.8.0 the same day. I spent the rest of the month building the core. Work is now defined in .aidd/features/*/feature.json instead of chat prompts. I added an audit framework for security, performance, and tech debt that sends findings directly to the backlog. Other additions include idle timeouts with agent nudging, automatic retries, stuck detection, and full iteration transcripts stored in .aidd/.
The audit framework came from real pain. In January, Spernakit underwent a long audit campaign. The process revealed how much technical debt piles up even in a well-maintained template. Doing that campaign semi-manually convinced me the audit process belongs inside the orchestrator, with the findings going into the backlog as features. Of everything in aidd so far, I suspect that’s the part that matters most.
Building features overnight and reviewing them in the morning is a genuinely different job, by the way. I’m not sure how I feel about it yet.
Stress test and a one-day build
Ten days after v0.8.0, I stress-tested it by running three projects under aidd orchestration at the same time. The activity was intense, but the useful result was that three independent runs could make progress concurrently without getting tangled together.
Two details from that day stuck with me more than the number. aidd’s audit mode caught issues that its own feature-building mode had introduced, which I hadn’t expected this early. And the one feature it couldn’t close was one that needed a human judgment call about requirements, not more implementation - it stopped and asked instead of guessing. I want to build that behavior in intentionally rather than hope it keeps happening.
Eleven days after that came the empty-repository run I opened with.
The three wrappers gave me enough examples to separate the shared run logic from each tool’s output handling. Adding another backend will give that separation a test.
This morning I started Spernakit v2 from a blank repository. All those January projects were built on v1, and v1’s technologies were picked because I already knew them. The rewrite replaces every major piece - the web server, the database layer, the logging system, the UI components, even how configuration files work - with a stack chosen specifically for the Bun runtime, based on everything v1 taught me. Dozens of dependencies gone.
A blank repository is daunting when a year of work is sitting in an archive folder right next to it. It’s also a chance to finally make every decision (that felt like a compromise the first time around) over again. I spent a big chunk of today writing a long migration guide. No one else will ever read it, but forcing myself to justify every change in writing keeps me from making arbitrary ones.