Vibe Strategizing: When AI Momentum Outruns Judgment in Infrastructure

When AI makes everything feel cheap to build, the old SRE question still holds: should this exist at all?

Infrastructure has always punished enthusiasm. It just used to take longer. Microservices took most of a decade to go from conference keynote (I know because I co-wrote one) to “who is on call for all of these,” because infrastructure remembers what you ship long after you’ve stopped thinking about it.

This wave ships in minutes. Meetings cancelled. Agents pushing features. Adoption dashboards climbing. The energy is both tangible and valuable.

Learning the tools matters. Engineers who don’t build hands-on intuition won’t necessarily recognize the high-value opportunities when they show up. The goal is to move faster at the stuff we already know we need to do.

The risk? Everything else. Work that isn’t connected to business problems. The vibe-coded dashboard that looks nice, but nobody other than you uses. Changes that help one person and hand a maintenance burden to forty others. Prompting for answers to the questions AI was meant to free us up to think about. Activity that looks productive but doesn’t move the needle.

Call it vibe strategizing: where hype drives priorities, rather than impact.

Why Infrastructure is Different

For proof-of-concepts or lower-blast radius problems, throwing darts at the wall to see what sticks can be hugely beneficial. Fast feedback loops, real signal, low cost of failure.

Infrastructure is different.

When infrastructure fails, it can break every product and every user sitting on top of it. Infrastructure teams wait weeks, or even months, to build confidence in reliability trends where cascading dependencies make rollback complicated or impossible. A new server type, a patched firmware, a fleet-wide kernel bump, a change to how machines boot or how storage is encrypted, infrastructure is where “breaking things” means firefighting incidents, data loss, and outages that ripple.

So when AI makes everything feel cheap to build, how do we decide what’s worth automating with AI-driven workflows? Google’s SRE framework gives us a useful lens.

The TOIL Lens

Google’s SRE workbook defines toil as “the repetitive, predictable, constant stream of tasks related to maintaining a service.” These tasks are characteristically:

• Manual (a human has to do it)
• Repetitive (it happens over and over)
• Automatable (it could theoretically be scripted)
• Tactical (interrupt-driven)
• Without enduring value (doing it today doesn’t prevent doing it tomorrow)
• Scaling linearly with service growth (more infra == more TOIL)

The key insight: not all TOIL is worth eliminating, and not all automation is worth the cost. This means prioritizing based on impact, not just feasibility or how “hip” it is. Instead, the framework asks:

• What engineering work are you not doing because of this?
• Will the automation itself become TOIL to maintain?

We can expect the operating cost of automation to drop significantly with AI. What once took a week might now take an afternoon. But the same questions hold: understand the TOIL before you automate it.

In the rush to adopt, we’re at risk of forgetting these principles. AI makes things easier, but it doesn’t negate the importance of asking whether or not the thing should be done in the first place. The thinking that made solid infrastructure engineers still applies. The job now is learning where.

Four Categories of AI Investment

Not all AI-driven work is created equal, but it does cluster. Tooling that didn’t exist six months ago has moved whole approaches from risky to routine, and a single project will drift between the soft edges of those clusters as it’s broken down. The boundaries below are a snapshot and we can expect them to shift with time.

High-value, but Perpetually Neglected

Onboarding docs. On-call runbooks. Status updates. The stuff that is genuinely valuable and historically under-invested in because it’s tedious and time-consuming.

This is an LLM’s sweet spot: low risk, high leverage, real-time human feedback. You can validate quality immediately, iterate quickly, and the cost of imperfection is low (some runbook beats no runbook).

• Onboarding documentation. The model synthesizes existing docs, chat history, code pointers, and who to meet into a structured guide. The new joiner uses it and provides feedback. The next joiner gets the corrected version plus whatever has changed since.
• On-call runbooks. The model ingests architecture diagrams, code commits, past incident reports, and alert/triage history to draft instructions and suggest thresholds. The on-call reviews through whatever the team’s standard process already is, and the next incident tests it.
• Status updates. The model drafts from code commits, meeting notes, and telemetry. The subject matter expert corrects it, and the audience probes around the output.

Strategic TOIL Elimination

This is classic SRE territory: the repetitive, predictable work that keeps systems running but does not change their fundamental capabilities.

Here the human deeply understands what needs to happen and why. The model accelerates the how. The human remains accountable for correctness and spends less time on mechanical translation. The guardrails are the ones you already have in any standard project.

• Boilerplate code generation. The model generates service scaffolding, configs, and standard code patterns. The expert and CI validate.
• On-call pruning. The model identifies low-signal alerts from response patterns and proposes threshold adjustments or suppression rules. The person who has been paged by them decides.
• Regression triage. The model aggregates context in real time so the first responder spends their time on resolution, not research.

Capability Unlocking (The “Big” Problems)

