You describe the feature in a paragraph. The model writes a few hundred lines. The tests pass — at least the ones it also wrote. You merge before lunch.
That loop has a name now: vibe coding. You don't sit down and design the system so much as describe the outcome you want, then keep prompting until the thing on the screen looks like what you meant. A year ago this was a party trick. Now people are shipping products this way.
I understand the pull. Software has always had a high wall around it: syntax, tooling, years of scar tissue. For anyone who has stood on the other side of that wall, this feels like someone finally handed them a key. Speak the idea. Watch a working app appear. The idea gets to matter more than whether you remember the right hook.
The trouble starts after the demo.
When the vibe fades
These models are trained on public code. Public code is full of old habits, copied vulnerabilities, and patterns that were fine in 2017. The model will reproduce all of it, with the confidence of someone who has never been paged at 2 a.m.
That's the obvious risk. The worse one is quieter.
Every time you accept a block of code you don't understand, you take out a loan against your own competence. You can still command the system. You cannot repair it. The next bug isn't a debugging session. It's another prompt, then another, hoping the same model that made the mess can also explain it.
Do that for six months and you don't have a codebase. You have a black box with a product wrapped around it. And you are the person who is supposed to own it.
This does not stay an individual problem. Teams that ship this way end up with systems fewer and fewer people can actually read. Fragility looks like velocity until the first real outage.
Treat it like a junior
I still want people using these tools. I use them. Going back to a blank editor out of principle is nostalgia, not craft. The question is how you receive the output.
Think of the model as a very fast junior who has read the entire internet and remembers none of your production incidents. You would not merge that junior's pull request unread. You would not let them invent the auth scheme, skip the tests you asked for, or "simplify" the payment path because the prompt was vague. You would sit with the diff.
If you review the code, test it, and can explain the parts that will hurt you later, you are using a tool. The moment you can no longer explain the PR, you have crossed into vibe coding.
Ask it why, not just how. Why this query shape. Why this state library. What it would do differently if the table had ten million rows. Use it as a tutor that happens to also type. The feature is the byproduct. The point is that you still understand the system you are responsible for.
And when it generates something in a stack you don't know — a React server component, a migration, a retry policy — go read the docs for that thing. Not a course for its own sake. Just enough that the next prompt is coming from you, not from the model's last guess.
Whoever ships the code has to be able to own it at 2 a.m., when a customer is stuck and the model is confidently wrong. Formal training is one way to get there. Reading the diff is another. Pretending you don't need either is how you bounce the check.
The check you have to cash
The pressure to produce is real. These tools make it easy to look done. Looking done is not the same as being able to live with the code.
Vibe if you want. Merge when you can defend the diff.