It's the DevOps Handbook All Over Again

Cassowary Colorizations, CC BY 2.0, via Wikimedia Commons.

Back in 2018 when I just started my new job, my manager took the team through the exercise of reading The DevOps Handbook.¹

I had actually already read The DevOps Handbook once before, but was happy to do it again as a team exercise, because the practices contained within those pages were quite important, and essential to some of the key initiatives that the team was trying to accomplish around that time.

Fast-forward to 2026, and I just finished reading a new book I’d been meaning to get to since its release in October 2025: Vibe Coding, by Gene Kim and Steve Yegge. October 2025 feels like forever ago in AI years. Some things have changed: engineers frivolously spent way too much money gaming the token leaderboards at some companies (a form of “tokenmaxxing,” as it came to be called), which in hindsight was more than a bit short-sighted. Some things have evolved: higher-level coding agent orchestrators² can be true “gas guzzlers” in their own right when it comes to token spend. But almost all the guidance from this new book is deeply foundational, and remains true now.

I bought Vibe Coding in January 2026 but didn’t pick it up and read it right away. On my first flip-through, the altitude it was aiming at seemed like old hat for me (“I already know that”), when what I was actually hunting for was concrete guidance on how to make my Claude Code setup better. That was me missing the forest for the trees. The book re-instilled several core principles that will continue to shape my approaches for a very long time. Much to the surprise of some folks who still take that term, “vibe coding,” at what could be a pejorative face value, this is a quite serious engineering book that further underscores the need for many of the practices of The DevOps Handbook, especially around establishing fast feedback loops.

I’m no stranger to vibe coding³, and like many others I dove in head-first over the 2025-2026 holiday break with Claude Code and Opus 4.6.⁴ But it was comforting reading Vibe Coding and knowing that my intuition was on the right track, realizing that I wasn’t alone (and I wasn’t crazy) in thinking that the core engineering discipline the DevOps movement spent a decade trying to establish (and that other parallel movements like SRE have tried to instill) is more important right now than it has ever been, in order to use these approaches effectively and safely.

The difference in 2026 is that we are moving at a million miles an hour and you are several orders of magnitude more likely to “crash the car” than you were in 2018, and potentially needlessly burn a ton of cash in the process. And there’s an added dimension to all this: the individual versus the team. A line from Gergely Orosz’s recent Craft Conference 2026 talk, written up in The Pragmatic Engineer, really resonated with me: individual productivity is up, but team productivity is flat. Everyone feels faster, but the team isn’t necessarily shipping any more than before.

These DevOps lessons need reinforcing more than ever, for everyone now in the driver’s seat, engineer and non-engineer alike.

It Turns Out This Is Still a DevOps Problem 🧑‍💻

The DevOps Handbook aggregated and distilled a set of ideas that were already understood in the best engineering organizations and high-performing companies of the time: get things flowing fast from idea to production; build feedback loops so that your systems tell you quickly when something is wrong; foster a culture of continual learning and experimentation.

These weren’t novel ideas on their own. The hard part was always execution. The gap between where teams were and where they needed to be was enormous, and the know-how lived in the heads of a set of elite teams at certain companies. The DevOps Handbook’s job was to distill and crystallize that knowledge into one place the rest of us could learn from.

Vibe Coding doesn’t discard this thinking; rather, it leans into it. The throughline is very similar: fast flow, fast feedback, and the discipline to actually look at what’s coming out the other end. What’s new is the speed at which you’re now operating and the scale at which mistakes compound when you’re not watching.

I wrote about this compounding effect in practice earlier this year in A Tale of Acceleration and Compound Engineering: the same CI workflows that I used to wire up by hand over days or weeks are now things I can stand up in a fraction of the time with AI assistance. But the practices themselves—the tests, the linting, the repeatable pipelines—are what made the speed benefits durable. The tools and models have gotten better, but the engineering practices are the compounding force that really multiplies them.

And to be perfectly clear, much like compounding financial investments, compound engineering can go in one of two directions: upward 📈, or downward 📉…

The 100mph Crash 💥

Instead of crashing the car at 30 miles per hour, you’re going to crash it at 100 miles per hour. Or perhaps drive it backwards out the window and crash it into the trees, like Cameron in Ferris Bueller’s Day Off, except instead of a vintage Ferrari, the collateral damage is a production system and someone’s data.

