Part 2: Sleepy Tom, Baking Martha, and My Multi-Agent Homelab

      Welcome back to Part 2 of my 3-part series on agentic software development. In Part 1, I vented a little about how painfully slow traditional corporate code-review queues feel once you have seen real-time, voice-driven AI prototyping in action. Today, I want to show you what happened when I took that rapid-iteration philosophy and built my own multi-agent engineering pipeline at home; before we bring everything full circle in Part 3 to ask what this massive jump in solo productivity actually means for the future of software engineers.

     That homelab experiment turned into FCI Operations, a "Paperclip company" I created that combines local AI inference (using Hermes Agent and local models on vLLM) with frontier models like Google Antigravity, Claude, and Codex. Instead of having three humans stare at every pull request, I set up a pipeline where specialized agents write the code, build the test harnesses, and review each other's pull requests before I ever step in as the final human quality gate on `main`. I even have local agents that dispatch tasks to managed cloud agents like Google Jules, wait for Jules to open a pull request, review the diff, and approve the merge so the CI/CD pipeline can take over - all while I am off doing something else.

     Of course, if you are going to let AI agents write and review code at high speed, you can't rely on wishful thinking to know if the software actually works; you need serious automated verification (otherwise you are just generating bugs at the speed of light). In my case, I was building and testing an integration tying Home Assistant into an analytics cloud platform for senior care, and I hit 95% code coverage by building an end-to-end simulation engine called the **Virtual Villa** harness.

     The idea behind Virtual Villa was simple: Home Assistant thinks it is talking to a house full of real physical Z-Wave motion sensors, contact switches, and smart plugs, and the cloud platform thinks it is monitoring a real building. In reality, the whole thing is a simulated retirement community populated by synthetic resident personas that I created.

Each resident has their own daily routine and quirks:

• Sleepy Tom, who sleeps in late and moves at a glacial pace.
• Active Jane, who is up at the crack of dawn and out the door on a strict schedule.
• Antisocial Jack, who mostly stays holed up in his living room all day (honestly, I can relate on some weekends).
• Baking Martha, who spends practically her entire day moving around the kitchen.

     Having these virtual residents wander around their simulated homes (with a little randomization around activities) gives the system a baseline of daily human activity. Once that baseline is established, I can start injecting anomalies. For example, what happens if Active Jane doesn't get out of bed at 8:00 AM one morning? The harness lets me simulate that exact scenario end-to-end, feed the telemetry stream into the cloud analytics engine, and automatically verify whether the right alerts get triggered and sent to the right caregivers.

     Most of that simulation code, along with the unit and integration tests validating it, was written, reviewed, and refined by agents working in a loop. My role shifted from typing boilerplate to acting as the product owner and system architect; I use the tool, spot where the behavior or speed feels off, and set the requirements for the next pass. I watch the system resources, and tell the agent when it is using too much memory or CPU. Agents monitor the logs daily for error messages, and report to me with suggested next steps.

     Coming Up in Part 3 (The Conclusion): I have to admit, part of me feels like a wizard running a five-person engineering team out of my home office; however, the other part of me sees a huge warning sign in how this works. Discovering performance requirements on the fly exposed a classic trap I remember from my days testing games at Microsoft, and it points directly to the final conclusion of this series: if agents are writing and reviewing all the code, who is training the next generation of senior engineers? Let's wrap up the trilogy in Part 3.

Later,

     SteveO

Part 1: Move Fast and... Wait for Reviewers?

     I am back, after... years.  Trying some new formats, but today I am starting with a bit of a rant... I am going to schedule some follow up posts that hopefully have a more balanced feel than my original 2,000 word wall of text I wrote over the weekend, and this is a not-so-quick heads-up: this post is part of a 3-part series about where I think AI-assisted software engineering is actually taking us. This is one of those love/hate topics for any developer, and its hard to know where all of this lands. So, as promised, I will start today with a rant.  Its about the frustrating disconnect inside modern corporate engineering teams, then detour through my own multi-agent homelab tomorrow, and finally arrive at the big question in Part 3: when AI agents make one senior engineer as productive as a five-person team, where the heck do the next senior engineers come from?

     So, over the past several months, I have been watching a pretty fascinating contradiction play out across the software industry. On one hand, executives everywhere are handing down mandates to push the envelope with AI and crank up development velocity. Everyone wants to get back to that classic tech ideal of moving fast and breaking things - just without the part where anything actually breaks. On the other hand, those exact same organizations are clinging for dear life to pre-AI "Human in the Loop" bureaucracy; meaning an engineer uses AI to generate a fix in ten minutes, and then the ticket sits in a queue waiting for two human code reviewers to sign off before it can ever be closed.

     If you stop and do the math on a four-person engineering team, requiring the author plus two peer reviewers on every single AI-assisted ticket means three out of four people on the team are tied up touching the exact same unit of work (which is a hilarious way to define "high velocity"). Those two ideas are completely antithetical to each other. There is a massive disconnect between the way corporate leadership dreams things will get done with AI and the actual rules they enforce on the ground.

     Right now, the traditional enterprise loop still looks painfully familiar: write some code, read some code, review some code, review it some more, run a few tests, and then answer a long thread of inquiries about why a function was written a certain way. All of this happens before the change is ever deployed to a proper staging environment where someone can actually click around and use it; literally adding days of overhead to a change that took minutes to write.

A while back, I got a front-row seat to a completely different way of working while collaborating with my friend David. Watching the way he works with AI was a real lightbulb moment for me. Instead of treating AI like a slightly faster autocomplete inside an IDE, he literally talks to the AI (with his voice) to spin up a working prototype, and immediately deploys that prototype to an internal staging environment.

     From there, the real magic happens while we are actually using the tool. In real time, while we are testing the workflow from an end-user perspective and running into flaws, he just speaks to the AI. He tells it the exact problem we are seeing, explains why it is a problem, and contrasts what the app is currently doing against how he expects it to behave. While we are still sitting there testing, the AI updates the logic and redeploys the fix on the fly - no three-day pull request thread required.

     Sure, new bugs pop up as we push the prototype further; that is just the nature of software development (and honestly, half the fun). However, by working in that tight voice-to-staging loop, the development agent stops being a fancy text generator and becomes an actual engineering partner. You iterate rapidly until the product meets the functional requirements and the spirit of what the user actually needs, and then you can circle back to optimize the code afterward; or better yet, hand it off to a separate, adversarial AI review agent to audit test coverage and suggest improvements before anything merges to `main`.

     Coming Up in Part 2: Watching my friend David work that fast left me slightly obsessed. If voice-driven rapid prototyping works that well with one developer and a staging server, what happens when you build an entire multi-agent engineering organization around that philosophy at home? Next time, I will introduce you to FCI Operations, my Virtual Villa retirement community simulator, and how I put a crew of AI agents to work in my homelab (which sets up the bigger industry problem we will tackle in Part 3).

Later,

     SteveO