Stop cooking. Start writing recipes.
There’s someone in your kitchen who cooks incredibly fast, does exactly what you ask, and has no idea what you’re making.
You say chop the onions. Perfect onions, thirty seconds. Brown the meat. Done. Now the sauce. Done. Two hours later there’s food across every surface, half of it went cold waiting on the other half, and you are still the only person in the room who knows what dinner was supposed to be.
That’s you and Claude. Today. On whatever you’re building.
There is a whole conversation happening about how to fix this, and it’s almost entirely in a language most of us don’t speak. Karpathy, the Shohei Ohtani of AI, stood up at Stanford and said delete everything, keep the graph. The people who understood him have moved on to arguing about loops, and to letting the rest of us know that copy-pasting between windows makes us peasants.
So I’ll ask the question I think a lot more people have and won’t admit. What the hell is graph engineering? What is a loop? Because I’m building things I couldn’t have built two years ago, and everyone explaining how I should be doing it has forgotten what it’s like to not already know.
I watched the lecture. I read the write-ups. I asked all the LLMs.
None of it is new. You already know all of it. You just know it as cooking.
The shopping list is not the recipe
Anyone can write down flour, sugar, butter, eggs. That’s the shopping list, and it’s the half people mean when they say they’ve planned something.
The recipe is the order. Cream the butter and sugar first, then add the eggs one at a time, then fold the flour in at the end. Get that sequence wrong and having every ingredient doesn’t save you. Dump the flour in first and you’ve got a bowl of grit.
That’s the graph. Not the list of things to do, but which ones have to wait for which.
You already know what it costs to skip it, because you’ve had the dinner where the chicken is ready and the potatoes have another twenty minutes. Nothing was missing. Everything was cooked. It still wasn’t a meal, because the order was wrong.

Keep whisking until stiff peaks
You need the eggs beaten, so you tell it to whisk.
It whisks. Then it stops and reports back: I have whisked the eggs, as requested.
So you look in the bowl and say keep going. It whisks. It stops. It reports. You look in the bowl again, because you are the only one in this kitchen with any opinion about whether the eggs are done.
A loop is what happens when you say the stopping condition up front. Keep whisking until stiff peaks. Now it whisks, checks the bowl itself, and carries on without asking, because it knows what it’s aiming at. You walk away and come back when it’s finished.
All the weight is sitting on the phrase stiff peaks. It works because it’s a thing that can be checked by somebody who isn’t you. Whisk until it looks good puts you straight back at the bowl, because good is a thing only you can see and only when you’re standing there.
Which means the loop was never really about the whisking. It’s about being able to say what stiff peaks means before anyone starts.
So you want to build something
What we all do instead isn’t baking. It’s throwing ingredients in a bowl, tasting it, throwing the bowl out, and starting over until something edible turns up. Sometimes it does, which is why nobody stops.
What I’m suggesting is that the step after “here’s my goal” is not build the thing. It’s write the recipe.
So sit down with the same AI and don’t ask it for a website. Ask it for the parts, and for every part, what has to happen before it. For an events site that’s roughly:
- decide where events are stored needs: nothing
- submission form needs: storage
- listing page needs: storage
- the design needs: nothing
- domain, go live needs: everything
Two things fall out of that which you would never have spotted in a chat window. The design and the storage decision never touch each other, so they can happen at the same time. And both pages wait on the same decision, so getting that one wrong costs you twice.
That list is the graph. Not a diagram with boxes on it, not a framework, not something you install. A text file that lives in the project instead of in your head, which means it’s still there tomorrow, and a session that has never met you can read it.
Then one more line per job. Proof. Not “the form works” but “submitting the form puts exactly one new row in the events table.” Something you can hold up against what you expected, never a status message, because when it reports back that the eggs are done, that is not the same as you looking in the bowl. Three rows is a test. OK is a vibe.
That file is the actual job. The loop that reads it took me an afternoon, about sixty lines. Everything else went on admitting I had never once had a definition of done.
Nobody told you the job changed
All of this probably reads like homework. You wanted a website and I’ve got you writing a file about the website.
But it isn’t extra work sitting on top of the job. It’s the job now.
A line cook does the job. Someone hands them a ticket, they make the thing, they’re fast and they’re good, and the measure of them is how many plates go out. A head chef doesn’t make the thing. They decide what’s on the menu, what order it gets built in, and they stand at the pass deciding what’s allowed to leave the kitchen. Neither is smarter, it’s just a different job.
What happened over the last two years is that everyone building with AI quietly got promoted to head chef, and nobody sent the memo. So we’re all still at the stove doing it by hand, twelve tabs deep, wondering why the people who took the promotion keep telling us we’re doing it wrong.
None of which means planning hard enough makes the work do itself. Your recipe will be wrong somewhere. The difference is that a recipe is a thing you can be wrong about cheaply. A cake isn’t.
The upgrade you keep thinking about
Somewhere in here you’ve looked at your plan and thought about the next one up. Free to Pro, Pro to Max. Just a bit more headroom and I’d get there.
I did that. What I actually needed was to stop paying for the same work three times. Every bowl you throw out was tokens, and every rebuild is the second and third go at a job that never had a definition of finished in the first place.
Which is the bit worth sitting with, because it was never really trial and error. Error means you tried and got it wrong. Most of it was you never having said what you wanted, so there was nothing there to be right about.
The recipe costs a few hundred tokens, once. The bowl costs the whole session, every time.
You don’t need the rest of it
Not the lecture, not loop engineering, not whatever the argument of the week is about. You need the three things a head chef does.
Define success. Not “the form works.” Submitting the form puts exactly one new row in the events table. Something with a number on the end that a person who isn’t you can check.
Set up the kitchen. The recipe file, with a needs line on every job, so that what happens next is a question with an answer instead of a question for you.
Then let them cook. Walk away from the bowl. Come back and check the work against what you wrote down, not against how it feels.
The first two take an afternoon. The third is the one you’ll struggle with, because standing over the bowl feels like working.
Personally, I hate reading a huge blurb of text and getting no takeaways, so if you scrolled all the way to the bottom, here you go:
Paste this into a session on whatever you’re building:
Before we build anything, write me two files.
PLAN.md: every job, in order, each with a "needs" line saying what has to
happen first, and a "proof" line saying how I'd know it's done. Proof has to
end in a number or a name I can check by eye, never a status message.
"3 rows" is a test. "OK" is a vibe.
gate.sh: one command that runs those proofs and prints PASS or FAIL.
Ask me about anything you're unsure of instead of guessing.
Happy cooking!
post written by me, stitched together with ai.