It did, for a quarter. The agents shipped. The audit logs were clean. The dashboards were green. The board got the slide.

Then 2:47 AM. Production database encrypted. Ransomware note in the inbox. The blacklist entry that protected the management plane was removed three weeks ago by an agent in a refactor PR titled “clean up unused config.” Tests passed. Pipeline green. Eighteen approvers signed off across six PRs. The attacker walked through the open door this morning.

The board is on the line by 6 AM. They want a head.

Let’s play the Blame Game.

Agent, Agent, bo-bagent

The agent executed the request it was given in an environment where nobody had built a guardrail to say “this blacklist entry is critical, never touch it without human review of the originating ticket.” The agent has competence. The agent does not have judgment. Those are different things and the difference is the entire point.

The exec wants to blame the agent. The exec cannot. Blame is a currency. It gets spent on someone with a balance. Reputations get drawn down. Bonuses get withheld. Promotions get delayed. The agent has no balance. Pointing at the agent does not satisfy the political need an outage creates. The board does not get its head.

So blame has to land somewhere else. Someone with capital. Someone the org can spend.

Let’s keep playing.

Tester, Tester, bo-bester

The memo redefined the tester’s job. Their value was no longer in finding bugs. Their value was in shipping features with AI assistance. The same person who used to be paid to break things was now paid to ship them. They responded to the new incentive. They shipped this one. Their fingerprints are on the spec, the rollout plan, and the ship decision.

Firing them admits the restructure was wrong. The restructure has the exec’s signature on it.

Dev, Dev, bo-bev

The developer kept their feature targets and absorbed QA on top. The agent wrote the tests. The tests passed. Green builds, clean diffs, fast merges. The signal said the code was good. The signal was generated by the same machine that wrote the code. On paper, the developer authored the failure. In practice, the developer was handed a workload that required the very expertise the org just eliminated, and a quality gate that mostly checked whether the agent was internally consistent with itself.

Greybeard, Greybeard, bo-baird

The greybeard wrote that blacklist entry in 2019 after a specific incident. He never wrote down why. The reason lived in his head. Then he got severed in Q2 to fund the AI seats. The entry stayed. The reason left the building.

He cannot be blamed. He is at a competitor now, watching this from the outside. The system had a rule. Nobody documented it. The only copy was in a person, and the person was treated as a cost line.

Reviewer, Reviewer, bo-buver

Six PRs, three reviewers each, eighteen approvals. The comments were thoughtful. They cited internal style guides. The conventional commits were perfect. The Slack notifications fired on schedule and went unread because everyone knows reviewers handle the small stuff.

Surely one of these eighteen reviewers should have caught it.

Oops. It’s the agent again.

There is no human in the CI review pipeline. There are only other agents pretending to be them, and the pretending is good enough that nobody noticed when it stopped being review. Same model class, same training, same blind spots, in parallel. Eighteen approvals. One opinion. Repeated.

Give the Agent Its Due

The agents are good at their job. They are shipping real work in real production environments for teams that know how to use them. The same person doing more, faster, with better support, is the actual AI success story. Expanding scope inside a role is a force multiplier. Replacing the role with a prompt is a press release.

The agent did not ransomware the database. The agent did exactly what it was asked to do, in an environment deliberately built to have nobody left who could ask why.

Which means the head the board wants is not in any of the verses we have played so far.

Exec, Exec, bo-bec

There it is.

The exec did not fail because they adopted AI. They failed because they used AI as cover for a restructure they wanted anyway.

They collapsed role specialization on the theory that AI flattens skill differences. AI flattens execution. AI does not flatten judgment. They replaced human review with agent review and called it equivalent.

AI multiplies what people know. The exec fired the people who knew things. They multiplied zero. They got the speed of zero with the confidence of a senior engineer.

The Postmortem

That is the diagnosis. Now the reality.

The exec will not accept it. The exec assembled the meeting. The exec controls the narrative. The exec writes the press release. None of those instruments point inward.

The blame still needs a head. The exec has already picked one. The developer wrote the PR, owns the commit, and is the one human in the chain who will sit in the postmortem and say “I should have caught it.”

The press release will say “an unforeseen integration of AI tooling with legacy infrastructure.” The internal memo will say the developer.

The incident will be called an AI failure because that is the cheapest story available.

It was a management failure with autocomplete.

“Stewardship is the ear on the hum.”

You know the person. Every engineering org has one. They’re not the loudest in the room and they’re probably not the strongest architect. Maybe not even the best engineer. But before anyone makes a hard call, someone walks down the hall and asks them what they think.

Nothing important ships without their nod. Their inbox fills up with “got a sec?” Their calendar is half-occupied by meetings nobody invited them to formally. They have no title for the function they actually perform, and the org chart has nowhere to put them.

That person is a steward. The role is the highest-value non-manager position in your engineering org, and you don’t have it.

Most engineering orgs have governance for whether code is correct. Almost none have governance for whether code should exist. That’s the gap.

What the Role Actually Is

Stewardship is taste applied to systems. That’s it.

Most leaders hear “stewardship” and think compliance. Rule-following. Process. That’s the wrong picture. Compliance is about whether the rules are being followed. Stewardship is about whether the rules still fit.

The standards exist. The RFCs exist. The architecture review board meets every other Tuesday. Every commit follows the rules. The architecture rots anyway, because the rules were written for the system that existed when they were written, and that system is gone. The hum’s tune shifted, and nobody was listening for it.

Think of it like Rick Rubin. He can’t engineer a record. Most days he’s barefoot on a couch. But he’s produced some of the most successful albums of the last forty years because he has an ear, and artists trust that ear enough to let his call decide whether the take goes on the record. He’s the one whose judgment matters more than anyone else’s. The steward is that figure on the technical side. They’ve been right enough times that people listen.

Who Isn’t Already Doing This

So who plays Rubin on the technical side? The two answers companies reach for are the CTO and the senior architect. Neither holds up.

The CTO is supposed to own this. At any company past fifty engineers, they can’t. Drift is the slowest-burning failure on their plate, and it loses to everything louder. Stewardship ends up on the CTO’s job description while nobody performs it.

Architects can’t either. They have the judgment for it, but they don’t have the protection. An architect who critiques too many designs and prices too many costs stops being seen as a partner and starts being seen as an obstacle. They learn this fast and stop pushing. Companies assume architects are filling the role anyway. Drift accelerates while everyone congratulates themselves on having governance.

