A software engineer and AI-tool builder has challenged the increasingly common claim that generative artificial intelligence has effectively “solved” computer programming. Alex Ewerlöf argues that large language models can accelerate code creation but that this is only one part of delivering dependable software.
In a newly published essay, Ewerlöf distinguishes producing code from maintaining systems that must remain secure, reliable and scalable. He says non-functional requirements account for much of the work and cost in real production environments. Even functional requirements—ensuring software actually performs the intended task—remain unresolved in his view.
The author is not rejecting AI-assisted development. He describes himself as an early adopter who has used coding models, built model harnesses, taught the subject and worked on products powered by language models. His argument is instead that usefulness in selected tasks should not be generalized into a claim that professional software engineering no longer requires human judgment.
Ewerlöf identifies personal tools and proofs of concept as areas where users may rationally accept more risk. Systems involving money, safety or legal consequences have a lower tolerance for error, he argues, and require accountable people to understand and control their behavior. Because an AI system cannot itself bear professional or legal consequences, responsibility remains with the people and organizations deploying it.
The essay also focuses on the probabilistic nature of language models. Coding assistants can be wrapped in conventional software that runs tests, reports compiler or runtime errors and gives the model repeated opportunities to repair output. That feedback loop can make the tools effective, but Ewerlöf says it does not turn the underlying model into a deterministic reasoning system. Larger context and more complicated logic can still reduce accuracy.
His practical warning is directed especially at technology leaders. He urges them not to require AI across every development surface simply because generation is faster. Inappropriate use, insufficient review or skipped quality work can transfer the resulting failures to customers, while the deploying company remains accountable.
The article is an informed opinion rather than a controlled benchmark of particular tools, and several examples reflect the author's own experience. Its core distinction is nevertheless relevant to current adoption decisions: productivity during initial implementation is not the same measure as total software quality or lifetime cost. Teams evaluating coding assistants still need to test their own workflows, track defects and security outcomes, and decide where human review is mandatory. On that account, AI is a potentially powerful engineering tool, but not evidence that engineering itself has been completed.
