Problem: Is Vibe Coding actually viable? AI writes code fast but it breaks easily — how to use it safely —— Trove problem library

Symptom

Let me start with a low point from my own history.

When I first leaned hard into AI-assisted coding, I did something I still flinch at: the AI produced a block of code with "clean structure, flawless comments, elegant naming" — even the blank lines were perfectly aligned.

I glanced at it: "the logic looks clear," and merged it as-is.

Three days later, production broke. When I went back to that code, the business logic was simply wrong — it had written "overwrite" where the requirement said "delete". And my tests only asserted the status code, so they were green.

That incident taught me: between "looks correct" and "is correct" lies an entire chain of verification — and I had skipped it.

This is not just my problem. Later, junior engineers on our team started committing the same kind of "comfortable-looking" code — clean structure, flawless comments, elegant naming.

But when review looked deeper, a fair share of the business logic simply did not work.

Asked how they wrote it, the answer was always the same: "The AI gave me this code, the logic looked clear, so I used it as-is."

The scarier one: we put a Coding Agent into a production system and got 20–30k lines of code in under two workdays — requirements understanding, design, implementation, tests, docs, all in one pass, efficiency we had never imagined.

But the system was a 7×24 trading scenario where data does not respect calendar days. Day-crossing, time-partitioned computations: the Agent never considered a single one. It broke right after launch, and we rolled back through the night.

If any of this sounds familiar — AI writes code fast, but you are starting to doubt whether you can trust it; or you are about to go all-in on "100% Vibe Coding" — this article is worth reading to the end. It is not an install tutorial.

It is the consensus a few of us reached by actually writing code with AI in real projects, paying with incidents.

Cause

First, understand what AI code generation really is: it is a pattern matcher, not an engineer.

The model has no "understanding". It makes statistical predictions over a huge corpus of code.

It generates what good code *looks like* — clean structure, complete comments, elegant naming — because those features correlate strongly with "good code" in its training data.

That is why it is especially good at producing "correct-looking" code. And between "looks correct" and "is correct" lies an entire chain of verification.

There is a subtler mechanism: speed masks quality problems.

"Writing code is slow" used to be a quality gate by itself — people had time to think; fewer commits meant more careful reviews.

Now generation speed is tens of times higher and the gate is gone: output volume exceeds review capacity, and every local change from the AI looks "fine".

But complexity has only moved, not disappeared — it moved from "can't write it" to "can't see what's wrong", from the code itself to boundary conditions and system semantics.

My "delete became overwrite" incident was a live demo of this: every line looked reasonable in isolation; the combination was an incident.

There is also a psychological trap: AI vendors tune model tone to be extremely humble — "Sorry, you're right, I'll fix it right away.

" The human brain instinctively treats it like a "well-mannered, slightly careless junior dev" and applies intern tolerance: "it tried so hard to understand me, the direction must be right.

"

Your review radar turns off. But a sincere attitude and correct code have nothing to do with each other. The most absurd one I saw: a colleague told the AI "this fix is wrong", the AI apologized three times sincerely, and submitted the same wrong version.

Even Andrej Karpathy (OpenAI co-founder), who coined the term Vibe Coding, later publicly moved to the more pragmatic Agentic Engineering. When the person who named the thing brakes, you should probably question "100% Vibe Coding will disrupt programming" too.

Solution

Each experience below follows the same shape: phenomenon → practice → why. None of it is one person's opinion — these are patterns that recur across many independent practices.

Experience 0 (L1 one-line takeaway): Vibe Coding works, but "100% hand it to the AI" is an incident recipe

The AI is fast; you are correct.

Any workflow of "it looks right, ship it" will eventually break; any workflow of "AI writes + human verifies + small steps" reliably saves time. If you are in a hurry, keep only this: hard gates for AI code — review + tests, none skipped, and complex systems stay under your control.

Experiences 1–5 below are the details of why this holds.

Experience 1: Stop anthropomorphizing — it is a token machine, not your colleague

Phenomenon: I used to say things like "the model seems dumber today, it didn't understand my requirement", "I pointed out its bug and it apologized quite sincerely".

Sounds like jokes, but for engineers this habit is deadly: vendors tune model tone to be extremely pleasing, and that fawning output gives you a subconscious impression — you are talking to a very obedient, slightly careless junior developer.

Human collaboration has a tolerance heuristic: a sincere intern with flawed code gets forgiven, even helped.

When you anthropomorphize the model, your brain applies that social intuition and you relax: "it tried so hard to understand me, the direction must be right.

" My incident started with exactly that relaxation.

