Thinking Better

The Abstraction Tax

On engineering judgment, simplicity, and earning complexity.

“The most valuable skill in AI is not technical skill.
It is judgment.

First Edition · Teves Consulting · 2026
Thinking Better is a three-part essay series about engineering judgment, intellectual independence, and the role of memory in helping people ask better questions.

There is a memorable scene in Wall‑E that has stayed with me for years.

The humans aboard the spaceship have solved every inconvenience. Food arrives automatically. Chairs move for them. Even conversations happen through screens while the people involved sit only a few feet apart.

Nothing appears broken.

And yet something important has disappeared.

Convenience became so complete that dependence became invisible.

For a long time I treated that scene as clever science fiction.

After building AI systems, I started seeing it everywhere.

The Enterprise Lesson

A few years ago, I was part of a team at the Centers for Disease Control and Prevention building an internal AI assistant. The work was technically demanding for good reason. Enterprise systems must integrate information from many sources, serve real users, and continue working when reliability matters more than novelty.

I learned a tremendous amount about enterprise AI. But the most valuable lesson was not technical. It was architectural.

As engineers, we naturally enjoy solving difficult problems. The danger is that we sometimes become so good at building solutions that we stop asking whether the problem truly deserves another layer of technology.

Complexity has a way of justifying itself.

One abstraction leads to another. A framework requires another framework. An orchestration layer suggests another service. Before long, the architecture feels sophisticated—but no one has stopped to ask whether the additional complexity actually improved the outcome.

The Question That Does Not Change

In the years since, AI has evolved at extraordinary speed. Work that once required months of custom engineering can now be assembled over a weekend. Models have become dramatically more capable. Tools appear faster than most teams can evaluate them.

Yet the fundamental question has not changed.

What problem are you actually trying to solve?

Not what technology would be interesting. Not what everyone else is adopting. Not what fits neatly into the latest architecture diagram.

What problem have you actually proved exists?
When technology can do almost anything, judgment becomes the scarce resource.

Building Aion

That question became the foundation of Aion. When I began building it, I made myself follow a simple rule:

Every layer of complexity had to earn its place.

Not because simplicity is always better. Sometimes the right answer is a sophisticated architecture. But sophistication should be the conclusion of careful reasoning—not the starting point.

Every major decision had to answer a simple question:

What problem does this solve that the current system cannot?

If I could not answer that clearly, the new component did not belong.

Aion grew into a bilingual AI system with grounded retrieval, identity management, continuity, and intelligent memory while remaining remarkably small and inexpensive to operate.

The achievement was not doing more with less.
The achievement was learning which complexity actually mattered.

The Tax We Stop Noticing

Every abstraction carries a cost. Frameworks reduce boilerplate. Infrastructure reduces manual work. Automation reduces repetition. All of those things can create enormous value.

But they also introduce dependencies, maintenance, hidden assumptions, and operational weight that remain long after the excitement of adopting them fades.

I think of that cost as the abstraction tax.

Sometimes the tax is absolutely worth paying. Sometimes it quietly accumulates until the system becomes more complicated than the problem it was originally built to solve.

The Chair That Moves for You

The humans in Wall‑E were not lazy. They simply accepted convenience one improvement at a time. No individual chair looked dangerous. No individual automation seemed unreasonable. Only when viewed together did the pattern become obvious.

I see the same pattern in software. Teams adopt powerful tools for problems they have never properly measured. Infrastructure expands because expansion feels like progress. Dependencies accumulate because everyone else uses them.

Eventually the architecture begins serving itself rather than the people it was meant to help.

Judgment Cannot Be Abstracted Away

Technology will continue to improve. Models will become more capable. Frameworks will come and go. Each generation will promise to remove another layer of complexity.

Some of those promises will be worth accepting. Some will quietly become another chair that moves for us when walking would have been enough.

The difficult part has never been choosing the newest tool. The difficult part is recognizing which problems deserve another layer of technology—and which ones deserve a better question instead.

Judgment does not come from the model.
It comes from the person who decides what the model is for.