From Build to Reality: Automation After the Demos
A few weeks after Build 2025, the event energy starts to cool down, and that is usually when the most useful reflection begins.
That post-event window matters to me because it creates enough distance to sort excitement from lasting value. During Build itself, everything arrives at once. The message is fast, the demos are polished, and the future always looks clean. A little later, the better questions start to emerge. What is actually going to change the way I work? Which ideas hold up outside the keynote frame? What survives contact with real environments?
Sitting with Build for a bit made a few things clearer for me, especially around IaC, AI-assisted workflows, and the continued role PowerShell plays in tying everything together.
IaC now feels like the default operating assumption
Infrastructure as Code is not new, but the tone around it has changed.
It no longer feels like a best practice that still needs to be argued for. More and more, it feels like the expected baseline. The question is no longer, “Should we use IaC?” The more revealing question now is, “Why are we still doing this manually?”
That shift matters because it changes what maturity looks like. Once IaC becomes the assumption, the conversation moves beyond adoption and into quality. The better questions become:
- Is the code readable?
- Is it reusable?
- Does it describe intent clearly?
- Can another engineer maintain it confidently?
- Will it survive platform change without becoming brittle?
Those are much healthier questions, and they are also harder ones. It is one thing to adopt IaC. It is another thing to make it durable.
AI helps, but it does not own the result
Since Build, I have been thinking a lot about the difference between acceleration and accountability.
There is real value in using AI to draft templates, suggest structure, reduce repetition, and help move through the early stages of a task more quickly. That part is obvious enough now. In the right hands, it can save time and reduce friction.
But none of that changes the fact that AI does not own the correctness of the outcome. It does not bear the consequences of a flawed deployment, a misunderstood dependency, or an automation pattern that seemed plausible but was operationally wrong.
That is why validation matters so much. The faster the first draft arrives, the more disciplined the review has to be. Otherwise, speed just becomes a way to produce fragile work more quickly.
For me, this is the right mental model: AI is useful as an accelerator, not as a substitute for understanding.
PowerShell still fills the gaps between systems
Even with more declarative workflows, stronger native cloud tooling, and growing AI assistance, I still keep coming back to PowerShell.
Not because I think it should be the center of every solution, but because it remains one of the best ways to connect systems that do not line up neatly on their own.
That connective role keeps showing up in practical work:
- Interrogating platform state quickly.
- Reshaping API output into something useful.
- Bridging a declarative workflow with a procedural step.
- Moving between services that expose similar concepts differently.
- Handling the awkward edges that abstractions often skip.
That is the role I see PowerShell playing more and more. It is not always the headline tool, but it is often the thing that makes the whole workflow actually work in the real world.
What changed in my own approach
The main thing Build changed for me was not direction so much as commitment.
It pushed me to be more disciplined about a few patterns I was already moving toward:
- Fewer one-off scripts.
- More reusable functions and modules.
- More direct use of APIs.
- More care around making IaC understandable as code, not just functional as deployment output.
- More intentional use of AI as a drafting and acceleration layer rather than a source of truth.
That feels like the right balance. I do not want automation that is merely fast to create. I want automation that is still understandable, maintainable, and adaptable after the initial urgency is gone.
What actually stuck after Build
The clearest takeaway for me is that modern tooling is not removing complexity. It is redistributing it.
Some things really are easier now. It is faster to scaffold ideas, easier to get a first draft, and quicker to connect pieces than it was a few years ago. But the responsibility for judgment, design discipline, and operational awareness has not disappeared. If anything, it matters more because the pace is higher and the abstractions are thicker.
That is why the weeks after Build often matter more to me than the event itself. Once the noise settles, the pattern becomes easier to see.
This year, the pattern was clear enough: automation is becoming more declarative, AI is becoming more embedded, and the people who will do best in that world are the ones who can move comfortably between those layers without losing sight of how the systems behave in production.