Every post about AI attracts the same comment, worded slightly differently each time: "Wait until your vibe-coded thing drops in prod \u2014 and then…"<\/p>\n
What "and then"? I genuinely can't tell. We'll throw out the AI and get on our knees begging you to fix it? Unlikely.<\/p>\n
The comment usually does not specify the failure scenario. Not an argument \u2014 a trailing-off. The implied assumption is that a production failure caused by AI is categorically worse than any other production failure. So let's spell it out. Let's take that "and then" and break it into concrete actions, by the size of the organization unlucky enough to drop production.<\/p>\n
<\/p>\n
If we're talking about an enterprise organization, it already has an incident response protocol and an on-call team. A critical bug is usually rolled back, hotfixed, or mitigated according to the incident process. Support sends a customer notice. If an SLA is breached, the company may issue credits or other compensation according to the contract. A postmortem or retro follows. The root cause or reproduction case should be added to tests, evals, or runbooks where possible \u2014 both into the eval set for the same agent and into the automated tests.<\/p>\n
The useful part is converting the incident into a reproducible regression case. A bug that once passed all tests and still took down prod becomes, after the postmortem, a line in the eval harness. If the regression is encoded well, future releases can be blocked when the same failure is detected. The failure mode people love to weaponize \u2014 "what if AI passes the tests but introduces an uncovered pattern" \u2014 is one of the cases the process is supposed to absorb after discovery. The process feeds from exactly that point.<\/p>\n
For teams with mature incident response, this is a routine procedure. In a large company, some service, dependency, or internal system is often degraded or under repair \u2014 and was, long before any AI showed up.<\/p>\n
If it's a small business, the owner will probably paste the error logs straight into Claude. Claude may help identify the cause, draft a fix, and document the lesson for future sessions. A concrete version of this workflow is: an agent that records its own root causes into its working memory reduces repeated mistakes of the same type \u2014 the For SMBs, this is how it has worked for decades \u2014 just by hand. They're no strangers to production breakage. They have often depended on overworked, inconsistent, or unavailable contractors and developers and have already "dropped" dozens of times. One practical difference is: they used to wait for a fix from a person with limited availability and competing obligations. Now they paste logs into Claude, and the tool is available immediately, assuming the owner can provide enough context and verify the fix.<\/p>\n If it's someone advanced with AI \u2014 like one solo developer I worked with \u2014 Claude can automate most of the loop if deployment permissions, tests, and rollback paths are already set up.<\/p>\n In one case, the deployment rate was high enough to make manual release management impractical. The actual number in this case was 10\u201315 deploys per day: this person, solo with AI, rewrote a decade-old codebase and reported no user-visible outages over six months at 10\u201315 deploys per day. Small scoped changes were planned, implemented, and deployed in roughly 30 minutes. This does not prove crashes are impossible, but it weakens the claim that frequent AI-assisted deploys inevitably cause outages.<\/p>\n This is the failure scenario critics usually gesture at, but the observed recovery loop is less dramatic: a workflow where detection, diagnosis, and patching can be faster than a manual handoff.<\/p>\n In many organizations with basic incident handling \u2014 from an enterprise with a dedicated on-call rotation to a solo owner with one Claude session \u2014 a production outage is not automatically a catastrophe. It becomes an incident record, a fix, and ideally a regression test or runbook update. The fear is often asserted without specifying the operational consequences: it rests not on what happens, but on the ellipsis after "and then…"<\/p>\n What do these critics making this argument mean, the ones threatening us with a production drop? I have no idea. Without a concrete failure path, the objection remains too vague to evaluate.<\/p>\n","protected":false},"excerpt":{"rendered":" Every AI post attracts the same comment: ‘wait until your vibe-coded thing drops in prod.’ Let’s walk through what actually happens next \u2014 by company size.<\/p>\n","protected":false},"author":0,"featured_media":120,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-121","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tdecisions.md<\/code> + mistakes.md<\/code> pattern is intended to work this way. That is the operational difference I care about here.<\/p>\nAdvanced operator: Claude can process logs and propose or apply a fix<\/h2>\n
What concrete failure path is being predicted?<\/h2>\n