From edf09c281d0e7cbe857a69dee4fa0ad39188226f Mon Sep 17 00:00:00 2001 From: arsam Date: Fri, 18 Sep 2026 23:26:42 +0330 Subject: [PATCH] Import source: global/article-contents-en-5 Import the existing local project snapshot. This commit organizes existing files; it does not represent newly developed functionality. --- global/article-contents-en-5.js | 55 +++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 global/article-contents-en-5.js diff --git a/global/article-contents-en-5.js b/global/article-contents-en-5.js new file mode 100644 index 0000000..701b58b --- /dev/null +++ b/global/article-contents-en-5.js @@ -0,0 +1,55 @@ +export const ART_EN5_CONTENT = ` +
+

At 3:17 AM on a Tuesday, the on-call engineer got paged: checkout was broken, transactions were silently failing, and the error logs showed something that looked like it had been written by someone who had never heard of error handling. The code had shipped three weeks earlier. An AI had written most of it in an afternoon. This is a post-mortem on what vibe coding looks like when it meets production.

+ +
+ AI-generated code in production: technical debt and failure patterns from vibe coding +
Vibe coding — using AI to generate code by describing intent rather than writing implementation — ships features fast but accumulates structural technical debt that manifests at the worst possible time: when the system is under load and a human needs to debug unfamiliar code at 3 AM.
+
+ +

1. What Vibe Coding Is (and Isn't)

+

Vibe coding is a term coined by Andrej Karpathy in February 2025 to describe a workflow where you describe what you want in natural language, let an AI assistant (Claude, GPT-4o, Cursor, GitHub Copilot) generate the implementation, test it superficially, and ship it — with minimal review of the actual code. The name captures the experience: you're working by feel and intention rather than by reading and reasoning about every line.

+

Vibe coding is not the same as using AI coding tools responsibly. A developer who reviews every AI-generated function, understands what it does, writes tests for edge cases, and then ships it is using AI assistance, not vibe coding. The vibe-coded workflow is characterized by skipping the understanding step: the code works on the happy path, it looks reasonable, ship it.

+

This distinction matters because the term has become pejorative in some circles and evangelized in others, but the actual failure mode is specific: understanding debt. When nobody on the team has read or understood the AI-generated code, nobody knows how it fails, what its invariants are, or how to modify it safely. That debt accrues silently until it collects — usually in production, usually at an inopportune time.

+ +

2. The Incident: Anatomy of a 3 AM Failure

+

The incident that prompted this post-mortem involved a payment processing integration. The feature: allow users to apply a discount code at checkout, with inventory reserved while payment was processed. Simple enough on paper. An engineer spent an afternoon with Claude generating the implementation — the discount validation logic, the inventory reservation call, the payment API integration, and the rollback logic.

+

The code worked in development. It worked in staging. It passed the manual test cases the engineer ran. It shipped on a Thursday.

+

Three weeks later, under a flash sale that drove 8x normal checkout volume, the system started silently dropping transactions. Inventory was being double-reserved, payments were succeeding without inventory being marked as sold, and some users were receiving success confirmations for transactions that had actually failed. The error logs showed nothing useful — there were effectively no error logs for the failure path, because the AI had generated a try/catch block that caught all exceptions and returned a generic success response rather than propagating the error.

+

The root cause was a race condition in the inventory reservation. The AI-generated code used two separate API calls — first check availability, then reserve — without any locking mechanism. Under normal load, the window between the two calls was small enough that collisions were rare. Under 8x load, concurrent requests were hitting that window constantly. The code had no concept of optimistic locking, no idempotency key on the reservation call, and no retry logic that could distinguish a transient failure from a duplicate.

+ +
"The code did exactly what I asked it to do. I asked it to make checkout work. It never occurred to me to ask it to make checkout work correctly under concurrent load." — engineer retrospective, incident post-mortem
+ +

3. The Technical Debt Pattern in AI-Generated Code

+

After reviewing the generated codebase, several debt patterns emerged that are characteristic of vibe-coded production code:

+

Missing error propagation. AI assistants have a strong bias toward generating code that handles the happy path completely and handles errors generically. A catch (e) { console.error(e); return null; } pattern appears frequently — it prevents runtime crashes but silently swallows failures, making debugging nearly impossible.

+

No idempotency design. Idempotent operations — where calling the same function twice with the same inputs produces the same result as calling it once — are a fundamental property of reliable distributed systems. AI-generated API integration code almost never includes idempotency keys unless you explicitly ask for them. The checkout code lacked an idempotency key on the payment API call, which meant network retries could result in double charges.

+

Race conditions in async flows. LLMs generate syntactically correct async/await code readily, but generating code that is correct under concurrent execution requires reasoning about shared state that LLMs handle inconsistently. The generated code had multiple patterns where a value was read, then an async operation was performed, then the value was written back — a classic time-of-check-to-time-of-use (TOCTOU) race condition.

+

No observability hooks. Production-ready code includes structured logging, metrics emission, and trace spans. AI-generated code typically includes console.log at best, and often nothing. Debugging a production incident in code with no structured logging is significantly harder than it needs to be.

+ +

4. The Definition of Done Problem

+

The engineering practice of Definition of Done (DoD) exists precisely to prevent the "it works on my machine" failure mode. A DoD checklist for a feature might include: unit tests for edge cases, integration tests for the critical path, error handling for all identified failure modes, logging for all state transitions, code review by at least one other engineer.

+

Vibe coding systematically skips most of these gates. The AI writes the code; the developer tests the happy path; the feature "works." The absence of tests is the most damaging omission — not because tests catch bugs at write time (though they do), but because tests document the assumptions and invariants of the code in an executable form. When the AI-generated checkout code was examined during the incident, there were zero tests. Nobody could answer basic questions: "Is this function supposed to be called once per transaction, or can it be called multiple times safely?" The code didn't say, and there were no tests to interrogate.

+ +
+ AI Code Review Prompt That Actually Works: After generating code with any AI assistant, follow up with this prompt before committing: "Review this code for: (1) race conditions and concurrent execution safety, (2) error propagation — is every error either handled meaningfully or propagated to the caller?, (3) missing idempotency on external API calls, (4) cases where the code returns success when an error occurred. List specific line numbers for any issues found." This meta-review prompt consistently surfaces the categories of issues that vibe coding misses. +
+ +

5. Structural vs Cosmetic Technical Debt

+

Not all technical debt is equal, and the debt from vibe coding tends to be structural rather than cosmetic. Cosmetic debt — inconsistent naming, missing comments, duplicated logic — is annoying but doesn't cause 3 AM pages. Structural debt affects the system's behavior under load, failure conditions, or modification.

+

Structural debt from AI-generated code tends to manifest in three categories: missing failure handling (the system doesn't fail gracefully — it fails silently or catastrophically), incorrect concurrency assumptions (the code was written as if only one thing happens at a time), and tight coupling to implementation details (the AI-generated abstraction layers are often thin enough that changing one component requires changing everything that touches it).

+

The repair cost for structural debt is disproportionately high because it requires understanding code that nobody on the team fully understands — the people who "wrote" it didn't read it carefully, and there are no tests to constrain the refactoring. The incident described above required two days of investigation before the root cause was identified, and another three days to implement a proper fix with idempotency, locking, and correct error propagation.

+ +

6. What Responsible AI-Assisted Development Looks Like

+

The goal is not to avoid AI coding tools — they are genuinely useful and will become more so. The goal is to close the understanding gap that vibe coding leaves open. The practices that make AI-assisted development reliable rather than dangerous:

+

Read everything before committing. This sounds obvious, but it is violated constantly under deadline pressure. If you cannot explain what a piece of AI-generated code does, you should not commit it.

+

Write tests as a comprehension exercise. Writing tests for AI-generated code forces you to understand its behavior. If you cannot write tests for a function, you do not understand it well enough to ship it.

+

Ask for failure modes explicitly. After generating implementation code, ask the AI: "What are the failure modes for this function? What happens if the database is unavailable? What happens if this is called concurrently?" The answers will often reveal missing error handling that the initial generation omitted.

+

Don't skip code review for AI-generated code. The social contract of code review — that a second human reads and understands the code — is more important for AI-generated code, not less. AI assistants produce confident-looking code that can be subtly wrong, and the review step is the check that catches it before production.

+ +
Note: The incident described in this article is a composite based on documented production incidents shared in engineering post-mortems across multiple organizations. Specific identifying details have been changed. The failure patterns — race conditions, swallowed errors, missing idempotency — are representative of recurring themes in published AI coding incident post-mortems from 2024–2025. Karpathy, A., "There's a new kind of coding I call 'vibe coding'" (X/Twitter, February 2025).
+ +

Conclusion: The Understanding Gap

+

Vibe coding is a reasonable workflow for throwaway scripts, personal projects, and rapid prototyping where production consequences are limited. It is a liability for code that handles money, user data, concurrent operations, or any system where silent failure is worse than visible failure. The 3 AM incident traced back to a single unchallenged assumption: that code which works correctly in development will work correctly in production under concurrent load. AI assistants will confidently generate code that violates this assumption without flagging it. Reading the code, testing its behavior, and reviewing it with a second human are not bureaucratic overhead — they are the checks that close the understanding gap that vibe coding leaves open.

+
+`;