You Can 'Code' With AI Now, But Do You Still Need a Real Developer?

Almost every week for the past few months, someone's asked me some version of the same question: "if I can just type a prompt into AI and get an app now, do I still need a developer?"

It's a fair question. Tools like Lovable, Bolt, and v0 can now spin up an app that looks finished from just a few sentences of prompting, and this isn't just a gimmick. Lovable reportedly crossed US$400 million in ARR (annual recurring revenue) by February 2026, with only 146 employees. This trend has its own name now: vibe coding, a term that took off in early 2025 to describe the "just prompt it, don't worry too much about the code" way of working.

The honest answer isn't a simple yes or no. Here's how I see it, from the side of someone whose actual job is building real systems for clients.

Two kinds of tools that get mixed up

Before going further, it's worth separating two categories of tools that people often treat as the same thing, even though they're built for different users:

• Builders for anyone: Lovable, Bolt.new, v0, Replit Agent. You describe what you want, and it becomes an app you can open in a browser. These are marketed at non-developers.
• Coding assistants for developers: Claude Code, Cursor, GitHub Copilot. Claude Code's own product page is explicit that it's built for developers working in a real codebase, handling bug fixes through multi-day migrations, with the developer staying "the architect and orchestrator." It's not built for someone who's never written a line of code.

The "do I still need a developer" question is really about that first category, the ones explicitly marketed at non-technical users.

What looks easy: most of it comes together in minutes

This is the part that goes viral: you describe an idea, and within minutes there's a clickable app with a real interface, looking like an actual product. For a simple idea or a prototype to show your team, this genuinely works, and I use it myself for exactly that kind of need.

But there's a pattern that keeps showing up: the part that looks good in a demo comes together fast, while the part that doesn't show, handling many users at once, storing data safely, or dealing with edge cases nobody thought of upfront, is what actually stalls things. The first part is easy because the patterns are generic and AI has learned from millions of examples. The second part is hard because it needs decisions specific to your own business, not just a generic pattern.

What rarely shows: security

This is the part that gets skipped over when people get excited about vibe coding, even though it's the most concrete risk for a business.

Escape.tech, a security firm, scanned 1,400 vibe-coded applications already running in production. Here's what they found:

Critical security flaws found across the 1,400 apps scanned

2,038

Leaked API keys and credentials, left in publicly accessible code

400+

Cases of exposed personal data (including bank account details) reachable through the app

175

This isn't an isolated case. The Cloud Security Alliance rounded up several separate studies on this: Veracode tested over 100 AI models on 80 coding tasks across Java, Python, C#, and JavaScript.

Share of AI-generated code samples that failed each security test(%)

• Average across all tasks45%
• Java code specifically72%
• XSS protection86%
• Log injection protection88%

The same research also notes that Georgia Tech has tracked 74 confirmed CVEs (publicly registered security flaws) traced back to AI-generated code as of March 2026, with the actual number estimated at 5 to 10 times higher than what's been confirmed.

Why this is riskier for non-technical users

There's an older finding that's become more relevant now, not less. Stanford researchers (Perry, Srivastava, Kumar, and Boneh) at ACM CCS 2023 found something counterintuitive: developers using an AI assistant wrote less secure code on 4 out of 5 security tasks tested, compared to developers working without AI at all. Stranger still, the developers using AI were more confident their code was secure.

If professional developers can fall into that kind of overconfidence, and they still have some baseline knowledge to catch problems, what happens to someone who doesn't have that baseline at all? There's nothing wrong with using a builder to get started quickly. The problem is treating "it runs" as the same thing as "it's secure." Those are two different things.

So when do you still need a real developer?

The more useful question isn't "do I still need a developer," it's "for this specific thing, how much is actually at stake if something goes wrong." A few simple guideposts:

• Internal, just for you or your team, no one else's data involved? Vibe coding is enough to get started, and often enough to keep running long-term if it works.
• Storing customer data, especially payment or login details? This is exactly what's most at risk in the Escape.tech data above. Get a developer to review the security before it goes live to the public, even if you built the app yourself.
• Going to be used by a lot of people, or become something you sell? That "last stretch" mentioned earlier, scalability, error handling, traffic load, is exactly what determines whether the product holds up.

If you've reached the point where you need a developer to go further, there are a few things worth checking before you pay, about who ends up holding the code and the data.

Wrapping up

Vibe coding is genuinely useful, and I'm not trying to write it off as hype. But the way it makes sense for a business isn't "AI vs. developer," it's AI to speed up the prototype stage, and a developer to make sure what actually ships is secure and built to last.

If you're trying to figure out what you can handle yourself with AI and what actually needs a real developer's hands, tell me about your situation and I'll help you think through what makes the most sense for what you need.