I was in a long argument with someone about what DevOps actually is. They were walking me through their setup — built around the standard infinity loop, eight stages, each stage tied to a category of tools, each handoff with its dashboards. The loop was the structure. The tools were the practice. They believed in it.
I sat there thinking: this is not what DevOps was.
The standard pattern
If you read about DevOps online today, you’ll find the same shape everywhere. The infinity loop. Eight stages: Plan, Code, Build, Test, Release, Deploy, Operate, Monitor. Per stage, a category of tooling. Per category, a market. Per market, certifications and platforms and vendor slots.
The career path follows the same shape. A junior learns the tools in stage 4. A senior learns the tools in stage 7. An architect designs across all eight stages. There are certifications for the loop. There are platforms that “complete” the loop. Job listings ask for experience in three of the eight stages.
This works as a diagram. It also works as a marketing surface. Eight stages is eight times the addressable market.
Look at the eight stages again. Plan, Code, Build, Test, Release, Deploy, Operate, Monitor. Notice anything? Not one of them is about humans. Not one is about how teams talk to each other, how blame gets distributed when something breaks, how trust gets built between developers and operators. Not one is about the cultural argument that started the entire movement.
That’s not an oversight. That’s what survived the translation.
The realization
DevOps started as a cultural argument. The lineage is older than software — Toyota Production System, Lean, Deming, Goldratt — applied systems thinking to organizations. The argument was that the people who make the work should also own the work running. Make developers accountable for production. Make operators participate in design. Share context, share blame, share wins. Stop throwing things over the wall.
That was a human argument. About teams, ownership, communication. About psychological safety, blameless postmortems, on-call rotations, retrospectives. About the right to push back when a deadline is going to ship something broken. Tools were incidental. Jenkins existed; Jenkins wasn’t the point.
Somewhere between 2015 and 2018, the argument got captured. The loop diagram appeared. The vendor categories crystallized. The certifications followed. And the original cultural claim — DevOps is about humans not throwing things over walls — got translated into the only language vendors speak: tool categories. Whatever didn’t fit a category got dropped.
Psychological safety didn’t fit a category. It got dropped. Blameless postmortems didn’t fit a category. They got dropped. Trust didn’t fit a category. It got dropped.
What survived was the eight stages. The shape that could be sold.
The loop became the new silo. It silos thinking into stages. It silos tools into categories. It silos roles into specialties. It even silos what counts as DevOps — if it isn’t on the diagram, it isn’t a topic. The thing meant to break silos has been reorganized as one.
That’s the heresy. And it’s everywhere now.
What I tried
CIDX is the smallest tool I could build that respects the original argument and doesn’t impose the loop.
It does one thing: run a declarative pipeline of containerized tools, the same way locally and in CI. That’s it.
There’s no cidx plan. There’s no cidx deploy. There’s no cidx operate. Not because those phases don’t exist — they obviously do — but because I’m not going to tell you what your phases are. That’s your team’s call. That’s the cultural part. That’s the part the tool shouldn’t take from you.
What CIDX gives you is composition. You declare phases. You declare which tools run in each phase. You run them. The CI workflow file is generated from your declaration, so what runs locally is what runs in CI. The runner is thin. The opinions are minimal. The choices stay yours.
cidx init
cidx run ciIf you want the loop, build the loop yourself by composing phases. If you don’t, don’t.
Why I prefer this for my projects
I work across multiple projects. None of them have the same shape. One is a Rust framework, one is a compiler, one is an infrastructure-as-code tool, one is a static blog. Asking each of them to fit the same eight-stage loop would be silly. Asking them to share a thin runner that lets each declare its own pipeline is reasonable.
More importantly: I don’t want a tool that pre-supposes how my team operates. I am the team, in most of these projects. The cultural decisions — what gets reviewed, what gets automated, what gets monitored, what gets ignored, what triggers a postmortem, what blocks a release — are mine. They shouldn’t be encoded in the tool I use to run scripts.
DevOps, in the original sense, is not something a tool can give you. The tool can stay out of the way. That’s the most useful thing it can do.
What this is not
It’s not “the DevOps loop is wrong.” For a team without an established practice, the loop is a useful starting point. It gives shape to a problem space. The danger isn’t the loop existing; it’s the loop being mistaken for the destination.
It’s not “you don’t need any of those tools.” You probably need most of them, eventually. Just not packaged as a loop you have to follow.
It’s not “everything is just culture.” Culture without tooling doesn’t ship. Tooling without culture ships the wrong thing.
It’s: DevOps is a thing humans do, not a thing platforms sell. The eight stages of the loop describe the work the tools do. They were never meant to describe the work the team does. When the loop becomes the practice, the team disappears from the picture. CIDX is what staying out of the way looks like, for a tool I built for myself.