Ask a room full of technology professionals to define DevOps and you can still start an argument.
Is it a culture? A collection of engineering practices? An organizational model? Automation? A job description? Somewhere along the way, we managed to make it all of those things, depending on who was talking and what they were selling.
That ambiguity has been with DevOps almost from the beginning. It helped the movement travel across organizations with very different needs. It also allowed companies to rename an infrastructure team, buy some pipeline tools and declare the transformation complete.
Now PeopleCert and DevOps Institute have published The DevOps Standard, and the familiar questions have returned. Can you standardize something people still struggle to define? Does a movement need a standard? And what happens when that standard arrives just as AI agents are changing who, or what, does the work?
I have a connection to this discussion. I am the founder and editor-in-chief of DevOps.com and a co-founder of DevOps Institute. Readers should know that. Those connections are also why I believe the book deserves a careful reading and a fair assessment.
My colleagues Mitch Ashley and Vikram Rathnam raised important questions in their Futurum analysis, “Does a 17-Year-Old Movement Need a DevOps Standard?”. Marc Hornbeek, a contributor to the book, offered his perspective in his Oct 2, 2026 DevOps.com article, “The DevOps Standard Gives Teams a Shared Model for Software Delivery.”
Having reviewed the book, I believe there is value here. There are also questions its publishers should answer. But the fact that DevOps remains difficult to nail down is hardly a new objection. We should judge this effort by what it helps organizations accomplish.
A Shared Reference Can Be Useful
DevOps did not wait for a universally accepted definition before organizations started applying it.
Teams recognized that development and operations were working toward different incentives. Software moved slowly between groups. Security arrived late. Problems discovered in production took too long to reach the people who could prevent them. Automation accelerated some steps while leaving the organizational obstacles intact.
DevOps offered a way to address those problems. Its language and practices evolved through use.
A shared reference can help that process. It gives people a vocabulary for discussing ownership, feedback, delivery, reliability and improvement. It can help a leader distinguish a tooling problem from a funding problem, or an engineering weakness from an approval process nobody has revisited in years.
Hornbeek’s argument is that organizations need a model connecting these activities. DevOps Institute’s own explanation of the initiative makes a similar case for common language and adaptable practices.
That is a reasonable ambition. The danger comes when the reference becomes a prescribed organizational chart, a mandatory toolchain or a scoring exercise that rewards conformity.
The book generally recognizes that danger. Its nine pillars connect leadership and collaborative culture with design, integration, testing, infrastructure, security, delivery and observability. They provide a broad way to examine an organization’s capabilities. They do not require every organization to implement them in the same sequence.
Breadth is useful here. DevOps problems rarely respect departmental boundaries, and fixing the pipeline alone rarely fixes the delivery system.
Read What It Actually Says About AI
The book’s treatment of AI deserves more credit than a quick reading of its positioning might suggest.
It distinguishes advisory assistance, assisted work, bounded automation and high-impact actions. Those categories carry different expectations for authorization, evidence and human involvement.
It permits automatic deployment when appropriate controls pass. It discusses probabilistic testing, representative evaluation sets, drift, prompt injection, tool restrictions and least privilege. It recognizes that an overloaded human review process can quietly stop providing meaningful oversight.
Its measurement guidance tells organizations to count accepted, useful outcomes rather than generated output. It connects AI operating costs with quality, errors and escalation.
These are consequential distinctions.
A framework that required someone to approve every machine action would struggle as agent activity expanded. But that is not a fair description of this book. It already allows classes of bounded action to be authorized in advance and reviewed through their outcomes and exceptions.
There are areas where the guidance needs more precision. Assisted coding still places considerable weight on human artifact review. Organizations will need clearer criteria for deciding when stronger automated verification can support less direct intervention.
Even so, we should begin with the guidance that is present. AI is addressed throughout the operating model, engineering practices and measurement sections. The book is making a serious attempt to accommodate it.
“The Standard” Invites Questions About Authority
The title makes a substantial claim.
There is already an ISO/IEC/IEEE DevOps standard, 32675:2022. Its published scope covers collaboration and the full software lifecycle, including conception, development, production, support and retirement.
I did not find references to that standard or IEEE 2675 in the book’s text or bibliography. The omission deserves an explanation and, preferably, a mapping that helps practitioners understand the relationship.
Different standards can serve different purposes. A practical body of knowledge may be more accessible to many organizations than a formal requirements document. But readers should not have to work out the relationship themselves.
Authority also depends on stewardship. Who can propose a change? How are competing views considered? What evidence causes the model to be revised? How do practitioners know which guidance is current?
The book’s composite organizations help illustrate how its practices might work. They are useful teaching devices. They do not independently validate the maturity assessment or demonstrate that the nine-pillar model produces superior results.
That evidence can develop over time, but it should be identified as a task still to be done.
There is a commercial dimension as well. PeopleCert sells training, certification and membership. That does not invalidate the content. Commercial organizations have supported plenty of useful bodies of knowledge. It does make access, governance and incentives relevant questions.
The book says its complete assessment tools are available through PeopleCert Plus and can be updated independently of future book editions. That is an important provision. It means we should not assume the entire framework is trapped on a publication cycle.
Still, a certification can demonstrate that someone has learned a body of knowledge. It cannot establish that an organization delivers secure, reliable software effectively. The assessment and commercial model should preserve that distinction.
When Agents Become Ordinary Participants
The next test comes as AI agents become routine participants in software delivery.
By a post-AI market, I mean one in which AI is ordinary infrastructure. Organizations stop treating each use as a separate experiment and start designing work around the capabilities available.
That is an emerging condition, not a claim that fully autonomous delivery is universal today.
An assistant proposes an answer or drafts an artifact. An agent can pursue a goal, select actions, invoke tools, coordinate other agents and continue working across systems.
The enduring DevOps principles remain relevant. Ownership, feedback, security and reliable delivery still matter. What changes is how those responsibilities are exercised and enforced.
Consider a request to restore service availability. An agent may find several ways to accomplish it. Some could weaken access controls, discard data or create an unacceptable bill. A clear goal does not supply all the boundaries needed to pursue it safely.
Those boundaries must exist in the systems the agent uses. Permissions, spending limits, protected resources and termination conditions need enforcement beyond a written instruction.
Identity becomes more complicated too. If an agent delegates to another agent, whose authority does the second agent possess? Can that authority be reduced or revoked? Can the organization reconstruct which person authorized the work and which agents performed it?
Independent verification becomes essential. The book correctly warns that generated tests are not independent proof of generated code. Adding another agent to review the result does not automatically solve that problem. Both may share assumptions or overlook the same failure.
Acceptance criteria and protected checks need to remain meaningful even when the agent doing the work can also modify the test environment.
Current engineering experience demonstrates why these details matter. In its account of containing Claude across products, Anthropic describes approval fatigue, changing tool trust, persistent memory poisoning and challenges with agent identity. It also documents an incident in which an approved network destination still allowed data to leave through an unintended path.
The lesson is that permission must be specific enough to constrain what a system can actually do.
OWASP’s 2026 guidance for agentic applications provides another reference for threats that arise when systems can act and delegate.
A broad DevOps framework does not have to reproduce every technical security specification. It should establish responsibilities and connect organizations to the specialized guidance needed to carry them out.
Make the Frameworks Work Together
PeopleCert faces a related challenge across its portfolio.
Its ITIL 5 explanation describes an AI-native approach to digital product and service management, with a stronger focus on outcomes and the full lifecycle.
Those ambitions overlap with parts of the DevOps Standard. That can be useful if the relationship is clear.
Practitioners need to understand how business accountability, engineering execution, operational management and agent authority fit together. They should be able to use complementary frameworks without creating multiple approval structures for the same work.
The DORA AI capabilities model offers another useful comparison. Its emphasis on data, version control, small batches, user focus and internal platforms reinforces the importance of established delivery foundations.
There is an opportunity here to show how the pieces connect. Published mappings would help organizations apply the guidance they already use while identifying what additional controls agentic work requires.
Economics should be part of that integration. Cheap code generation does not necessarily mean cheap delivery. Agent usage, retries, evaluation, coordination, human review, rework and incidents all contribute to the cost of a successful outcome.
The book recognizes useful outcomes as the right direction for measurement. Its future guidance should help organizations make that calculation in practice.
Let Practice Establish Its Value
DevOps has always evolved through disagreement, experimentation and changing technology. A standard should participate in that process.
The DevOps Standard provides a substantial foundation. It brings organizational and engineering practices together, treats AI seriously and allows more flexibility than some criticism suggests.
Its publishers now have work to do: explain its relationship to existing standards, make its stewardship transparent, build evidence around its assessment model and show how broad principles translate into practical controls for agents.
As a DevOps Institute co-founder, I want this effort to be useful. As the founder and editor-in-chief of DevOps.com, I believe usefulness has to be demonstrated in the organizations doing the work.
We never needed everyone to agree on one definition before DevOps could improve software delivery. This book does not have to end that argument either.
It needs to help teams make better decisions, deliver more reliably and remain accountable as people and agents take on different parts of the job. Its standing as a standard will grow from that experience.
from DevOps.com https://ift.tt/X3fLFNj
Comments
Post a Comment