Better models won't fix your AI failures

A Google engineer built a command-line tool that wrapped Workspace APIs into a single scriptable interface, used it to move faster than the approved internal tooling allowed, and lost the job over it. Strip away the headline and the lesson has nothing to do with the CLI. The tool worked. It did exactly what a well-built automation layer should do: it collapsed a dozen manual steps into one repeatable command, removed the human cleanup that the official path required, and let one person operate at the throughput of a small team. The system functioned. The organization around it did not.

This is the part most people miss when they read the story as a personnel dispute. The failure was not technical and it was not really about one employee’s judgment. It was an orchestration failure at the company level. Google ships some of the most capable models and developer infrastructure on the planet, then runs internally on processes that treat unsanctioned automation as a threat rather than a signal. When the most capable people inside an organization build tools that outperform the approved workflow, you have two options: absorb the capability into the system, or punish the person and lose both the tool and the lesson. Google chose the second.

The deeper claim is this: companies are not failing at AI because the models are weak. They are failing because they have no operational layer for managing what happens when someone actually uses the capability. Capability is now cheap. A single engineer with API access and a weekend can build something that bypasses six months of roadmap. The scarce thing is the process that decides what to do when that happens - whether to govern it, integrate it, or kill it. Most large organizations have no such process, so disruption gets handled the only way an unprepared system knows how: by removing the disruptor.

The assumption underneath nearly every large company’s tooling policy is that workflows are stable and tools are the variable. You define the approved way to do something, you build or buy tooling that enforces it, and then you control change by controlling which tools people are allowed to run. Under that model, an unsanctioned CLI is a deviation to be corrected. It bypasses logging, it sidesteps review, it does work in a way the system did not anticipate. From a pure governance standpoint, the instinct to shut it down is internally consistent. The problem is that the assumption it rests on is no longer true.

That model was built for a world where building a tool was expensive and slow. When it took a team and a quarter to produce internal tooling, controlling the small number of tools that existed was a reasonable way to control how work got done. Scarcity did the governance for you. Almost nobody could build a parallel path, so the approved path was effectively the only path. The entire structure of access reviews, tooling allowlists, and workflow enforcement was designed around that scarcity. It assumed that the people doing the work could not easily route around the system, because building the route was harder than following the rules.

LLMs and accessible APIs broke that assumption without replacing the governance model that depended on it. The cost of building a working parallel path has collapsed. A competent engineer can now wrap an internal API, add a model in the loop for the messy parts, and produce something that genuinely works in an afternoon. The constraint that used to make tool-control sufficient - that almost nobody could build their own tool - is gone. But the policies, the review gates, and the cultural reflex that treats unapproved tooling as deviation are all still calibrated to the old scarcity. The organization is enforcing a model whose foundation has already been removed from under it.

This is why the Workspace CLI story is not an outlier. It is the predictable output of a system running on a stale assumption. When you keep a scarcity-era control model in an abundance-era environment, you guarantee a steady stream of people building useful things you did not authorize. The governance layer reads every one of those as a violation, because it was designed in a world where building your own path was rare enough to treat as suspicious. The mismatch is structural. It will keep producing the same outcome until the underlying assumption is replaced, not patched.

What changed is the location of leverage. For most of software history, leverage lived in the platform: whoever controlled the infrastructure, the approved tools, and the deployment pipeline controlled what work could happen and how. The individual operated inside boundaries the platform defined. That arrangement made tool-control an effective form of governance, because controlling the tools meant controlling the leverage. Now the leverage has moved down to the individual. Anyone with model access and basic engineering skill can manufacture their own leverage on demand, inside or outside the sanctioned boundary. The platform no longer holds a monopoly on capability.

