Are you a driver or an engineer?

The hype around vibe coding, and AI-related tectonic shifts in how software is developed, got me thinking about cars as a metaphor for what's happening with software development.

To drive a car, you don’t need to understand how the engine works. You just use a car's familiar user interface: a steering wheel, pedals, and controls. Most of the time, that abstraction is a feature. It makes driving accessible.

Until something goes wrong.

When a car breaks down, a driver typically can’t diagnose or repair it. They give it to a mechanic who understands the underlying systems. The mechanic didn’t design the car’s components, but they know how to inspect, troubleshoot, and fix what’s failing.

The distinction between driver and mechanic is a critical one for vibe coding.

In this automotive metaphor, a vibe coder is like a car driver, and a software engineer is the mechanic.

When a company I worked for hired a Prompt Engineer, my first reaction was to wonder why we needed a full-time specialist just to write prompts. But as my team was developing AI coding tools using LLMs, I learned the value of well-designed prompts. The disparity between a “good enough” prompt and a great prompt was dramatic. Prompting is a real skill.

But prompting skill is not the same as engineering skill.

A prompt can produce something that works, but the prompter doesn't understand the code that was generated, its dependencies, or its failure modes. You can drive it, but you can't necessarily fix it.

When I started experimenting with vibe coding, I deliberately chose not to look at the code. I wanted to see whether it was possible to build an application without ever touching source code. It was.

The platform I was using had a publish button. I clicked it one day and immediately realized that was a bad idea. I needed to know what was under the covers. What I found was naive code with obvious issues, including an Azure API key embedded directly in the source, and other glaring security flaws.

As an engineer, I knew how to fix those issues. But if I were only skilled in building software with prompts, I wouldn’t know what needed fixing, let alone how to fix it.

When we rely on AI tools to write code we abstract ourselves from how the software actually works. We aren’t making design decisions. We aren’t engineering for security, reliability, or resilience. If the app runs, that feels “good enough.”

But what do you do when the brakes unexpectedly fail?

At that point you need a mechanic, a software engineer who can inspect the code, trace the logic, and patch the issue. Except many vibe coding tools make that hard by design. The source code is treated as fluid. Manual fixes get overwritten by the next prompt-driven change. The tools don’t just let you be a driver by choice. They force you to be a driver by design.

We’re heading in a dangerous direction if we confuse “I built something quickly” with “this is well-engineered.”

Building applications that are scalable, secure, and resilient requires skill. It is not just about generating code. It is about architecting systems with constraints, proven design patterns, sensible tradeoffs, and explicit security requirements.

The temptation is to throw together an application without those considerations because the productivity benefit is immediate and visible. But risk is delayed and insidious. It shows up later as fragile systems, security incidents, reliability failures, and a growing inability to understand what’s running in production.

I’m not writing this to dismiss AI coding. Writing code character by character is becoming as obsolete as shoveling coal into steam engines. But we shouldn’t fool ourselves into thinking that turning a prompt into code is enough.

What we need are tools that make architecture and constraints first-class entities. Threat models. Secrets management. Dependency and permission boundaries. Reliability requirements. Patterns you can express directly, before you generate a single line of code.

Only after those constraints are in place should we unleash the code generators.

If you’re vibe coding today, here’s the question I’d leave you with: are you driving, or are you engineering?