engineer@aine:~/learn$ diff -u vibe-coding/ ai-native/
Four ways to use AI.One of them ships.
Vibe coding is not evil and prompt engineering is not useless. They are just answers to smaller questions. This page puts all four side by side so you can pick deliberately instead of drifting.
- 4 modes
- 9 dimensions
- no strawmen
fine for prototypes, wrong for production
Vibe coding
Rough idea in, suggestions accepted, errors pasted back, no diff read.
a small productivity nudge
AI-assisted coding
The engineer does most of the work and AI fills autocomplete-size gaps.
one useful skill, not a practice
Prompt engineering
Optimising one input to get a better one-shot output.
what you use when it ships
AI-native engineering
The whole system designed around the agent, with a human owning intent and judgment.
--- a/how-we-worked-last-year+++ b/how-we-work-now@@ -1,9 +1,12 @@- idea in a chat window+ intent, constraints and acceptance criteria in spec.md+ [human] reviews the spec before anything is written- prompt, accept, prompt again+ plan.md, reviewed, then the agent executes against it- "looks right"+ lint, types, tests, mutation score, sast, secrets, scans+ an adversarial reviewer that tries to break the change- merge and hope+ feature flag, canary, error budget, automatic rollback- the knowledge stays in one person's head+ the harness improves: rules, skills and tests updated+ [human] owns the result either way
side by side
| dimension | vibe coding | ai-assisted | ai-native |
|---|---|---|---|
| Before the prompt | Nothing written down | A ticket, maybe | A spec: intent, constraints, acceptance criteria |
| Who writes the code | The model | Mostly you | The agent, under a spec you own |
| Context given to the tool | Whatever is in the chat | The open file | Engineered: rules, examples, tools, retrieved code |
| Review | Skimmed, or skipped | Line by line, as you type | At artifact boundaries: spec, plan, diff, deploy |
| How correctness is proven | It ran once | Existing tests, if any | Four layers of gates, deterministic first |
| What survives a tool change | Nothing | Your habits | Specs, rules, skills, gates: the harness |
| Failure mode | Plausible code that breaks in production | Slow, but familiar | Over-ceremony on work that did not need a spec |
| Scales to a team | No | Not really | Yes, that is the point of Chapter 10 |
| Right tool for | Weekend prototypes, throwaway spikes | Small local edits | Anything a customer will touch |
- You are answering a question, not shipping a feature.
- The code will be deleted this week and you mean it.
- You are learning an unfamiliar API and want a feel for it.
- It is a spike with a written question and a delete date.
- Nobody but you will ever run it.
The book calls this vibe prototyping, and recommends doing it on purpose rather than by accident.
- A customer will touch the result.
- The change reaches payments, auth, migrations or infrastructure.
- Somebody other than you will maintain it.
- You cannot state, in a sentence, how you would know it is wrong.
- It is Friday and you want to merge before the weekend.
Chapter 1 names the three failure modes this produces: the plausibility gap, architectural drift, and missing context.
man aine
The vocabulary
Every term, defined properly.
./assess --team
Which one are you doing?
Forty questions will tell you honestly.
open --oreilly
Read chapter 1 free ↗
Where the whole argument is laid out.