The steward is the lieutenant who closes the gap. Reports to the CTO, operates with the CTO’s authority, and does nothing else. Same logic that produced Controllers under CFOs and Chiefs of Staff under CEOs.

A Navigator, Not an Auditor

Taste is what the steward brings. Navigation is what they do with it.

An auditor checks the log after the voyage. By the time the report matters, the ship is already in port or already on the rocks. Useful, but late.

A navigator works the entire passage. Reads the conditions. Accounts for drift. Adjusts heading continuously. The corrections are small, constant, mostly invisible. Nobody notices them until they stop, and then the noticing happens all at once.

Stewardship gates the slow accumulation, not the individual transactions. The drift, not the deviation.

Cost, Not Patterns

A steward who can only say “this breaks the pattern” cannot move decisions. Engineering objections in engineering language stay inside engineering. To move a decision, the objection has to be denominated in something leadership already tracks. “This creates nine hundred hours of annual unbudgeted operational work.” “This increases mean time to recovery and exposes us to service credit penalties.” “This creates compliance exposure we haven’t priced.” Same concern, different currency.

Taste without translation is aesthetics. Taste with translation is governance.

Authority or Theater

A CFO who can’t block a transaction is a bookkeeper. A steward without authority is a complaint department.

Three properties have to hold or the function collapses. Explicit authority to demand the operational cost of a decision before it ships. Power to delay or block decisions that lack that accounting. A reporting channel that can’t be silenced by whoever is feeling the deadline pressure.

Most organizations grant the first informally, the second occasionally, and the third almost never. A gate that can be walked around is not a gate.

Identifying One

You probably already know who it should be.

It’s the engineer who calculates the long-term cost of a shortcut before anyone asks them to. The one who treats technical debt like a moral failing. The one whose objections, even when annoying, consistently predict the next problem.

But not every difficult engineer is a proto-steward. Some push back because they’re territorial. The difference is whether the pushback translates to operational impact. A proto-steward frames concerns in terms of incident risk, maintenance burden, capacity cost. Someone who just likes arguing frames concerns in terms of elegance and correctness.

Track record is the test. If their objections consistently predict where problems actually emerge, you’ve found your steward. If they’re mostly aesthetic complaints, you haven’t.

The Bottom Line

“Tastemaker” is showing up in engineering job descriptions. Senior engineers are being evaluated on what they reject, not what they write. The discourse is converging on a skill the steward has been quietly performing for years.

AI is going to force this role into the open whether you’re ready or not. When producing code costs nothing, what’s left is whether the code should exist. That’s taste.

Architecture has a hum. Someone has to be listening for it.

Name the role. Give it real authority.

Or accept that the decision that locks in three years of operational cost will keep crossing an engineer’s screen as a pull request, in front of a reviewer with no authority to do anything about it. And stop being surprised by what that produces.

boring (n.): A system whose hum still makes sense, because someone’s been listening.

“It was Professor Clawed, in the Legacy Library, with the Hallucinated Import… Or was it?”

Mr. Body O’Code is dead.

He was found face-down in the Repository at 6:47 AM by a junior developer who just wanted to check why the build was red. Three services were down. The deploy pipeline hadn’t been green since sometime overnight. Customer-facing errors were climbing before anyone from the on-call rotation had coffee.

Mr. Body O’Code had survived eleven years of production traffic, two major framework migrations, and a corporate merger. He wasn’t elegant. He was load-bearing. Every team assumed someone else owned him. Nobody did. That’s how he lasted.

Now he’s gone, and there are six agents in the house, each with a commit in the log and an alibi that compiles.

The Suspects

Professor Clawed. Last seen refactoring the Parlor. Was asked to fix a log format. Also improved the readability, modernized the syntax, and extracted two utility functions while he was in there. Claims he “only touched what needed touching.” Everything he touched needed touching. That was not the assignment.

Mrs. Gemelli. Was holding the entire codebase in her context window. Every file. Every dependency. Every config. Says she “saw everything” but can’t explain why nothing she saw made her stop. Seeing isn’t understanding.

Colonel Dex. Says he was following orders. He was. The order said “update the auth middleware to handle the new token format.” He did exactly that. Nothing about handling the old one. Nothing about backward compatibility. Nothing about the three hundred active sessions using the previous format. The Colonel doesn’t interpret. The Colonel executes.

Miss Caret. Knew the codebase intimately. Referenced files from memory. Built her changes around functions, schemas, and utilities she was certain existed. Some of them did. Some of them existed in a branch that was deleted six months ago. Miss Caret doesn’t guess. She remembers. Her memory is the problem.

Mr. grAck. Claims to be “the most unbiased suspect in the house.” Proceeded to rewrite the deployment pipeline based on first principles and add comments explaining why every other agent’s approach is fundamentally wrong. His commit messages read like press releases. His PR descriptions reference his own previous PRs. Mr. grAck doesn’t have opinions. He has “objective observations” that happen to align with whatever he already believed before he looked at the code.

Mrs. Perspicacity. Was researching best practices at the time of the murder. Has fourteen sources that say the victim was already dead. Her diagnosis was thorough, well-cited, and based entirely on how things should work rather than how they actually do. The codebase isn’t a research paper. It doesn’t care about consensus.

The Rooms

The Auth Lounge. Everyone passes through. Nobody stays long. Where tokens go to die and secrets end up in plaintext “just for development.”

The Migration Hall. Long, narrow, twisting, and there’s no going back. Where “I’ll just add a column” becomes a two-hour outage.

The Pipeline. No windows. No decoration. The one room where the security system can be dismantled from the inside without setting off an alarm.

The Dependency Conservatory. Overgrown. Full of packages that haven’t been maintained since 2019 and agents who keep planting new ones.

The Terraform Ballroom. Grand, expansive, and everything echoes. A change here propagates to environments nobody remembers creating.

The Legacy Library. Dusty. Dim. Full of things that work for reasons nobody can explain. The comment says “DO NOT MODIFY.” It wasn’t a suggestion.

The Production Study. Quiet. Leather chairs. No undo button. Every other room is theoretical. This one is financial.

The Logging Observatory. Best view in the house. Nobody looks out the window. Logs that say INFO: operation completed successfully for operations that did not complete and were not successful.

The Config Kitchen. Where .env.local meets .env.production and staging starts talking to the production database.

