We have been here before.
When DevOps arrived, a lot of time was spent talking about tools. Jenkins or Bamboo. Puppet or Chef. People drew diagrams of their pipelines and called it a strategy. They were wrong, but productively wrong. At least they were trying to automate something, and it made things better. A bit.
The second argument was more sophisticated. It was about the shape of the pipeline itself. How many stages. Where to gate. Shift left. Continuous deployment versus continuous delivery. This felt like real thinking. It was still solving the visible problem rather than the important one.
In the DevOps transformations I saw work, the decisive shift was not the pipeline. It was developers taking responsibility for what they deployed. That meant tearing down the wall between the people who wrote the code and the people who ran it. The tools were downstream of that insight. The pipeline was simply a means to achieve the outcome. The Jenkins debate was distracting us from the change that actually mattered.
Agile followed the same script. First came the tool debate: Jira, VersionOne or Rally. Then the framework debate: Scrum, SAFe, Kanban or a bespoke playbook. Meanwhile, the people who understood the change were talking about feedback loops, cost of delay and what it really meant to collaborate with a customer.
Now we are doing it again.
Today, the conversation usually starts with models: GPT, Claude or Gemini. This is the Jenkins debate.
From there, it moves to orchestration and architecture: LangChain or LlamaIndex, multi-agent or single-agent, a common workbench or multiple platforms. This is the CD pipeline debate.
The harder question is how we learn to work with systems we cannot fully understand. It requires knowing when to constrain an agent and when to give it room. It is the difference between telling an agent to “review the program plan” and deciding what information it can use, what evidence it must show, when it should stop and when a human needs to step in.
Tooling and vendor selection are only the surface. The real challenge is building this as an organisational capability. Very few organisations know how to develop that capability, govern it and make it repeatable.
And just as with Agile and DevOps, the implications are not the same for everyone. What this means for an engineer is not what it means for an architect. What it means for a tester is not what it means for an executive. Both movements reshaped every one of those roles. We spent years working out what that meant in practice, and we got plenty wrong along the way. AI will do the same. In most organisations, that conversation has barely moved beyond engineering and productivity use cases.
That is the AI Jenkins moment. We are arguing about the tool while a new craft is being invented.
Too few organisations are helping people develop the skills that craft requires: curation, architectural judgement, leading hybrid human-agent teams and working with non-deterministic systems.
I have developed a leadership programme that I am excited to pilot internally in the coming weeks. It is one attempt to move the conversation beyond tools and start building that capability. The tools will change. The capability is what will remain.
Not A Factory Anymore 
You are of course absolutely right. One of the challenges with all of these is understanding the model, and in particular how the tools fit into the model. If we think the tool is the model – a message that the tool vendors would promote – it is sadly lacking the overall perspective of the capability required. When I first joined Accenture (a very long time ago) the People+Process+Technology seemed obvious and intuitive – but unfortunately rare.
The particular challenge with AI is that it’s more than a tool – it moves from automation of cognitive-routine work to the potential of cognitive-non-routine work – something that humans have traditionally done. But the way AI works is not like a human – and this difference in the way intelligence is framed is important. For example the effort to replace humans with autonomous agents is I believe flawed – the AI can absolutely do things autonomously but that work needs to be confined to the tasks that it is actually good at. And this requires an entire transformation of the model.
AI is very capable at general knowledge, summarisation, and writing new content (like code) from an initial concept. What it lacks is detailed context – it knows a lot, and it can apply itself to a narrow context; but if the context is broad it risks losing track, hallucinations, and skipping details. This is a feature not a bug – the answer is not a bigger and bigger context window and bigger parameter model. The answer is to understand the way AI works, and then complement it with other capabilities (other tools, people, process) to actually create a model that is better.
This is our challenge – AI will transform everything – but it needs to be built into capability models, and not implemented as the only answer to everything.
LikeLike
You are of course absolutely right. One of the challenges with all of these is understanding the model, and in particular how the tools fit into the model. If we think the tool is the model – a message that the tool vendors would promote – it is sadly lacking the overall perspective of the capability required. When I first joined Accenture (a very long time ago) the People+Process+Technology seemed obvious and intuitive – but unfortunately rare.
The particular challenge with Al is that it’s more than a tool – it moves from automation of cognitive-routine work to the potential of cognitive-non-routine work – something that humans have traditionally done. But the way Al works is not like a human – and this difference in the way intelligence is framed is important. For example the effort to replace humans with autonomous agents is I believe flawed – the Al can absolutely do things autonomously but that work needs to be confined to the tasks that it is actually good at. And this requires an entire transformation of the model.
Al is very capable at general knowledge, summarisation, and writing new content (like code) from an initial concept. What it lacks is detailed context – it knows a lot, and it can apply itself to a narrow context; but if the context is broad it risks losing track, hallucinations, and skipping details. This is a feature not a bug – the answer is not a bigger and bigger context window and bigger parameter model. The answer is to understand the way Al works, and then complement it with other capabilities (other tools, people, process) to actually create a model that is better.
This is our challenge – Al will transform everything – but it needs to be built into capability models, and not implemented as the only answer to everything.
LikeLike