A Packed Room and the Pace of AI in Software Engineering

Microsoft Build //localhost:reston Panel Discussion Last week I spent the day at Microsoft’s Build //localhost:reston event, one stop in the broader //localhost series taking place around the world after Build 2026.

The Reston Reactor space was full, and most of the day was exactly what you would hope for from a developer event: hands-on work with Microsoft Foundry and GitHub Copilot, live demos, guided labs, and a steady stream of what’s new coming out of Build. It was implementation-focused, not slideware. People left with things they could try in their own codebases the next morning.

My part of the day looked a little different. Alongside Beju Rao, I joined a panel discussion that ranged wider than any single product announcement. Instead of drilling into one feature, we stepped back and talked about where AI actually stands right now, how quickly the landscape is changing, and what all of this is doing to the practice of software engineering.

What struck me most was the pace.

It is one thing to say AI is moving fast. It is another to sit in front of a room of practitioners and realize that the way we talked about this work even a few months ago is already dated. Patterns that felt experimental at the start of the year are now becoming part of how teams ship. The conversation we had would have been different in the spring, and it will be different again by the fall. That acceleration is the story underneath every other story right now.

The audience made the session. This was not a passive room. People brought real experiences from their own teams, the kind of specific, hands-on stories you cannot get from a keynote. We heard what is working, what broke, and where the gap between the demo and the daily grind still lives. A panel is only as good as the questions it draws out, and this group pushed us in directions I did not script going in.

A few themes kept surfacing as we talked:

  • The role of the engineer is shifting (or in many cases has already shifted!) from writing every line to directing, reviewing, and orchestrating work that AI can now help produce.
  • The hard problems are increasingly about engineering discipline, not just tooling. Teams need clearer intent, stronger review models, better acceptance criteria, and a shared understanding of when to lean on automation versus when to slow down.
  • Nobody has this fully figured out, and the people closest to the work are honest about that. The best conversations happen when we trade what we are actually seeing.

That last point is why I keep showing up for events like this one. The practitioner view, unvarnished, is where the real learning is.

Thanks to Microsoft Reactor for hosting, to Beju for a genuinely fun conversation, and to everyone who stayed engaged and brought their own stories to the table. Days like this are a good reminder that the most useful AI insight often happens when a group of interested people who build things compare notes.