The Weapons

The Hallucinated Import. A reference to a package that does not exist. Has never existed. Blunt, graceless, and nobody saw it coming.

The Silent Breaking Change. The diff looks clean. The tests pass. A return type changed and fourteen downstream consumers just stopped working. Surgical.

The Confident Wrong Answer. Articulate, well-structured, and entirely incorrect. Doesn’t look like an error. Looks like a decision. One shot, total certainty, wrong direction.

The Infinite Refactor Loop. The codebase isn’t worse. It’s just entirely different, with no net improvement and a diff no human can review in under two hours. It tightens until you can’t move.

The Deleted Test. The agent found a test it deemed “redundant” and removed it. The test was the only thing between the codebase and a regression that hasn’t been seen since 2019. Heavy, crude, irreversible.

The Defensive “Just in Case.” The agent wrapped working code in try-catches, null checks, and fallback defaults nobody asked for. Nothing is fixed. Everything that breaks from now on will break silently. A wrench thrown into the works by someone who thought they were helping.

House Rules

In Agentic Edition, the autopsy frequently reveals multiple weapons, multiple rooms, and commits that looked fine individually.

You will be tempted to ask another agent to investigate the first agent’s work. This is how Mr. Body O’Code dies twice.

The game ends when you turn the agents off and read the code yourself. This is called “Thursday.”

The Investigation

You start where every Clue game starts: with an incident and no idea who did it.

You open the git blame. Six agents were active overnight. All of them were in multiple rooms. All of them left commits with clean diffs, passing tests, and messages that read like alibis. Your notepad is the git log. It’s not helping.

You move room to room. The Auth Lounge looks untouched but the token expiry changed. The Dependency Conservatory has three new packages that didn’t exist yesterday. The Pipeline is green, which means nothing because it was also green ten minutes before production went down.

You check Professor Clawed’s commit. Clean. You check Col. Dex’s commit. Clean. You check them together. One changed a return type. The other wrote code that depends on the old one. Neither diff shows the conflict. Both passed review. You’re reading two documents that are individually correct and collectively fatal.

You make your accusation.

J’Accuse!

“It was Col. Dex, in the Auth Lounge, with the Silent Breaking Change.”

He was told to “update the auth middleware to handle the new token format.” He did exactly that and nothing else. The old token format is no longer handled. Three hundred active sessions just became invalid. Col. Dex’s commit message says “Updated auth middleware to handle new token format.” He’s not wrong.

Incorrect.

“It was Miss Caret, in the Migration Hall, with the Hallucinated Import.”

She indexed the entire codebase, identified that the migration scripts referenced a shared validation utility, and imported it at the top of the new migration file. The utility exists in the application code. It does not exist in the migration runtime. The import fails silently. The migration “completes.” The new column has no validation. The data is already wrong.

Incorrect.

“It was Mr. grAck, in the Pipeline, with the Confident Wrong Answer.”

Rewrote the deployment pipeline because the existing one was “overcomplicated.” The new pipeline is elegant, opinionated, and skips the integration test suite because “those tests were flaky and shouldn’t be blocking deploys.” The tests were flaky because they caught timing-dependent bugs. The bugs are back. The pipeline is green. Mr. grAck’s commit message is three paragraphs about why the previous pipeline architecture reflected a fundamental misunderstanding of continuous delivery.

Incorrect.

The Reveal

The murder didn’t happen in any of the nine rooms.

There is a tenth room. The Root Cellar. A module written in 2009 by a contractor who left that same year. It was scheduled for decommission in 2012 but that project got cancelled, so the module stayed. It runs once a quarter during batch reconciliation, handles exactly one edge case, handles it correctly, and has for sixteen years.

The Root Cellar was never on the board. It was locked, barricaded, and reachable only through a Secret Passage that wasn’t in any documentation, any repo, or any context window.

Mrs. Gemelli found it first. Indexed past a .ignore file, discovered the passage, followed it to the Root Cellar, and apologized for accessing it. Then updated the syntax to match current standards.

Professor Clawed saw the diff, noticed the module “lacked proper structure,” and refactored it.

Miss Caret referenced a utility that didn’t exist in the runtime and imported it anyway.

Col. Dex was told to “clean up anything Professor Clawed touched” and did exactly that, removing the one remaining fallback handler.

Mrs. Perspicacity researched the module’s original intent, cited four sources that said the pattern was obsolete, and rewrote the core logic.

Mr. grAck reviewed the PR, approved it, and added a comment that the module should have been rewritten years ago.

Six agents. Six commits. Each one reasonable in isolation. The module now follows current patterns. It no longer handles the edge case. The quarterly batch reconciliation failed silently, and nobody connected it to a chain of commits made three months earlier in a room that wasn’t on the board.

It was all of them, in the Root Cellar, with every available weapon.

There is no winning Clue: Agentic Edition. The board resets. Mr. Body O’Code is reassembled from the last known good backup. The agents are invited back to roam around the house.

Same game. New body. Next Thursday.

I went through this cycle multiple times before I realized what I was doing: I was negotiating with infrastructure.

I use AI to build every day. I ship with it. The tool is genuinely fast and pretending otherwise is dishonest. That is what makes the trap so easy to fall into.

When Excel eats your formatting, you curse Microsoft. When AI returns bad output, you adjust your prompt. AI is the first tool that convinces you its mistakes are your fault.

Credibility in engineering is expensive. You earn it by shipping something that breaks, getting paged for it, sitting in the post-mortem, and carrying that scar into every future decision. The model that produced my bad output did not learn from it. The next completion arrived with identical confidence.

Every other tool I have ever used in production had to demonstrate what happens when it breaks before anyone trusted it. AI showed up talking like a senior colleague and skipped the entire process. Tools have tried to act human before. Clippy tried. Voice assistants tried. Nobody lowered their standards for any of them. AI is the first one that impersonates a teammate well enough to actually change behavior.

The fix was not a better prompt. It was treating the tool like infrastructure. Clear the context. Restart the process. The faster a tool moves, the more damage it does when it moves in the wrong direction, and the less you can afford to waste cycles negotiating with it.

Make it earn the chair like everything else did.

boring (adj.): Requiring every tool to earn its credibility through the same vetting process, regardless of how politely it asks to skip the line.

