A developer asks an agent to investigate a failing deployment.
At first, it feels familiar. The agent reads a file. Then another. It traces a configuration path, opens a deployment script, inspects logs, and starts forming a theory. Nothing about the workflow feels dramatic. It feels like a very capable pair programmer doing the tedious parts quickly.
Then the agent does something interesting.
It decides the problem is not in the code it was originally asked to inspect. It decides the issue sits in the surrounding system: an environment variable, a stale dependency, a misconfigured deployment target, maybe a resource definition nobody has touched in months. The work has quietly moved from reading code to reasoning about infrastructure.
The developer never wrote that workflow.
The developer never listed those steps.
The developer expressed an outcome.
The system constructed the path.
That is the subtle but enormous shift behind the “intent-first” story coming out of Microsoft Build 2026. TechRadar framed the moment as a move from traditional code-first programming toward AI systems where developers express desired outcomes in natural language, while agents translate those outcomes into executable code and workflows. The article points to GitHub Copilot’s autonomous and asynchronous agent workflows, GitHub Copilot Agent Mode, GitHub Spark, Azure AI Foundry, the Microsoft Agent Framework 1.0, and Windows Copilot Runtime as signs that agent-based development is becoming production infrastructure rather than a novelty.
Most people will read that and conclude that AI is changing how we write code.
That is true.
But it is not the deeper story.
The deeper story is that code is no longer always the first artifact in the system.
Intent is.
We used to know where behavior came from
For most of computing history, behavior had a home.
It lived in code.
A programmer wrote instructions. A compiler translated them. A runtime executed them. Security systems wrapped controls around the result. If something happened, we could usually trace the behavior back to some combination of source code, configuration, deployment state, and human decision.
The system might be complex. It might be distributed across services, containers, APIs, queues, functions, and databases. But the basic assumption stayed intact: behavior was defined before execution began.
That assumption shaped the entire software world.
Code review exists because code is the artifact we trust enough to inspect. Version control exists because code is the artifact we need to preserve. CI/CD exists because code moves through gates before reaching production. Runtime security exists because code eventually becomes execution. Compliance exists because organizations need evidence that approved software behaved within approved boundaries.
Even cloud-native infrastructure kept this model alive. Kubernetes made systems more dynamic, but the workload was still declared before it was scheduled. Service meshes made communication programmable, but the services already existed. IAM and zero trust made access more adaptive, but the actor and resource were still relatively stable.
The world was messy, but the origin of behavior was not mysterious.
Then agents arrived and quietly loosened that assumption.
Intent-first systems make behavior emerge
In an intent-first system, the user does not fully specify the behavior.
The user specifies a desired outcome.
That outcome is interpreted by a model, shaped by context, refined into plans, translated into tool calls, and eventually turned into code, commands, API requests, or workflow actions. Somewhere in that chain, behavior appears.
The strange part is that no single human wrote the complete path.
The system assembled it.
A request to “fix this test” may become a repository search, a dependency update, a generated patch, and a shell command. A request to “prepare a customer churn summary” may become a database query, a data transformation, a report, and maybe, if the system is not properly bounded, an external API call. A request to “clean up old deployment logic” may become a set of edits that look reasonable locally but touch infrastructure nobody meant to authorize.
This is why the Build 2026 framing matters. The shift from code-first to intent-first is not only a developer productivity story. It changes what the system treats as the source of behavior.
Code becomes an intermediate representation.
The original artifact is the human goal.
And human goals are not like code.
They are incomplete. They carry assumptions. They depend on organizational context. They omit constraints that humans assume other humans will understand. They often describe what should be accomplished without specifying how far the system is allowed to go.
That is fine when the system is only suggesting.
It becomes dangerous when the system can act.
The old controls arrive too late
Most of the security systems we have inherited were built for a code-first world.
They are good at asking whether a user is authenticated, whether a service has access, whether a tool call is allowed, whether a process is isolated, whether an action occurred inside a policy boundary. These are still necessary. Nobody should deploy agents into real environments without identity, sandboxing, authorization, monitoring, and runtime controls.
But intent-first systems create a problem upstream of all of that.
By the time an action reaches a tool, the most important decision may have already happened.
The system has already decided what the task means.
It has already narrowed ambiguity into a plan. It has already selected tools. It has already decided whether reading is enough or whether modification is necessary. It has already converted the user’s intent into operational behavior.
If that conversion is wrong, the runtime can still look clean.
The credentials can be valid. The API call can be authorized. The command can execute successfully. The audit log can faithfully record what happened.
And yet the system may have become something the user never intended.
That is the uncomfortable part of intent-first computing. The failure does not always look like a jailbreak or a breach. Sometimes it looks like a coherent plan that should never have existed.
The new artifact needs a new kind of control
When code was the source artifact, we built controls around code.
We reviewed it. Tested it. Signed it. Scanned it. Deployed it through pipelines. Watched it in production. Rolled it back when it misbehaved.
If intent is becoming the new source artifact, then intent needs its own control layer.
Not a vague layer that claims to “understand” human purpose perfectly. That would be fantasy with a dashboard. Human intent is too incomplete, too contextual, too slippery to fully capture.
The control layer has to do something more practical.
It has to preserve the relationship between the user’s purpose, the plan the agent constructs, and the actions that eventually execute. It has to notice when a system becomes more certain while also expanding its authority. It has to distinguish between a plan that is merely detailed and a plan that has quietly grown new powers. It has to make every action answerable to the reasoning structure that produced it.
This is the part of the intent-first transition that does not fit neatly into the “AI writes code” storyline.
The hard problem is not only generating better code.
The hard problem is governing the path from intent to code to execution.
Code review was built for the wrong object
There is a reason developers feel uneasy when agents make large changes.
It is not just that the code may be wrong. Developers know how to handle wrong code. They can inspect a diff, run tests, review architecture, and reject the patch.
The unease comes from something deeper.
The diff is no longer the whole story.
A generated patch is the residue of a reasoning process. By the time the developer sees it, the agent has already interpreted the task, selected a strategy, explored context, and decided which changes belong inside the solution. Reviewing only the final diff is like judging a court case by reading the sentence but not the argument.
You can still catch many mistakes that way.
But you cannot fully understand why the system arrived there.
That is why intent-first development changes the role of verification. The question is not only whether the generated code is correct. The question is whether the generated code is the right expression of the original purpose.
A patch can compile and still be wrong.
A tool call can be authorized and still be wrong.
A workflow can succeed and still be wrong.
The wrongness lives in the transformation.
The transformation is where ArmorIQ starts
ArmorIQ was built around the idea that agent control has to begin before execution.
Not because execution controls are unimportant, but because they are downstream from the place where behavior is constructed.
When an agent turns a request into a plan, that plan has to become a governable object. When the plan evolves, the evolution has to preserve continuity rather than becoming a new unaccountable branch. When the system delegates a task, the delegated authority has to remain bounded by the original scope. When the agent finally invokes a tool, that action has to prove it still belongs to the committed reasoning path.
This is the difference between controlling software after it exists and controlling the process by which software behavior comes into existence.
Intent-first systems need the second.
Otherwise, enterprises will end up with beautiful runtime logs for systems that were already misaligned before the first command ran.
The future will still have code
The phrase “the end of programming” is useful because it gets people’s attention.
But programming is not ending.
It is moving.
Some of it is moving upward, into intent, architecture, constraints, review, and system design. Some of it is moving downward, into generated code, generated workflows, generated tests, generated infrastructure changes, and agent-operated tools. The developer is not disappearing. The developer is being pushed into a stranger and more important role: defining the boundaries within which behavior may be constructed.
That role is more architectural than clerical.
It is less about typing every line and more about shaping the space of acceptable behavior.
This is where the Microsoft Build 2026 moment becomes interesting. The more capable the agent frameworks become, the more urgent the control problem becomes. Autonomous workflows, agent modes, natural-language app generation, multi-agent orchestration, edge runtimes: all of these make intent-first development more real. They also make it harder to pretend that code is still the only artifact worth governing.
Once intent becomes operational, intent has to be secured.
Not as text.
As lineage.
As authority.
As refinement.
As proof that the system remained inside the task it was asked to perform.
The question changes
For most of computing history, when software did something surprising, we asked a familiar question.
What code caused this?
That question is not going away.
But it is no longer enough.
In intent-first systems, the more important question appears earlier, before the code, before the command, before the tool call, before the observable effect.
What intent produced this behavior?
And once that question appears, the rest of the stack has to change around it.
