Developers Used to Write Logic. Now They Write Intent.

Most conversations about AI and software stop at the wrong place. They talk about speed, about how much faster you can ship, how many lines you can generate per hour. That's real, but it's the least interesting part of what's happening.

The actual change is deeper. It's moving through four stages, and each one shifts not just the velocity of development but its fundamental nature.

Stage 1: The Baseline

Human writes the code. App runs deterministically.

This is how software has worked for decades. A developer translates business logic into explicit instructions. If a user clicks this button, call this function, return this value. The machine does exactly what it's told, every time. You can trace any output back to a specific line of code someone wrote.

Testing is straightforward. Debugging is painful but tractable. The system does nothing you didn't tell it to do.

Stage 2: AI-Assisted Development

Humans code faster. The deployed app is still traditional.

GitHub Copilot, Cursor, Claude in your IDE. These tools make the developer more productive. You describe what you want, the model suggests the implementation. You write a comment, it fills in the function.

But here's what most people miss: the output hasn't changed. The app you deploy is still deterministic. The AI helped you get there faster, but what's running in production is the same class of system it always was. A Rails app is still a Rails app whether you wrote it yourself or had Copilot fill in the blanks.

This stage is genuinely valuable. But it's a productivity story, not an architecture story.

Stage 3: The Shift

LLMs become decision makers. Non-deterministic behavior enters the system.

This is where things get structurally different. The developer is no longer writing logic. They're writing intent. You describe what the system should accomplish, and the model figures out how to get there at runtime.

A support bot that decides whether to escalate or resolve. An infrastructure agent that reads your environment and proposes a remediation plan. A data pipeline that interprets ambiguous inputs and chooses how to handle them. In all these cases, the LLM isn't helping you write code. It's making decisions that would have been hardcoded before.

The implications are real. You can no longer fully predict the output from the input. Traditional unit tests don't cut it because you can't enumerate all possible model responses. The system's behavior is now a distribution, not a function. You need evaluation frameworks, not just test suites.

This shift is already in production. If you've built any AI-native feature in the last two years, you've crossed this line whether you named it or not.

Stage 4: The Destination

Autonomous agents apply reason. No human in the loop.

The endpoint of this progression is a system that can act on its own. Not just respond to a request, but observe a situation, reason about it, and take action. Read the production logs. Identify the anomaly. Draft the fix. Test it. Deploy it. Notify the team.

The developer's job in this world isn't to write the logic or define the steps. It's to define the goal, the constraints, and the guardrails.

We're not fully there yet. Today's agents are reliable on narrow, well-defined tasks and unreliable on anything requiring sustained judgment across complex state. But the trajectory is clear, and the systems being built now are the infrastructure for that destination.

The Part Nobody Is Talking About: The Security Model Breaks

Here's what most of these conversations skip. When you move from Stage 2 to Stage 3, your entire security model stops working. Most organizations haven't noticed yet.

Traditional IAM was built around one assumption: a human is behind every action. OAuth tokens, RBAC, SAML assertions. They all trace back to a person who logged in. But when an AI agent calls an API, who is the principal? When that agent spawns a sub-agent that calls a different API, what governs the chain of trust?

Most teams handle this one of two ways, and both are inadequate. Either they embed static API keys in agent configurations, giving the agent broad context-free permissions, or they pass the user's session token through, which means the agent inherits full human-level scope regardless of what the task actually requires.

Neither approach answers the real questions. What is this agent trying to accomplish right now? Is it allowed to take this specific action in this specific context? And when something goes wrong, can you prove what happened and why it was permitted?

This is the governance gap Stage 3 creates. Stage 4 makes it existential.

Broadcom built AgentMinder to close that gap. Verifiable agent identities, mission-bound policies that travel with the agent through multi-agent delegation chains, and compliance-grade audit trails at enterprise scale. I covered the architecture in detail in a separate piece, worth reading if you're building anything in Stage 3 or planning for Stage 4.

The point here is simpler: governance isn't a feature you add later. Once agents are making decisions and taking actions on their own, the accountability question stops being theoretical.

What This Means If You're Building Today

The developers who matter in Stage 4 aren't the ones who write the most code. They're the ones who can define intent precisely, evaluate non-deterministic outputs rigorously, and design systems that fail gracefully when the agent gets it wrong.

The skill set is shifting. From implementation to architecture. From logic to constraints. From testing to evaluation. From access control to agent governance.

If you're still in Stage 1 or 2, the time to get comfortable with Stage 3 thinking is now. Not because it's coming eventually, but because some of your competitors are already there.