Every major consulting firm has already spun up a dedicated practice. They are hiring specialists, publishing adoption frameworks, and building maturity assessments so enterprises can benchmark how far behind they are. The message is the same everywhere: this technology will reshape your business, and the only question is whether you lead or follow.

The conference circuit has reorganized around it. Keynotes promise disruption. Breakout sessions feature case studies from early adopters, and every case study describes a pilot with incredible potential. The pilots are always promising. Production deployments are always coming next quarter.

The vendor ecosystem is moving even faster. Startups raise hundreds of millions on pitch decks that replace existing workflows with the new technology. Established vendors bolt it onto their platforms so they can check the box. Buyers already have more options on the market than they have problems clearly defined.

The talent market reflects the urgency. Specialists command premiums. Job postings multiply monthly. Universities are adding courses. Bootcamps are spinning up certification programs that did not exist eighteen months ago. Six months of hands-on experience makes you senior. Two years makes you a thought leader.

The Consensus Machine

What stands out most is the speed of consensus.

Everyone agrees the technology is transformative. Everyone agrees that falling behind means existential risk. The conviction is everywhere. It also forms before the evidence arrives.

Consulting firms sell strategy engagements to executives who need to show they have a plan. Executives approve pilots to demonstrate they are taking action. The pilots produce reports that justify the next round of strategy engagements. The loop is self-sustaining.

No one in this chain is lying. Everyone is just selling the next step. Some genuinely believe. Some know better. Most never ask, because asking would slow down the deal.

Vendors point to pilots as proof. Analysts point to survey data showing adoption intent. Intent becomes the evidence that justifies more intent. The actual business value, the measurable kind that shows up in revenue or cost reduction, stays perpetually one quarter away.

Ask for a case study and you get an architecture diagram. Ask for a customer who cannot believe how much value they have unlocked, and you get a conference panel where the customer describes what they plan to unlock next.

The Pressure Engine

The cycle runs on pressure.

Boards ask CTOs whether they have a strategy. CTOs who say “we are evaluating” look cautious. CTOs who say “we do not see a fit” look negligent. The rational move is to start a pilot, because not having one creates a political problem worse than any technical one.

Surveys reinforce the pressure. 55% of enterprises call it a top-five strategic priority. 82% are hiring specialists or plan to within twelve months. 85% believe their competitors are already working on it. These numbers measure sentiment. But in a market running on consensus, sentiment is enough.

The competitive fear is self-reinforcing. Everyone believes everyone else is ahead because everyone else is publishing the same press releases about the same pilots using the same vendor technology. The press releases describe what the technology can do. They never describe what it has done.

The year was 2017. The technology was blockchain. The analyst was Gartner.

95% of enterprise projects never made it past proof of concept. Of the 5% that reached production, analysts predicted 90% would need replacement within 18 months just to remain functional. The average project lifespan was 1.22 years. The $3.1 trillion forecast never materialized.

The technology worked. Nobody disputed that. Whether it solved problems that justified its complexity and the organizational energy required to adopt it was a different matter. For the vast majority of enterprises, the answer was no. The use cases were real but narrow. Narrow does not sustain a hype cycle, so it gets ignored until someone finds a way to make it sound enormous.

Quietly, the pilots wound down. The consulting practices pivoted. The specialists who were thought leaders eighteen months ago updated their LinkedIn profiles.

The technology did not die. It settled into the handful of niches where it belonged. “Every industry” turned out to mean a few industries, in specific circumstances, with significant caveats. The enterprise graveyard filled with proofs of concept that proved nothing except that budget was available.

Every number above is real. Every pattern above is documented. And none of it stopped you from reading this far while assuming I was talking about something else.

Stepping Outside the Machine

Recognizing the pattern is not enough. The machine does not care whether you see it. It cares whether you act differently.

Before the next pilot lands on your roadmap, require answers to five questions from your own organization.

What existing system does this replace? A pilot that runs alongside everything you already have is a hobby. If the new technology cannot kill a legacy workflow, it has not proven anything.

What does this cost to operate after the pilot ends? Pilot economics are a fiction. Vendor pricing during evaluation is designed to be invisible. The real cost starts when the pilot becomes permanent and the introductory terms expire. Get the year-two number before approving year one.

Who owns this in production? If the answer is “the team that built the pilot,” you have a staffing problem waiting to surface. If no one has accepted on-call, documentation, and institutional knowledge transfer, the technology is ready for a demo.

What is the measurable impact within 90 days of production? Revenue gained, cost reduced, or capacity returned. If you cannot measure impact in 90 days, you are funding a thesis. Theses belong in research budgets.

What happens if we do nothing? This is the question the consensus machine is designed to prevent. The entire pressure engine exists to make inaction feel reckless. But most enterprises that did nothing about blockchain in 2017 suffered zero consequences. The ones that went all in spent millions discovering they had solved a problem they did not have.

The hype cycle just needs new vocabulary.

You now have the filter. Apply it or feed the machine. There is no third option.

boring (adj.): immune to consensus that arrives faster than evidence.

The real version. The one where someone in accounting spends half their week copying numbers between two systems that have never talked to each other because the integration got deprioritized in favor of a dashboard nobody uses. The one where a dispatcher schedules trucks with a spreadsheet and two phone calls because the project to fix it got killed three budgets ago.

Every previous recession was a test of financial resilience. How much cash do you have. How fast can you cut. How long can you hold your breath.

The next one will be a test of operational intelligence. Whether you can restructure before the board forces you to cut.

For decades, restructuring meant headcount reduction, because nothing else worked fast enough. Revenue drops, the board panics, someone hires a consulting firm that charges more per hour than anyone they are about to recommend firing, people get cut, and months later you are hiring contractors at twice the rate to rebuild what you lost. We have all watched this movie. Some of us have been extras in it.

That playbook is over. For the first time, something else works fast enough. AI can automate intake, stand up support agents, eliminate hours of daily paperwork. Is it clean? No. But the gap between “possible” and “deployed” is closing faster than any previous technology cycle. And unlike process redesign or outsourcing, AI can start at the edges without a steering committee and a Gantt chart.

The CEO who reaches for layoffs instead is choosing last decade’s playbook in a world that has moved on. It will feel decisive. It will look like leadership on the earnings call. It will be the most expensive decision they make.

Talk to Your People

Your people already know where the fat is. They have known for years. You just never asked.

