When Intelligence Becomes Programmable. Why agentic AI needs better change management.

The Pattern Behind Every Wave

Technological revolutions follow a familiar pattern. An enabling infrastructure appears, capability becomes democratized, network effects compound, applications cascade, and incumbents are disrupted. So I will dare to compare today’s Transformer-backed Generative AI, and the ecosystem growing around it through harnesses and agentic AI, with the revolutions that came before. History does not merely rhyme in technology. It compounds.

The Industrial Revolution multiplied human muscle. Personal computers made computing personal. Compilers made software expressive. The internet made information free to move. Distributed systems made scale reliable. Smartphones made the computer disappear into everyday life. Each wave brought excitement, skepticism and anxiety, and each became the foundation for the next.

So instead of only asking how powerful AI will become, I find a different question more interesting: what happens when intelligence becomes programmable, scalable, and increasingly inexpensive? Every major wave made a previously scarce capability cheaper, then more accessible, then easier to build upon.

The biggest impact of a technological revolution is not necessarily the technology itself. It is everything that gets built on top of it.

And we may still be very early in that story.

The Agent Can Generate the Code

Brilliant. And yet I still see many software engineers complaining about the quality of code generated by AI agents. That is often the first stage of grief: denial.

The real issue is rarely that an agent cannot write code. It is that teams ask an agent to write code before the team has made the decisions that make code correct, safe, maintainable and reviewable. AI has made implementation dramatically faster. But specifying intent, choosing an approach, resolving ambiguity, approving scope, verifying behavior and accepting accountability remain human-paced activities.

That is where the opportunity lies.

Productivity Runs on Confidence

Strip the topic down to what a team actually wants and you get one word: productivity. Not lines of code per day, but the ability to ship more of the right changes without breaking what already works. Here is how I now frame the problem, as a chain of demands.

Productivity improvement demands adaptability. The models, tools, prompts and agent capabilities underneath us change every few months. A team that cannot change how it works as fast as they change is stuck with yesterday’s best practice, or adopts every new thing blindly.

Adaptability demands confidence. Nobody swaps a model, loosens a review step or lets an agent touch a shared code path unless they believe they will notice if it goes wrong, and can undo it. Without confidence, the rational move is to freeze, and freezing is the opposite of adapting.

Confidence demands control. Not control as in slower, but control as in knowing who decided, what the agent may do alone, and when it must stop and ask. Control is one of four inputs that together produce confidence.

Read it from the left. If you can see what happened and why (observability), try another approach cheaply and safely (experimentation), decide with names, limits and stop conditions (control), and prove the change does what was agreed (evidence), you get confidence. Confidence is what lets a team adapt without fear. Adaptability is what keeps productivity gains from decaying the moment the tooling shifts.

Speed is easy to buy. Confidence is what makes it repeatable.

The Missing Layer: Change Management

High-level SDLC diagrams are useful, but they do not tell an AI agent what “correct” means for this ticket, in this codebase, under these constraints. That is a different layer, and it is the one that is missing.

A change-management workflow is the part of that harness that supplies the four inputs. A note on the term: I mean it in the engineering sense of governing one change through its lifecycle, not the ITIL sense of organisation-wide change enablement. ITIL asks whether a change may enter production. This asks whether a change was decided, planned, built and verified as agreed.

Where Confidence Leaks

I went back through my team’s recent tickets, code reviews and review comments to see what kept going wrong with AI-assisted changes. This was a retrospective reading, not a counted sample, but the same ten gaps kept recurring. Mapped onto the four inputs, they stop looking like a random list and start looking like four leaks.

These are not model-quality problems alone. They are process and governance problems, and each one makes a team a little less willing to change anything.

When implementation becomes fast, the scarce asset becomes the record of why a change was made, by whose decision, and against which requirements.

A Tracker-Anchored Workflow

One practical approach is to treat a tracker ticket as the unit of governance. Each stage of the change produces a durable, structured record on the ticket. The next stage reads that record before proceeding. The agent does the mechanical work; humans make the decisions that require judgment.

Each of the four inputs has a home in this flow. The ticket itself is the observability: every stage posts a record anyone can read. Assess and an isolated workspace per ticket give experimentation: options are compared before one is chosen, and trials are cheap to set up and throw away. Confirm and the stop conditions are the control: a named person decides, a Critical question cannot be skipped, and commits and pushes wait for a human. Plan’s acceptance mapping and Verify’s conformance check are the evidence: the code is judged against what was agreed before it is judged on how it was written.

Where this stands

I want to be direct about the evidence. I have run this workflow end to end on bunch of tickets, while some are in progress, as its author. There are no measurable results yet, so what follows is a plan, not an evaluation. I would pilot it on a few live tickets and read four numbers from the tracker: rework cycles per ticket, review rounds before approval, deferred items that reach a tracker versus those rediscovered later, and elapsed time from assessment to a pushed change. If review rounds and rework do not rise and every deferral has a ticket, continue. If deciders find the confirmation step slower than the conversation it replaces, stop and revise.

Why This Matters

This is not bureaucracy for its own sake. It is how teams convert AI speed into reliable engineering throughput. Look at the same team, with and without a shared record.

That last row is the one I care about most as a builder. A chat history is a lossy, private, perishable thing. A ticket is none of those.

The Shift in the Engineer’s Job

The engineer’s job does not disappear. It moves up the abstraction ladder. Instead of spending most of their time translating intent into syntax, engineers increasingly spend it defining the problem precisely, identifying constraints and risks, comparing approaches, making and recording decisions, designing verification, reviewing evidence rather than just diffs, and owning the outcome.

In other words, the engineer becomes the designer and governor of the system that produces software, not merely the author of every line.

What Will Become Obsolete

Some specific tools, prompts, workflows and agent capabilities will certainly become obsolete. That is normal. Compilers improved. Frameworks changed. Cloud platforms evolved. Mobile ecosystems matured. The underlying capability persisted and became the foundation for the next layer.

This is where the chain earns its keep. A team with observability, experimentation, control and evidence can replace a model, a harness or a whole tool next quarter and know within days whether it helped. A team without them can only hope. The durable ideas are likely to be explicit intent, recorded decisions, named accountability, verification before review, guardrails around autonomous action, and a shared, queryable record of why software changed. The exact implementation may change. The need for it will not.

The Takeaway

Agentic AI can generate code. That is no longer the hard part. The hard part is ensuring the code represents a decision a responsible human actually made, against requirements that were understood, with assumptions that were examined, and with evidence that the result behaves as intended. That is the work of change management, and it is what turns a one-time speed-up into lasting productivity.

In an era when intelligence becomes programmable, scalable and inexpensive, the teams that win will not simply be the ones that generate the most code.