The Abstraction Crisis: Why AI is a Bad Tool for Software

The author argues that AI is a poor tool for software development because its opaque nature makes verification more costly than manual creation. He suggests that AI's ability to generate code simply reveals a widespread lack of proper abstraction in the industry. To remain relevant, developers must move beyond trivial tasks and focus on deep ownership and sophisticated software design.

Key Points

• AI is useful for condensing information but fails in software because its outputs are opaque and difficult to verify.
• The effort required to validate AI-generated code or security claims often negates any perceived productivity gains.
• AI's success in code generation highlights a systemic failure in software engineering to properly abstract repetitive and trivial tasks.
• Prompt engineering is dismissed as a scam because users cannot establish stable correlations within a black-box system.
• The anxiety surrounding AI in the industry stems from the machine's ability to expose the inherent uselessness of many current programming roles.

Sentiment

The community sentiment toward the article is mostly negative. Commenters broadly reject its categorical conclusion and often describe it as overstated, outdated, or poorly argued, though many still agree that verification, abstraction quality, and developer ownership are legitimate concerns. The thread is argumentative but not one-sided: the dominant reaction is opposition to the article's hard anti-AI stance, tempered by substantial agreement that careless AI coding can damage maintainability and craft.

In Agreement

• AI-generated code is opaque in a way that compilers, high-level languages, language servers, and traditional code generators are not, because LLMs can make unpredictable design choices rather than simply translating formal intent.
• Verification can become expensive when a model produces large or unfamiliar changes, especially if the developer lacks the context needed to understand the code deeply.
• Blind vibe coding threatens maintainability, bus factor, and operational ownership because the code still has to be debugged when the model is unavailable or wrong.
• The strongest use cases for AI may be prototypes, end-user applications, and internal tools, while libraries, infrastructure, languages, and other foundational systems demand more rigor and less tolerance for fuzzy output.
• If developers repeatedly need AI to generate fragile boilerplate, templates, or glue code, that may signal a missing abstraction that should be fixed rather than endlessly regenerated.
• Some commenters worry that relying on AI as an intermediary can erode craftsmanship, mental models, and the direct satisfaction of precisely expressing ideas in code.

Opposed

• Many commenters argue that the article is outdated because recent frontier coding models are already useful for real software work when guided by experienced developers.
• AI can be treated as a power tool or junior colleague: the human still defines the goal, reviews the diff, writes or runs tests, checks behavior, and remains responsible for the shipped code.
• Verification is not always as hard as creation; security findings, failing inputs, narrow refactors, generated tests, and staged product behavior can often be checked more cheaply than they can be discovered or implemented manually.
• Dismissing AI-writeable code as trivial ignores how much valuable software work consists of pragmatic product delivery, integration, scaffolding, documentation, and repetitive business logic.
• AI can improve engineering quality by making tests, refactors, design exploration, documentation updates, and alternate implementations cheaper to attempt.
• Some commenters say the real problem is not AI itself but lazy execution, weak review discipline, and bad leadership using AI as a cost-cutting or blame-shifting excuse.