Ai, Complexity, And The Illusion Of Expertise

The conversation that sparked this article was informal, scattered, and half-typed on Telegram. That feels appropriate, because the idea itself is not something that arrived fully formed. It emerged gradually, out of experience, repetition, and frustration, which is precisely the point.

What I noticed recently is that the AI that I work with no longer tries to overcomplicate things. Where it once defaulted to sprawling frameworks, elaborate abstractions, or heavyweight applications, it now often suggests the simplest viable solution: a shell script instead of an app, an existing system component instead of a new dependency.

The difference wasn’t an upgrade to the AI. It was accumulated context, not just technical details, but assumptions about how problems should be approached.

I had already told it, repeatedly and implicitly, to prefer what already exists, to avoid unnecessary structure, and to be careful not to create complexity that doesn’t serve the problem. Over time, that became its default behavior.

This is often described as “learning how to prompt,” but that framing misses something important. What’s really happening is that the AI is reflecting back the user’s understanding—or misunderstanding—of systems.

AI doesn’t reward authority; it rewards clarity

There’s a popular idea that AI is dangerous, powerful, or in need of certified experts to operate it safely. But in practice, AI tends to amplify whatever mental model the user brings with them.

If you approach it assuming complexity is intelligence, it will happily generate complexity. If you approach it assuming that clarity matters, it will try to be clear. It doesn’t know which is virtuous—it infers virtue from you. This is why two people can use the same model and get radically different results. One ends up buried under abstraction; the other quietly replaces work that used to require a team.

That doesn’t make the second person smarter in some absolute sense. It means they are less attached to inherited rituals.

Learning AI versus learning with AI

During the conversation, my friend mentioned possibly taking a course on how to use AI. My instinctive reaction was skeptical, almost hostile—not because learning is bad, but because courses tend to encode old assumptions.

Most AI courses are designed for teams, for managers, and for corporations that already believe software must be built in a certain way. They teach process, governance, and coordination—not understanding.

There’s a line from the Japanese poet Matsuo Bashō that captures this better than any syllabus:

“Go to the pine if you want to learn about the pine, or to the bamboo if you want to learn about the bamboo; and in doing so, you must leave behind your subjective occupation with yourself, otherwise you impose yourself on the object and do not learn.”

The AI is the pine. Sitting through slides about how other people claim to use it is often a way of avoiding direct engagement.

In that sense, a course can actually slow progress. It teaches you how you’re supposed to relate to the tool, rather than letting you discover how it behaves when unburdened by expectation.

Speaking the wrong language fluently

This reminded me of a story from Blackfoot Physics by F. David Peat. Peat, a trained physicist, spent time living with the Blackfoot tribe to understand how their knowledge systems related to modern science.

After a year, confident in his language skills, he began casually greeting people only to be met with laughter. Eventually he discovered why: children and adults use different forms of the language, and he had been addressing adults using what was effectively baby talk.

He wasn’t wrong. He was fluent. He was just operating at the wrong level of meaning.

Much of the contemporary discourse around AI feels like that. Perfectly articulated, confidently delivered—and fundamentally misaligned with how the tool actually works.

Why AI quietly dissolves the need for large teams

One of the least discussed effects of AI is what it does to coordination costs.

A huge amount of modern software complexity exists not because machines demand it, but because humans do. Version control rituals, sprawling frameworks, endless processes—these are social technologies designed to allow many people to work on the same thing without constantly colliding.

AI changes that equation.

If one person can now hold the entire system in their head, with the AI acting as a fast, tireless collaborator, then many of the practices we’ve normalized stop being necessary. Not optional. Unnecessary.

This helps explain phenomena that otherwise seem shocking, like Elon Musk firing the majority of Twitter’s staff without the platform collapsing.

At a basic level, Twitter didn’t need thousands of developers to serve millions of users, because the service itself does not become conceptually more complex as the user count rises. A timeline is a timeline whether it has one hundred users or one hundred million. Posting, following, replying, and moderation do not suddenly require new ideas at scale.

What does increase with user numbers is load: more traffic, more storage, more redundancy, and more monitoring. Those are largely operational concerns. They require servers, networking, databases, and a relatively small number of competent system administrators—not endless layers of product teams continually reinventing the same features.

In other words, scale mostly changes the quantity of resources, not the nature of the software. Twitter needed infrastructure and a small number of people who actually understood the system.

Scale was never primarily about headcount. It was about clarity.

A small concrete example

A trivial but telling example came up recently while I was working on a system that synchronizes files across servers. Under certain conditions, switching rapidly between sites could cause conflicts. In a financial context, that kind of conflict is dangerous because it risks users losing funds.

In the past, this would likely have been framed as a sizeable application: a service, a dashboard, perhaps even a frontend. Instead, with the right context, the AI suggested a simple solution: a small shell script that detects conflicts early and usually resolves them automatically, only halting operations safely when the state genuinely cannot be reconciled.

No frameworks. No new abstractions. Just existing system tools arranged carefully.

The point isn’t the specific technology—you don’t need to know what file synchronization software was involved to understand it. The point is that the AI didn’t simplify the problem. The problem was already simple. It merely refused to inflate it.

That refusal is the real shift.

AI doesn’t change everything; it reveals what never mattered

People often say “AI will change everything,” but they rarely stop to ask what “everything” means.

AI doesn’t abolish judgment, responsibility, or understanding. It removes excuses. It strips away practices that were justified mainly by human limitation and coordination overhead. What remains is uncomfortable.

Developers who relied on ceremony struggle. Institutions built on credentialism wobble. Systems designed to obscure rather than clarify become harder to defend, and lone builders who understand systems thrive.

A quiet ethic of restraint

Running through all of this is an ethical stance that rarely gets named: Don’t impose yourself on the tool. Don’t overbuild. Don’t confuse motion with progress. Don’t mistake teamwork for virtue. This isn’t anti-human. It’s anti-bureaucratic.

AI doesn’t replace people. It replaces the need to pretend that complexity is wisdom, that size implies competence, or that experts are necessary simply because they exist.

If you want to learn about AI, go to the AI. Ask it to help you make better requests! 

Graphic by Paul Petard (with permission back in the 90s!)