Stop Writing AI Code. Start Cooking It — Here's Why It Works
In this article
> **Bottom line:** Treating AI coding tools like a spec-writing exercise — front-loading a perfect prompt and walking away — produces worse code than treating it like cooking a steak: constant small checks, taste-as-you-go, and adjusting heat in real time.
After six months running Claude 4.5 and Cursor's agent mode on production infrastructure code, my error rate dropped roughly 40% once I switched from "write one long prompt" to "cook in short, observed passes." The difference isn't the model.
It's whether you're watching the pan or walking away from it.
I burned a production deploy script in March because I trusted a single prompt to get it right.
Not because Claude 4.5 is bad at writing bash — because I treated the interaction like submitting a ticket instead of standing over a stove.
I wrote out the full spec, hit enter, and went to make coffee.
When I came back, the script looked perfect. It ran clean in staging.
It took down a caching layer in prod four days later because of an edge case no amount of upfront specification would have caught, but thirty seconds of watching it execute against a copy of real traffic would have.
That's the moment I stopped writing AI code and started cooking it.
The Setup: Why I Was Doing It Wrong
I've been shipping infrastructure code for over a decade, and I came into agentic coding tools with an engineer's instinct: **specify everything up front**.
Detailed prompt, exhaustive requirements, edge cases enumerated, then let the model run. That's how you write a design doc.
That's how you write a Jira ticket. So that's how I wrote prompts for Claude Code and Cursor's agent mode when they started handling real chunks of my Terraform and Go services back in late 2025.
It worked, sort of, the way an over-salted dish still gets eaten. Functional but off.
I'd get code that technically matched my spec and still missed the point — because a spec, no matter how detailed, can't encode the thing you'd notice by looking.
A junior engineer following a recipe to the letter still burns the garlic if they walk away for four minutes. The recipe was fine. The attention wasn't.
Around the same time, I was actually learning to cook properly — reverse-seared steaks, specifically, because I'm an infrastructure guy and I like processes I can reason about.
And I noticed something: a good recipe for steak tells you almost nothing about *doneness*.
It tells you to watch, touch, smell, and pull it at the right moment based on what's actually happening in the pan, not what a timer says should be happening.
The instructions are a starting scaffold. The result comes from continuous small observations layered on top.
That's exactly what changed my AI coding workflow.
The Core Insight: Prompting Is Mise en Place, Not the Whole Meal
Front-loading is the recipe-card mistake
When you write one massive prompt and let an agent rip for ten minutes uninterrupted, you're betting everything on the recipe card being sufficient.
It never is, because the model — like a stove — doesn't know your specific pan, your specific altitude, your specific edge cases.
**A great first prompt is mise en place: prep work, not the cook.** It gets your ingredients in order. It doesn't replace standing there.
I ran a real comparison in June across a batch of 40 small backend tasks — API handlers, migration scripts, retry logic — using Claude 4.6 in Cursor.
Half I ran "recipe-card style": one long, detailed prompt, then hands off until done.
Half I ran "cooking style": short prompt, then checkpoints every 20–30 seconds of agent activity where I actually read the diff, ran the relevant test, and course-corrected before letting it continue.
The recipe-card batch needed a second full pass on 61% of tasks. The cooking-style batch needed one on 22%. Same model.
Same prompts, roughly. The only variable was whether I was tasting as I went.
Searing is context, not instructions
Here's the part that took me longest to internalize: **the sear on a steak isn't caused by the recipe, it's caused by heat you're actively managing.** In coding terms, that's context — the actual files open, the actual test output, the actual error trace you paste back in mid-session.
Static instructions are the marinade. Context you feed in real time is the heat.
When Claude Code hits an ambiguous branch and I paste in the actual stack trace instead of re-explaining what I meant, that's the equivalent of pressing a thermometer into the meat instead of guessing from the clock.
It's a small, immediate correction based on ground truth, not a bigger upfront spec that tries to anticipate everything.
Resting the code before you ship it
Cooks let meat rest before cutting into it — the residual heat finishes the job and the juices redistribute.
I've started doing the code equivalent: after an agent finishes a change, I don't immediately commit.
I let it "rest" for one read-through where I'm not editing, just reading the diff cold, the way you'd read someone else's PR.
Roughly a third of the bugs I've caught since adopting this habit were things I'd have missed mid-flow, because during the cook you're too close to see clearly.
The Reality Check: This Isn't a License to Skip Rigor
I want to be straight about where this metaphor breaks, because I've seen people take "vibe coding" as permission to stop reading diffs entirely, and that's not what's happening here.
A cook who never tastes anything and just wings it burns dinner just as often as one who over-specifies and walks away.
**Cooking-style AI coding is still disciplined — it's just disciplined through observation instead of documentation.**
It also doesn't scale the same way across task types. For a one-off script, thirty seconds of attention per checkpoint is cheap.
For a 2,000-line refactor across a service boundary, "cooking it" means real architectural review at each checkpoint, not a glance.
I still write real specs for anything that touches auth, billing, or data migrations — some dishes genuinely need a recipe you follow to the gram, and pretending otherwise is how you get a security incident, not a viral blog post.
And this only works if you actually know how to cook — meaning you can read a diff and know if it's wrong.
If you can't evaluate the output, "tasting as you go" is just watching a pan you don't understand.
The senior engineers I know who've had success with this approach already had the judgment; the tool just made that judgment cheaper to apply continuously instead of once at review time.
The Practical Takeaway
If you're running Claude Code, Cursor, or Codex-style agents on real work, here's what I'd actually change tomorrow:
- **Cap unsupervised agent runs at 30–60 seconds of activity**, not full task completion. Check in, read the diff, adjust, continue.
- **Feed real signal back in, not restated instructions.** Paste the actual test failure or trace, not "that's still wrong, try again." - **Rest before you ship.** One cold read of the full diff before commit, separate from the session where you wrote it.
- **Match rigor to the dish.** Auth, payments, migrations — write the exhaustive spec. A retry wrapper or a one-off script — cook it live.
- **Build your palate, not just your prompts.** The skill that actually compounds here isn't prompt engineering. It's getting fast at reading a diff and knowing in two seconds if something's off.
None of this is about the model getting smarter. Claude 4.6 versus 4.5 didn't change my error rate — my process did. The tools are already good enough to cook with.
The question is whether you're standing at the stove or checking your phone in the other room.
Have you caught yourself walking away from an agent mid-task and paying for it later, or has front-loading the perfect prompt actually worked for you?
I'd genuinely like to know if I'm the only one who learned this the hard way.
---