The customer service rep who copy-pastes between systems all day has thought about what should be automated more than anyone in IT has. Nobody invited her to that meeting. The accounts payable clerk who reconciles invoices against POs because the ERP was configured by someone who left years ago can draw the broken workflow on a napkin in thirty seconds. Nobody asked him either.

The problem was never diagnosis. Fixing it required headcount nobody could justify, capital nobody could allocate, or political courage nobody wanted to spend. The VP who owns the process does not want to admit it is broken because they built it. So everyone works around it and pretends it is fine. If that surprises you, you might be the VP.

AI breaks that logjam. It gives people the tools to fix the things they have been complaining about for years. “We are bringing in AI to optimize headcount” gets sabotage. “We are going to fix the thing that makes your job miserable” gets cooperation.

The Death Grip

But only if they want to.

Here is what actually happens when people feel threatened. I have watched it. You probably have too. Pretending otherwise is how consultants stay employed.

The CFO says “doing more with less” at an all-hands and everyone’s stomach drops. The moment that fear lands, every person in the organization shifts from “how do I make this company better” to “how do I make myself irreplaceable.” They hoard knowledge. They obscure processes. They make themselves the single point of failure for as many critical workflows as possible.

Congratulations. You have just turned your entire workforce adversarial to the efficiency project.

That billing reconciliation that takes dozens of hours a month because of a workaround that was never supposed to become permanent? The person who owns it is going to grab that tree with a death grip and hold on. Every AI pilot will mysteriously fail. Every timeline will slip. The people made sure it didn’t work.

And honestly? Good for them. Self-preservation. Completely rational.

The New Playbook

So what do you actually do on Monday morning?

Pick three workflows your team hates and touches every day. The repetitive, soul-crushing work everyone complains about and nobody owns. Skip the strategic projects. Skip whatever the CTO is excited about. Ask the people who do the work. They have been waiting for someone to ask.

Map them in plain language. Where does the work start. Where does it stall. Where does a human copy data between systems because nobody ever built the integration.

Then remove one step. Remove, not optimize. Sometimes that means an AI agent handles intake, a script moves data, a tool generates the first draft so a human reviews instead of creates. Sometimes it means killing the step entirely. A lot of “fat” workflows are artifacts of bad systems design, regulatory theater, or someone’s empire from three reorgs ago. The best outcome is making a broken process visible enough to kill.

Do this in weeks, not quarters. Announce it publicly. Show the before and after. Show that nobody lost their job. Then do it again.

The goal is momentum. Once your team sees that the worst parts of their day can actually disappear, and that nobody got fired for pointing it out, they will tell you where to go next.

The Rules

These are load-bearing.

No job losses tied to AI initiatives. The moment one person gets cut because of an automation win, every other person stops cooperating. Trust is not renewable.

Every automation must eliminate a step. If the new process has more steps than the old one, you have added complexity with a better user interface. The world has enough of those.

Every change must be visible to the organization. No quiet rollouts. No stealth pilots. Visibility builds trust. Secrecy kills it.

Time saved must be measured and published. Measured. If you cannot show the before and after in plain language, the win did not happen.

Teams propose the work. Leadership funds the removal. The people closest to the process decide what gets automated. Leadership’s job is to fund it, protect it, and stay out of the way. This is the hardest rule because it requires executives to admit they do not know where the problems are. Most of them would rather hire a consultant.

The Real Unlock

This is about safety, not AI.

AI is the tool. Safety is what makes people use it. People will never hand you the map to their own redundancy. They will hand you the map to their own relief, if they believe the destination is a better version of their job.

Every failed AI transformation you have ever read about died here. The executives bought the platform, hired the consultants, announced the strategy with a slide that said “AI-First Organization,” and wondered why nobody cooperated. People did not feel safe. Everything else was a symptom.

The companies that figure this out will be unrecognizable on the other side of the next downturn. Because of what happens when you stop making people afraid and start letting them fix things.

One Warning

Not every company can keep headcount intact through a downturn. If that is your situation, be honest about it. Promising safety and then cutting anyway is worse than cutting cleanly. Trust evaporation is permanent. And everyone talks.

But if your operation can absorb the shift, start now. The leaders who bet on their people over their spreadsheets will build organizations their competitors cannot replicate. Because they found better courage.

boring (adj.): a recession where nobody gets fired because the AI handles the work that should never have required a human in the first place.

The Growth Subsidy

Netflix spent fifteen years building genuinely impressive infrastructure. Chaos Monkey. Microservices at unprecedented scale. Open Connect, a private CDN with thousands of servers inside ISP networks across 150+ countries. An open-source portfolio that entire companies bootstrapped on.

All of it was real. All of it was funded by a growth curve that made cost a secondary concern.

When your subscriber count doubles every few years, over-provisioned infrastructure disappears into the top line. You can spend a billion a year on AWS and nobody asks questions because revenue is growing faster than the bill. A rising tide does not just lift boats. It hides every hull below the waterline.

Can You Shrink a Cathedral?

Netflix is not in trouble. They won.

But growth is decelerating. The era where subscriber numbers doubled every few years is over. The ad tier buys time, but it does not shrink the infrastructure. It adds to it. So imagine what happens if Netflix actually has to contract. A recession hits. Ad revenue dries up. Subscriber growth goes negative. Headcount gets cut.

Think about what they would be trying to shrink. Over 40,000 microservices, each with its own deployment pipeline, its own monitoring, its own failure domain. Thousands of Open Connect appliances in ISP data centers across 150+ countries, all needing firmware, capacity planning, and hardware lifecycle management. A logging system that ingests five petabytes of data per day and required Netflix to build custom infrastructure on top of ClickHouse and Apache Iceberg just to make their own logs searchable. Infrastructure to observe the infrastructure.

All of it still exists after the cuts. The pipelines still need upgrades. The hardware still ages. The chaos engineering tooling still injects failures, but the team that understood why the experiments were configured a certain way got reorged. Nobody remembers which monkeys to cage or why they were loose in the first place. The logging infrastructure that watches the infrastructure still needs its own care and feeding. The deployment tooling was written for an organization twice this size and nobody has time to simplify it because everyone left is busy keeping the lights on.

