Background & Context§
The proliferation of AI coding assistants—from GitHub Copilot to Cursor and proprietary agentic systems—has created a narrative that software development is becoming accessible to anyone, regardless of technical depth. The promise: describe what you want, and the AI will build it. This allure has driven adoption across startups and enterprises, with teams racing to integrate AI into their pipelines. However, a recent blog post by Sydorets (posted on his personal blog) draws a sharp analogy between this workflow and cooking a steak: anyone can throw a steak in a pan, but consistently producing a perfect medium-rare requires understanding heat, timing, and technique. Similarly, AI can generate code that runs, but producing software that truly meets user needs, performs reliably, and embodies intentional design still demands human expertise. The post has resonated widely, sparking discussions about the practical limits of AI development tools and the enduring necessity of skilled engineers.
The News: What Happened Exactly§
The blog post, titled "Software development with AI is starting to feel like cooking steak," argues that AI-assisted development is lulling developers into a false sense of competence. The author observes that we now build continuously—during commutes, between tasks, almost unconsciously—using agents, pipelines, and prompts, yet we often have little understanding of how the underlying systems work. We throw "everything at a model and hope it gives us what we imagined," without mastering the fundamental principles of software engineering. This approach yields inconsistent results: sometimes surprisingly good, other times a "charcoal with a sprig of thyme" that the AI confidently presents as a perfect dish. The author notes that these failures persist even when we invest in premium AI tools, agencies, or new frameworks, because we're essentially outsourcing the undefined problem—hoping someone else has solved it for us, but often finding that they haven't.
The article's central metaphor paints AI as a "steak machine": it can follow recipes and repeat processes at scale, but it lacks the ability to understand the vision in your head. Translating that vision into requirements, constraints, and tests remains a human responsibility. Even with fine-grained feedback, the AI is bounded by its context window and the quality of the surrounding system—it cannot become a "Michelin-starred chef." The author draws a frustrating conclusion: after paying for premium AI services, you might still get the same burnt steak you'd make at home, because all restaurants (i.e., AI providers) have hired the same AI cook. Management optimizes for cost, accepting that most users won't notice mediocre quality. But for developers who care deeply about their craft, this is unacceptable.
The only path forward, the post argues, is to "learn to cook"—to acquire the deep understanding of software architecture, trade-offs, and quality that AI cannot replicate. This means studying how code works, why certain patterns matter, and how to judge AI-generated output. The author encourages embracing failure as a learning tool and iterating until you can produce the desired result reliably, rather than relying on luck. Eventually, you might become skilled enough to "open your own restaurant"—meaning, you can leverage AI as a sous-chef rather than expecting it to replace your judgment. Most users won't notice the difference, but you will—because you care about what you build.
This narrative is unique in its emphasis on the craft of development, rather than just productivity gains or model capabilities. It mirrors growing concerns in the industry about code quality and maintainability as AI-generated code proliferates. The post does not cite specific metrics or case studies, but its anecdotal evidence and relatable analogy have struck a chord, leading to broad discussions on Hacker News, LinkedIn, and X.
Historical Parallels & Similar Incidents§
The "steak machine" metaphor echoes earlier moments in the AI development landscape. One direct parallel is the rise of low-code and no-code platforms in the late 2010s, such as OutSystems, Mendix, and Bubble. These tools promised to democratize software creation, allowing non-programmers to build apps by dragging and dropping. However, they quickly revealed their limitations: complex logic, scalability, and security often required hand-coded solutions. As a result, developers who embraced these platforms as a full replacement for coding found themselves hitting a glass ceiling—the platform could handle the easy 80%, but the remaining 20% needed a professional. This led to the common adage: "No-code is for building prototypes, not production software." Yet, the allure of speed and ease persists, and AI tools are merely the next evolution of this pattern.
Another historical parallel is the advent of code generation tools like in the early 2000s, such as Visual Studio's drag-and-drop UI builders or code wizards. These tools aimed to reduce boilerplate code, but they often produced bloated, hard-to-maintain codebases that required refactoring. Developers who relied too heavily on wizards found themselves debugging generated code that they didn't fully understand. The industry's response was a push toward clean code practices and a renewed emphasis on understanding fundamentals. Similarly, today's AI assistants often produce code that looks correct but may have hidden issues—insecure dependencies, performance bottlenecks, or architectural flaws. The lesson from both eras is that tools that abstract away complexity do not eliminate the need for expertise; they shift it to a higher level. The developer must become the chef who knows when to trust the machine and when to intervene.
The difference with AI is the confidence with which it generates plausible but wrong output. Unlike a wizard which follows fixed templates, AI generates novel combinations, making it harder to spot flaws. This is reminiscent of the early days of automated translation, where systems would produce grammatically correct but semantically nonsensical sentences. Only with understanding of the source and target languages could a translator catch these errors. Similarly, today's AI coding assistants require a developer who can perform code review with a critical eye—someone who has tasted enough "burnt steak" to recognize it.
These historical parallels reinforce the article's message: technology amplifies human capability but does not replace it. Every leap in abstraction—from assembly to high-level languages, from imperative to declarative, from coding to no-code, and now to AI-magic—has required a new layer of expertise to manage the complexities that the abstraction introduces. The blog post is a timely reminder that, as AI becomes ubiquitous, the demand for skilled software engineers who understand the fundamentals will not diminish; it will evolve. Those who invest in learning the craft will be able to harness AI effectively, while those who rely solely on the "steak machine" will produce mediocrity at scale.
The article's call to "open your own restaurant" suggests a future where AI agents are hired as cooks, but the head chef (the developer) still defines the menu and oversees the kitchen. This vision aligns with emerging trends like "agentic development," where AI agents execute tasks within a defined framework. However, the author cautions that without human judgment, the result is still likely to be burnt steak—just faster. As we navigate this new era, the most successful developers will be those who treat AI as a tool to augment their skills, not to replace them, and who remain committed to understanding the principles that govern software quality. The steak may be easier to cook, but creating a Michelin-starred meal will always require a chef's touch.