What Is Vibe Engineering? Why Experienced Developers + AI Beats Vibe Coding Alone

You’ve probably heard the term “vibe coding” by now. Andrej Karpathy coined it earlier this year and it spread fast, because it captured something real: developers (and non-developers) prompting AI tools, accepting whatever comes back, and shipping it. No deep review, no architectural thought, just vibes.

I want to be honest about something: it works, up to a point. You can build impressive-looking prototypes quickly. The demo looks great. The investor is impressed. And then you hand it to real users and things start falling apart.

At Exe Squared, we’ve been using AI tools seriously in our development workflow for the past couple of years — Claude Code for agentic coding, Cursor for IDE-level AI assistance. We’ve gotten genuinely fast. On the right project, we’re delivering features in a fifth of the time it used to take. But the way we work looks nothing like vibe coding. I’d call it vibe engineering instead.

What’s Wrong With Vibe Coding?

Let me be concrete about the failure modes, because they’re well-documented at this point.

In early 2025, a security researcher audited a batch of apps built primarily through AI prompting sessions with minimal human review. He found 170 applications with exploitable security vulnerabilities — SQL injection, broken authentication, exposed API keys hardcoded in repositories. These weren’t hobbyist side projects. Several were in production handling real user data.

The other finding that surprised people: a study from GitClear tracked developer productivity across teams using AI assistants. Teams that adopted AI tools naively — accepting suggestions without meaningful review — saw a 19% decrease in effective output over time, because they spent increasing time debugging the subtle mistakes AI tools confidently produce.

Neither of these findings means AI is bad for software development. They mean using AI without the judgment layer is bad.

The judgment layer is the part vibe coding skips.

What Vibe Engineering Actually Is

Vibe engineering is what happens when experienced developers use AI as an accelerant rather than a replacement for thought.

The term sounds a bit self-congratulatory, I know. But it’s useful because it names the thing that distinguishes professional AI-augmented development from the “prompt and pray” approach.

Here’s the four-step process we follow on every feature:

1. Architect

Before any AI tool touches a keyboard, a developer makes the structural decisions. What data model is required? What are the performance constraints? Where are the security boundaries? What will be hard to change later?

This is the step AI currently cannot do for you. It lacks context about your specific business, your existing codebase, your users’ actual behaviour, and the constraints that aren’t written down anywhere. An experienced developer carries all of this. The AI doesn’t.

When we were building the reporting system for ANA Airports of Portugal’s operations platform, the architectural decisions about how to aggregate flight data across terminals couldn’t be delegated to an AI prompt. Those decisions depended on understanding the airport’s operational structure, the expected query patterns, and the regulatory reporting requirements. Getting those wrong would have meant a rewrite, not a debug session.

2. Generate

With a clear architectural brief in hand, AI is genuinely excellent at code generation. Give Claude Code a well-specified task — “implement a Laravel Eloquent scope that filters this query by date range and airport terminal, with appropriate indexes” — and you’ll get working code in seconds that would take a junior developer twenty minutes and a senior five.

The key word is “specified”. Vague prompts produce vague code. Precise architectural thinking produces precise prompts which produce good output.

3. Review

Every piece of AI-generated code gets reviewed before it ships. Not a cursory glance — an actual code review. Does it handle edge cases? Does it validate inputs correctly? Could this query return unexpected results with production-scale data? Does this create a security boundary problem?

This is where the experience pays off again. An AI will write you a file upload handler that works in testing. An experienced developer will notice it doesn’t validate file type server-side, only client-side, and fix it before it becomes an incident.

4. Test

AI is very good at writing tests, which is one of its least-appreciated strengths. We routinely ask AI tools to generate unit tests and integration tests for code they’ve just written, then extend those tests to cover edge cases we’ve identified during review. The result is higher test coverage than we’d typically achieve under time pressure on a conventional project.

The test suite is also the signal. If AI-generated code passes a comprehensive test suite written with genuine thought about edge cases, you can deploy it with reasonable confidence.

Why Experience Is the Multiplier

Here’s the thing people miss when they talk about AI replacing developers: the value of an experienced developer isn’t in typing speed or memorising syntax. It’s in accumulated judgment.

Judgment about architecture. About what will scale and what won’t. About where security boundaries need to be drawn. About which business requirements are being stated explicitly and which are being assumed. About when a client says “we just need something simple” and they mean it, versus when they mean something that needs to grow with their business.

None of that judgment is in the model weights. It’s in the person directing the model.

When we built the Department for Education project — a data pipeline handling sensitive educational records — the decisions about data retention, encryption at rest, access controls, and audit logging all came from human architectural work before any AI touched the codebase. The AI wrote the implementation. The implementation is correct and it’s fast. But if we’d just prompted our way to a data pipeline, those decisions would have been whatever the model assumed was reasonable. That’s not a position you want to be in when you’re handling children’s personal data.

What This Means for You

If you’re a business thinking about commissioning software: the question to ask any agency or freelancer isn’t “do you use AI tools?” It’s “what does your review process look like?” Anyone can generate code. The value is in the architectural judgment and review discipline that makes it production-ready.

If you’re a developer thinking about how to stay relevant: the answer isn’t to avoid AI tools. It’s to invest in exactly the skills that AI can’t replicate. Deep knowledge of your domain. Architectural thinking. Security intuition. The ability to read code critically, not just write it.

If you’re already using AI tools and wondering why results are inconsistent: look at your review process. The inconsistency almost certainly lives in the gap between “AI generated something” and “someone with deep experience checked whether it was right.”

Vibe engineering isn’t a clever rebrand. It’s a recognition that the developers who will build the best software over the next decade are the ones who combine AI’s raw generative speed with the judgment that only comes from years of building things and watching them succeed or fail in production.

We’ve spent 15 years building that judgment at Exe Squared. The AI tools just mean we can apply it faster.

If you want to understand more about how we actually work day to day, the how-we-work page goes into more detail about our process. And if you’ve got a project where this kind of approach would make a difference, let’s talk.