Almost no skill required to cook a steak

Most of the energy went into rejecting the steak metaphor. A lot of people pointed out that steak is unusually easy to get to very high quality at home if you start with a good cut and use basic tools like a thermometer, reverse sear, or sous vide. That objection ended up reinforcing the software point more than disproving it. Several comments reframed the issue as preconditions and judgment. The cooking itself may be simple once you know the cut, target temperature, searing method, and equipment. The same is true for AI coding. The easy part starts after the important decisions have already been made. Where the discussion actually landed on software was more useful. People agreed that LLMs work well on common, repetitive, tightly scoped tasks, especially CRUD, glue code, prototypes, and UI experiments. They save real time there. The failure mode shows up when teams confuse faster output with solved engineering. Generated code tends to bloat, lose parsimony, and accumulate changes nobody fully understands. Several practitioners said the initial speed gains get eaten by review, cleanup, and iteration when maintainability matters. Others said the models are already good enough if you stay in a director role and judge results rather than line-edit every detail. That split was not really about whether AI works. It was about whether your standard is “good enough to ship” or “good enough to own for years.” There was also a broader business read. Software quality is usually set by market pressure, not craft ideals. Plenty of products only need to be edible, not perfect. That makes AI economically attractive even if it lowers average quality, because most buyers reward speed and acceptable outcomes over elegance. The sharpest takeaway was that AI is shifting the supply curve for software, especially at the low end, while increasing the premium on the people who can still define taste, verify outputs, and decide where quality actually matters.