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.
Coming soon · written in the open
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.
I’m publishing Part I free on Substack, one chapter per edition. Chapter 1 is out now.
Free · one chapter per edition · unsubscribe in one click
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.
Free on Substack
Read it as it’s written
Part I goes out free, the whole chapter each time, not a summary. Here’s everything published so far.
- Chapter 1 I asked Claude Code to build an AI image generator 6 times. All 6 made the same mistakes. Read
-
Chapter 2 Next up. Subscribe and it lands in your inbox.
Free · one chapter per edition · unsubscribe in one click
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.
Two real pages
You don’t just read it.
You don’t just read it.
You hand it to your agent.
These are pages 12 and 13, untouched — the end of Chapter 1. They show the two devices the whole book runs on, and the whole chapter is free on Substack.
-
1
The prompt block. The question 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
84
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 why Part I goes out on Substack as it’s written: subscribe there and you read each chapter as it lands, and hear first when the book is done.
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?
Part I costs nothing: I’m publishing all six of its chapters free on Substack, one per edition. The price of the finished book and its release date aren’t decided yet, and I would rather say so than invent them. When it’s done, Substack subscribers hear first.
What do I actually get today?
Chapter 1, the whole chapter, free to read on Substack right now. Not a teaser — it ends on the first checklist you can hand to your agent today. Subscribe and each new Part I chapter lands in your inbox as it’s published.
Can I read it without subscribing?
Yes. Every chapter I publish is public on Substack, and they’re all linked on this page. Subscribing just means you don’t have to come back and check.
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.
How often will I hear from you?
Substack sends you each chapter as it goes out, plus the other posts I publish there. Unsubscribing is one click at the bottom of any of them.
Read Part I as it’s written.
Chapter 1 is out now, free. Subscribe and each new chapter lands in your inbox, and when the whole book is done, you hear first.
Free · one chapter per edition · unsubscribe in one click