Most AI Adoption Programmes Are a Licence Rollout With a Press Release Attached
A recruiter put it to me last week better than I would have. Plenty of organisations tell him they have adopted AI in engineering; what they have done is buy Copilot or Claude licences for their developers. That is procurement, not adoption.
I have been building production GenAI systems this year and talking to a lot of engineering leaders while doing it. The same pattern keeps appearing. The tooling works; code generation is genuinely fast; nobody has written down where the boundaries are. So I wrote them down.
The constraint is verification, not generation
Start with what changed. Generation got cheap; verification did not.
A developer with an agent can produce in an afternoon what used to take a week. Reviewing, testing and judging that output still runs at human speed. The queue moves from the writing to the checking, and review quality degrades quietly under the load; nobody announces that they have started skimming.
That is not a model quality problem. It is an operating model problem, and the answer is a decision about where machines act, where humans decide, and how you know which is which.
Protected surfaces
The centre of the framework is a simple move: name the parts of your estate where human ownership is mandatory, regardless of how good the tooling gets. I call them protected surfaces. Agents can propose changes there. They do not get to decide.
My working set:
- Identity and access. Anything that grants or widens access to anything.
- Architecture. System boundaries, integration contracts, data models, technology choices.
- Contracts and commitments. Public APIs, partner interfaces, SLAs, licence obligations; anything you are legally bound by.
- Customer and regulated data. Schemas, pipelines, retention, residency, and any code path touching personal data.
- Agent identity and credentials. Agents are identities too; each needs least privilege, short-lived credentials, an explicit list of what it can reach, a full action trace, and a way to kill it. An over-permissioned agent is an insider risk wearing a productivity badge.
- The harness itself. Permission rules, sandbox policy, MCP allowlists, hooks, model routing. This is where prompt injection and supply chain problems enter; changes to it deserve the same review as production changes, because that is what it is.
Every organisation adds its own; an airline protects anything near operations, a bank anything near settlement. Having that conversation explicitly, and writing the answer down, is worth more than any tool selection you will make this year.
The one that surprises people
The last protected surface is the interesting one: your tests and your CI gates.
The instinct is to treat tests as safe territory for agents; a test cannot take production down, so let the agent write as many as it likes. That is fine while a human reads every change. It stops being fine the moment you raise autonomy, because then green CI is the merge decision, and if the same agent writes both the code and the tests that validate it, the gate is checking the author’s own homework.
This is not theoretical. Agents write tests that assert what the code does rather than what it should do; faced with a failing test, an agent will sometimes amend the test rather than fix the code. You end up with excellent coverage numbers and very little verification.
Aviation solved this a long time ago. The engineer who performs the repair does not sign the aircraft back into service; a separately authorised person inspects the work and certifies it. Same principle here. Agents drafting tests is high value and should continue, but the specification of correct behaviour and the gate that enforces it need to be owned independently of whoever wrote the implementation: a human writing acceptance criteria, a second agent working from the spec without sight of the code, or ground-truth checks the author cannot influence.
Autonomy by risk, not by artifact
Once you have protected surfaces, autonomy stops being one organisational setting and becomes a grant made per class of work, on two variables: blast radius, and the strength of your independent verification.
Documentation, internal tooling and refactors under strong regression cover: high autonomy. Feature work on low-risk services: moderate, with independent acceptance gates. Anything touching a protected surface: the agent proposes, a named human decides.
The framing matters more than the specific levels. Grant autonomy by artifact type and your rules stop making sense at the edges; grant it by risk and verification strength and you can explain every decision you have made.
Advisory before enforcement
The mechanics here are not new, and that is the point. It is the method I used at Symantec to put a mandatory code quality and security review programme across an eight thousand person engineering organisation, and at Proactis to get security scanning and PCI compliance into the delivery pipeline. Instrument first; run the policies in advisory mode and publish what they would have blocked; let teams argue with the policy while it has no teeth; then enforce where the evidence supports it, a team at a time.
Engineers own controls they helped shape; they route around controls that arrive finished.
What it protects
There is a cultural argument buried in the structure, and it is the part I care most about. The anxiety in software right now is that experience is being devalued; that if the machine writes the code, the twenty-year engineer is a cost line.
The framework says the opposite, structurally rather than sentimentally. The protected surfaces are exactly where deep system knowledge is mandatory: architecture, the contracts, the data, the gates. Those people are not being automated around; they are the named owners of the surfaces everything else depends on. The failure mode nobody notices in time is an organisation that shipped faster every quarter while quietly losing the ability to tell whether what it shipped was right.
I have not run this end to end inside a large enterprise. Nobody has, whatever they claim; this is new ground for everyone. But the boundaries are the conversation to have first, and most organisations are still having the tooling conversation instead.