Steve Yegge’s cautionary tales in Vibe Coding make this viscerally concrete. In “The Vanishing Tests” story, his agent silently deleted 80% of his test files. There was no warning, and no confirmation prompt; it was just… gone. In “The Vanishing Repository” story, a branch cleanup exercise with his agent nearly tossed his codebase history going back many weeks, with only an open terminal window containing the last unsaved copy standing between him and losing his entire TypeScript client he was writing.

These aren’t edge cases invented for dramatic effect. They’re war stories about what happens when you take your eyes off the road and let the system drive at super highway speeds without any verification or validation or sanity checking.⁵ Based on my own experience, I can confidently say we are quite a ways off from “self-driving” in the vibe coding era, and even if we aren’t, it may mean you can do semi-autonomous self-driving with vibe coding only because you took the time and care to put all of these best practices and validation in place.

None of this means everything needs the full ceremony. If you’re spiking a throwaway prototype, exploring an unfamiliar API, or sketching an idea you’ll delete by Friday, move fast and loose; that’s exactly the right speed. The discipline isn’t something you need on every line of code in every single endeavor, however small it might be; the discipline is what you put in place once the code stops being an experiment. The failure mode is forgetting which mode you’re in, and letting the weekend prototype quietly graduate into production without ever stopping to add the things production demands.

I’ve written about this from my own experience. When I contributed a fix to a React frontend in an area where I’m not strong, the AI output looked great. And that was exactly the problem. Left to my own devices I maybe wouldn’t have attempted this in the first place; rather, I would have searched around docs online, explored the codebase a bit to try to find the related files, attempted to make a minimal viable edit on a branch, but ultimately would have handed off guidance to a fellow engineer who better knew the terrain of this project and of frontend engineering with React. Instead the AI wrote it quickly, more than was needed, actually, and I had to study the output 10x more carefully, slow down to ask “why did it do that,” and ultimately catch a couple of mistakes that only my gut feeling (“something is not right here”) would have flagged.⁶ Tasting the soup matters—not just the final dish, but also as it simmers.

The tools have democratized code generation to the point where a director of marketing can genuinely commit to Git.⁷ But when their “intern” helping them is an AI model embedded in a non-engineering workflow, the mistakes don’t get caught in code review. They get caught in production.⁸

The CFO Is Side-Eyeing Your Tokens 👀

Production incidents are one kind of expensive. There’s another bill coming due, and it’s the literal one.

This shift is recent, landing in the months since Vibe Coding was published. Finance departments up until now have been much like the Ents of Fangorn⁹: slow to wake, slow to rouse, not quite convinced anything was urgent enough to march on. Then Saruman (us engineering wizards) started burning their forest (their cash) at an alarming rate. Now, Finance is awake.¹⁰ (As is a certain CEO.)¹¹

The AI bills are real and visible, and CFOs are asking a fair question: where is the impact? It deserves a better answer than “trust the process.”¹²

There’s a historical echo here. From roughly 2020 to 2022, cheap capital and a growth-at-all-costs mood pushed a lot of companies to over-hire, treating headcount as a proxy for ambition. The correction arrived as layoffs and a sudden corporate religion of “efficiency” and “doing more with less.” The last six months or so have echoed that arc, except this time maybe we over-hired AI: we provisioned maximum horsepower for everything, treated raw token spend as a proxy for being “AI-native,” and only later started asking what all of it actually shipped. Right-sizing your model usage may be part of that same type of correction, just applied to compute instead of people.

The instinct that got us here, namely “reach for the biggest, most capable model, fire away,” is the right instinct if you’re trying to maximize quality on a single critical output and cost is genuinely no object. But most organizations aren’t in that position, and most tasks don’t warrant firing up a top-tier model: summarizing a Jira ticket, drafting a quick email, wiring up some glue code.¹³ These don’t need the heaviest model available; they need a fast, cheap one that you can iterate on quickly within tight feedback loops. A practical habit: ask the agent itself which model is best suited for the task; more often than not, it won’t recommend the largest one. It’s the same judgment as knowing which mode you’re in: the discipline that tells you when a prototype has graduated and earned real tests is the discipline that tells you when a task has earned the bigger model.

This judgment compounds the moment you’re delegating to subagents rather than prompting one at a time. A tool like Claude Code will sometimes hand the lighter, more mechanical steps—say, a codebase search—to a smaller, faster model on its own, the way its built-in Explore subagent runs read-only searches on Haiku, but the defaults only get you so far. Deciding which subagent runs on which model, with the heavy reasoning on the top tier and the search, summarization, and boilerplate on something cheap, is a deliberate design choice, and one of the bigger levers you have on token efficiency. That said, fanning out a dozen subtasks to a dozen subagents, each using a top-tier model, is exactly the kind of gas guzzler that can empty the tank; and that’s just with subagents… Higher-order coding agent orchestrators can guzzle even quicker.

