Vibe coding has followed a fairly typical industry arc. At first it sounded almost like a joke, then like a buzzword, and then it became part of a fairly official development vocabulary. If you go by GitHub’s materials, vibe coding is no longer framed as a meme but as a real workflow: you can assemble an app, add features, and change the UI with almost no hands-on coding. To me, that is an important signal: the industry has largely stopped debating whether this approach is possible at all and moved on to a more practical question — where it actually belongs.

What interests me in this topic is not “does it work at all.” That question is no longer very interesting. It clearly does work — at least for prototypes, UI tweaks, small utilities, and starter scaffolds. A much more interesting question is: can you code by vibe and still understand what you are actually building?

If you look at how GitHub describes vibe coding, one thing stands out: the emphasis shifts from manually writing code to articulating intent. Building on that description, I would say convenience here arises precisely because AI takes on most of the mechanical work. But with that comes a risk of confusing steering the direction with understanding the structure. Setting the course does not mean you deeply understand how the solution is now put together.

This is where the main hypothesis of this article appears for me.

Yes, you can vibe-code and still understand your own code — but only up to a point. Beyond that threshold, vibe coding stops being acceleration and starts creating a debt of understanding.

If you look at Stack Overflow’s 2025 data, AI in development no longer has a distribution problem — the problem is trust. More than 84% of developers use AI tools or plan to, yet trust in the accuracy of such tools is noticeably lower: Stack Overflow separately notes trust falling to 29%, and in the survey results distrust in the accuracy of AI answers is actually higher than trust. My takeaway: AI has become normal as a tool, but not as a standalone source of engineering confidence.

That is already a strong signal for me. If almost everyone uses the tool but far fewer people trust it, the main value of AI-assisted coding is not “let it write instead of me,” but a subtler model: “let it help me move faster, but control and understanding still stay with me.”

If you look at METR’s 2025 study, the picture gets even more interesting. In their randomized study, experienced open-source developers expected AI to speed up their work by roughly a quarter. After completing tasks, they also subjectively felt they had worked faster. But the actual result was the opposite: using AI increased task completion time by about 19%. For me, this is one of the most curious and uncomfortable conclusions in the whole topic: the feeling of speed and real speed are not the same thing.

Building on that study, I would frame the problem like this: AI is very good at selling a sense of motion. You get a first result faster, get stuck less on boilerplate, and see “something working” sooner. But if you then spend time re-checking, fixing, fitting the result into an existing context, and trying to understand why the code is structured the way it is, part of the benefit is eaten after generation. In other words, the speed of the first step is not the speed of solving the whole task.

This, I think, is where what I would call a debt of understanding shows up.

When you write code yourself, you pay for it immediately: time, focus, cognitive load, mistakes, dead ends, manual trade-offs. When AI writes the code, part of that cost seems to disappear. But, following the logic of the same METR study, I would say it does not disappear — it shifts forward. You pay less at generation time, but then you pay in reading, verification, debugging, and manually reconstructing meaning.

In my view, vibe coding creates a special illusion of understanding. You see the system respond to your prompts. You steer. You get code. You refine. You edit. You feel a sense of authorship because you moved the process. But, given everything the data shows about trust and actual productivity, I would say authorship of direction is not the same as understanding the construction. You can confidently steer iteration and still not fully understand what now lives in the project.

For me, a good practical test is simple: if someone took your AI assistant away in an hour or a day, could you calmly keep evolving that code by hand? If yes — understanding survived. If not — you likely had control over the session with the tool, not control over the code.

If you look at the Linux kernel’s position, this distinction becomes very clear. Current documentation on AI coding assistants states outright that assistants may be part of the process, but responsibility for the contribution remains with the person. Moreover, AI use should be transparently disclosed, and compliance with project rules, licensing, and quality remains the developer’s obligation. My sober takeaway: even in a mature engineering environment, AI is accepted not as a substitute for understanding but as a tool that does not cancel personal responsibility for the code.

That is perhaps one of the most honest reference points in the whole debate. Even where AI is officially part of the process, nobody removes the obligation to understand what you are putting into the system.

So my answer to the article’s question is not radical but grounded.

Yes, you can vibe-code and still understand your code. But only as long as vibe coding stays a layer of interaction, not a replacement for engineering thinking.

In practice, I think that means a few simple things. First, after generation you still read code as code, not as “well, it seems to work.” Second, you can explain without AI why the solution is structured the way it is. Third, you can change it locally by hand without breaking everything around it. And perhaps most importantly: you know where this is just boilerplate you can safely delegate, and where logic, meaning, and responsibility begin that you should not hand to the model on autopilot.

Once any of that disappears, vibe coding quietly changes your role. You are less a developer and more an operator of lucky iterations. That can still be convenient. Sometimes even very fast. But, given the data on trust in AI and METR’s results, I would say that mode is poorly compatible with deep understanding of the system. It gives a sense of motion, but not always a real footing for maintenance.

This shows up especially clearly in the difference between types of tasks.

If you go by how GitHub positions vibe coding, it fits best with a fast start: assemble an interface, glue a prototype, sketch a form, get a working scaffold. Here I mostly agree: for simple UI tweaks, small utilities, internal tools, and one-off scenarios, vibe coding can be an almost ideal mode. The cost of error is lower, code lifetime is often shorter, architectural depth is smaller. In those places, losing full understanding is not always critical, and the speed gain really shows.

But as soon as you talk about integrations, domain rules, authorization, transactional logic, error handling, migrations, queues, contracts between services — everything gets much stricter. “It works” is no longer enough. You need to understand why it works, where it will break, what happens at boundaries, how it behaves on retry, where the source of truth is, which invariants must not be violated. Here, in my view, vibe coding without hard reading and review quickly produces code that looks usable but stays mentally foreign even to its own author.

So my main conclusion is this.

The problem with vibe coding is not that AI necessarily writes badly. Sometimes it writes quite well. The problem is different: people easily confuse the speed of getting code with the speed of understanding the solution. Those are different things.

You can indeed get code in seconds. But grasping its place in the system — not in seconds.

You can quickly make it pass the happy path. But understanding edge behavior — not quickly.

You can piece together something that visually works. But that does not yet mean you can safely maintain it a month from now.

So my final answer would be:

You can vibe-code and still understand your own code only for as long as you have not stopped reading, checking, and re-explaining it to yourself.

The moment you no longer want to open the diff. When it is easier to ask AI again than to figure it out locally. When the code “sort of works” but you cannot confidently say where its boundaries are. When you plan to make the next change only through another prompt because doing it by hand feels scary.

That is probably when understanding has already started to slip away.

And if you look at everything visible in the industry today, the most honest way to use vibe coding is to treat it not as a new form of development but as a very powerful accelerator for the first step — not as a replacement for engineering work, but as a way to reach faster the point where engineering work actually begins. That, I think, is what high AI adoption, low trust in it, the METR study, and the cautious Linux kernel stance are saying together.

Because today you really can write code through AI almost on vibe.

But maintaining it afterward still takes a human head.