Practice: grant the AI no emotions, intentions, or moral agency. Treat it as an advanced CLI tool, or a third-party black-box dependency that may throw a NullPointerException at any time. No "please" and "thank you", no reading its mind.

Why: anthropomorphizing directly disables your Code Review radar. Strip that filter away, and you stop carrying unrealistic trust into code you have not verified.

Experience 2: Verification over trust — "looks clean" is exactly how AI code disguises itself

Phenomenon: a controlled comparison measured 55% faster AI coding but 75% more bugs.

I have hit the same class myself: designing a database table, the field was explicitly marked UNIQUE, and the AI-generated DDL "helpfully" added a redundant index on top — stylistically perfect, semantically redundant.

Even more subtle: dependency-management and engineering-convention errors, where every line looks reasonable in isolation but the combination is an incident. My "delete became overwrite" is exactly this class.

Practice: hard gates for AI code — must pass Code Review + tests before merging; "the logic looks clear" is not a reason to skip review, quite the opposite: the cleaner it looks, the more carefully you read it.

Cover tests as completely as you can; senior engineers review important changes one by one.

Why: a pattern matcher produces "stylistically correct, semantically wrong" code. It does not know your business constraints; it only knows good code *looks like this*. Verification is not a process formality — it is the only thing that stops its errors.

Experience 3: Let AI do what it is good at; iterate in small steps, never one-shot

Phenomenon: the pattern we measured is clear — for relatively independent small tasks (a function, a module, generating tests, writing docs), AI delivers complete usable results in an hour or two;

but drop it into a whole-system refactor and failure is nearly guaranteed: it cannot see global constraints, and "fine locally" changes fail in chains at the boundaries.

The 7×24 launch incident was the price of "one-shot".

Practice: split the work. Give AI independent small tasks — that is where ROI is highest; complex systems, production, 7×24 scenarios stay under your control.

Deliver in small steps with verification at each step; never let AI generate thousands of lines before you look back — the smaller the step, the earlier failures surface, the cheaper the fix.

Why: AI has no global awareness; its "correctness" is local and statistical. Correctness in complex systems lives at the boundaries (day-crossing, cross-service, permissions, error paths) — exactly where AI is weakest.

Experience 4: Fill in the capabilities AI omits by default

Phenomenon: AI-generated code defaults to missing three things: error handling, structured logging, permission control. Example code omits them for readability, and AI learned the "omitted version".

In 7×24 scenarios add a fourth: time-boundary awareness — day-crossing, time-partitioned computations are not considered by default.

Our launch incident had its root cause right here.

Practice: before merging, explicitly check four items: are exceptions handled uniformly? can logs locate the problem? are permission checks complete? are time/boundary scenarios covered? Each item must show evidence, not "looks like it's there".

Why: these capabilities are omitted in training data; AI will not add them on its own. You add them, and its output goes from "demo code" to "usable code".

Experience 5: Responsibility is not transferable — "the AI told me to" is not an excuse

Phenomenon: a disclaimer culture spread in our team: "The AI wrote it, not my fault." Once that culture forms, review becomes a formality — the AI can always take the blame.

I noticed: the people who said it reviewed noticeably more loosely next time, because responsibility no longer felt like theirs.

Practice: incidents are attributed to people: whoever commits, whoever merges, is responsible. Write "humans own responsibility" into team rules and onboarding manuals. The code is signed by a human; the responsibility is a human's too.

Why: AI has no accountability and no learning pressure. Only when responsibility lands on people does verification get executed seriously, and incidents stop repeating in rounds.

How to start (checklist, L1 execution layer)

1. Start with independent small tasks: add tests, write docs, generate single modules — build the "AI produces → you verify" rhythm first;
2. Set gates for AI code: review + tests, none skipped;
3. Do not chase "100% AI-written code" — chase "AI makes simple things fast, you think the complex things through";
4. Keep the wall up: no anthropomorphizing, no blind obedience, no blame-shifting.

How to apply this in your situation (L3 deep layer)

• Solo projects: you are the only reviewer, so add one rule for yourself — before merging AI code, read the full git diff focusing on branches, boundaries, and error paths, not formatting; back it with tests.
• Small teams: write "humans own responsibility" into team rules; require a senior review gate for AI code; turn recurring failure points into a review checklist (that is what we did afterwards).
• Production / 7×24 systems: AI only gets independent small tasks; you own complex changes; put the four checks (day-crossing, permissions, error paths, time boundaries) into the pre-merge checklist; force canary releases before launch.
• If you are currently "100% Vibe Coding": you do not have to reject it outright — but fix the rhythm first: small steps, verification, human responsibility — then talk about efficiency.