The second thing that changed is the failure mode of the gap between policy and reality. There has always been a gap between how a company says work should be done and how it actually gets done - the unofficial scripts, the shared spreadsheets, the workarounds everyone quietly relies on. That gap used to be tolerable because the workarounds were small and slow, roughly the same order of magnitude as the official path. AI widened the gap to the point where a single workaround can outperform the entire approved process by a wide margin. When the unofficial path is marginally faster, the organization can ignore it. When it is dramatically faster, ignoring it becomes a competitive liability, and shutting it down becomes a visible act of choosing the slower path on purpose.

The third change is what disruption now costs the people who create it. In the old model, an employee who built an unsanctioned tool was taking a small, contained risk - a minor process violation, easily corrected. Today that same act exposes a structural truth the organization may not want surfaced: that the approved workflow is slow, that the official tooling is behind, that one person can do the work the system was built to spread across many. That is threatening in a way a small workaround never was, because it does not just break a rule - it demonstrates that the rule is protecting an inefficiency. Organizations without a process for absorbing that demonstration tend to treat the messenger as the problem, because the alternative is admitting the workflow is.

None of this is an argument that the engineer was simply right and Google was simply wrong. Unsanctioned tooling against production APIs carries real risk - security exposure, data handling, audit gaps, the possibility of one person’s convenience becoming the whole company’s liability. Those concerns are legitimate. The point is that they are operational problems with operational solutions: sandboxes, sanctioned API surfaces, fast-track review for internally-built tools, a path to promote a useful workaround into supported infrastructure. What changed is that the absence of those solutions is no longer a minor gap. It is now the single thing standing between an organization and the capability its own people are already proving they can build. The companies that win the next few years will be the ones that build the process to capture that capability. The ones that keep firing the person who demonstrated it will keep wondering why their official tools are always a year behind what their best engineers can make in a weekend.

Trace the path a homemade tool actually travels inside a large company and the firing stops looking like a decision anyone made. It looks like the only output a broken pipeline can produce. The detection layer works fine - access logs, API monitoring, and data-loss tooling all fire exactly as designed the moment an unsanctioned CLI starts hitting production endpoints. What does not exist is the next step: a classification node that asks whether the thing it just caught is a violation or a prototype. Without that node, every signal collapses into a single bucket marked unauthorized activity, and unauthorized activity routes automatically to the one function built to handle it - security and compliance, whose entire vocabulary is contain, revoke, and discipline. The tool was never evaluated as engineering. It was processed as an incident.

This is drift, not malice, and the distinction matters because it explains why the outcome repeats. Walk each handoff and every actor behaves correctly inside their own mandate. Security correctly flags an unmonitored path to sensitive data. Legal correctly notes the audit gap. The engineer’s manager correctly declines to put their name on production access nobody approved. Not one of those people decided to destroy a working capability, yet the sum of their locally rational moves is exactly that. No individual in the chain holds both the authority and the incentive to say this should become supported infrastructure, so that sentence never gets spoken. The decision to kill the tool is emergent. It falls out of the routing, which is more dangerous than a bad call by one manager, because you cannot fix it by replacing the manager.

The reason the drift is stable rather than self-correcting is a cost asymmetry baked into the structure. Promoting a homemade tool into something supported requires a named person to accept ownership, absorb the risk, and fund the maintenance - all of it visible, all of it accountable, all of it career exposure if it later breaks. Killing the tool requires nothing but enforcing a policy that already exists, which is invisible, defensible, and free. The incentive gradient points one direction at every node. Given a choice between owning a risk and citing a rule, an unprepared system picks the rule every time, and it keeps picking the rule no matter how good the tool or how senior the builder. Intentions do not enter into it. The gradient does the deciding.

There is a second loss layered on top of the first, and most companies never see it. When the tool dies, the signal dies with it. That CLI was a precise, free measurement of where the official workflow was slow enough to be worth routing around - a piece of operational intelligence the roadmap team would have paid for. Removing the tool and the person who built it deletes the data and guarantees the same gap gets rediscovered later by someone else, who builds the same workaround and meets the same fate. The mechanism does not just fail once. It erases the evidence that would let you stop it from failing again.

This is shadow IT running on a faster clock, and the shape is decades old. Finance analysts built Excel macros that quietly became load-bearing infrastructure no one in IT could see. Marketing teams put SaaS subscriptions on a corporate card because procurement took two quarters to approve a tool they needed that week. Engineers stood up unsanctioned cloud accounts because the internal platform could not give them what a public API gave them in an afternoon. Every one of those stories has the same skeleton: the sanctioned path is too slow, one capable person builds a parallel path, the organization discovers it late, and the reflex is control rather than absorption. The Workspace CLI is not a new kind of event. It is the latest instance of a pattern the enterprise has been losing to for forty years.

What is different now is the ceiling, not just the clock. Earlier shadow tooling produced roughly what the official tooling could produce, only sooner - a faster route to the same destination. AI-built tooling clears a bar the sanctioned process cannot reach at all. The analyst who wires a model into their reporting does not merely save a day; they generate output the official pipeline has no way to produce. The support rep running an unsanctioned model against the ticket queue is not cutting corners; they are operating at a quality and speed the approved macro was never capable of. The gap stopped being a matter of timing and became a matter of kind. That is why the modern version reads as more threatening to the organization - the workaround no longer just beats the schedule, it exposes a capability the official system structurally lacks.

Every prior wave resolved the same way, which tells you how this one ends. Excel chaos eventually produced sanctioned BI platforms. Rogue SaaS produced single sign-on and a procurement fast-track. Shadow cloud produced the internal platform team. Absorption always wins in the end, because the capability is real and the demand is real, and you cannot permanently police away something people need to do their jobs. The only variable is timing and cost. The organizations that absorbed early kept their builders, captured the tool, and turned a violation into infrastructure. The ones that fought it lost the people, lost the years, and then absorbed anyway - later, more expensively, and with a culture that had learned not to show its best work to management. The AI wave is the identical fork at higher speed. The destination is fixed. The price of getting there is the only thing still up for grabs.

You can read which branch you are on without waiting for a headline. The signs are concrete: a growing informal list of tools people do not mention to IT, power users who quietly route around the official platform, sanctioned tooling that runs a consistent release or two behind what the team actually uses, and a security function that meets every internal build with revocation rather than review. None of those are discipline problems, though they are almost always filed as discipline problems. They are a backlog signal wearing a compliance costume. The companies that read them correctly treat each shadow tool as a feature request with a working prototype attached. The ones that read them as insubordination keep the costume and lose the signal.

How a company responds to unsanctioned capability is the most honest measurement of its operational maturity, more honest than any AI strategy it has written down. A polished deck about adoption means nothing next to what actually happens when one engineer shows up with a tool that works. Firing that person is not a personnel decision, and it is not really about risk, however it gets documented. It is a confession. It says the organization built detection without absorption, control without integration, and policy without any path to turn a proven internal build into supported infrastructure. The firing is the system telling you, out loud, exactly which capability it is missing.

The capability is distributed now, and it does not go back in the box. Every competent person on the payroll can manufacture a working parallel path in a weekend, and the cost of doing it keeps falling while the payoff keeps getting more visible. You cannot police your way out of that condition - the math is permanently against the policy. The only response that holds is to build the intake the old model never needed: a classification step that separates a prototype from a breach, a sandbox where internal tools can run against safe surfaces, a promotion path with a named owner and a real budget, and a security function whose first move on an internal build is review rather than revocation. That is not a culture initiative. It is a piece of operational architecture, and it is buildable this quarter by anyone who decides the gap is worth closing.

So the choice is narrow, and it is already in front of every large organization. You build the layer that captures what your best people prove they can make, or you keep removing them one at a time and keep wondering why your official tooling trails your own engineers by a year. Google had the models, the infrastructure, and the talent to do the first thing. It did the second. The tool was never the problem and the engineer was never the problem. The missing operational layer was the problem, and it is still missing the next time someone inside the building opens a terminal and builds something that works.