Coding is not solved
Veteran software engineer Alex Ewerlöf argues that claiming coding is solved by LLMs ignores non-functional requirements, accountability, and the fundamental limits of stochastic models.
read it It provides a much-needed reality check on AI coding hype with a pragmatic breakdown of where LLMs fail in production systems.
summary
Alex Ewerlöf pushes back against the narrative that AI has solved software engineering, arguing that functional code generation is only a small part of building reliable systems. He highlights that non-functional requirements like security, scale, and long-term maintenance cannot be outsourced to tools that lack accountability or genuine logical reasoning. While acknowledging LLMs are exceptional for proofs-of-concept, translation, and localized generation, he warns that relying blindly on them degrades software quality and erodes human skill. The comment section fiercely debates this, with some echoing his concerns about code slop and others arguing that agentic tools drastically scale developer productivity.
key points
- Most software engineering costs stem from non-functional requirements like maintenance, reliability, and security, which stochastic LLMs cannot inherently guarantee.
- AI tools lack legal and moral accountability, making it dangerous to blindly trust them in mission-critical environments where mistakes carry real-world consequences.
- While LLMs excel at syntax translation, summarization, and proofs-of-concept, they struggle with core logical consistency over large contexts without heavy deterministic wrappers.
who should read it
Software engineers, engineering leaders, and tech professionals navigating AI integration in development workflows.
discussion mixed
consensus
Commenters are deeply divided, with many senior engineers echoing the author's warnings about code quality degradation and slop, while power users argue that agentic workflows and newer models radically shift what a single developer can achieve.
pushback
Critics of the post argue that dismissing LLMs is a coping mechanism for fear of obsolescence, noting that fuzzing, testing, and rapid iteration enabled by AI can actually make software more reliable if used correctly.
Reading the code does not mean you understand the code. One lesson that experience in software gave me: I never understood the code. You think it works a certain way, until you find out that it doesn't.
What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.
If we are committed to it, if we put the resources towards it and …
It argues that instead of manually reading code, developers can use LLMs to scale fuzzing, property testing, and failure analysis to achieve higher reliability.
Generated by an LLM from the article and thread. Check the sources before relying on it.