In many ways, token efficiency is the ROI story. I wish we could say it’s as simple as an instrumentation problem, but even if you wanted to, you can’t realistically observe someone reflexively reaching for the most powerful model in their terminal or an IDE plugin. A lot of that usage is opaque by design, and even trying to observe it all will likely create a larger bill just from that effort alone.

And there’s a deeper problem than cost or observability: you simply cannot micromanage the way people use AI, prescribing which model for which task, prompt by prompt and person by person.¹⁴ There are too many people, too many tasks, and the terrain shifts by the week. It is far better to set reasonable caps, give people real guidance on how to be efficient, and trust them to work within them. To put this AI usage micromanaging in terms we’ve used for a long time: it doesn’t scale.

What you can control is what your tooling defaults look like. The DevOps parallel isn’t observability—it’s provisioning policy. You don’t stop over-provisioned EC2 instances by monitoring them after the fact; you change the defaults, set controls at the provisioning layer, and build a culture around right-sizing. Models are quite similar: steer toward the right-sized one at the point of configuration, not at the point of observation.¹⁵

Step back, and it’s clear we’re still in the stick-shift era of these tools. You choose the model, dial in the effort, sometimes explicitly route to the subagents—shifting gears by hand every time the road changes. The automatic hasn’t arrived yet: tooling that quietly picks the right-sized model and effort for the moment and lets you keep your eyes on the road, your hands upon the wheel.¹⁶ (Full self-driving, where you just state where you want to go and hand over the keys entirely, is further off still.) For now, knowing how to drive stick is part of the job.¹⁷

There’s a psychological shift underneath all of this that we haven’t fully absorbed: we are not yet used to paying for software by consumption. Enterprises have made their peace with it through cloud, where you provision a database or a fleet of instances and more or less know you’re paying for what you actually use to host something, within reason. But day-to-day AI usage is a different animal: jagged, unpredictable, and driven by the individual rather than steady infrastructure, which makes it much harder to forecast and requires sensible budgets and limits. (Ask me how I know…) Consumers have even less intuition for any of this. Imagine paying for Netflix by the minute; the meter running in the background would change how it feels to press play. That’s roughly the discomfort of watching a token counter tick up while you work.

For me that sets a concrete threshold. A flat monthly subscription, even a pricey one, keeps the meter out of sight, and right now it’s a great subsidy: the labs are still eating a lot of the true compute cost to win the land grab, so a flat plan buys far more than the same dollars would at metered rates. I’ll happily spend $100 or $200 a month¹⁸ while the subsidy lasts, because renting at that price makes more sense than amortizing the cost of my own hardware. Even after it ends I’d keep spending something with the frontier labs; they’ll still be the sharpest tools for the hardest problems. But some months I’d sail well past that number, and that’s exactly when I’d want a local fallback of my own. The minute consumer plans move to pure consumption pricing is the minute my calculus flips to “okay, when do I build my next tower PC to run models locally?” A local model is also how I’d want to first try a token-hungry agent orchestrator like Gas Town, dipping a toe in without one runaway experiment blowing the whole month’s budget.

The hardware frontier is worth watching here, too. Local inference on Apple Silicon—M5 Max and above—is becoming increasingly capable, and there’s an argument hiding in plain sight: most developers are getting new laptops periodically anyway. Speccing up to hardware that can run a solid open-source model locally costs incrementally more than a baseline machine, but could vastly reduce the API bill for that developer entirely, or give them an escape hatch when they hit their reasonable monthly limit on frontier models in vendor coding agent tools. Contrast that with standing up your own OSS model hosting, which trades the API bill for GPU instances and cloud infra costs and an ops burden. This is really the old build-versus-buy question wearing new clothes, the same spectrum we already know from the rest of cloud: consumption-priced serverless at one end (call a frontier API, pay per token, run no infrastructure of your own), a managed middle (a service like Amazon SageMaker that hosts an open model for you), and rolling it entirely yourself at the other (VMs or Kubernetes in the cloud, or bare metal in your own datacenter). Each tier trades dollars for control and operational burden in a different ratio. There is no free lunch.¹⁹ But there is likely a right-sized lunch that fits within your proverbial AI per diem.

