The post says the hard part of software engineering was never typing code. It was turning fuzzy business needs into systems that stay understandable, safe, and adaptable over time. The author argues that LLMs are strong at local pattern matching and boilerplate, but still weak at the work that makes a codebase survivable, like choosing boundaries, handling edge cases, resisting prompt injection, and reasoning about long-term maintenance. That landed with a lot of people. The strongest consensus was that AI raises the premium on fundamentals because somebody still has to define requirements, decide tradeoffs, and catch the silent assumptions the model invents when the prompt leaves gaps.
What people added is that this breaks differently by scope. For throwaway scripts, prototypes,
CRUD apps, internal tools, and small business workflows, many see real value already. Several comments framed LLMs as finally delivering on the old dream of empowering non-specialists to automate office work, much like Excel or scripting tools did. But once software becomes part of an evolving business process, the burden shifts from code generation to supervision. The sticking point was not whether models can emit working code. Many agreed they can. It was whether they can preserve coherent architecture and correct intent over months of change without an experienced person holding the whole system in their head.
A recurring theme was the "spec gap". Even formal verification, tests, or clean passes from the compiler do not save you if the model implemented the wrong thing precisely. Several comments pushed this further and said the core software engineering job is often to discover requirements, not merely encode them. That is why claims that prompting quality alone solves the problem rang hollow for many readers. If the essential ambiguity lives in the business, the model has to guess, and those guesses are exactly where maintainability and correctness go to die.
There was also a practical split between people reporting strong success and people reporting repeated failure. The success cases usually came with heavy scaffolding: an existing test suite, strong
type checking, reference repos, narrow scope, or a template that forces the model to run checks before writing much code. The failures clustered around bigger repos, unclear requirements, UI and state management, and tools that optimize for one-shot completion instead of asking clarifying questions. That produced a more grounded conclusion than either hype or dismissal. LLMs are already good enough to speed up implementation and repetitive refactors. They are not yet dependable stewards of architecture, requirements, or production reliability at scale.
rhonabwy.com