16 posts tagged with "Agentic AI"

Why Understanding Still Matters When AI Can Write the Code​

It has never been easier to turn an idea into working software. Describe what you want in plain language, and an AI tool can generate a web page, a script, an API integration, or even a multi-step agent that takes actions on your behalf. For anyone who felt shut out of software because they did not know how to code, that shift is real and welcome.

But there is a difference between software that runs and software you understand. AI can produce the first one in seconds. Only you can produce the second, and only if you know enough about how software actually works to read what the AI gave you, question it, and fix it when it is wrong.

Why the next chapter of FinOps is not about finding a cheaper model. It is about engineering systems that do not waste the tokens they already have.

A finance leader opens the monthly invoice for the company's AI platform and finds a number that does not match any story anyone can tell. Usage grew modestly. The bill grew sharply. Nobody switched to a pricier model. Nobody approved a new integration that anyone remembers. The line item simply grew on its own, the way cloud bills used to grow before anyone built a discipline around watching them.

Ask the engineering team what happened and the answer is rarely a single cause. It is a hundred small decisions: a system prompt that grew every time someone patched in a new rule, a retrieval step that fetches ten documents when two would do, an agent that retries a failing tool call five times before giving up, a workflow that hands a conversation between three specialized agents and resends the full history at every handoff. None of these decisions looked expensive in isolation. Together, they are the bill.

The Bottleneck Moved, and Most Teams Have Not Noticed​

For decades, writing code was the expensive part. Reading it was almost free by comparison. A developer spent hours producing a change, and a reviewer spent minutes confirming it. That ratio shaped everything: our tools, our processes, our sense of who was busy and who was waiting.

Agents inverted that ratio. A capable agent now produces a complete branch with code, tests, and documentation in the time it takes to write a thoughtful task description. Authoring became cheap. Reading did not.

Eight building blocks that turn a capable model into a system that ships real work: agents, subagents, skills, context, memory, prompts, notebooks, and projects.

Most people believe they are using Generative AI when they open a chat window and type a question. They are using the least interesting part of it. The chat box is the front door, not the house.

On Friday, June 12, 2026, I delivered a webinar on the Microsoft Reactor YouTube channel called DevOps Foundations for the AI Agentic Era. The recording is now available, so you can watch it anytime.

Choosing how to build a mobile or device app used to be a contained decision. Pick the platforms, weigh native against cross-platform, factor in team skills, and choose a framework. The trade-offs were mostly about runtime performance, hiring, and how much code you could realistically share.

Two things have shifted that picture. First, the platform landscape itself has matured: SwiftUI, Jetpack Compose, WinUI 3, .NET MAUI, React Native's New Architecture, Flutter with Impeller, and Kotlin Multiplatform have all reached a level of stability that makes a clean comparison possible. Second, AI agents are now part of the daily loop for most teams. They do not just complete code; they read repositories, summarize unfamiliar APIs, generate scaffolding, and shorten the path from "I have never used this framework" to "I shipped something with it." That changes how the framework decision should be made.

This guide walks through the realistic options for iOS, Android, Windows, and Xbox, the main cross-platform frameworks, and the pros and cons of each in 2026.

Picture this. A GitHub Copilot coding agent picks up an issue, creates a branch, writes the implementation across four files, adds tests, and opens a pull request. CI passes. Code scanning reports no alerts. A developer reviews the diff, approves, and merges. The change ships to production through an automated deployment pipeline.

Three weeks later, a penetration test discovers that the agent-generated code introduced a server-side request forgery vulnerability. The code was syntactically clean, the tests covered the happy path, and the reviewer did not catch the flaw because the logic looked reasonable in isolation. Now the team needs to answer a question that their security model was never designed for: who is accountable for code that no human wrote?

Here is a contradiction I keep running into. Every piece of cognitive science research I have read says the same thing: focus on one task at a time. Multitasking is a myth. Your brain cannot do two demanding things simultaneously without paying a steep performance penalty.

And yet, every day I find myself reviewing a pull request that GitHub Copilot cloud agent opened, while a CI/CD pipeline runs on a second branch triggered by AI-generated code. More parallel workstreams than I ever managed before AI entered my workflow and somehow it feels less chaotic than before.

Something does not add up. Either the science is wrong, or what I am doing is not actually multitasking. I think it is the latter, and the distinction matters for every engineer adapting to agentic workflows.

The Definition Worked. Until a Fourth Participant Showed Up.​

DevOps has always been defined by a simple, powerful equation: People + Process + Tools. That formula captured something essential about how modern software gets built and delivered. It broke down walls between development and operations. It gave organizations a mental model for diagnosing what was wrong when things moved too slowly, failed too often, or created too much friction.

For over a decade, this three-pillar model served the industry well. And it did so because it rested on an assumption that nobody questioned: every participant in the software delivery lifecycle was human.

That assumption no longer holds.

Your Pipeline Was Built for Humans. That's About to Be a Problem.​

Not so long ago, every commit in your repository came from a human. A developer wrote code, pushed a branch, opened a pull request, and a reviewer approved it. Your CI/CD pipeline was designed around that flow: run tests, check lint, scan for vulnerabilities, deploy if green.

That assumption is breaking.