To be honest, the target keeps moving. The best open-source models are already outgrowing what a laptop can hold, and they have started outgrowing modest self-hosting too. GLM-5.2, released in June 2026 under a permissive MIT license, is a 744-billion-parameter mixture-of-experts model that beats GPT-5.5 on several long-horizon coding benchmarks at a sixth of the cost. It activates only about 40 billion parameters per token, but you still have to keep all 744 billion resident in memory to serve it—and none of that fits on a laptop, or on a single modest GPU box. Open weights does not mean locally runnable, and the OSS frontier is drifting toward the same “someone else has to host this” reality as the closed models, which folds it right back into that build-versus-buy spectrum.

Even so, don’t count the laptop out. The open models small enough to run locally today are already very capable across a wide range of everyday tasks, and the efficiency techniques that keep landing—quantization, distillation, smarter sparsity—pull more capability down onto hardware you already own. The locally feasible ceiling is rising even as the frontier sprints away from it.

Slow Down 🐢 to Speed Up 🐇

Back to that Gergely Orosz line—individual productivity is up, but team productivity is flat.

It’s not a paradox if you’ve read The DevOps Handbook. An individual moving faster through a system without feedback loops doesn’t make the system faster; it creates more in-flight work, more unverified assumptions, and more places for things to quietly go wrong. You’re shipping code faster. You’re not necessarily shipping better code faster—not quality code, and not the kind of modular, decoupled architecture that gives you optionality and room to evolve. That same modularity is increasingly what lets multiple agents, like humans, work on a codebase in parallel without stepping on each other and colliding in major merge conflicts; the cleaner the boundaries between components, the more safely that parallel work scales. The fast-but-careless path does the opposite: it quietly backs you into an architectural corner, where every decision forecloses the next one and each later change costs more than the one before it. Vibe Coding surfaces an old maxim, which I had never heard before, but fits aptly here: “You can’t un-blend two frogs.” Move fast without the feedback infrastructure and you’re just as likely to end up with a big ball of mud that even AI will struggle with and will cost you a small fortune to untangle.²⁰

The missing ingredient is the feedback infrastructure: tests that run on every commit (or perhaps even every file save operation), ideally as close to the developer as possible, and CI that catches issues (perhaps even with additional structured AI review) before they hit main, and, for live systems, observability so you know when something breaks in the dark.²¹

None of this is free. A single engineer can pick up the tools and feel faster almost overnight. Building the feedback infrastructure that makes the team faster is a different kind of work—slower, less glamorous, and impossible to do alone. It takes a real investment of time and energy, and leadership willing to buy in and protect that time when the pressure is to just ship.²² That asymmetry is the gap behind Gergely’s line: the individual gains are cheap, and the team gains are expensive.

The DevOps Handbook said this years ago. Vibe Coding says it again for the AI era. The practices don’t care what year it is.

That’s the speed these practices enable: the kind that compounds in your favor, not the kind that compounds debt until the car drives itself backwards out the window.

Read the Books 📚, But Do the Work 🛠️

Reading a book doesn’t change behavior on its own. If it did, this post wouldn’t need to exist, and neither would the long line of books that keep (rightfully) restating the same lessons for each new era.

But if you haven’t read The DevOps Handbook, there’s no better time. And if you haven’t read Vibe Coding, set aside whatever the name might conjure—it earns the serious treatment.

The real takeaway, though, is that the practices—tests, CI, fast feedback loops, observability—are the thing. Not the books, not the tools, not the models. The practices are what let you drive at 100mph without ending up like Cameron’s dad’s Ferrari mangled on the forest floor.

The weeks where I moved fastest with my own personal projects were always the ones where I had the feedback infrastructure already in place. Tests caught what the model got confidently wrong. CI ran in minutes and I knew before I merged. The loop was tight enough that the AI’s mistakes were a course correction, not a production incident.

Tokens cost money, but misspent tokens cost you something you truly can’t get back: time. As Vibe Coding reminds us, time is the one resource you can’t recover, even for personal projects. You can right-size your models to rationalize your token spend; the same tight loops from DevOps are what make the cheaper models viable to lean on. You can’t, however, buy back the hours spent untangling an untested and architecturally jumbled codebase that was shipped fast but built without the feedback infrastructure—both automated loops and manual inputs from skilled practitioners—to keep things on the rails;²³ it’s the guiding hands of humans with good judgment that keep the codebase testable and in an architecturally sound state where it can actually be iterated on by AI, and humans, in the future.

We keep hearing that code is “free” now.

It is so, so not.

Footnotes