The premise
DevOps in 2026 is a discipline with a peculiar status. Almost every engineering team claims to do it. A much smaller number actually have the operational properties the term originally promised: short lead times, low change-failure rate, fast recovery from incidents, and a culture where deployment is not a quarterly event.
The gap between the two has widened with the arrival of AI-using products. The deployment cadence that supported a CRUD application breaks down when the product has a model-served endpoint that can drift, degrade, or get rate-limited by an upstream provider. The DevOps that worked is no longer enough.
This article is about what the operational layer actually has to deliver for products that ship AI features, and how AI itself changes the DevOps work.
Two factors stretched the operational layer at once
Cadence and surface area both grew. The DevOps that was sufficient stopped being so.
The first factor is cadence. AI-assisted engineering compressed the time between writing a change and being ready to ship it. Teams that took a week to land a non-trivial change now land it in a day. The pipeline that gated the slower cadence becomes the bottleneck for the new one.
The second factor is surface area. AI features add upstream dependencies (model providers, retrieval systems, vector stores, evaluation harnesses) that did not exist in a classical web application. Each of them can fail in ways the rest of the application has to handle gracefully. The operational layer has to know about all of them.
Together, these two factors pushed DevOps from a back-office discipline back into the centre of engineering. Teams that did not invest accordingly produce more outages with worse blast radius. Teams that did, ship more, faster, with calmer incident response.
Pipelines, infrastructure-as-code, observability, response
At SDEN, the operational layer is built around four practices. Pipelines: every change builds, tests, and deploys through the same machinery, with no manual steps that depend on someone's laptop. Infrastructure as code: every environment is reproducible from the repository, including the secret structure (not the secret values). Observability: metrics, logs, and traces from every component, with dashboards owned by the team that owns the component. Incident response: written runbooks, an on-call rotation that is humane, and post-incident reviews that produce actual changes.
These four are the floor. They are also where most stalled engagements turn out to have gaps, usually in observability and incident response, because pipelines and IaC are visible while the other two only become visible during outages.
Operational properties an AI product cannot ship without
A product that depends on a model in production needs operational properties a classical web product can skip. Provider redundancy: at least two model providers wired through a thin abstraction, with the ability to fail over in seconds. Output evaluation in production: a sampled, automated check that the model is still producing acceptable output, with alerts when quality drifts. Cost circuit breakers: hard limits that throttle or disable AI features when the bill is heading in a direction the business has not agreed to. And rollback that includes the prompt: not just code, but the prompt, the retrieval index, and the evaluation suite, all versioned together.
None of this is exotic. It is the operational discipline equivalent of using a seatbelt. The cost of skipping it is the kind of incident that becomes a post-mortem nobody wants to write.
How AI changes the DevOps work itself
AI is now visible inside the operational layer, not just downstream of it. Four shifts in 2026 production stacks.
An on-call engineer reads an alert, opens a runbook, follows the steps, and spends the next forty minutes correlating logs across three services to find the root cause.
A first-pass triage assistant correlates the logs, proposes the three most likely causes, and points the engineer at the screens that will confirm or refute each one. The engineer still owns the fix.
Takeaway · Mean time to diagnosis drops. The hard part, the decision, stays human.
Post-incident reviews are written by the engineer who handled the incident, in the day after, when memory is freshest and bandwidth is lowest.
A structured draft of the timeline, the actions taken, and the contributing factors is assembled from the chat logs and the change history. The engineer edits and signs off.
Takeaway · Post-incident review quality goes up because the writing tax goes down.
Capacity planning for the holiday season is an annual ritual based on last year's traffic and a hand-built spreadsheet.
A forecast model trained on the actual traffic history proposes a capacity plan, including the AI-cost projections. The platform team reviews and adjusts.
Takeaway · Capacity planning compresses from weeks to days, with more honest uncertainty bounds.
A configuration change pushed to production breaks a downstream service, and the rollback takes an hour because nobody remembers which knob was turned.
Every change to the configuration is versioned, reviewed, and reversible in one command. The rollback takes the time of one deploy.
Takeaway · AI did not deliver this; version control did. But AI made the documentation around it cheap.
Three defaults that decide whether a team can ship calmly
These are the practices we install on every engagement. They are not negotiable: skipping them produces the incidents we then have to clean up.
One pipeline, no manual steps
Every change goes through the same pipeline: build, test, security check, deploy. There is no manual step that depends on a specific engineer's laptop, account, or memory.
Observability owned by the team
Dashboards, alerts, and runbooks are owned by the team that owns the code. Observability is not a separate function; it is part of the engineering work.
Humane on-call
On-call rotations are sized so that an engineer is not on call for more than one week in five. Pages are sized so that an on-call engineer can sleep. If the system cannot deliver this, the system is fixed, not the rotation.
A team that ships every day and sleeps every night
Operational maturity is felt as boredom, and boredom, in this discipline, is the goal.
A mature operational layer changes the rhythm of the engineering team. Deployments are not events. Incidents are rare, contained, and produce learning instead of trauma. The on-call engineer goes a week without being paged. The team ships small changes constantly, because small changes are safe and large changes are not.
When this is working, it is invisible. The honest test is what the engineers say about the on-call rotation. If they describe it as humane, the operational layer is healthy. If they describe it as anything else, there is work to do.
When SDEN finishes a DevOps engagement, the deliverable is not a Kubernetes manifest. It is a team that can run the system without us, and that wants to.
DevOps & Automation:
questions we get asked.
Direct answers to the questions we get asked the most. If yours isn't covered, write to the team.