Vibe Coding Reality Check: Why AI-Built Apps Still Need Human Expertise

Would you ‘vibe code’ a building?

Something quite remarkable has happened to software development. People who would never have described themselves as software developers are now building working applications using tools such as Claude Code, Codex, Cursor and GitHub Copilot.

I know, because I’ve been doing it myself. I understand technology, architecture, product management and UX, and have worked with software developers for decades, but I would never describe myself as a developer.  

Despite that, I can now describe what I want, work iteratively with AI coding agents and create software that would previously have required a development team.

This approach has become known as “vibe coding”, a term coined by Andrej Karpathy in 2025. The basic idea is wonderfully simple: describe what you want, let the AI write the code, see what happens, then keep prompting and refining until the application does what you want.

It is enormously empowering. It is also potentially dangerous when the thing you have built stops being an experiment and starts becoming a real product.

The problem isn't whether the code works

One of the awesome things about modern AI coding tools is just how quickly you can get something working. You can create a database, build an interface, connect APIs, add authentication and deploy an application without necessarily understanding every line of code underneath it.

That changes who can create software. A subject matter expert with a good idea no longer necessarily needs to raise money, hire developers and spend six months building a Minimal Viable Product (MVP) before discovering whether anybody wants it.

The problem comes when the MVP works. Suddenly you start thinking that perhaps other people could use it. Maybe you could charge for it. Perhaps you're thinking about starting a business.

At that point, “it works on my laptop” isn’t an adequate definition of done.

‍

AI might not tell you that your approach is bad

This is something I’ve learned through my own AI-assisted development work. If I tell an AI coding agent to implement something in a particular way, it will generally try very hard to do exactly that.

Unfortunately, I might have made a poor architectural decision. The AI would then build perfectly reasonable code on top of my questionable decision. I ask for another feature, which builds on the first one. Then another. Before long, the original decision has propagated through the application and changing it becomes considerably harder.

This is not really an AI problem. Human development teams have been creating technical debt for decades. The difference is the speed at which AI lets someone without deep development experience create it.

A professional developer or architect might look at the original idea and say: “You probably don't want to do it that way.”

‍

Working code isn't necessarily good code

There are also things that are difficult for a non-developer to assess simply by looking at whether an application works. Security is an obvious example, but the same problem applies to scalability, maintainability, data architecture, error handling, testing, observability, authentication, privacy and deployment architecture.

Research suggests this isn't just a theoretical concern. Veracode tested more than 100 AI models across Java, Python, C# and JavaScript and found that 45% of generated code samples failed its security tests. Interestingly, newer and larger models were better at producing functional code, but weren't significantly better at producing secure code.

That distinction matters. AI is becoming extremely good at helping us make software that works, but “works” and “is ready to become a production application” are two very different standards.

Once an application stores customer information, processes payments, connects to corporate systems or becomes something a business depends upon, the consequences of getting those foundations wrong become much greater.

Can't we just get another AI to check it?

One approach I've found particularly useful is what I think of as adversarial development. Instead of asking the AI that created something whether its own work is good, I use another AI as the reviewer.

For example, one coding agent might create a feature and another model or agent can independently review the implementation, look for bugs, challenge architectural choices or identify security problems. AI coding platforms themselves are increasingly adding this type of capability; GitHub Copilot, for example, can now perform automated code reviews and analyse changes using broader project context.

This is a very useful technique and I think multi-agent development and review will become increasingly normal. However, GitHub's own documentation makes an important point: its AI code reviewer is not guaranteed to identify every problem and its feedback should still be supplemented with human review.

There is also a more fundamental problem. Two AIs can debate whether your code correctly implements the architecture without necessarily asking whether you chose the right architecture in the first place.

Sometimes you need someone who has built these things before.

‍

The missing layer in vibe coding

I don't think the answer is telling people to stop vibe coding and hire a traditional development team from day one. That misses one of the most important benefits of AI: people can now test ideas, build prototypes and create genuinely useful applications at a fraction of the cost and time previously required.

Instead, I think we need a new type of support sitting between completely DIY vibe coding and handing the entire project to a software development company.

Imagine you're building an application yourself. Before you get too far, an experienced application architect spends a few hours reviewing what you're trying to achieve and helps you make sensible decisions about the architecture, technology stack, data model, authentication, integrations, deployment and security.

You continue building with AI, because that's fast, inexpensive and gives you enormous control over the product. But at appropriate points, experienced developers review what has actually been created and identify problems before they become deeply embedded.

Then, before you expose the application to real customers, there is a more structured production-readiness review covering areas such as:

• application and solution architecture

• security and authentication

• data architecture and privacy

• code quality and maintainability

• scalability and performance

• error handling and resilience

• testing and quality assurance

• logging, monitoring and observability

• cloud infrastructure and deployment

• backup and recovery

• third-party libraries and dependencies

• ongoing support and operational ownership

The objective isn't to take the application away from its creator. It is to provide some experienced guardrails so that the speed and accessibility of AI-assisted development don't create problems that become expensive to fix later.

‍

From prototype to production

This idea particularly resonates with me because Argenti has spent years working on the part of technology that comes after the clever demonstration. Our application work includes architecture, application modernisation, integration, cloud infrastructure, security and ongoing managed services, with a strong emphasis on building things that can operate reliably in production.

Increasingly, I think there is an opportunity to apply that experience much earlier and at a smaller scale. Not every person building an AI-assisted application needs a development team, but anyone considering putting real customer data, business processes or money through one should probably have an experienced developer and architect look under the bonnet.

Perhaps what is emerging is a new development model: AI does much more of the building, while experienced humans increasingly provide the architecture, challenge, assurance and judgement.

That isn't replacing developers. In some ways, it makes their experience more valuable because a relatively small amount of expert input can guide an enormous amount of AI-generated work.

‍

Would this be useful?

I’m considering developing a lightweight service specifically for people and businesses building applications with AI coding tools. It could range from an early architecture session, through periodic technical reviews, to a full security and production-readiness assessment before launch.

For now, I’m calling it a Vibe Coding Review or maybe a Vibe Coding Support Service.

If you're currently building an application using Claude Code, Codex, Cursor, Copilot or another AI coding tool, I'd be interested in hearing about your experience.  

I’d like to know whether having an experienced application architect or developer available periodically to challenge decisions, review the code and help you get safely into production would be useful.

Because vibe coding makes it remarkably easy to build an application. The interesting question is what happens when that application becomes something people depend on.

‍