devwhateverops.com / manifesto
Breaking things carefully is how you go faster.
A set of principles for engineers who build end to end, written as the AI hype begins to settle.
Dev, Ops, Sec, AI, whatever. One loop, one team. Fear of breaking things is the real bottleneck, and this manifesto is about building the kind of system where that fear has nowhere to live.
Culture
Own the full loop. No gates, no handoffs, no role hiding.
DevOps was never a role. It was a direction. Every “-Ops” suffix we invented since, SecOps, AIOps, DocOps, FinOps, was an attempt to name a culture shift. Most of the time it became a job title instead: a new silo built to solve the problem of silos.
The baseline for any engineer is understanding the full system they work in: how their code is tested, how it is deployed, how it behaves in production, and what happens when it breaks. Specialisation on top of that foundation is a multiplier. Specialisation instead of it is a liability.
End-to-end ownership is not a senior bar. It is the entry bar. Hiring should reflect that. Can you write it, test it, pipeline it, deploy it, instrument it, and close the loop with metrics and observability? Are you ready for partial rollout, A/B tests and gradual promotion to full deployment? That is the question, for any engineer at any level.
Pipeline
Automate everything. Smooth is fast, fast is smooth.
Automation removes every ceiling on how fast and safely people can move. Every manual step in a pipeline is a speed limit. Every approval gate that exists because nobody automated the check is a tax on momentum.
Requirements, specifications and architectural decisions (RFCs, PRDs, ADRs) are first-class inputs. Code, tests and pipeline stages should be able to reference them, trace back to them and validate against them. The loop from specification to deployment to observation should be closed, instead of scattered across tools and folders nobody reads.
CD over CI. The real signal comes after deployment.
Smaller deployments, early metrics, real user behaviour. You build confidence in a pipeline by shipping smaller and observing more.
Ops must be invisible. It matters too much to depend on human intervention. Smooth is fast. Fast is smooth.
Experiments
Every change is a hypothesis. Ship small, observe, decide.
It is okay to break things. That is why we have controlled rollouts.
The fastest engineering teams break things more often than slow ones. They aren't reckless. They built systems where breaking things is safe, observable and cheap. A/B testing and gradual rollouts are permission structures as much as risk management. They change what “safe to ship” means.
An experiment is an experiment whatever you are changing. A new UI button observed against click behaviour. A copy change measured against conversion. An AI model swap validated against a baseline dataset. A feature rolled out to five percent of traffic. The discipline is identical: hypothesis, controlled change, observation, decision. The tooling varies. The culture does not.
Evaluation, dataset versioning, experiment tracking and baseline comparisons are what CI/CD looks like when your system has a probabilistic component. AIOps is a variation on the theme. Old quality is still there: static analysis, dependency scanning, test coverage, security in the pipeline. AI evaluation is the new layer on top, and it needs that foundation.
Why most teams aren't here yet
The cost of fragmentation is invisible.
Nobody budgets for the deployment that required three teams and a ticket. Nobody measures the speed lost to a gate that exists because the test was never automated. The real cost of the current way of working is consistently underestimated, so the investment needed to change it is consistently underfunded.
Beyond cost, most organisations have people with rational reasons to resist this direction. Specialists who built careers inside a narrow lane. Managers who built teams around a function. Change that threatens identity moves slowly. And automation costs now but pays later, which is the wrong shape for most quarterly plans.
These are not excuses. They are the terrain.
From here
This is not a new movement. It is the original one, still completing itself.
The principles here are intended to age well. The specific articles, tools and examples will evolve, and that is the point. This page is the anchor. Everything else is the elaboration.
If you build end to end, you are already here. If you are trying to get there, you are in the right place.
The hands-on writing lives on Medium: