A real-life incident has been circulating widely in developer circles: a company CFO (Chief Financial Officer), using AI coding tools, built a background batch job (Batch job) in just two days and deployed it directly to the production environment.
Because the task ran in the background and did not directly respond to real-time user requests, deploying it directly seemed reasonable at the time. In many people’s intuition, since it did not directly affect the user experience, any minor bug would not bring down the website or trigger a call to the on-call engineer.
No one expected that this seemingly harmless deployment would quietly snowball into a massive cost incident in the background.
It was only when the SRE engineer happened to check the billing dashboard that they noticed a massive, sharp peak in the API cost chart. The AI call cost for that single day was not only dozens of times higher than usual, but it also exceeded the total monthly server bill for the entire company. The system logs revealed that the same batch job had been automatically rerun 21 times in a single day, with each run incurring a full and expensive API bill.
In an earlier code audit, the engineer had also discovered that the CFO had hardcoded API keys directly into the source code. When told it was insecure, the CFO did modify it—by removing the keys from the code and pasting them into the README documentation instead. This disconnect from basic engineering standards paved the way for the subsequent cost incident.
Throughout the incident, no single part of the system actually failed: the LLM successfully returned the results, the database correctly rejected the invalid writes, and the task queue faithfully executed the retry logic. Everything operated according to the predefined rules, but the ultimate result was a massive amount of budget burned in the background.
From a traditional software engineering perspective, this incident is easily interpreted as a disaster caused by non-professional hands touching production. Traditional engineers might instinctively try to reclaim control, demanding that development and deployment be locked back inside the engineering team’s boundary.
However, from the perspective of historical trends, this defensive stance is futile.
Consider the early days of electrification in the late 19th century. Because early power grids were highly unstable and lacked safety devices, only highly trained, professional electricians could touch electrical wiring. If an ordinary person tried to wire a lamp themselves, they risked burning down the entire house. At that stage, control of electricity was the exclusive privilege of the electrician guild.
Yet, technology never stops just to protect professional monopolies. With the invention of standardized plugs, circuit breakers, and fuses, the power grid became safe enough for anyone to plug in appliances without calling the utility company. Ordinary people still trip breakers occasionally, but the grid’s safety mechanisms absorb these mistakes at the physical layer.
Today’s vibe coding—describing requirements in natural language and letting AI generate the code—is at a similar historical inflection point. A CFO can drive Claude Code to turn a business idea into a production feature in two days. This is a massive leap in commercial velocity and an unstoppable trend of technical democratization. To survive, businesses must move faster with less friction. Business people building and deploying software is as inevitable as ordinary people plugging in household appliances.
This incident is not an indictment of vibe coding; it is simply a milestone hurdle on the path of technological democratization. It shows not that non-engineers should stay away from production, but that our software infrastructure has not yet built the corresponding circuit breakers and fuses for non-technical creators.
The CFO felt safe deploying the task directly because of its nature: it was a background batch job.
Traditional peace of mind is built on non-real-time responses. In developer intuition, if a service synchronously responds to user requests, any failure is immediately visible, making it a high-risk area. On the other hand, background batch jobs, cleanup scripts, or offline data pipelines run late at night or in the background, away from direct user traffic, and are often treated as low-risk zones.
However, system behavior is changing fundamentally: computing steps are becoming financialized.
In traditional software architectures, API calls mostly involved data transport, and retrying a failed task consumed only CPU cycles and memory. Due to server depreciation or fixed cloud service quotas, even if a loop occurred, the physical cost of these pure-compute failures had a hard ceiling. The company did not have to pay extra for consumed CPU cycles.
But once LLM APIs and other pay-per-use interfaces (such as Tavily search, third-party SMS gateways, or micro-payments) are introduced, the nature of execution changes. Every API call becomes an atomic financial transaction. This means that retry logic is no longer just a logical recalculation; it is a real-time money transfer.
In this new paradigm, if safety frameworks and audit systems are not upgraded, traditional fault-tolerance designs turn directly into financial loopholes. For instance, a notification job that automatically retries could turn into a billing machine that repeatedly sends paid SMS messages. An automatic data scraper could exhaust its budget by repeatedly querying a paid search API.
This shows that cost control can no longer be treated as a post-hoc financial audit. It must be designed as a first-class security control in the system architecture. When computational steps carry direct financial side-effects, the boundary of safety protection must expand from preventing unauthorized access to preventing budget exhaustion.
Analyzing the technical details of the incident reveals a combination of three engineering flaws: reversed deployment order, automatic task queue retries, and a non-idempotent API loop.
First was the reversed deployment sequence. In the release that day, the team deployed code before database migration: the new code was live, but the migration script to add the new database column had not yet run on the production database. When the batch job ran, the code tried to access a column that did not exist yet, causing the process to fail.
Second was the misclassification of deterministic failures. When the
write failed, the database threw a column does not exist
error, and the task returned a 500. In traditional queue designs, when a
task dies with a 500, the managed queue automatically retries. This
default rule is designed for transient failures like temporary network
drops or timeouts.
But a missing database column is a deterministic failure. No matter how many times you retry, the missing column will not appear automatically unless the migration script runs. The retries were pointless.
Third was the non-idempotent design of the batch job. The batch workflow executed multiple LLM queries first and saved the results to the database at the very end. Because the task was not idempotent (it had no checkpoints to skip already-completed work), every retry started over from the very beginning.
This is where the counterintuitive behavior occurred: all the LLM
calls succeeded technically, returning 200 OK. The models
delivered the data, and the API provider billed for the tokens. The
failure only happened at the very last step when writing to the
database.
So, the retry mechanism cleared the failure record and restarted from the top. It called the LLM again, paid for the tokens again, and failed at the database write step again.
This is the opposite of a typical retry storm where a system is overwhelmed by failing requests. Here, it was a storm of throwing away successful, paid results and purchasing the exact same computation again and again.
It is like going to a restaurant, ordering food, paying the bill, but the system crashes right as the cashier prints the receipt. Because the receipt is not saved, the waiter assumes you haven’t eaten and makes you sit down, order the same meal, and pay the bill again. After repeating this 21 times, the receipt is still not saved, but you have paid for 21 meals.
Reversed deployment order, automatic retries on deterministic failures, and non-idempotent API loops. When these three flaws align, money burns quietly in the background.
Since business personnel deploying features directly is an inevitable historical trend, the engineering team’s job is not to ban the plugs, but to install circuit breakers in the walls. We must adapt our infrastructure to absorb the risks of low-friction development.
First, cost must be elevated to a first-class metric alongside security and availability.
Traditional rate limiters and circuit breakers are designed around QPS, concurrency, or error rates. In the AI era, we must introduce pre-call budget enforcement and retry budgets at the gateway or harness level. Every tenant and batch task must have a strict maximum cost ceiling. Once retries exceed this limit, the gateway must cut off communication with the model provider to stop the drain, rather than waiting for the invoice to arrive.
Second, idempotency protection for paid API calls should be built into the framework level by default, rather than left to application developers.
When a batch job calls expensive third-party models, the underlying harness framework should automatically cache and persist the returned results locally. On a retry, the framework should intercept the request and reuse the cached data. Computational results must be treated as high-value assets to prevent automatic retries from turning into repeated billing.
Third, risk tiers must be redefined to establish low-risk paths for business users while enforcing high-risk review gates.
Non-engineers should be free to experiment in sandboxes. Business logic that does not incur paid external side-effects and does not touch sensitive data should be classified as low-risk and fast-tracked for deployment. However, any task that involves external paid APIs, batch model calls, or direct production schema modifications must trigger staging validation and engineering review gates.
Finally, we need to establish best practices and training for non-engineers. Business creators do not need to understand concurrency or database engines, but they must learn a basic truth of the AI era: in code logic, loops have a price.
Claude Code allowing a CFO to turn an idea into a feature in two days is a massive win for democratization. But in this accelerated world, the classic rules of production environments have not disappeared.
As GitHub Copilot moved to usage-based billing in June 2026, every execution in software development is being precisely metered.
AI has dramatically shortened the time it takes to build a feature, but it does not inherit the operational responsibility of running it. When every rerun is tied to a real bill, termination conditions become the most critical production metric.
The role of the engineer is shifting from writing code to designing the safe power grid. We cannot stop business users from plugging in their appliances, but we must ensure that when a wire is crossed, only the fuse blows—not the company’s bank account.