DevOps adoption rarely fails for technical reasons: it fails when an organisation hires a role instead of building a culture, buys tools before dealing with human problems, or automates without understanding. This guide lists 9 DevOps anti-patterns among the most common, with for each one the trap, why it fails and the concrete fix. It is for technical teams, tech leads and managers steering a DevOps adoption, including its most recent aspect: bringing generative AI into pipelines.
This lesson assumes you have the fundamentals of the module: What is DevOps? for the wall between Dev and Ops, and Three Ways and CALMS for the cultural pillars each anti-pattern contradicts.
What you will learn
- Identify the 9 most frequent DevOps anti-patterns, from magic hiring to blame after incidents
- Understand why each trap fails structurally, not just in theory
- Tell a real culture change from a cosmetic renaming (Platform Engineering, "DevOps" team)
- Apply the concrete fix for each anti-pattern in your organisation
- Diagnose your own exposure with a scored self-assessment checklist
1. The "DevOps Engineer" as a magic fix
Hiring is the quickest decision an organisation can make: a job description goes out in a day, whereas aligning development and operations takes months of work on processes. That is why this anti-pattern tops the list, and it can be recognised by a precise symptom: responsibility for production stays attached to one person instead of being carried by the team that writes the code.
The trap
"We need DevOps. Let's hire a DevOps Engineer!"
The organisation believes that by hiring someone with "DevOps" in their title, it will magically become DevOps. It is the first reflex seen in most failed transformations: treating a cultural change as a mere hiring problem.
Why it is a problem
DevOps is a culture of collaboration between development and operations, not a job. Creating an isolated "DevOps Engineer" role often recreates... a new silo.
What actually happens:
- The "DevOps Engineer" becomes an intermediary between Dev and Ops
- Developers ship a release and move on to the next ticket, without ever touching its operation
- There are now three silos instead of two
- The person is overloaded, a single point of failure
In 2026, this anti-pattern has taken a subtler form: renaming the DevOps team the "Platform Engineering team" without changing any interactions. Six months later, developers still file tickets to get an environment, and the team remains the bottleneck of every deployment. Only the name has changed. Platform Engineering is only a valid answer if it builds self-service paths (provisioning an environment without opening a ticket, shared and documented tooling) used by all teams, not one more queue.
The solution
Build DevOps skills into the existing teams rather than creating a separate role. The Team Topologies framework, which distinguishes four team types (stream-aligned, platform, enabling and complicated-subsystem), helps clarify where to place these roles without recreating a silo: a platform team serves the other teams in self-service, it does not become a mandatory checkpoint.
If you have "DevOps Engineers" or a Platform Engineering team, make sure they work with the teams, not for them. Their role should be to:
- Train and support the teams
- Build shared self-service tools
- Spread good practices
- Make themselves progressively unnecessary by making the teams autonomous
2. Tooling without culture
A tooling budget can be voted in a committee, a team culture cannot be bought. This anti-pattern is the most expensive of the nine: it consumes a real budget line without changing daily work. It shows up as a precise gap between the technical inventory, often impeccable, and the delivery indicators, which do not move from one quarter to the next.
The trap
"We bought Kubernetes, Jenkins, Terraform and Datadog. We're DevOps now!"
The organisation invests heavily in tools, thinking technology will solve everything. It is a comfortable shortcut: buying a tool is visible and measurable, changing human behaviour is slow and uncomfortable.
Why it is a problem
Tools without cultural change solve nothing. An organisation can tick every technical box and stay stuck with the same human dysfunctions.
You can have:
- A perfect CI/CD
- Kubernetes in production
- Impressive dashboards
And still have:
- Silos between teams
- A blame culture
- Stressful deployments
- Repeated incidents with no improvement
The solution
Start with culture, tools will follow naturally. The order in which an organisation tackles its transformation largely determines its success, well before the choice of the tools themselves.
| Wrong order | Right order |
|---|---|
| 1. Buy tools | 1. Identify the cultural problems |
| 2. Hope it changes behaviour | 2. Work on collaboration |
| 3. Be surprised nothing changes | 3. Choose the tools that support the culture |
| 4. Buy more tools | 4. Iterate and improve continuously |
Questions to ask before buying a tool:
- Which human or cultural problem does this tool solve?
- Are the teams ready to use it?
- Who will maintain it?
- How do we measure its success?
3. Automating without understanding
A pipeline nobody understands works perfectly until the day it stops. The cost of this anti-pattern only shows at incident time, when someone must change a configuration nobody wrote line by line. The arrival of generative AI assistants did not create the problem: it multiplied the volume of configuration produced without review.
The trap
Building complex pipelines by copy-pasting from Stack Overflow, a tutorial, or now a generative AI assistant.
"It works, I'm not quite sure how, but it works."
This trap is not new, but it has changed scale. The practice of vibe coding (generating code from a natural-language prompt, popularised in 2025) has made producing configuration and scripts faster than ever, at the cost of an often superficial understanding.
Why it is a problem
When the pipeline breaks, and it will, nobody knows how to fix it. The DORA 2025 report measures the gap at scale: 90 % of respondents use AI in their work, but 30 % report little or no trust in the code it generates. Code that is used without being trusted is all the more dangerous because it is not always reviewed before being merged. Generated code inherits the same flaws as sloppy human code: unvalidated configurations, plain-text secrets, unpinned dependencies.
Consequences:
- Very long resolution times during incidents
- Fear of touching the pipeline ("we don't know what it does")
- A build-up of invisible technical debt, now generated faster than before
- Dependence on specific people or, worse, on a prompt history nobody can replay
The solution
The fix is not to ban code generation, but to apply exactly the same requirements as to a human contribution: review before merging, a comment explaining the intent, and at least two people able to maintain the result. The two lists below contrast the reflexes to build and the ones to drop.
- Understand every line of configuration, written by a human or an AI
- Document the why, not just the how
- Simplify: if nobody understands it, it is too complex
- Train several people on each part
- Systematically review any AI-generated code or pipeline before merging
- Copy-pasting without understanding, human or AI
- Merging generated code without a security review
- A single expert per area
- "If it works, don't touch it"
- Cryptic configuration with no comments
Rule of thumb: if you cannot explain your pipeline to a new team member in 30 minutes, it is too complex, whether it was written by a human or generated by an AI assistant.
4. Measuring without acting
Plugging in a metric takes a few hours of integration; deciding what to do with it involves a whole team. Many organisations therefore stop at the first half of the work and confuse visibility with steering. The test is simple: ask which concrete decision was taken over the last three months based on an indicator shown on a dashboard.
The trap
Dashboards everywhere, impressive metrics, but no action.
"Our lead time is 3 weeks." "And what are we doing to reduce it?" "... We measure it."
Why it is a problem
Metrics are not an end in themselves. A measurement that triggers no decision changes nothing in the observed system: it is collected, displayed, then forgotten, and its only effect is to reassure about steering that is not happening.
Symptoms:
- Dashboards nobody looks at after the first week
- "Metrics review" meetings with no decisions
- Metrics chosen because they are easy to collect
- Flattering but useless vanity metrics
The solution
For each metric, define a goal, an alert threshold, an action and an owner. The DORA metrics (DevOps Research and Assessment, the research team behind these indicators) and observability practices are useless if they trigger no decision.
- The goal: what is the target?
- The alert threshold: from when do we act?
- The action: what do we do if the threshold is crossed?
- The owner: who decides?
| Metric | Goal | Threshold | Action | Owner |
|---|---|---|---|---|
| Lead time | < 1 day | > 3 days | Analyse the blockers | Tech Lead |
| Deployment frequency | 1/day | < 1/week | Pipeline review | Team |
| Change failure rate | < 15 % | > 30 % | Strengthen tests | QA Lead |
| MTTR | < 1 h | > 4 h | Mandatory postmortem | SRE |
5. Blame after incidents
This anti-pattern is the most destructive of the nine because it acts on the available information: an organisation that punishes mistakes stops learning what really happened during the outage. Following incidents are then handled with an incomplete timeline, which mechanically lengthens the time to restore. No tooling makes up for this loss.
The trap
"Who made this mistake?" after every incident.
The organisation looks for a culprit rather than understanding the system. This reflex is human, but it destroys exactly the behaviours a team needs to progress.
Why it is a problem
Pointing to an individual gives a quick and wrong answer. In a system involving several people, tools and procedures, an isolated action is almost never enough to cause a major outage: no safeguard must have stopped it. The effects of blame then add up across the whole team.
- People hide their mistakes for fear of the consequences
- The real systemic problems are never addressed
- Innovation is killed: who takes risks if failure is punished?
- The same mistakes repeat: the individual is punished, not the system
The solution
Blameless postmortems, documented in detail in the Incidents and postmortems lesson.
| Blame culture | Learning culture |
|---|---|
| "Who did this?" | "How did the system allow this?" |
| Look for a culprit | Look for systemic causes |
| Punish the mistake | Fix the process |
| Hide problems | Report quickly |
| Avoid risks | Experiment with safeguards |
Structure of a blameless postmortem:
- Timeline: what happened? (facts, not judgements)
- Impact: what were the consequences?
- Causes: why did it happen? (technical, process, communication)
- Actions: how do we avoid it happening again?
- Follow-up: who does what, by when?
6. The "Big Bang" DevOps
Changing several things at once makes it impossible to attribute a result to a cause: if delivery degrades, nothing tells whether the new pipeline, the orchestrator or the move to microservices is responsible. This anti-pattern therefore destroys the feedback loop that all continuous improvement depends on. It almost always stems from a schedule commitment made to management before any technical study.
The trap
"We'll transform everything in 6 months. New CI/CD, Kubernetes, microservices, everything!"
The organisation wants to change everything at once, attracted by the idea of a fast, total transformation.
Why it is a problem
A total transformation removes the point of comparison: no team works the old way any more, so nothing can demonstrate that the new way is better. Difficulties then pile up on every front at once.
- Too many simultaneous changes multiply the risks
- The learning curve becomes insurmountable for the teams
- No fast feedback on what really works
- A global failure if a single part fails
- Resistance to change reaches its peak
The solution
Incremental transformation with quick wins. Each step must produce a measurable result before moving on to the next one, which ties directly into the principles of the value stream.
Recommended strategy:
- Choose a low-risk pilot project
- Implement one improvement at a time
- Measure the result before continuing
- Document the learning
- Extend progressively to the other projects
7. Ignoring technical debt
Technical debt triggers no alert: it is paid in slowness, a little with every change to the affected code. Since no incident makes it urgent, it systematically loses the trade-off against a new feature, year after year. The moment it finally becomes visible is also when it is most expensive to pay back.
The trap
"We'll refactor when we have the time. For now, let's ship features."
Technical debt (the hidden cost of shortcuts taken to ship faster) builds up until it becomes insurmountable, often without anyone noticing until it is too late.
Why it is a problem
The effect of debt is cumulative, not one-off: each shortcut makes all later developments touching the same code area more expensive. A year on, the team is still working, but it delivers much less for the same effort.
Technical debt:
- Slows down every new feature
- Weakens the system, with more bugs
- Frustrates developers faced with code that is hard to change
- Increases the risk of incidents
- Costs more and more to pay back over time
The solution
Build debt repayment into daily work rather than turning it into a separate project that keeps being postponed.
| Approach | Problem | Alternative |
|---|---|---|
| "Debt sprint" | Never prioritised | Allocate 20 % of the time continuously |
| "We'll see afterwards" | Build-up | Boy Scout rule: leave the code cleaner |
| "No time" | Progressive slowdown | Measure the cost of the debt |
8. Disguised silos
This anti-pattern is the hardest to detect from the inside, because the org chart shows exactly what is expected of a DevOps organisation. The diagnosis therefore does not look at team names but at the real workflows: who opens a ticket to whom, and how long that ticket waits before being handled.
The trap
Renaming the Ops team the "DevOps team", or more recently the "Platform Team", without changing the interactions between teams.
"We merged Dev and Ops... by creating a separate DevOps team."
Why it is a problem
The silo still exists, it just has a new name on the org chart.
Signs of a disguised silo:
- The "DevOps" team receives tickets from developers
- Developers never see production
- "Not my job" is still common
- Team goals remain contradictory
The solution
Clarify who does what with a framework such as Team Topologies, which explicitly distinguishes a stream-aligned team, which delivers and runs its service, from a platform team, which serves the others in self-service to reduce their cognitive load.
| Disguised silo | Real DevOps |
|---|---|
| Separate "DevOps" team | Skills built into each team |
| Tickets between teams | Direct collaboration |
| Separate responsibilities | Shared responsibility |
| Contradictory goals | Goals aligned on customer value |
9. Waiting for AI to make up for missing DevOps foundations
This is the most recent anti-pattern, and its effects are already measured at scale. It is not about refusing generative AI, but about recognising that it increases the throughput of code production without touching the causes that stop this code from reaching production: fragile tests, manual approvals, unavailable environments. Organisations that adopt it without dealing with the previous eight points mostly see an increase in rework.
The trap
"We rolled out Copilot and AI agents everywhere. Productivity is going to take off."
The organisation invests in generative AI tools to speed up development, without first having solved its culture, testing or technical debt problems.
Why it is a problem
The DORA 2025 report on AI-assisted development (Google Cloud DORA, published in 2025, based on nearly 5,000 professionals surveyed) makes a clear finding: AI amplifies what already exists. It speeds up teams that already have good foundations, reliable tests, a collaborative culture, an understood pipeline, and it worsens the situation of struggling teams: more rework, more failed changes, longer resolution cycles. Adopting AI without solid foundations therefore increases the volume of code produced for a delivery chain that already cannot absorb what it receives.
Warning signs:
- AI is seen as a substitute for solving cultural problems, not as an amplifier
- No systematic review of generated code or configurations before merging
- Struggling teams get "more AI" instead of support on the fundamentals
- No indicator distinguishes throughput (features shipped) from stability (incidents, rollbacks)
The solution
Treat AI like any other tool: it follows the culture, it does not replace it. Before rolling out a generative AI assistant to the whole team, check that the basics are in place: solid version control, reliable automated tests, working in small batches, and a team that already understands its pipeline (anti-pattern no. 3). The DORA metrics remain the best instrument to check that AI really speeds up delivery without degrading stability, rather than relying on a subjective impression of productivity.
Checklist: how many DevOps anti-patterns do you have?
This checklist does not replace a full audit, but it helps quickly spot the risk areas before going further with a dedicated tool such as the DevSecOps maturity and roadmap lesson. Answer each question honestly.
| Question | Yes = warning |
|---|---|
| Do you have a separate "DevOps" or "Platform" team that remains a bottleneck? | Anti-pattern 1 |
| Were the tools chosen before the problems were defined? | Anti-pattern 2 |
| Is there code or configuration, human or AI-generated, that nobody understands? | Anti-pattern 3 |
| Do you have dashboards nobody looks at? | Anti-pattern 4 |
| Do you look for a culprit after incidents? | Anti-pattern 5 |
| Are you planning a "Big Bang" transformation? | Anti-pattern 6 |
| Is technical debt ignored? | Anti-pattern 7 |
| Do teams still pass tickets to each other despite a recent renaming? | Anti-pattern 8 |
| Are you rolling out AI assistants without having dealt with the points above? | Anti-pattern 9 |
Score:
- 0-2: on the right track
- 3-6: attention required
- 7-9: transformation to rethink
Key points
-
DevOps is a culture, not a job: hiring a "DevOps Engineer" or renaming a team "Platform Engineering" without changing anything recreates a silo
-
Tools follow culture: not the other way round
-
Understand before automating: copy-paste, human or AI-generated, creates invisible debt
-
Measure to act: a metric with no action is useless
-
No blame: mistakes are opportunities for systemic learning
-
Progressive rather than Big Bang: small improvements, fast feedback
-
Technical debt is real debt: it must be paid back, not postponed
-
AI amplifies what exists: it speeds up teams with good DevOps foundations and worsens those without, according to the DORA 2025 report
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Where to place DevOps roles in Team Topologies?
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below come up most often at the start of a DevOps transformation, especially about the boundary between a role, a team and a shared culture.