We should go from AI assisted coding to Vibe Engineering not Vibe Coding

We’re still wrestling with how much AI belongs in our day to day coding. Three phrases keep getting mixed together:

These are not the same.

AI AssistedVibe codingVibe engineering
Generates the code👨‍💻 (+ 🤖)🤖🤖
Owns the design👨‍💻︎🤖👨‍💻 ︎

They differ along two dimensions: who generates most of the code and who owns the design and quality bar.

1. AI-assisted coding #

This is where we started.

  • You, the programmer, write most of the code.
  • AI acts as super-powered autocomplete.

You type most of the code yourself. AI handles completions, boilerplate, pieces of the logic and maybe small refactors. Your eyes stay on every line, and the AI rarely acts without you explicitly placing or accepting a suggestion. This is still “you drive, AI rides shotgun”.

GitHub Copilot was the early poster child. Here’s an early video of me dabbling with Copilot and scripts. Today, Cursor Tab has taken the crown: fast, inline help without giving up control of the codebase.

 

I particularly like how accurate Cursor is at predicting the next point of code entry or edit. When it works well, it disappears into the background and silently increases your productivity. Get it wrong, and you’re immediately frustrated with AI.

2. Vibe coding #

This took the world by storm.

  • AI generates most if not all of the code.
  • You, the programmer, react with feedback in English and are not as in tune with what the actual code shapes up to be.

You give up intentional design. In practice, you’re letting the model make the architectural calls: file structure, abstractions, naming, everything. As your codebase grows and needs ongoing maintenance, vibe coding breaks down. Your code turns into mystery‑meat: it runs, but nobody understands clearly how or why.

This is why experienced greybeards raise alarms and complain about AI bots on their lawns.

But Vibe coding does shine in a few scenarios:

Andrej Karpathy, the godfather of LLMs, coined the term. Some say it with affection, others with disdain. For better or worse, the term has stuck.

 

I vibe‑coded a script to check if your USB‑C cable is any good and can attest to some of this. It started as a bash shell script and, for a more cross‑platform version, I asked the AI to convert it to Go. That took a few minutes; I actually know very little Go (but I know enough to know that the output code quality was not great). I still haven’t gone through every line of that script, even after that post became somewhat popular.

 

And that’s the whole point of vibe coding: you get something that mostly works, very quickly. It serves the purpose, even if the code isn’t something you’d proudly own long term.

3. Vibe engineering #

This is where I think software engineering with AI is headed.

  • AI generates most of the code, but within your explicit constraints.
  • You design the architecture, set boundaries, and review structure & behavior.

Vibe coding and vibe engineering both have AI generating most of the code. The difference is who owns the design: in vibe coding, the model effectively owns it; in vibe engineering, you stay the architect.

Simon Willison, wizard of LLM CLIs and skilled pelicans, is trying to popularize the term vibe engineering. He uses it to describe seasoned engineers who use LLMs and coding agents to move faster, but stay accountable for design, quality, and long‑term maintainability. I know the term “vibe” annoys folks, but I don’t mind it tbh1.

The difference from AI‑assisted coding is autonomy. With vibe engineering, you let the AI act in bigger chunks: run commands, edit files, refactor modules; all while you still stay on the hook for overall design and behavior, not every keystroke. You’re still doing real engineering: researching approaches, making architectural decisions, defining success criteria, and spending time on code review and QA.

It amplifies classic senior‑engineer habits: tests, planning, documentation, version control, and ruthless code review.

I vibe‑engineered a fairly complex Firefox add‑on (very proud of this one; it’s one of the few Firefox extensions with tests). That experience sold me on this approach. I wasn’t vibe coding: I decided the architecture, wrote the spec, set constraints, and then used LLMs and agents to explore implementations, generate code, and iterate based on test results and reviews.

 

In practice, you shape the playground for the AI:

  • Write a quick design doc: modules, responsibilities, key interfaces
  • Provide strong instructions (tech choices, dependencies to avoid, safety constraints)
  • Ask agents to implement one slice at a time (a feature, a module, a refactor), using exec-plans
  • Review diffs for structure and behavior: are the boundaries clean, tests meaningful, logs sane?
  • If the shape is wrong, steer; if the shape is right, let the details go

As I explored in programming paradigms, we’re fully in the agentic coding era. That shift demands vibe engineering discipline. Agentic vibe-coding feels like a recipe for scaling chaos.

  1. An alternative name to this could be agent-driven coding but vibe-engineering has a better ring to it? Vibe Coding; AI Assisted Coding; Agent Driven Coding. hmm… ↩︎