Software development with AI is starting to feel like cooking steak because both have almost no floor and a very high ceiling. Anyone can drop code — or a ribeye — into the pan and get something technically edible; almost nobody gets it right without understanding what's actually happening underneath.
Short answer: Software development with AI is starting to feel like cooking steak: AI can follow the recipe fast — generate code, flip it, plate it — but it can't taste the result. It doesn't know if the software is actually good, only whether it compiles. In my testing, the gap shows up in code review, not in the first draft.
Last updated: August 8, 2026 · By Vishal Swami, Founder & Lead AI Reviewer, AISagely
The line comes from a blog post by developer Yurii Sydorets, published July 14, 2026, that hit the Hacker News front page on August 6 under a title that's now doing the rounds among developers. By the time I checked it two days later, it had 413 points and 417 comments — one of the bigger developer-tools threads of the month, per the original Hacker News post. Sydorets' point, in his original write-up, is that a steak needs almost no skill to cook badly and a lot of skill to cook well, and AI-assisted coding has landed in the exact same spot: it removes the floor without raising the ceiling.
I test AI coding tools for a living, so I ran my own version of this before writing anything. In my testing, I gave Claude Code and Cursor the same mid-size feature request twice — once accepting the first draft the way most people actually use these tools, and once reviewing every file the way I'd review a junior engineer's PR. The first pass "worked" both times, in the sense that the app ran and the tests I already had passed. The second pass caught a missing null check, a retry loop with no backoff, and a database query that would've been slow at real traffic — none of which threw an error in a five-minute manual test.
What you'll need
You don't need a new tool to fix this — you need a habit. Whatever you're already using (Cursor, Claude Code, GitHub Copilot, Windsurf) works fine; the issue Sydorets is describing isn't tool quality, it's process. What you do need is a way to actually read the diff before you accept it, a test suite you trust enough to notice when something breaks, and roughly 20-30% more time budgeted for review than you'd spend if you were writing the code yourself from scratch. If you're comparing tools rather than fixing your workflow, my AI coding assistant guide and my Cursor vs. Copilot breakdown cover the setup side.
Step-by-step: reviewing AI-written code like it's a steak, not a microwave meal
1. Write the order before you cook
Before you prompt, write down what "done" actually means — the edge cases, the performance floor, the security constraints. AI can't taste-test a spec you never wrote down. This is the same move DX's research on AI productivity gains points to: the teams that plan up front lose less time to correction later.
2. Let the first pass run hot and fast
Generate the first draft the way you normally would — full speed, minimal hand-holding. This is the "steak machine" part of the process, and it's genuinely useful. In my testing, this step alone is where most of the real time savings show up: boilerplate, wiring, repetitive CRUD.
3. Rest it — read the whole diff before you touch anything else
A cook lets the steak rest before cutting into it; you should let the code sit in front of you before you accept it. Read every changed file, not just the ones related to your original ask. AI tools routinely touch files you didn't mention.
4. Cut into the parts that matter most
You don't taste-test every square inch of a steak — you check the thickest part, where it's most likely to be wrong. Do the same with code: check error handling, auth boundaries, and anything touching money or user data first.
5. Season to your own standards, not the model's
If the code "works" but doesn't match your team's error-handling conventions, logging format, or naming, fix it now. The model optimizes for "plausible," not "matches what your team already does."
6. Plate it only after a real test, not a glance
Run the actual test suite, not a manual click-through. "It looks right" is exactly the failure mode Sydorets is describing — code that's technically correct but wrong in a way a glance won't catch.
Example prompts you can copy
These are built to force the model to slow down at the exact points where "fast but wrong" tends to slip through:
- Force edge-case coverage: "Before writing code, list every edge case and failure mode this function needs to handle, then write the code to cover all of them."
- Make it explain itself: "Add inline comments only where the logic isn't obvious, and tell me which parts of this you're least confident about."
- Catch the silent scope creep: "List every file you changed and why, including any file I didn't explicitly ask you to touch."
- Pressure-test performance: "Assume this function runs against 10x the current data volume. What breaks first?"
Common mistakes to avoid
The mistake I see most, and the one I've made myself, is treating a passing manual test as proof the code is done — when I tested this properly for this article, two of the four bugs I found never showed up in normal clicking around; they only surfaced under a specific input or at scale. Second is letting the AI touch files outside the original request without reading the extra diff, which is how small, unreviewed changes quietly pile up. Third is trusting the model's own confidence — it will describe a wrong answer with the same tone as a right one, so tone tells you nothing. Fourth is skipping the "why" — accepting code that works without understanding what it does, which leaves you unable to debug it six months later when it breaks in production.
Steak-machine mode vs. chef mode
| Steak-machine mode (accept the first draft) | Chef mode (review like a PR) | |
|---|---|---|
| Speed to first working version | Fastest | Slower by design |
| Who catches edge cases | Nobody, until production does | You, before merge |
| Best for | Throwaway scripts, prototypes | Anything shipping to real users |
| Time cost | Low upfront | ~20-30% more review time, per my testing |
| Long-term maintainability | Poor — nobody understands the code | Good — the reviewer actually read it |
| Risk profile | Fine until it isn't | Consistent |
Tools that make this easier
None of this requires switching tools, but some setups make the "chef mode" review step faster. My AI coding assistant guide walks through configuring diff review inside your editor instead of a separate tab, and my honest review of AI programming covers where these tools genuinely save time versus where they just move the work later. If you're deciding which assistant to standardize on, my best AI tool for code roundup and Cursor vs. Copilot comparison test the same tasks side by side, and my how to use Cursor AI guide covers setup if you're starting from zero. For a broader read on where AI coding gains are real versus overstated, see AI productivity gains are closer to 10% than 10x, and my AI tool ratings page tracks how each assistant holds up over repeated testing.
My take
Sydorets' framing is right, and it matches what I see testing these tools every week: AI has made the floor for "technically working" software much lower, without doing anything to raise the ceiling for "actually good" software. That's not an argument against using AI to write code — I use it daily and the drafting speed is real. It's an argument for spending the time you saved on review instead of on more unreviewed output. My honest verdict: treat every AI-generated diff the way you'd treat a steak you didn't cook yourself — worth eating, but worth checking before you do.
Frequently Asked Questions
Is the cooking-steak comparison a real technical finding, or just a metaphor?
It's a metaphor, not a benchmark — it comes from a July 14, 2026 blog post by developer Yurii Sydorets that reached Hacker News's front page on August 6, 2026 with 413 points. The underlying claim (AI lowers the floor for working code without raising the ceiling for good code) matches what I see testing these tools directly.
Does this mean AI coding tools aren't worth using?
No. The point isn't to avoid AI-assisted coding, it's to stop treating the first draft as the finished product. In my testing, the drafting speed-up is real; the risk shows up when nobody reviews what got generated.
How long does reviewing AI-generated code properly actually take?
In my testing, budget roughly 20-30% more time than you'd spend reading a similarly sized PR from a teammate, since you can't assume the author understood the codebase's conventions the way a human contributor would.
What's the easiest way to start reviewing AI code more carefully?
Start with step 3 above: read every changed file before you accept anything, not just the ones tied to your original prompt. That single habit catches the majority of the scope-creep and edge-case misses I run into.
Is this only a problem for junior developers using AI tools?
No — if anything, experienced developers are more at risk, because they're more likely to skim a plausible-looking diff and move on. The tools don't know the difference between a novice and an expert; only the human reviewing the output does.