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