We Need to Stop Calling Everything Vibe Coding

I returned to coding after a long break, and Lovable was where I picked it up again. The apps looked great, worked at first glance, and came together in a few hours. At first, that felt remarkable. But it stopped being enough the moment I wanted to know what the code was doing – and why. That was when my approach began to change.

The difference isn’t about the tool, or how much of the code AI writes for you. It’s about the contract you accept with your output: whether you can explain what you just released into the world, or not.

Vibe coding, in its original sense, means accepting AI-generated software without properly examining or understanding what sits underneath it. AI-assisted development is different. The model may still write most of the code, but the person building the system remains responsible for understanding its behavior, testing its assumptions and deciding whether it is ready to ship.

For a disposable experiment that never leaves your own machine, the distinction may have few consequences. Once the software is deployed, used by others or connected to real data, it matters enormously.

How “Vibe Coding” Lost Its Meaning

The term “vibe coding” was coined in February 2025 by Andrej Karpathy, co-founder of OpenAI. His example was deliberately casual: a “throwaway weekend project” built by automatically clicking “Accept All,” ignoring the diffs and allowing the code to grow beyond his understanding.

Weeks later, developer and tool-maker Simon Willison noticed the term was being used very differently: as a stand-in for any AI-assisted programming at all, which he argued dilutes the term and gives a false impression of what responsible AI-assisted development can achieve.

What’s telling is that Karpathy eventually agreed. A year later, he introduced a different term for more disciplined work with coding agents. He described “agentic engineering” as a workflow in which developers direct and oversee agents rather than simply accepting what they produce. The distinction matters: professional AI-assisted development requires planning, scrutiny and accountability in ways that casual vibe coding does not.

The Line Is Responsibility

Willison’s rule is simple, and it works as a test for anyone: don’t commit code you can’t explain to someone else. That doesn’t mean reading every single line: with agents generating hundreds of lines at once, even experienced developers don’t do that anymore. It means understanding the core logic and being able to justify why the code does exactly what it does. If you can, it doesn’t matter whether a model wrote it or you did: that’s not vibe coding, that’s using a tool to build software.

Research published in December 2025 supports that distinction. Drawing on field observations and a qualitative survey of professional developers, the researchers found that experienced practitioners retained control over software design and implementation rather than handing the entire process to AI. They treated agents as collaborators, planned their work carefully and remained involved in oversight.

So, experience alone doesn’t explain it. It’s about whether you’re willing to take responsibility for what AI generated. That’s a decision every developer makes over again on every project.

What Happens When Control Is Missing

The consequences of releasing software without understanding or verifying its security aren’t abstract. Tea, an app meant to help women stay safe while dating, exposed tens of thousands of ID photos and more than a million private messages across two security incidents. The failures included an unsecured storage bucket and a separate database accessible without authentication.

The same underlying problem – software appearing to work while its authorization logic remained dangerously wrong – showed up in an application built on the Lovable platform: security research found the authorization logic inverted, locking out logged-in users while letting unauthenticated attackers in freely, affecting more than 18,000 users, including students.

These aren’t isolated cases that only happen to “bad” projects. According to Google’s 2025 DORA report, 90% of developers now use AI at work, while roughly a third report little or no trust in what it generates.

AI use is now widespread, even though trust remains limited. And that makes careful review especially important when generated code handles authentication, permissions or sensitive data.

Control Is Built in Layers, Not All at Once

In my case, I didn’t begin with a formal security audit. I simply refused to move on whenever I could not explain why something behaved the way it did – a natural instinct I bring to work as an analyst. I care less about the syntax than whether the result matches what we originally needed. When it doesn’t, I keep digging.

My workflow became more structured as the projects became more serious. Instead of relying on prompts alone, I began preparing specifications before generating anything. I documented the business requirements, tech stack and integrations. Then came unit tests and Playwright tests for the main user journeys.

Security checks were added in much the same way. I reviewed the libraries the AI selected and introduced malware scanning for uploaded files. Each check came from asking what could go wrong next, rather than following a control list I had prepared at the beginning.

That habit caught a problem on one project. The AI introduced a library that was incompatible with the framework version I was using. The application had not failed outright, so the incompatibility could easily have remained unnoticed. Finding it later would have made the cause far harder to identify.

Compared with the Tea and Lovable cases, this was an ordinary problem. I found it early, fixed it and moved on. That is what review usually looks like in practice. Most of the time, it prevents small problems from growing into larger ones.

I don’t distrust code simply because AI produced it. I also don’t trust it simply because the application runs. Tests and review are how I establish whether it behaves as intended.

From Vibe Coding to Agentic Engineering

Karpathy’s own move away from “vibe coding” toward “agentic engineering” isn’t just a change in vocabulary. “Agentic engineering” gives us a more useful name for the direction professional development is taking. Developers may write fewer lines themselves, but that does not reduce their responsibility. It shifts their work toward specifying what the system should do, directing agents, testing their output and deciding what is safe to release.

The danger is not that AI generates code quickly. It is that generation can move faster than understanding. When that happens, apparent productivity conceals risks that nobody has properly examined.

A Rule Worth Keeping

Stop using “vibe coding” as a label for every form of AI-assisted development – it dilutes the term and erases a distinction in control that matters. Set a simple rule: do not ship what you cannot explain. And build control into the project as it grows, layer by layer, adding checks in step with the risks that emerge.

AI may write most of the code. It cannot take responsibility for shipping it. That still belongs to us.