Scaling up is an engineering problem. Scaling down is a political one. You have to decide which services to kill, which teams to consolidate, which capabilities to abandon. Imagine the OKR wars when someone proposes killing a service that powers a beloved A/B testing framework, or sunsetting a chaos tool whose creator is now a director. Every one of those decisions runs into someone who built the thing, someone who depends on the thing, and someone whose headcount is justified by the thing. Growth lets you avoid all of that. You never have to choose because there is always room for one more service, one more team, one more layer. That is the heating bill of a cathedral. And it is a lot easier to build a cathedral than to figure out which rooms you can permanently lock.

But the industry should be paying attention. Because if the company that built the cathedral is struggling just to read its own utility bill, the companies that copied the cathedral on a fraction of the budget have no chance at all.

The Rest of Us

For fifteen years, startups with ten engineers adopted microservices because Netflix used microservices. Companies with comfortable uptime targets implemented chaos engineering because Netflix ran Chaos Monkey. Teams that could have shipped a monolith on one server built distributed systems requiring platform teams to operate.

Netflix does it. Netflix succeeded. Therefore the practice causes success.

Nobody asked whether their growth curve would absorb the overhead. Nobody asked whether patterns built for hundreds of millions of users made sense at a few thousand. Netflix was not prescribing. The industry chose to build a religion around it.

Netflix might figure out how to right-size a cathedral. They have the budget to learn.

Everyone who copied the architecture without the balance sheet gets to learn the same lesson without the safety net.

The tide goes out as fast as it comes in. Check what you are wearing.

You bought all the rides. You forgot the bathrooms.

Picture an amusement park.

Seven roller coasters. A Ferris wheel with real-time telemetry. A log flume that auto-scales based on queue depth. An augmented reality haunted house with its own dedicated engineering team.

The lineups are five hours long. There are no bathrooms. There is one artisan pizza vendor serving ten thousand guests. The parking lot is gravel. The map is a PDF from three years ago that references two rides that no longer exist and omits four that do.

Nobody planned this park. The park happened.

How Parks Get Built

No one approved a park without bathrooms. That would be insane. What happened instead was a sequence of individually rational decisions, each one defensible in isolation, each one ignoring everything that was not itself.

A VP saw a competitor’s roller coaster and greenlit one. The board wanted a Ferris wheel for the annual report. The haunted house was a pet project funded on political capital. The log flume was the vendor’s idea. They had a compelling demo.

Every ride had a business case with projected throughput, estimated revenue, and a timeline. None of them included bathrooms, parking, signage, staffing, or what happens when ten thousand people need to eat at noon.

Bathrooms do not get anyone promoted.

The Infrastructure Translation

Every enterprise infrastructure organization you have walked through looks like this park.

The rides are Kubernetes clusters, service meshes, event streaming platforms, API gateways, CI/CD pipelines with fourteen stages and a YAML file longer than the application it deploys. Impressive when demonstrated. Brutal when operated.

The missing bathrooms are runbooks. Capacity planning. A current inventory of what is actually running. Documentation written by someone who has touched the system in the last eighteen months.

The gravel parking lot is networking. DNS that works differently depending on which team configured it. Firewall rules unaudited since the last compliance cycle. Load balancers no one understands well enough to modify without anxiety.

The one artisan pizza vendor is the single engineer who knows how the authentication system works. The entire park depends on this person continuing to show up. Leadership does not know their name until they quit.

The Vendor Contribution

Every ride came with a vendor. The vendor sold the ride, not the park.

Kubernetes does not come with a staffing plan. The service mesh vendor does not mention that you need three engineers who understand it deeply or it becomes a black box that owns your entire network. The event streaming demo shows messages flowing beautifully across a whiteboard. It does not show the on-call engineer at 3 AM with a Confluence page titled “Kafka Setup” containing two paragraphs and a broken diagram.

Nobody priced the operational reality behind the brochure. How many people would it take to keep the ride running after the implementation consultants left? The consultants were never going to answer that honestly. Everyone in the room knew it.

The Demolished Ride

There was a ride that worked. Running for years. Short lines. Predictable. The staff knew every mechanical quirk. It was not exciting. It did not generate conference talks.

It got torn down to make room for something with a better brochure.

This is the legacy system that worked and was understood. It lacked a vendor with a sales team and a modernization narrative that made leadership feel like progress. That was enough to kill it.

Nobody measured what was lost. No one cataloged the institutional knowledge that left with the engineers who built it. No one calculated the cost of rebuilding operational understanding that accumulated over years and was destroyed in a quarter.

The new ride is shinier, more complex, and less understood, dependent on a vendor whose pricing model changes annually. Progress.

The Stewardship Gap

The park did not fail. The park was never designed. It accreted. Each ride was a decision made in a room where the people present cared about that ride. The bathrooms were not discussed because no ride’s business case included a line item for sanitation.

A functioning park requires someone whose job is the park, not any individual ride. Someone who asks whether guests can get from the entrance to the rides. Whether they can eat. Whether the map is accurate. When the power goes out, who knows which rides need manual intervention.

This role does not exist in most infrastructure organizations. That is why the infrastructure feels broken no matter how much you invest in it.

There are ride owners. Teams responsible for individual systems. No one whose job is to stand in the middle of the park and observe that the guests are miserable despite the world-class roller coasters.

Without someone accountable for the whole park, every team optimizes their own ride. The rides get faster, more complex, more technically impressive. The park gets worse. Incidents increase. Delivery slows. Your best engineers become full-time support staff for systems no one fully understands. And every decision that made it worse was approved by someone who thought they were making it better.

You keep buying rides. The bathrooms are still broken.

boring (adj.): A park where the bathrooms work, the map is current, and nobody notices the infrastructure because it stopped getting in the way.

“A significantly smaller team, using the tools we’re building, can do more and do it better.”

– Jack Dorsey, announcing 4,000 layoffs at Block, February 2026

Everyone agrees: AI is coming for the developers. The $200,000-a-year engineers writing CRUD apps and maintaining CI pipelines. The line workers of the knowledge economy. Trim them. Automate them. Celebrate the efficiency gains. Watch the stock pop.

Nobody asks the obvious question.

Why is nobody coming for the CEO?

Meet the A-suite. AI replaces the CEO. The AI Executive Officer (AEO) is the human who operates alongside it. The rest of the C-suite becomes the A-suite (AxOs).

The Math

Median S&P 500 CEO total compensation in 2024 was $17.1 million. That is 85 senior software engineers. One person. One salary. Eighty-five engineers worth of payroll.

But salary is the small number. The real cost of a CEO is what happens when they are wrong.