LLMs unlock these problems by helping you explore the why, generate options for the what, and execute the how. Problems that were always theoretically possible but practically infeasible (e.g. too tedious for humans to execute and maintain at scale, too expensive to implement) suddenly become tractable.

The risk is sharpest at the what. The model’s proposal can look entirely plausible and be catastrophically wrong for infrastructure. Civil engineers can evaluate whether a structural design will hold without pouring the concrete themselves. The skill is recognizing what is dangerous, both in landing the change and in saturating the team that has to live with it.

Which suggests the real AI-assisted skill isn’t prompting, but thinking like an agent: decompose, delegate, validate.

• Debugging complex interactions. The model surfaces and correlates signals across systems. You recognize which patterns indicate real problems and which are noise.
• Architecture exploration. The model generates options. You identify which approaches would fail at your scale.

Vibe Strategizing

This is the trap. It feels productive. The output looks competent. But “looks valid” and “is valid” are different things. Adoption is up, and that speed is intentional. The upside is real. At scale, though, some patterns emerge that are worth naming.

Pattern 1: Adoption targets drift from impact targets. When orgs set AI goals, adoption is the first tangible thing to measure. Percent of changes agent-assisted. Percent of new code AI-generated. Tool adoption amongst employees hitting a certain threshold. These are not necessarily bad goals; after all, you can’t learn or measure impact without usage. But they become problematic when adoption is the only success criterion. A one-line config change and a two-thousand-line feature both count as AI-assisted.

The fix isn’t to stop measuring adoption, but to pair it with outcomes. Are AI-assisted code changes deploying faster? How often are they rolled back? Is the on-call burden decreasing? Are partners happier? Can we make decisions faster?

Pattern 2: Speed outpaces understanding. LLMs let people ship code, docs, and posts faster than ever. The ability to review and absorb them has not kept up. Teams are finding out the hard way that velocity can outrun validation, and when the retrospective asks why, the answer is already familiar: nobody fully understands what shipped. In documents and posts, the problem is volume. Everyone drafting in minutes instead of hours creates a firehose. We skim. We miss things. In other words, the bottleneck is shifting from production to consumption.

The fix is not necessarily to slow down. It’s to be intentional about what must be deeply understood:

• Match understanding depth to blast radius. Not everything needs a deep review, but high-risk changes need someone who can debug them at 3AM.
• Treat review as the expert work it’s rapidly becoming and reward accordingly. Once LLM output reaches infrastructure, the code, the design, the runbook, the proposed migration may arrive with no author to ask and a surface that looks right. Knowing the wider landscape well enough to see what’s wrong in it is a senior skill, and the supply is shrinking just as the demand goes up.

Pattern 3: The pressure is real and people feel it. Beyond usefulness, there is pressure around appearing to have mastered the art of AI. Performing adoption for its own sake. The tools multiply faster than anyone can learn them, each with its own quirks and failure modes; one engineering manager compared running several agents at once to having a dozen browser tabs open in his head. Priorities and capabilities shift with each new model release, and “AI burnout” has entered the vocabulary. Senior engineers wonder if they’re building their replacements. New grads wonder whether what they spent four years studying will matter at all.

It did, though not enough people are telling them so. The loudest version of employment doom came from a lab CEO, and it’s worth remembering that replacing labor is the bet the whole industry is financed on, not a result anyone has measured. The Stanford analysis of US payroll records behind most of the headlines found a 13 percent drop among 22-to-25-year-olds in AI-exposed occupations, while more experienced workers in the same occupations held steady or grew. In other words, experience is the moat. Languages change, frameworks change, the means to the end has always changed; what carries over is the judgment, and that’s the skill Pattern 2 says is running short.

The fix isn’t to dismiss the felt pressure. It’s real and warranted. But judgment gets built the way it always has: by doing the work. AI assistance on a new engineer’s task is an e-bike on a training ride: the distance gets covered, sure. But the legs don’t get trained. Per Anthropic, juniors who learned a library with AI scored nearly two letter grades lower than those who coded by hand, and saved no time doing it. Let the juniors build context. Normalize “I tried using an LLM for this task and it was slower.” And if seeing the whole system is the new senior skill, growing people who can see it is senior work. Measure it accordingly.

The Anti-Vibe Strategizing Checklist

🔍 Before Starting

🗺️ Map Your Approach

Start by decomposing. Models excel at well-defined subproblems with clear success criteria. Decomposition also makes it easier to validate each piece and identify where AI output might be wrong.

🚩 Trap Check

• “Looks valid” ≠ “is valid” (LLMs can generate code that superficially resembles safe and secure implementations).
• Confidence ≠ correctness (LLM tone doesn’t indicate accuracy).
• Don’t outsource intuition (LLMs only know the data they are trained on).

✅ Merge and Learn

Speed is a multiplier on judgment, not a substitute for it. Infrastructure keeps the receipts either way.