Only a year ago, putting together a working application from a single description in plain language was a party trick people bragged about on Twitter. Today that is how internal tools get built in teams that used to wait months for a slot in a developer’s queue, and nobody finds it remarkable any more. Vibecoding has stopped being a sideshow and become something anyone can simply do — much the way building a website without knowing HTML once stopped being a miracle.
Along with that, a stock reply has appeared in developers’ conversations, and I hear it constantly now: “vibecoding is not coding.” It is delivered in every possible tone, from the condescending to the openly angry, but the meaning is always the same: what those people are doing does not count. I thought that way myself for quite a while, and that is exactly why I want to work out why it is a bad reaction — not because it is factually wrong, but because it misses the target and spoils the person who says it.
Where the irritation comes from
It is worth starting with the fact that the irritation is entirely understandable. Behind the person feeling it lie years spent on things nobody sees from the outside: algorithms that had to be learned twice, nights spent debugging someone else’s code without a single line of documentation, postmortems in which it turned out that you were the cause yourself, and the slowly collected bruises out of which professional instinct is eventually made. And right next to that, someone describes a task in the words they would use with their grandmother, and gets the result in one evening.
It feels as though the part that was hard is precisely the part being devalued. As though years of experience had collapsed into an ability to phrase things neatly in plain language. This is not greed and not snobbery — it is an ordinary human jealousy over one’s own labour, and it would be strange not to feel it. The problem is not the feeling but the conclusion drawn from it.
Honestly: I thought the same
At first I caught myself on exactly that thought — nonsense, not serious, toys for people who do not want to learn properly. I watched a couple of demos, looked inside the resulting code, saw things there I would not let into prod even at the point of a deadline, and calmed down: not a competitor.
The mistake was not in my assessment of the code — the code really was mediocre. The mistake was that I was comparing the wrong things with each other: someone else’s result after one evening against my own result after months of work. The comparison that would have made sense sounds different — what I myself can do with this tool, and how that will differ from what I do without it. The moment I put the question in that form, there was no one left to argue with.
The tool does not level, it amplifies
It turned out that the better a person understands how systems are built, the more they get out of code generation. That contradicts the first impression — you would think a tool that writes code for you ought to level out the strong and the weak. It does not level anything out; it multiplies what is already there.
The reason is simple: an engineer’s work never did come down to typing text. It begins long before the first line — with framing the problem, where you have to formulate not only what the result should be, but also what happens when everything goes wrong: what we do on a timeout, what we do when two requests race each other, where the load limit lies beyond which the solution stops working. Half the problems of the future task are visible right here, and they are visible to the person who has already stepped on them.
Next you need context the model cannot know in principle: how this particular service is put together, why there is a queue here rather than a direct call, which decisions were already taken and written down a year ago and why they should not be reopened along the way. Then the resulting code has to be read with the eyes of the person who will answer for it in prod — which means looking not for typos but for the quiet places: an unhandled timeout, idempotency lost somewhere along the road, a query that works beautifully on a hundred test rows and falls over on a real million. And finally all of it has to be rolled out, the metrics watched, rolled back if it went wrong, and answered for — that part is delegated to absolutely no one and is covered by no tool at all.
Generation covers the middle: the actual writing of the code, the very part that was already the fastest for an experienced person. The edges stay where they were, and it is in them that everything an engineer is paid for lives.
Two different occupations under one name
This, it seems to me, is where the whole argument grows from: one word is used for two different things, and then people are surprised that they cannot come to an agreement.
The first is vibecoding as entertainment and as a way into the profession. Someone puts together something of their own, takes pleasure in the fact that what they had in mind works, and sees a result they would never in their life have seen without this tool. For most of them it will stay an evening pastime, and there is absolutely nothing wrong with that. More than that, it is through such trifles that new people come into the industry — and they come several years earlier than they would have come through a textbook on algorithms, if they ever arrived at all.
The second is an engineer who uses generation professionally. The tool is exactly the same, but the tasks are of a different scale and carry a different cost of error: data migrations that cannot be replayed, integrations with someone else’s payment systems, rewriting a service that is holding load right now, infrastructure you answer for with night shifts. This is no longer vibecoding in the sense in which the word is usually used — it is engineering work in which generation stands in the same row as the debugger and the profiler, and just as surely decides nothing on its own.
The difference, in short, is not in the tool but in what happens before it and after it.
About the musician at his friends’ gig
When an engineer, in reply to “but you’re vibecoding,” starts explaining that he is not vibecoding at all but doing real, difficult work, he is arguing about a word — and from the outside that looks not like an argument but like a defence of status, whatever he may actually have meant.
I like the comparison with music here. Picture a musician from a good orchestra who has come to a concert by his friends’ band: they got together six months ago, they play in a garage, they miss half the notes, the drummer rushes. And there he is all evening, wincing and telling everyone around him how bad this is and how much he dislikes it. Formally he is absolutely right — they really do play worse than he does. In human terms he has simply ruined the evening for people who took nothing away from him.
The people putting together their first application from a description today are the friends in the garage. They are not laying claim to a seat in the orchestra and they are not taking it away from anyone. Some of them will come a year from now to learn to play seriously, and it will be precisely because they had a good evening, not because someone explained to them how bad they were.
How to answer it
So when you are told that you are vibecoding, the best thing you can do is not to take offence. Smile and agree: yes, and I do it brilliantly and professionally. After that the conversation either moves into a normal professional channel or ends — and both options are better than an argument about terms.
Along the way I have forbidden myself three things. Not to prove that my work is difficult: if its difficulty is not visible in the result, no words will explain it, and if it is visible, there is nothing left to explain. Not to correct other people’s terminology: the phrase “this isn’t vibecoding, it’s engineering with code generation” has never yet made anyone smarter, but it reliably ends the conversation. And most importantly — not to devalue someone else’s interest: a person showing you a thing they put together over the weekend is not waiting for a review, what they need is for someone to notice that they made it at all, and that is worth saying out loud even if inside there is terrifying code and three hardcoded passwords.
The last of these matters more to me than the first two. Interest is the rarest and most fragile resource in our profession: it is put out with a single condescending comment, and lighting it again afterwards almost never works.
What this means for an engineer
The skill does not disappear, it shifts. Value moves out of the speed of typing code — where, frankly, there was never much of it to begin with — and over to where there was always the most of it: understanding the domain, framing a task so that it can be solved at all, seeing the boundaries, and answering for what runs in prod at three in the morning.
That, incidentally, is exactly the same set the team lead is responsible for — there was a separate post about it. And it is exactly what cannot be generated: no model knows what downtime counts as acceptable at your company, why the last migration was rolled back at the final moment, and whom you need to talk to before touching this service.
And how a working everyday tool gets assembled out of generation — projects, goals, routine — I will tell separately, closer to December.
In short
⬜ Vibecoding has gone mainstream; arguing with that is too late and pointless
⬜ The tool does not level, it amplifies: the better you understand systems, the greater the return
⬜ Generation covers the middle of the work, but not the framing, the context, the review or the responsibility
⬜ Entertainment and engineering work share one word — they are different occupations, and both are fine
⬜ If you are told “you’re vibecoding,” agree and add that you do it professionally
⬜ Do not review someone else’s interest: notice it and praise them for having made the thing