By now, it’s practically routine to see posts on LinkedIn, X, or Reddit with people bragging, “I wrote 10,000 lines of code in an hour.” Or, “I built an app from scratch without knowing how to program.” Many even claim this is the beginning of the end for software developers. After all, why keep hiring developers if AI can do the job?
But I think this is where we need to take a critical step back. In some ways, they’re right: the barriers to entry have collapsed. A founder can sketch out an idea in the morning, describe it in a prompt by noon, and have a prototype running before dinner.
Still, things aren’t as simple as they look. Mariano Baca-Storni, CEO of Inclusion Cloud, explains it this way: “The fact that a startup can validate an idea in hours with so few resources opens doors that didn’t exist before.” But we also need to look at the other side, the more problematic part of this new way of approaching digital product development: “That doesn’t mean vibe coding is enough to scale a real product. It’s a useful tool for a PoC, but after that comes the serious work: architecture, security, and systems that can handle thousands of users.”
And that’s the core of the issue: what happens when we need to scale a product? More users, more data, ultimately more exposure. Any vulnerability in the code can mean the downfall of everything the brand has been building. This is why hiring tech talent will remain a crucial part of success. But at the same time, the way we used to do it before AI is already an exhausted model.
Today, almost anyone can look like a software developer if we keep measuring them by the amount of code they can produce. Now we need to start looking for other signals—the ones that reveal who really understands architecture, follows best practices, and codes with growth and sustainability in mind.
The rise of vibe coding
In early 2025, OpenAI co-founder Andrej Karpathy popularized a phrase that quickly stuck: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
The term spread like wildfire. Suddenly, thousands of developers—and non-developers—were building apps with little more than natural language prompts. As Amjad Masad, CEO of Replit, put it: “You can just have a prompt and have an app.”
For some, this is a dream. For others, it could be an authentic nightmare…
What vibe coding promises
Dario Amodei, CEO of Anthropic, has gone as far as to predict: “In 12 months, we may be in a world where AI is writing essentially all of the code.”
I think there are good reasons for this optimism. Sundar Pichai, Google’s CEO, recently stated that 25% of all the code written at his company already bears the mark of AI. Vibe coding itself is even becoming an attractive skill to add to résumés, including at major companies like Visa, Reddit, and DoorDash. Right now, it’s all about how to hit the accelerator and release apps or new features as quickly as possible. And we also know that if something carries the “AI-product” label, it brings extra marketing appeal—drawing interest from both consumers and a press eager for novelty.
But on the other hand, there are also voices with a more critical perspective on this phenomenon. Andrew Ng, the Stanford professor and former Google Brain scientist, acknowledges the productivity gains but warns against being misled by the term itself. “It’s unfortunate that that’s called vibe coding,” he said at a recent conference. “It’s misleading a lot of people into thinking, just go with the vibes, you know—accept this, reject that. In reality, coding with AI is a deeply intellectual exercise. When I’m coding for a day with AI assistance, I’m frankly exhausted by the end of the day.”
So while the barrier to entry has collapsed, the discipline required to use these tools responsibly hasn’t gone away. As Amjad Masad also pointed out: “People need to invest effort. It’s not magic. You still need to learn prompt engineering, iterate, and understand that AI models have randomness—like temperature settings.”
In other words, while vibe coding promises breakneck speed, if the developer using this technique doesn’t have solid best practices and deeper knowledge of systems, they could end up spending much of the time they initially saved doing more manual, detail-oriented work like debugging.
“What’s the point of vibe coding if I still have to pay a dev to fix it?” asked one Reddit thread. This is the weak spot of vibe coding: the part that makes us question whether we’re truly saving time at all. And that’s without even mentioning the possible risks of data leaks, increased technical debt, malfunctions, system crashes, prompt injections, and many other vulnerabilities that can come from code written by someone who doesn’t really know code.
When minutes of coding lead to months of fixes
This is where the illusion of speed begins to fall apart. A prototype that looks functional today can easily turn into a maintenance nightmare tomorrow. What seemed like efficiency—10,000 lines in an hour, an app in a weekend—often leads to weeks or even months of debugging, patching, and rewriting.
Mariano Baca-Storni has seen this play out: “The companies that rely too heavily on vibe coding come back to us later, but now the conversation is different. Instead of ‘We need to build something new,’ it’s ‘We need to stabilize what we already launched because it’s breaking.’ And that is always more expensive.”
The problems don’t show up right away. At first, everything looks like it works. But then usage grows, data accumulates, integrations get added, and suddenly the system begins to misbehave. Small glitches turn into outages. Fragile shortcuts reveal hidden vulnerabilities. Teams that thought they had saved weeks of work discover they’ve only postponed the hard part.
And here lies the paradox: the promise of speed often creates its own drag. The time you thought you gained on day one comes back multiplied as technical debt, emergency fixes, and fire drills.
What was supposed to be acceleration becomes friction.
Beyond the Prompt: Why We Believe It’s Time to Rethink Tech Hiring
And this brings us back to the central question: Why can’t we keep hiring the same way we did before AI?
If AI can make anyone look like a developer, then hiring becomes a much harder puzzle. A candidate armed with Cursor or Replit can cruise through a coding test, generate clean-looking functions, and even hand in a flawless take-home assignment.
On the surface, it’s convincing.
But building a career—or a company—on surface impressions is risky. Mariano Baca-Storni frames it like this: “The challenge today isn’t just finding people who can use AI. It’s figuring out who can think beyond the prompt. Who understands systems, who anticipates vulnerabilities, who designs for scale. That’s what separates someone who codes with AI from someone who builds with AI.”
The distinction matters because traditional hiring models were designed for a pre-AI world. They rewarded candidates for speed, syntax, and memorization. But in 2025, those signals are misleading. Everyone can be fast. Everyone can write boilerplate. The real question is: who knows how to turn that generated output into a reliable, scalable product?
That’s why processes need to evolve. Instead of asking “Can this person code?” we should be asking:
- Can they reason about architecture?
- Do they follow best practices even when AI suggests shortcuts?
- Can they debug what AI produces as confidently as they could their own work?
Why traditional hiring no longer works
The way companies have traditionally hired developers no longer works. More and more candidates are leaning on AI to pass interviews or complete technical tests—often without disclosing it. On the surface, this can make them look highly capable at writing lines of code. But we know the role of a developer today goes far beyond that.
True software talent is not defined by how many lines of code someone can generate. It requires a solid grasp of architecture and computer science fundamentals, the ability to design systems that are secure and scalable, and the discipline to debug and refine what AI produces. Just as importantly, it requires communication skills—the capacity to work across teams, to interpret business needs, and to translate them into technical solutions. These are the qualities that distinguish someone who can simply “use AI” from someone who can actually build with it.
Our answer: inMOVE™ by Inclusion Cloud
That is why we saw the need to rethink the entire process and build a new recruiting engine for this era. We called it inMOVE™ by Inclusion Cloud. It begins with AI-driven discovery, scanning millions of profiles to identify not just technical backgrounds but adaptability to new ways of working. It then goes deeper, profiling how candidates actually use AI tools: which models they rely on, which methodologies they apply, and how they approach problem-solving when the AI output isn’t enough.
Double validation: HR + Engineering
Finally, the process closes with a double validation layer. HR experts validate each candidate’s real-world experience, working through practical cases that mirror business challenges. On the technical side, senior engineers conduct live coding tests, system design reviews, and in-depth conversations about AI usage—what tools they choose, how they integrate them, and whether they can adapt those workflows into secure, scalable environments.
This is how inMOVE™ by Inclusion Cloud helps companies cut through the noise and identify developers who can truly build for the AI era. Not just people who can generate code, but professionals who can turn it into products that last. If you’re ready to strengthen your talent pipeline and adapt your hiring to this new reality, schedule a discovery call with us—we’ll show you how inMOVE™ can make it happen.
