# Vibe coding vs. AI-assisted engineering: the difference that decides quality

> Vibe coding accepts code without reading it; AI-assisted engineering reviews, tests and starts from a spec. What changes and when to use each.

*Tags: ai, vibe-coding, engineering, ux-for-ai*

---


> [!info] Quick Definition
> **Vibe coding** means programming with AI and accepting the code without reviewing it (the full definition is in [[what-is-vibe-coding|what is vibe coding]]). **AI-assisted engineering** uses the same tools inside a process with a specification, a plan, human review and tests. The difference is not the tool but what happens before and after the AI writes.


## What separates one from the other?

Both start the same way: a description in natural language and an AI that generates code. The difference shows up at three moments.

| Moment | Vibe coding | AI-assisted engineering |
|---|---|---|
| Before coding | Describe the idea and ask the AI to build it | Write a specification or mini-PRD and ask for a plan before touching code |
| While generating | Accept the result if the screen looks right | Review each change, ask for tests and read the diffs |
| Afterwards | Publish if it works in the demo | Test, review security and document what changed |

Addy Osmani, an "Engineering Leader" at Google focused on AI and developer experience, frames it in his online guide *Beyond Vibe Coding* as a spectrum: AI-assisted development ranges from simple vibe coding to complex, production-ready engineering. He defines vibe coding as a playful approach built on high-level prompting, and AI-assisted engineering as a more structured approach that combines the creativity of vibe coding with the rigor of traditional engineering practices ([Osmani, Beyond Vibe Coding](https://beyond.addy.ie/)).

Simon Willison draws the line at review: for him, vibe coding is building software with an LLM without reviewing the code it writes, and it is not the same as writing code with the help of LLMs. His personal rule is not to commit anything to his repository that he could not explain to someone else ([Willison, March 19, 2025](https://simonwillison.net/2025/Mar/19/vibe-coding/)).

## Why does it matter to a designer?

Because vibe coding gets you far quickly and then slows down. Osmani calls it "the 70% problem": AI tools let you get about 70% of the way to a working app surprisingly fast, but the final 30%, the part that makes software production-ready, maintainable and robust, becomes an exercise in diminishing returns ([Osmani, December 2024](https://addyo.substack.com/p/the-70-problem-hard-truths-about)). In that essay he also points out that demo-quality software tends to have edge cases that crash the application, and that people who accept the AI's output without questioning it miss security and performance considerations. And in his guide he warns that vibe coding is fun until you start leaking database credentials.

For a designer, the practical consequence is that the prototype deceives. A demo that looks right proves the idea works visually, not that the system is secure or maintainable.

## What does an AI-assisted engineering process look like?

You do not need to be a programmer, but you should ask for four things, which match the recommendations in Osmani's guide:

1. **Specification first.** A SPEC or mini-PRD with the goal, users, rules and the cases that must work. See [[prd-for-agents|how to write a PRD an agent understands]].
2. **Plan before code.** Ask the AI for the plan before the implementation ([[plan-mode|plan mode]] is made for this) and approve it before it runs.
3. **Tests after every change.** Automated tests for every generated function and a security check. See [[vibe-coding-security-basics|vibe coding security basics]].
4. **A person who approves.** Osmani asks to keep human oversight as the final reviewer and approver, and to treat generated code like code from a junior developer: it needs review and testing before it goes in.

## When is vibe coding enough?

When the goal is to learn, explore or validate an idea, and nobody depends on the result. Willison asks for projects to be low stakes. The limit appears when real people's data, money or availability is involved: at that point, AI-assisted engineering stops being optional. A quick test: if the code could affect someone who is not you, use the second approach. The criteria for stopping are in [[when-not-to-vibe-code|when not to vibe code]].

## Example

Illustrative example: a product team builds a booking prototype with vibe coding in a couple of days. To take it to production, they write a one-page spec (roles, booking states, what happens on cancellation), ask the AI for a change plan module by module, and run each change through tests for duplicate bookings and permissions. An engineer reviews the credentials and how data is stored before launch. The prototype was fast; the published version took much longer, and that extra time is the last 30%.

## What can you do tomorrow?

1. Before asking for a feature, write three lines: what problem it solves, for whom and what it means for it to work. This is the first step of any specification; continue with [[spec-driven-development|spec-driven development]].
2. Ask for a plan with the list of files that will change, and review it before approving. If it touches something you did not expect, ask why. See also [[iterating-with-prompts|iterating with prompts]].
3. Define a minimal, repeatable test: a flow the system must complete without errors. Run it again after every change.
4. Before publishing, ask an engineer to review access, secrets and personal data, and write down what they found for the next version.

## Common mistakes

- Believing that prototype speed predicts production time.
- Skipping the specification because "the AI understands".
- Approving plans without reading them, just to move on.
- Confusing visual checks with automated tests.
- Letting the AI handle secrets or credentials without review.
- Using the word "engineering" as a label without changing the process.

## Sources

- Addy Osmani, "Beyond Vibe Coding" (online guide on the spectrum between vibe coding and AI-assisted engineering): [https://beyond.addy.ie/](https://beyond.addy.ie/)
- Addy Osmani, "The 70% problem: Hard truths about AI-assisted coding" (December 4, 2024): [https://addyo.substack.com/p/the-70-problem-hard-truths-about](https://addyo.substack.com/p/the-70-problem-hard-truths-about)
- Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)" (March 19, 2025): [https://simonwillison.net/2025/Mar/19/vibe-coding/](https://simonwillison.net/2025/Mar/19/vibe-coding/)


---

Source: https://www.fernandoux.com/en/wiki/ai/vibe-coding-vs-ai-assisted-engineering/