In February, the man who invented vibe coding quietly tried to rename it.
Andrej Karpathy coined the term exactly a year earlier in a throwaway tweet that he never expected to land. It landed so hard that Collins made it Word of the Year for 2025. Twelve months on, his genie well out of the bottle, Karpathy has backtracked, proposing a new term for what he actually meant - “agentic engineering”. A bit of a mouthful if you ask me, and it doesn’t quite have the right… vibes. Others have weighed in, with blogger Simon Willison proposing “vibe engineering”.
The reason behind the shift isn't that anyone particularly minds the word. It's that the word has well outgrown what Karpathy meant by it. "Vibe coding" has latched onto two very different practices, and the gap between them is making people scratch their heads. If you're a founder, CEO or anyone making decisions about software in your business, untangling these two things is worth half an hour of your time.
(No apologies for the facepalm pun)
What Karpathy originally meant was narrow. A developer using an AI assistant, getting good enough output that they stop reading the code line by line and "fully give in to the vibes." The crucial detail is that there's a developer in the loop. Someone who could read the output if they chose to, who knows what good architecture looks like, who recognises a security hole when they see one.
What the term came to mean is broader and stranger. Within months it had attached itself to a wave of platforms - Lovable, Replit, Bolt, v0, Base44 - that let people with no technical background build working software by describing it in plain English. By the time Collins picked their word of the year, this was the meaning that had won. The marketing person building a landing page. The ops manager spinning up an internal tool. The founder shipping an MVP without ever opening a code editor.
The term has also become associated with what professional software development has become. Not “fully giving into the vibes”, but marshalling the full range of AI-assisted coding techniques to accelerate development - subagents, skills, spec-driven development - but keeping a firm handle on what exactly is under the hood.
These are genuinely different activities, even though they share an interface. The developer using Claude Code or Cursor is operating with full visibility and judgment. The non-technical founder on Lovable is operating on trust. The output from both can look identical from the outside. What sits behind it is not.
The developer side is, broadly, going well. According to JetBrains' January 2026 survey of over 10,000 professional developers, 90% now regularly use at least one AI tool at work, and 74% have adopted specialised AI developer tools - coding agents and AI-native editors rather than just chatbots. The trajectory at Google is the more striking number: in his Cloud Next keynote on 22 April, Sundar Pichai said 75% of new code at Google is now AI-generated and engineer-reviewed, up from 50% last autumn and 25% in 2024. For people who can read what the AI produces, it's a genuine velocity multiplier. They're not vibe coding in any meaningful sense - they're using a very capable assistant and shepherding it. The good ones are getting more done in a week than a team of five could manage two years ago.
The layman side is messier and more interesting. Millions of non-technical people are now shipping software, and a lot of the time it works. Founders are getting from idea to prototype in an afternoon for the cost of a Claude subscription. Even Linus Torvalds admitted in January that part of one of his projects had been "basically written by vibe-coding." That's not nothing.
But the cracks are showing, and they're showing in places you'd expect.
The most visible one is the App Store. Submissions are up 60% year on year - over 550,000 new apps last year, the highest in a decade. Apple's review queue, which used to clear in 24 to 48 hours, now takes anywhere from a week to a month. Established developers shipping bug fixes are stuck behind a wall of AI-generated submissions. Worse, Apple has started pulling the vibe coding platforms themselves. In March it removed an app called Anything - which had raised $11m and helped publish thousands of apps - because it let users execute code Apple had never reviewed. Replit and Vibecode have had updates blocked since late 2025. Apple's stated position is technically narrow: it isn't banning vibe coding, it's enforcing a long-standing rule that apps can't change their behaviour after review. But the practical effect is that the layman vibe coding pipeline runs straight into Apple's gatekeeping model and breaks against it.
The other crack is security. Studies from Georgia Tech, Tenzai and Georgetown's CSET keep finding the same thing: AI-generated code contains vulnerabilities at roughly two to three times the rate of human-written code. The UK's National Cyber Security Centre put out a notice earlier this year warning that AI-generated code can propagate vulnerabilities at scale unless properly reviewed. There have been some genuine disasters - the Moltbook social network reportedly leaked 1.5 million authentication tokens after a founder shipped a vibe-coded app with a misconfigured database, having "not written one line of code" himself. Lovable, a $6.6bn-valued platform, has had three documented security incidents in two months.
These aren't stories about exotic novel attacks. They're stories about basic security practice being skipped because nobody in the loop knew it needed to be there.
We recently audited a vibe-coded SaaS product for a client. It was a real product, with real users, doing useful work. The founder had built it themselves on Replit, with no engineering team. We found 14 critical issues and another 15 of medium severity. It’s a common story, and it’s why we now offer a formal Vibe Code Audit at Old.St Labs to help founders turn 'AI-vibe' into 'production-viable' in just one week."
The patterns were the ones the industry research keeps pointing to. User data stored in plain text. Endpoints that returned data from other organisations if you knew how to ask. Public pages that exposed internal database IDs and access tokens. No protection on any state-changing route. Personal information being passed to third-party AI providers without anonymisation. A 7,000-line file mixing authentication, business logic, and database access. An error handler that crashed the server when triggered.
None of this is the founder's fault. They weren't reckless. They were doing exactly the thing the marketing copy on these platforms encourages you to do: describe what you want, get something working, ship it. The AI is genuinely excellent at making things that work. It is not, currently, good at making things that are safe under adversarial conditions, or efficient at scale, or maintainable by a team that didn't write them.
There's also a deeper issue that one of my colleagues calls the "ugly beast" problem. Each new feature gets prompted on top of the existing codebase. The AI works with whatever is already there, including all the obsolete code from earlier directions and abandoned experiments. Over time the code becomes harder for the AI itself to extend, let alone a human picking it up later. By the time you bring in a developer to fix something, unpicking what's there is often more expensive than rewriting from scratch.
The gap between a "demo" and "production-ready" software will not close as fast as the tools improve. Security, scalability, and maintainability require a human understanding of the business.
For operators deciding how to move this year, here is the practical posture to adopt:
Author:
Imagine, if you can, that you are a budding entrepreneur with an exciting concept for a new app. You’ve done your market research, identified your customers, you’ve even found someone to fund the initial stages. In fact you’ve done everything you need to launch the business except actually build the damn thing. How do you […]
“So I’ve noticed this problem, I have an idea how to solve it, can you help?” This is the type of question Rob L and I love to hear. In fact, this question is exactly the reason why we started Old.St Labs in the first place. Just over a year ago we set out to […]
In this podcast, Rob dives into how non-technical founders can tackle the challenges of building a tech startup. He shares actionable strategies for working with developers, grasping key tech concepts, and leveraging the right tools and resources—no coding skills necessary. With his extensive experience in the startup space, Rob offers valuable insights on bridging the divide between business and technology, helping founders transform their ideas into thriving ventures.
.svg)