[SC]()

iOS. Apple. Indies. Plus Things.

The Abstraction Layer

// Written by // // Read it in about 2 minutes // RE: A.I.

This post is brought to you by Clerk. Add secure, native iOS authentication in minutes with Clerk’s pre-built SwiftUI components.

When I first began my degree in the field of CompSci, I picked up a book: “Code”, by Charles Petzold. I don’t distinctly remember if it necessarily changed my life or sparked my love of software development. But, I remember with certainty that it did give me the gift of curiosity.

Code by Charles Petzold.

What was actually happening when I was typing in Visual Basic on some Windows desktop in a computer lab at Ozarks Technical Community College? How did the characters transform and…just…do stuff? I wanted to know, and that book went in on it all. I remember learning about how every computer begins with simple, basic physical states: on and off. Open, and closed. And, of course, 1 or 0.

From there, those binary states can be represented by all sorts of interesting modes: switches, relays, and then transistors. Building on that some more, wire enough of them together and now we get to the interesting stuff. Logic gates, adders, memory, clocks, and eventually down the line — a CPU that can read instructions from memory! And, execute them!

But in my day to day? That’s all abstracted away from me, as it should be. It’s just as well, though, since abstractions have long been a core part of our indsutry. In fact, who remembers interviews in the aughts when object orientated programming was king? We had to remember our favorite acronym, A.P.I.E. — abstraction, polymorphism, inheritance, and encapsulation. So, in that sense, code has long been an abstraction layer. It’s one that sits comfortably above the raw hardware, but it’s close enough that, after enough of said translation, it can still make silicon do something real and tangible in the world.

I’ve been thinking a lot about abstraction layers lately.

What the “abstraction” layer is now, and how we define it, is changing. And, naturally, it has me wondering. With the rise of agentic engineering, I’ve started to consider something I thought impossible only a few years ago:

Is code going to be abstracted away, entirely, soon?

And, yeah, I realize the word “soon” is doing some heavy lifting here.

Once the frontier models improve, how soon until it matters if you read what it outputs? No, seriously, I’m wondering that lately. I know, I know — I KNOW — it’s not there yet. Today. But, I think eventually, it will be. And what does that mean for software engineering? Is it then prompt engineering? Will knowing how the all the pieces fit together matter even more, or less?

How much longer is understanding code a competitive advantage? I know it certainly is today. And, lest I’m not making my stance clear enough, you do need to understand code to succeed in my opinion. In 2026, most of us in this field grew up figuring outs its intimate inner workings. That’s why those with years or experience are currently building software at a blistering pace. Though, how long will it keep us ahead of everyone else? Because when it becomes abstracted away, well — that’s a different world we’ll live in.

let concatenatedThoughts = """

Of course, we will always need people in the world who understand code. In the same way that we need people in the world who have a professional, expert knowledge of how computers actually work. We can't afford to lose that, obviously, because when one machine drives another — both machines will always need a captain.

"""

I’m pondering here, not panicking. We need to remember that abstraction layers are not inherently bad. In fact, by most measures, not only are they incredibly useful — they are necessary. I don’t want to manually tweak logic gates. I want to write code to do it. Years ago, there was undoubly a time where writing code woud seem as outlandish as using a chat interface to produce that same code for you.

Naturally, as the future progresses and technology advances, making software will look different, too. The future of software engineering versus “AI does it all” hopefully will not be a zero-sum game. More abstraction does not automatically mean we need less understanding, but I think it does most likely change “what” is important to understand.

I don’t know the answer, and to be honest — I’m not scared of the answer, either. I’ve made my way in this industry by being curious. People like to say it’s all changing so fast, and there’s an inordinate amount of AI tooling, advances, or models to learn. I say it’s always been that way. I’ve done well in this career because of adapting to changes. By wondering how logic gates, bits and bytes, and code eventually create a piece of software I made. And whatever the tools and technology become to keep creating those things well and with precision, I’ll keep learning.

When I went back to speak at my community college years ago, I told the prospective students that the only constant in our industry is change. Now, I suppose, never has that been more apt.

Until next time ✌️

···

Spot an issue, anything to add?

Reach Out.