Cooking a steak needs almost no skill; a good one needs plenty, and AI coding is the same

An essay published on the blog blog.sydorets.com and discussed heavily on Hacker News (308 points, 346 comments at the time it was read) builds its argument around a single analogy: cooking a steak takes almost no skill to produce something technically edible, but a genuinely good steak, browned properly and cooked evenly to the same result every time, takes real skill. The author says AI-assisted software development now feels the same way. Developers build constantly, with AI in the loop for nearly everything, assembling agents, harnesses, tools, prompts and feedback loops, then hand the whole pipeline to a model hoping it produces what they imagined without needing to understand how any of it works. The results are inconsistent: sometimes the model delivers, sometimes it hands back something broken while acting completely confident that it is correct, which the author likens to a machine serving charcoal and calling it medium-rare. The essay describes the common reaction to that inconsistency as reaching for someone else's solution: paying for a premium AI product, hiring an agency, subscribing to another coding assistant, or switching frameworks, hoping the problem has already been solved elsewhere. To dramatize the failure of that shortcut, the author imagines going to an expensive restaurant and being served the same burnt steak as at home, because, in the analogy, every restaurant in the city hired the same AI cook and management calls it 'cost optimization,' reasoning most customers will not notice. The essay is explicit that this restaurant scene is a hypothetical device inside the analogy, not a real reported event, and no company, product, AI model or vendor is named anywhere in the piece. The author's conclusion is that AI is not a chef but a steak machine: it can follow a recipe and repeat a process quickly at scale, but it cannot know what the user actually wants unless that is translated into requirements, constraints, examples, tests and feedback, and even then it stays limited by its own capability, context window and the system around it. Standing over the machine correcting it constantly may help, the author writes, but it will not turn the machine into a chef. The piece argues that the only durable path is to learn the craft directly: understand what heat does to food, why thickness and resting matter, why a timer alone will not save the dish, and accept that ruining a few attempts is part of getting there. Applied to software, the parallel is that AI makes a developer faster, automates repetitive work, and offers a starting point, but it cannot replace judgment: it cannot define quality, cannot decide which tradeoffs are acceptable, and cannot always catch the moment when code is technically correct but wrong in every way that matters. The author's stated conclusion is that building good software with AI still requires understanding software: knowing what you are actually asking for, how to judge what comes back, and when the machine is confidently serving you charcoal.

Key facts

  • The essay argues AI can make software development faster but cannot replace the human judgment needed to build consistently good software.
  • Its central device is a steak-cooking analogy: an edible steak needs almost no skill, a genuinely good one needs real skill, and AI-assisted coding shows the same gap.
  • The 'every restaurant hired the same AI cook, cost optimization, most people won't notice' scene is explicitly the author's hypothetical illustration, not a real reported event; no company, product or AI model is named anywhere in the piece.
  • The author's stated conclusion: to build good software with AI, you still have to understand software, including how to judge what the model returns.
  • The post drew heavy Hacker News engagement at the time it was read, with 308 points and 346 comments.

Why it matters

The piece pushes back on a narrative common in AI-coding discourse, that tools alone can carry a project to a good result, by arguing the missing ingredient is not more automation but the developer's own judgment: what quality looks like, which tradeoffs are acceptable, and when output is technically correct but wrong in every way that matters.

Who it affects

The essay speaks to developers who lean on AI coding assistants, agents and generated workflows day to day, and to anyone deciding whether switching tools, subscriptions or frameworks can substitute for understanding the software being built.

How to use it

There is no product, price or feature to adopt here; the piece is a general essay published on the author's personal blog, not a tool release, so its only actionable content is the argument itself: keep learning the underlying craft rather than expecting a new AI product to close the gap.

How solid is it

The essay is an opinion piece, not a study: it presents no data, benchmark or survey, and its central 'restaurant hired the same AI cook' scene is an admitted hypothetical inside the analogy rather than a reported event. Its standing rests on the argument and its reception, not on cited evidence; the piece drew 308 points and 346 comments on Hacker News in its first roughly 13 hours.

Risks and caveats

The analogy is broad and unfalsifiable by design: it makes a values claim about the necessity of human judgment rather than a testable empirical one, and readers who disagree about how far current AI coding tools can go on their own will find nothing here to settle the disagreement either way. No company, model or vendor is named or evaluated, so the piece cannot be read as a review of any specific product.

“It can't define quality for you, can't decide which tradeoffs are acceptable, can't always catch the moment when something is technically correct but wrong in every way that matters.”

— the author