A Critique of AI Use — Misunderstanding Driven by Easy Access · The Illusion of Competence · The Erosion of Experience and Knowledge · The Normalization of Low Expertise

Software development has always gone through shifts in paradigm. More abstract programming languages and visual development tools have been appearing and entering the mainstream for decades. But as a consequence, understanding of lower-level systems—and the ability to work directly with them—has consistently become rarer.

The arrival of AI is similar in that respect.

Much of the AI-assisted development discussed on social media today can be understood as using AI as an abstraction layer: even at the application level, people rely heavily on visually observable UI while allowing AI to abstract away the underlying domain and data logic. The point at which AI can truly be regarded as a mature development tool will probably come only after the current debate over technical debt—created partly because humans cannot keep up with the speed at which AI produces software—has largely been resolved.

So this tool is not about to excessively encroach on the day-to-day work of professional developers overnight. What makes the situation harder to see clearly is the optimistic misunderstanding encouraged by AI’s extraordinarily rapid progress. For now, it is probably enough to think of it this way: Building fairly superficial applications has become much easier.

There is growing concern that AI is causing previously acquired experience and technical knowledge to deteriorate rapidly. The idea that simply using AI will cause your knowledge to increase is a fairly optimistic assumption. Unless you deliberately approach AI with the intention to learn, while actively reviewing and questioning its answers, that is unlikely to happen automatically.

A common saying about AI is that “you get out of it what you know.” There is a good chance the same principle will be reflected directly in the quality of the final product. Even when the result looks perfectly convincing on the surface.

If someone becomes overly dependent on visual information, loses the ability to detect non-visual bugs and contradictions, and cannot interpret the specialized answers AI provides well enough to make independent judgments about them, it becomes difficult to call that person an expert merely because they use AI.

This applies not only to developers, but to doctors, lawyers, tax professionals, real-estate specialists, and virtually every other field. No matter how well AI explains an illness, if you cannot interpret that explanation, reason about exceptional cases, or actually provide treatment, then you are not a doctor. As a patient, you can certainly ask AI for advice about a diagnosis or possible direction of treatment. But that is a different thing. The same principle applies elsewhere.

Incidentally, one of the things doctors increasingly find frustrating these days is apparently hearing patients begin with: “I asked AI, and it told me that...”

It is true that vibe coding can solve security problems and many other technical issues. The point, however, is that the person prompting the AI may lack the ability to raise those issues in the first place.

Even if they do identify a problem and the AI proposes a solution, someone still has to judge whether that solution is appropriate for the situation at hand. But what if the person lacks the ability to make that judgment? Then perhaps they ask the AI to make the judgment as well. But for the AI to do that properly, the person has to explain the current situation in sufficient detail. What if they lack the ability to explain that, too? That is where things begin to unravel.

The result is a flood of products whose creators look at a plausible UI and think, “Oh, it works,” while having little idea what kinds of negative outcomes may be hiding underneath.

People sometimes boast about impressive revenue, download counts, or visitor numbers for an app or service they have built.

Keep in mind that the service may be supported by paid advertising or expensive commercial APIs. There may be significant costs that are simply not being mentioned.

For example, suppose someone builds a service that merely wraps the Codex or Claude API and then offers it to users for almost nothing. It may be relatively easy to attract users under those conditions.

The real skill then becomes controlling the rate of financial bleeding while continuing to receive enough new funding to keep the app or service alive. Scale that problem up far enough, and we call it management.