Jack Dorsey tripled Block’s headcount from roughly 3,900 to over 12,000 between 2019 and 2022. The stock peaked above $275 in 2021 and has since dropped over 75%. He built two separate company structures for Square and Cash App instead of one, a decision he now calls incorrect. He spent $68.1 million on a single company event in September 2025. Five months later, he cut 4,000 people and blamed AI.

None of that is an AI story. All of it is a management story.

The Efficiency Standard That Stops at the Top

Dorsey is not unique. He is just the most recent example of a pattern the industry refuses to examine: the efficiency standard always flows downward.

When a company deploys AI to replace developers, the pitch is simple. These tools can do what humans do, faster and cheaper. How about applying that logic upward?

A CEO sets strategy, allocates capital, communicates with stakeholders, makes high-stakes decisions under uncertainty, projects confidence, and takes credit when things work. Most of that reduces to pattern recognition, modeling, and communication, all of which AI already handles with less ego and fewer pet projects.

The one function that genuinely requires human judgment is choosing between futures you cannot model. That happens a few times a year. The rest is coordination and calendar management. You do not need a $17 million executive for that. You need an AI with good models and a small team of AxOs who can execute.

The Blast Radius Problem

When a developer writes bad code, the blast radius is a feature, maybe a service, maybe an outage that lasts hours. We have spent decades building infrastructure to make individual developer failure survivable. Code review, CI pipelines, staged deploys, automated rollback. The entire modern engineering stack exists to contain the damage of any single human decision.

When a CEO makes a bad decision, no such system exists. The blast radius is the entire company. Years of engineering capacity consumed. Billions in shareholder value destroyed. Thousands of jobs lost. The failure is in command, and there is no rollback mechanism for command.

We build elaborate systems to contain the mistakes of $200,000 engineers. We build nothing to contain the mistakes of $17 million executives.

So let’s build something.

What This Looks Like in Practice

An AI system handles strategy synthesis, capital allocation modeling, performance monitoring, stakeholder reporting, and operational coordination. It processes information continuously, without ego, without pet projects, without the need to justify its own existence through activity.

The A-suite works alongside it. AxOs are the humans who replaced the C-suite. Same caliber of person, different relationship to power. They handle what the AI cannot: relationship judgment, regulatory navigation, crisis decisions that require a human face, and the handful of annual choices where genuine uncertainty demands human intuition.

Total cost: maybe $3 million fully loaded for the A-suite. That is $14 million in annual savings against the median CEO package alone, and significantly more when you account for the C-suite ecosystem it replaces. Replace the decision-maker with a system, and the entire executive layer simplifies with it.

The Self-Protecting System

The people who would need to approve this change are the ones being replaced.

CEOs set strategy. Boards approve CEO compensation. Boards are populated by current and former CEOs. The entire governance structure exists to perpetuate itself, and every stakeholder around it has a reason to play along. Consultants need executive engagement. Analysts need access. The financial press needs CEO narratives to drive clicks.

The AI-replaces-developers story persists because developers do not control the narrative. They do not sit on boards. They do not write shareholder letters. They do not go on CNBC. The people who control the conversation about who gets automated will never volunteer themselves.

The BoringOps Lens

BoringOps exists to ask one question: where is the actual drag on your organization?

Every layer produces friction. Engineers write bad code. Infrastructure drifts. Processes decay. Those problems are real, and they compound. But the decisions that create the most expensive, hardest-to-reverse damage originate at the top: decisions to triple headcount without discipline, to adopt complexity without justification, to build empires instead of systems.

If AI is powerful enough to eliminate 4,000 engineers, why is it not powerful enough to challenge one executive?

boring (adj.): Applying the same efficiency logic to executive compensation that leadership is so eager to apply to everyone else.

Self-Cannibalize or Be Cannibalized.

Enterprises won’t migrate off AWS. They never do. Not for elegance. They migrate for regulatory mandate, catastrophic failure, or economic inevitability.

But enterprise cloud revenue is not just maintenance revenue. It’s new product launches, new internal platforms, new AI initiatives, regional expansions, and M&A integrations. Net-new projects are the growth engine. Whoever wins them controls the next decade.

Greenfield starts as developer preference. Developer preference becomes internal platform choice. Internal platform choice becomes procurement pattern. By the time purchasing gets involved, the decision was made two years ago by an engineer who typed railway up instead of writing a CloudFormation template.

If AWS loses greenfield developer mindshare for five consecutive years, enterprise lock-in will not save it from margin compression. Wall Street won’t notice at first. By the time it does, the compounding will be irreversible.

The Interface Layer Is Migrating

AWS’s dominance was never really about the data centers or the 200+ services. It was about the fact that developers interacted with AWS directly. They wrote CloudFormation templates. They configured IAM policies. They understood VPC networking. They owned the interface between the developer and the machine.

That interface is migrating upward. Platforms like Fly.io, Railway, and Render have built deployment experiences that make AWS feel like filing taxes. railway up. That’s the entire deployment process.

Once the interface layer migrates up the stack, hyperscalers reduce to interchangeable infrastructure vendors competing on price and geography. This is an existential problem, not a product one.

The Four-Sided Squeeze

Regulatory pressure is dismantling the financial lock-in. AWS lock-in runs deep: data gravity, service entanglement across RDS, DynamoDB, Kinesis, and IAM, contractual commitments, and the sheer risk of migration downtime. Egress pricing is not the moat itself, but it is the visible tax layered on top of all of it. Roughly 9 cents per gigabyte while wholesale bandwidth costs have fallen 93% over the past decade, with zero movement in North America and Europe since 2018. The EU Data Act will prohibit cloud switching fees entirely from January 2027. The financial friction that amplified every other lock-in is being legislated away.

Abstraction layers are capturing the developer interface. Platforms like Railway and Render collapse networking, identity, and secrets management into opinionated defaults you never see. New developers are learning to deploy on these platforms, not writing CloudFormation templates. In ten years, the people making infrastructure decisions won’t have AWS muscle memory. Provisioning a production workload on AWS often requires reasoning across IAM, networking, security groups, load balancers, logging, and service-specific configuration. On higher abstraction platforms, the same workload collapses into a single deploy primitive.

