The image engine
A feature that calls somebody else’s AI
It looked finished the afternoon it worked. Then the failures started arriving with an invoice attached — every retry on a paid call is a charge, whether or not the user got a picture.
Written in the open · first 2 chapters free
The judgment the AI doesn’t have.
Your agent can build anything you describe. So you described it, it built it, it worked, and you shipped it. Then real users arrived and it broke in ways you didn’t know existed. Beyond Vibe Coding is about the gap between those two moments.
The gap
AI made code cheap.
AI made code cheap.
It did not make judgment cheap.
Vibe coding gets you a demo. Vibe engineering gets you a system that survives real users. The difference isn’t typing ability — the agent has that. It’s knowing what to be afraid of, and saying so before a line is written.
This book teaches that judgment the only way it transfers: by taking real, shipped systems apart, slowly, and showing the naive version next to the engineered one until you can see the shape coming yourself.
What it’s built on
Three systems that really shipped, and really broke
Not invented examples. These are mine — the code is running right now, and every war story in the book is one that actually happened. Where there wasn’t a real failure, I say so and show you what the agent builds when you ask it plainly instead.
The render engine
The expensive job, running on my own machine
VidTSX shipped as a video studio that could not render a video. On purpose. When the heavy work moves inside your fence, nothing crashes — everything just gets slower at once, and the machine picks the victim without asking what you cared about.
The mail engine
Input written by someone trying to hurt you
You cannot reject what you are being paid to inspect. So you take it in, defuse it, and compute your own verdicts — and you never, ever score “I couldn’t check” as “this is bad.”
What’s inside
21 chapters in 5 parts
Every part ends the same way: the idea lifted off the specific system and applied to a completely different feature, then a checklist of questions to hand your agent before you build. The checklists compound — by the last chapter you’ve assembled your own rules file out of them.
-
Part I
The feature you rent
WrittenDepending on what you don’t control · 6 chapters
Any feature that leans on something slow, costly, or flaky you don’t control inherits its failures unless you build a layer between you and it — and that layer is always the same handful of moves: make it async, give it a same-capability backup, make failure cost nothing, keep your own copy, put a price and a limit on it, watch what it spends.
-
Part II
The job that ate the server
WrittenOwning your compute · 5 chapters
When you run the expensive thing yourself, you must wall it off so it can’t take down everything around it. Isolation, resource limits, and failure-that-doesn’t-bill keep one heavy job from becoming everyone’s problem.
-
Part III
The input that fights back
Being writtenCorrect under hostile input · 4 chapters
Taking in data you don’t control means never rejecting what you must inspect, computing your own verdicts instead of trusting the input, and above all distinguishing “this is bad” from “I couldn’t tell” — treating uncertainty as failure is its own bug.
-
Part IV
Seeing it break before your users do
PlannedOperating what you shipped · 4 chapters
You cannot fix what you cannot see. Operating what you shipped means watching the data, the failures and the bill — and finding out your restore works before the day you need it.
-
Part V
The fear you have to supply
PlannedSecurity as a lens, not an aisle · 2 chapters
Security isn’t a feature you add. It’s a lens you apply to every feature the moment it touches the outside world.
One real page
You don’t just read it.
You don’t just read it.
You hand it to your agent.
This is page 5, untouched — Chapter 1 — The feature you rent. It’s in the free sample, and it shows the two devices the whole book runs on.
-
1
The prompt block. The sentence to paste before the agent writes anything — here, asking it to list every way the feature can fail and what each failure costs.
-
2
The checklist. The questions that turn the chapter into something you keep. They accumulate part by part into the rules file the final chapter assembles.
Scope
What’s deliberately not in it
A book that covers everything teaches nothing. Here’s what I cut, and why.
-
Frontend and UI
Not because it doesn’t matter. Because this book is about what happens after the button is clicked.
-
Docker, hosting, deploy mechanics
Mentioned where it matters, never taught. That’s a different course, and this book stays out of its lane.
-
Prompt engineering
The agent-craft here is at the seams — plan-first, the grill-me pass, reviewing what it wrote. Not a chapter of prompt tricks.
-
Model comparisons and AI-API roundups
They date the moment they’re printed. Every idea in this book will outlive the model you use it with.
Where it actually is
Written in the open
11/21
chapters drafted
2/5
parts finished
73
pages typeset
Parts I and II are finished and typeset. Part III is next — the mail engine, and the chapter about telling “this is bad” apart from “I couldn’t tell.”
No launch date, and I’m not going to invent one — a date I miss is worth less to you than the truth. That’s exactly why there’s a list: when it’s done, you hear first.
Who it’s for
A vibe coder becoming an engineer
You build by prompting, and it works right up until it doesn’t.
The agent shipped it. Two users showed up and it fell over in a way you had no name for. This book gives you the names, and the questions that catch it first.
You want to go deep, not wide.
This is not forty concepts at one page each. It is a handful of real systems taken apart slowly, until the shape underneath them is obvious everywhere else.
You’re ready to stop being surprised by your own app.
By the end the book has handed you a checklist you built yourself, part by part, and the last chapter turns it into the rules file and skills your agent reads every session.
Written by
Hasan Aboul Hasan
I’ve been building software for 16 years, and building it with AI for the last few. Everything in this book comes out of systems I run in production and teach on YouTube. The failures in it are mine, with the numbers attached.
Questions
How is this different from the free Vibe Engineering Blocks book?
Blocks goes wide: 47 ideas, one page each, so you know what the words mean and what to ask for. This one goes deep: three real systems torn down chapter by chapter, showing how those ideas combine under pressure. Blocks is the vocabulary. This is the judgment. Start with Blocks — it’s free, and it’s at learnwithhasan.com/blocks.
What does it cost, and when does it come out?
Neither is decided yet, and I would rather say so than invent a date. The book is being written in the open; when it’s done, the list hears first. That’s the whole reason the list exists.
What do I actually get today?
The first two chapters as a PDF, immediately after you confirm your email. Not a teaser — the real opening of the book, typeset exactly as it will ship, ending on the first checklist you can hand to your agent today.
Do I need to know how to code?
You need to have built something, even if the AI wrote most of it. The early chapters explain every term the first time it appears, and the vocabulary compounds from there — that ramp is the book, not an apology for it.
Is it Python only?
The examples are Python, but the book is about shapes, not syntax. Every specific lifts to a principle you apply to a completely different app, and the equivalents in other stacks are named as they come up.
Will you email me constantly?
No. You’ll hear from me when the book has real news, plus the Saturday email if you want it. Unsubscribe whenever.
Read the first 2 chapters now.
The real opening of the book, typeset exactly as it will ship — 16 pages, ending on the first checklist you can use today. Then nothing until the book is done.
First 2 chapters, free
Join the list