Pages

Wednesday, October 21, 2026

Part 3: From Xbox and Windows 95 to Today: Who Trains the Next Senior Engineer?

   This is Part 3 (the final installment) of my trilogy on agentic software development. In Part 1, we looked at the clash between slow corporate code reviews and live voice-driven prototyping; in Part 2, I walked through how I run a multi-agent team at home with FCI Operations and my Virtual Villa simulator. Now it is time to connect those dots and get to the final point I promised back in Part 1 - why this amazing new workflow leaves me genuinely conflicted about the future of our industry.

     In Part 2, I mentioned how running a multi-agent engineering pipeline changed the way I write requirements; specifically, how often I come up with performance requirements on the fly while actually using the software and realizing, "Hey, this button should not take this long to respond."

     We love to pretend in software engineering that we can sit down before writing a line of code and declare a blanket non-functional requirement like, "All UI interactions must complete within 500 milliseconds." That sounds wonderful in theory, but in practice, it falls apart the second your software meets unpredictable hardware.

     This is something I learned early on during my time at Microsoft working on Xbox 360. On a console, Microsoft has strict Technical Certification Requirements (TCRs). When a player launches a game or presses a button, the game has a hard time limit (down to the second) to display something on screen (even if it is just a spinning wheel or a loading bar) so the user knows the system didn't freeze. On an Xbox, enforcing that rule makes complete sense because every single customer is running the exact same hardware in their living room.

     Desktop and web software is a completely different animal. You have no idea if your user is running a high-end gaming rig or some $99 Walmart cheapo PC that barely boots the browser. The same unpredictability applies to the cloud backend too; you don't know if a request is hitting a warm Kubernetes pod or a serverless AWS Lambda function that just went into a cold reload - surprise, your half-second budget is already gone. Because of that, real performance tuning usually happens in the middle of testing a working prototype, when you feel the lag yourself and tell the agent to fix the bottleneck.

     However, watching how easy it is to let agents handle that heavy lifting brings me full circle to my biggest worry for our industry. Right now, a lot of developer burnout is coming from engineers trapped between two worlds: trying to satisfy slow, pre-AI corporate review processes while simultaneously being pushed to adopt high-speed agentic workflows.

     As the agentic model wins out, we are heading toward a world where one senior engineer leading a team of AI agents can comfortably do the work that used to take five or more developers. I love the velocity in my own homelab, yet I can't shake the obvious question: where do the next senior engineers come from?

     Think about how operating systems evolved over the last thirty years. Back in the Windows 95 era, you only had a tiny sliver of RAM and CPU, so engineers had to be incredibly disciplined and sparing with every megabyte. Today, a modern OS like Windows 11 will happily eat a gigabyte of RAM without a second thought, and then chew up another gigabyte just to draw the graphical user interface so you can finally run an application on top of it. Now, there are valid reasons for modern OS features, and I am certainly not arguing that we all need to go back to Windows XP here; however, cheap hardware made us lazy about resource discipline.

     I worry we are about to treat software engineering talent the exact same way. Right now, it is very tempting to just let the agents do everything because you can move so much faster when you don't have three humans staring at every line of AI-generated code. If the function does what it needs to do, the performance feels good enough, and a security auditing agent says the security is good enough, we ship it. Yet writing those routine tickets, breaking things, and debugging the mess is how junior developers learn what good code actually looks like. If nobody is doing the foundational work anymore, in ten years, who is going to have the deep systems knowledge required to review what the agents are building?

     Anyway... that is the full circle of my rant on agentic development. I am having a blast building with these tools, even if I am a little nervous about where the industry ladder goes next.

Later,

     SteveO