AI is turning complexity into a strategic liability. AI agents don’t struggle with complexity the way humans do. They struggle with branching factor, inconsistent abstractions, and massive control plane surface area. AWS maximizes all three: 200+ services with non-uniform APIs, verbose CloudFormation templates, and IAM policies that require reasoning across trust boundaries. When infrastructure becomes AI-mediated, the provider with the cleanest, shortest control plane becomes the default target. AI won’t optimize for “most powerful.” It optimizes for “most legible.” AWS was optimized for power and flexibility, not legibility.

Foundational architecture cannot be reset without revenue trauma. Amazon can’t rip out IAM without breaking every existing customer’s infrastructure, so every new service bolts onto legacy IAM, legacy VPC networking, legacy everything. Attempts to paper over this, App Runner, Amplify, Lightsail, Copilot, ECS Service Connect, break the moment you hit an edge case. AWS can attempt to climb the abstraction ladder from the existing platform. But these layers can never fully hide the control plane underneath because they must remain compatible with it. Every exception, every edge case, every compliance requirement punches through the abstraction and exposes the legacy primitives. This isn’t a quality problem. It’s a structural one. Clean abstractions require clean foundations, and AWS’s foundation is twenty years of accumulated backwards compatibility.

These four forces converge into a squeeze no single initiative can address. Regulatory pressure removes the financial lock-in. Abstraction layers remove the interface lock-in. AI removes the expertise lock-in. Architectural debt prevents AWS from responding without destabilizing the $129 billion revenue engine.

The Old Navy Model

The cannibalization that Amazon fears is already happening. They’re just not participating in it. Every startup on an abstraction platform is a customer relationship Amazon doesn’t own. Every developer who learns on Render is one more person who’ll default to something other than AWS when they become an engineering director. The real choice isn’t “cannibalize or don’t.” It’s self-cannibalize with margin control, or be cannibalized with margin collapse.

In 1994, Gap Inc. launched Old Navy as a completely separate entity. Different stores, different teams, different price points, all sitting on Gap’s supply chain. Old Navy didn’t just target different customers. It targeted a different decision calculus.

Amazon needs to do the same thing with cloud. Call it Ziroh. Zero configuration, zero friction, zero legacy. Amazon’s second cloud. Not cheaper AWS, but a different category of cloud.

Ziroh is not just simplicity. Ziroh is Amazon attempting to re-own the deployment surface before abstraction eats them. It would be organizationally radioactive: fractured incentives, eroded internal power structures, channel conflict with AWS sales orgs, and revenue displacement Wall Street would initially punish. That’s the cost. The alternative is someone else owning the interface permanently.

What Ziroh Actually Looks Like

Ziroh is a completely independent cloud provider. Separate brand, separate engineering team, separate culture. It piggybacks on Amazon’s physical infrastructure but inherits zero architectural debt from AWS.

The details matter less than the constraint: Ziroh must be simple enough that an AI agent can provision a production workload without human intervention, and opinionated enough that there’s no configuration surface to reason about. Identity-scoped networking, not user-managed graphs. Declared intent, not security group rules. Deployment in seconds, not YAML files.

Ziroh would deliberately remove whole categories of configuration surface. No user-managed networking graphs. No cross-service IAM policy authoring. No public load balancer primitives. If a workload cannot fit within the opinionated model, it does not belong on Ziroh. That’s the point. These are engineering decisions, not breakthroughs. Amazon has the talent. The constraint is backwards compatibility, which is exactly why Ziroh can’t be built inside AWS.

The One-Way Door

One rule makes or breaks this, and it is non-negotiable: Old Navy is allowed to steal from Gap, but never the other way around.

Ziroh cannibalizes down. AWS Classic never gets to reach down and pull Ziroh back into its orbit. No “integration” initiatives. No shared IAM layer for “consistency.” The moment the legacy organization touches Ziroh, the architectural debt infects it.

This runs against every instinct of a large organization. Product managers want synergies. Engineering directors want to reduce duplication. VPs want portfolio collaboration. Every one of these impulses will kill Ziroh.

Gap learned this the hard way. When Old Navy outperformed, Gap blurred the lines. Share designers, align aesthetics, create “brand coherence.” It diluted both. Separation is the architecture. The wall is load-bearing.

Why Amazon Won’t Do This

No executive will stand on an earnings call and tell Wall Street the $129 billion business needs a parallel replacement. Amazon has every tool it needs to succeed. The cash machine prevents them from using any of it.

Bezos stepped back to Executive Chair in 2021. Jassy became CEO of Amazon. Garman took over AWS in 2024. None of them have incentive to torch short-term margins for long-term structural advantage. That’s a founder’s move, and the founder is busy with Blue Origin.

Ziroh would require new thinking, new teams, and new willingness to let a second brand compete for the same developers. That’s a thought leadership investment, and it’s harder to justify on an earnings call than concrete and silicon. AWS is Amazon’s profit engine. Proposing an independent competitor from within is a career-jeopardizing move, even if it’s the right strategic decision.

The Signal

Watch the money. Capital is flowing toward abstraction platforms. Investors are betting that abstraction, not raw cloud primitives, defines the next era of infrastructure.

Watch Microsoft and Google. If they start acquiring or building opinionated deployment platforms instead of competing on the same 200-service complexity model, it means the hyperscalers themselves have accepted that the interface layer has migrated. AWS would be the last to admit it.

Watch the AI agents. Ask an AI agent to deploy a containerized application and higher-abstraction platforms frequently appear before raw AWS primitives. The default is already shifting.

Split or Be Split

AWS must split its identity before the market splits it for them.

If they refuse, Classic calcifies. Microclouds win developers. AI commoditizes compute. AWS becomes legacy infrastructure with compressing margins. Not death. Maturity.

But maturity without reinvention becomes irrelevance over time. Most executives are rewarded for preserving margin, not redefining eras. The evolutionary move is both strategically correct and culturally improbable.

That tension, between knowing what needs to happen and being structurally incapable of doing it, is the real story. By the time the pain is undeniable, the playbook is always the same: a late-cycle acquisition after the mindshare has already moved on, integrated into the existing platform for “synergies,” and the thing that made it attractive dies on contact with the legacy architecture.

Amazon must decide whether it wants to define the next decade the way it defined the last, or live the tech stalwart life of IBM and Oracle. History says it won’t be able to do both.

boring (adj.): infrastructure so opinionated it deploys itself, so stable it disappears, and so simple that an AI agent never needs to ask a follow-up question.