← Writing

Below the Abstraction

This one's for my peers who feel as conflicted using AI as I sometimes do, and for anyone questioning why they're still learning how to program. There's always a place for understanding the layers below.

Remember that scene from Silicon Valley where Jared gets into a driverless car? He thought he was going to Palo Alto, but he ended up in a shipping container on its way to Arallon.

Don't be like that with your AI.

Nine months ago, that was me. Minus the ocean crossing, but not by much.

If you find yourself asking your AI to "please fix it," or "go build it," or "do what X, Y and Z would do," I hope you read on. I was hacking away, asking my AI to build so, so many things. I've abandoned many of them. I've reworked a few of the remainders.

Yesterday I was doing the reading for a grad course I'm taking, and I hit this paragraph in Patt and Patel's Introduction to Computing Systems:

The Bottom Line

Abstractions allow us to be much more efficient in dealing with all kinds of situations. It is also true that one can be effective without understanding what is below the abstraction as long as everything behaves nicely. So, one should not pooh-pooh the notion of abstraction. On the contrary, one should celebrate it since it allows us to be more efficient.

In fact, if we never have to combine a component with anything else into a larger system, and if nothing can go wrong with the component, then it is perfectly fine to understand this component only at the level of its abstraction.

But if we have to combine multiple components into a larger system, we should be careful not to allow their abstractions to be the deepest level of our understanding. If we don't know the components below the level of their abstractions, then we are at the mercy of them working together without our intervention. If they don't work together, and we are unable to go below the level of abstraction, we are stuck. And that is the state we should take care not to find ourselves in.

They wrote that in 2001. The book walks you up from 0's and 1's, through gates and a little instruction set, through assembly, to C. They were talking about circuits. Read it again with an LLM in mind and it still holds, 25 years later.

You can be effective with an LLM without understanding what's under it, as long as everything behaves nicely, and you should celebrate that. But once you combine components into a larger system (agents calling tools, pipelines feeding pipelines, generated code you never read), the model's output becomes the deepest level of your understanding. When the components stop working well together, you can't go a level down. And that's a problem.

What "below the abstraction" means when AI owns the layers and you'd rather not open the box

For Patt and Patel it meant knowing the bits, the gates, the instruction set, and the assembly underneath. For an LLM, a layer below is the code it wrote, so being able to read code is being able to go down the layers of abstraction. For me, in 2026, it means three things, and the first one is the precondition for the other two.

  1. Know what "behaves nicely" means for the thing you asked for. Your why and your what. The how is what you bought the abstraction for. But if you can't say why a thing exists and what it's supposed to do, you'll never notice when it stops behaving. Neither will the model.

  2. Every decision your AI makes either goes through you, or gets audited and reviewed by you. Some of mine are pre-approved by design: a queue of tickets I've explicitly marked as safe to work overnight. Some I review after the fact. The ones I worry about are the decisions that were neither, and I try to keep that bucket empty. Over the past several months I've worked through about 400 Linear stories and hundreds of pull requests. I've reviewed about half of those PRs myself.

  3. Have the paper trail. Breadcrumbs to follow, so when something breaks you can trace back to exactly what happened and at which layer. There's no magic here. Just abstractions upon abstractions, like how it was when the first computer came to life.

The most useful thing I built for this is a team of falsifier skills. Their job is to tell me why certain things shouldn't be done, or how things could go wrong. They speak the truth because they're built that way, to make sure what's built continues to work properly. One of them recently challenged a new idea I was excited about and told me I realistically don't have the time to pursue it. Like what a best friend would say to you. I burn tokens on understanding why as much as I use them to build.

How I'll know if I've slipped

Two questions, for any system I've handed to the AI:

  1. Can I say, without looking it up, why something "I" built exists and what it's for?
  2. When my system breaks, can I trace what happened, layer by layer, back to the decision that caused it?

If either answer is no, then call me Jared! The "reviewed about half" number is the one I watch. If it drops toward zero while the PR count keeps climbing, then the abstraction has become the deepest level of my understanding, and I'm at the mercy of the components working together without me.

Patt and Patel wrote a timeless book. They were writing about transistors and circuits, and 25 years later it gave me a grounded way to have my cake and eat it too: keep my abstractions, and still know the way down, even if I never make it all the way to the 0's and 1's.

How far down the stack can you still go?