Twenty-Five Years Up the Abstraction Ladder

I wrote code for a living early in my career, at Nokia, on the protocol software inside GSM mobile phones. My work has since moved further from the keyboard, though I’ve never stopped following what happens on it, and over those years I’ve watched the abstraction layers in software development pile up one on top of another. Today I build software by describing what I want, and AI agents write the code. So the question I keep coming back to is a simple one: does experience from the lower layers still carry weight on the top one, or is it a story we like to tell ourselves?

I have an opinion, and I’ll share it, but I want to build the case first. That means the ladder itself, rung by rung, with the research along the way, which is more mixed than either the enthusiasts or the skeptics usually admit, and then what the top rung actually looks like from where I stand today.

How the Layers Piled Up

Every layer in this story did two things at once. It removed work, and it removed visibility. Keep that pair in mind, because it is the thread through everything that follows.

Writing Everything Yourself

At Nokia I worked on the GSM protocol stack inside the phone, at the layer closest to the radio. GSM shares each radio channel between eight users by cutting time into frames of about 4.615 milliseconds, each split into eight timeslots of roughly 577 microseconds, and the phone’s software has to be ready for its slot every single time. Software like that runs on hard real-time deadlines and scarce memory, and nothing is done for you. You allocate a buffer, you release it, and if you forget, nobody reminds you.

One day I compiled my change, ran it, and the system crashed. I’d love to tell you I found the cause in five minutes. I didn’t, and the details have blurred over the years, but I remember how it ended: a memory leak. And the surprising part was that the leak was not only in my code. Part of it was in the existing code, and my change was simply what brought it to the surface.

I can’t reconstruct the exact lines anymore, but the shape of the problem is one every embedded developer will recognize. In a protocol stack, memory is taken and given back continuously, a buffer for each message or frame that passes through. If one path through the code takes a buffer and never returns it, the loss is tiny each time, and a system can live with that hole for a long while because nothing exercises that path often enough to matter. Change the timing or the traffic, which is exactly what new code does, and the small loss repeats faster than before, until memory runs out and the crash appears somewhere that has nothing to do with the cause.

That is why knowing memory management mattered. A crash like that points you to the wrong place, so you have to reason backwards: account for where memory is taken and where it should come back, find the path where the two don’t balance, form a hypothesis and test it. Without that understanding, you end up poking at the code near the crash and hoping.

The other thing that got me to the answer was the people sitting around me. There was no Stack Overflow back then (it launched in 2008) and no AI assistant to ask. When you were stuck, you turned your chair around and asked a more experienced colleague, and working through it with them was as much a part of finding the leak as anything I knew myself.

The lesson I took from it was not really about memory leaks. It was that a symptom can show up far from its cause, and that code which works is not the same as code which is correct. The old code had worked for a long time. It was never correct.

Knowing What to Call

In the years that followed, the daily work of developers moved up a level. Memory was mostly managed by the language and the runtime, and the craft became knowing which library or framework fits the problem, how to call it, and how to combine several of them without them fighting each other. A good developer was someone who knew the ecosystem and could assemble a solution from proven parts quickly.

But the lower layer never went away. It just went quiet. When a framework behaved strangely under load, or a library did something its documentation didn’t mention, the person who could reason about what was happening underneath was usually the one who found it. The abstraction made the everyday work faster, and it made the unusual failure harder to see, because more of the machinery was hidden.

Letting the Assistant Finish the Line

The next layer arrived only a few years ago, with AI coding assistants that suggest, complete and edit code inside the developer’s own editor. The developer still drives, but a growing share of the typing is proposed by the machine. It was also the first rung where research could watch the climb as it happened, and the early results pointed one way. In three field experiments with 4,867 developers at Microsoft, Accenture and a Fortune 100 electronics manufacturer, an AI coding assistant increased completed tasks by about 26%, and less experienced developers gained the most (Cui et al., 2025).

Read quickly, that sounds like bad news for experience. But the tools have moved fast, and some of the early findings have already aged. METR, which ran one of the most cited trials of experienced developers, has since said its own early slowdown result no longer reflects current tools. It also could not get a clean measurement in its follow-up, partly because 30% to 50% of developers did not want to do some tasks without AI at all (METR, 2026). So I looked at what the more recent work says about experience in particular, and the picture is more interesting than a single speed number.

• Experienced developers lean on AI more, and check it more. In a survey of 791 US developers, about a third of those with 10 or more years of experience said over half of their shipped code was AI-generated, against 13% of those with two years or less. Nearly 30% of the senior group also said they edit AI output enough to offset most of the time it saved, against 17% of juniors (Fastly, 2025).
• The work itself is moving from writing to checking. A longitudinal study that followed developers over six months found that 82% now spend less time writing code, and described what replaces it as “supervisory engineering work, encompassing the direction, evaluation, and correction of AI output” (Vella and Blincoe, 2026).
• Leaning on AI too early can skip the lower rung. In a randomized trial, 52 mostly junior engineers learned a new Python library with or without an AI assistant. The AI group finished about two minutes faster, a difference that was not statistically significant, and then scored 17% lower on a comprehension quiz, with the largest gap on debugging questions. The authors expect the effect to be stronger with agentic tools, which do even more of the work (Anthropic, 2026).
• AI amplifies what is already there. Google’s DORA research, drawing on nearly 5,000 technology professionals, describes AI’s primary role in software development as that of “an amplifier,” with the greatest returns coming from the underlying organizational system rather than the tools themselves (DORA, 2025).

None of these is the final word. One is a vendor survey, two are preprints, and most of the data was collected before agents took over the keyboard. But read together, they point the same way. The less experienced gain most when the task has already been defined for them. The experienced delegate more and verify more. And the skill that fades first when you skip the lower layer is debugging, which is exactly the skill you need to tell whether finished work does what it was meant to do. Those are the parts of the job that were hidden on every rung, and they are exactly the parts that grow on the next one.

Engineers who learned a new library with AI scored 17% lower on understanding it, and the widest gap was in debugging. The skill that fades first when you skip the lower layer is the one you need most to verify the top one.

What It Looks Like Today

The top rung is different in kind, not just in degree. On this rung the person no longer drives the editor at all. In the delivery work we run at A-CX, AI agents write the code, test it and review it, and the people define what should be built and decide whether it was. Building that has taught me more about abstraction than I expected, so this is where I want to spend most of the time.

The Description Is the Work

What a person writes now is not code. It is a brief that says what we intend to deliver, in language the person paying for it can check. It is a specification with testable requirements and acceptance criteria. And it is a plan: an architecture first, then work broken into pieces that are actually ready to be built. Those documents are the source. The code is what comes out of them.

That shift changes where mistakes are cheap. An assumption caught in the specification costs a sentence. The same assumption caught after the code exists costs everything built on top of it, and when agents work through the night, that is a great deal more code than it would once have been. An underspecified task doesn’t produce a slow result or a broken one. It produces a fast, well-tested, confident implementation of something nobody asked for. Speed doesn’t make a wrong requirement cheaper. It makes it bigger.

Even the Instructions Moved Up a Layer

The most surprising lesson was about how we instruct the agents themselves. Our first instinct, like most teams’, was to write down the steps: do this, then check that, and if the check fails, do something else. Every time an agent surprised us, we added a rule. At its peak, about 27,000 lines of Markdown and 58,500 lines of Python governed our seven delivery agents.

And it didn’t work as well as it should have. A fixed rule is followed even in the corner case where it makes no sense, so we wrote exceptions, and then exceptions to the exceptions. What worked was climbing one more rung: we stopped describing the route and started describing the destination. Each agent is now a short contract of its purpose, its inputs, its outputs and the professional it behaves like, each in fewer than 200 lines, and the work got better. I wrote about that in more detail in We Cut Our AI Instructions in Half and It Got Better.

The part I like best is what happens when the models improve. A scripted route stays exactly as good as the day it was written. A well-stated goal lets a better model find a better route, without anyone touching the definition. That is the abstraction ladder again, in miniature, and it points straight at what experience is for on the top rung.

Defining the Intent in Detail

On the top rung, I believe experience moves to two places: defining the intent in detail, and verifying that the intent is fulfilled.

Defining the intent in detail means saying what done looks like before any code exists. Not only the feature, but the constraints around it: how much load it has to carry, what happens when the network drops, which data it must never touch, and what the system next to it expects. Anyone can describe the happy path well. What experience adds is the list of things that go wrong, because you have seen them go wrong. I ask about memory and resource limits because a leak once brought down a system under my hands. Every rung I’ve stood on or watched closely added items to that list, and the agent can’t add them for me, because it doesn’t know which ones matter in this system for this customer.

The agent can write a memory-safe function, choose a sensible library and wire the pieces together far faster than I ever could. What it can’t do on its own is know what I meant. It works from what was written down, and what was written down is always a compressed version of what someone actually wants. Everything left out, the agent fills in with a reasonable guess. Most of the time the guess is fine. The trouble is the time it isn’t, because the result usually still looks right.

Verifying That the Intent Is Fulfilled

Verifying that the intent is fulfilled is the other half, and it is not the same as checking that the code runs. Code that runs is exactly what that old Nokia code was. Verification asks whether what was built does what was intended, including the parts of the intent that never got written down. It means reading the result with healthy suspicion, knowing where a system like this tends to hide its problems, and recognizing an answer that looks right and isn’t.

One design choice in our own delivery carries much of that weight: the agent that writes the code and the agent that reviews it never share a context. The reviewer sees the change and the standards it has to meet, not the reasoning that produced it. An agent checking its own work in the same context finds its own reasons persuasive, because it found them persuasive the first time, and that is the difference between a review and a justification. People are no different. Our own sense of how well things are going is not a reliable instrument, so verification has to be done against the intent, not against a feeling.

I learned a similar lesson in a very different place, an AI analysis of the instruments on a 1976 Swan 47, where the quality of the inputs decided what the answer was worth. Software is no different. An agent’s output is only as good as the intent it was given and the check it has to pass.

Looking back, what my more experienced colleagues gave me at Nokia was much the same thing. They didn’t write my code. They helped me get clearer about what should be happening and then check whether it was. That is the job that remains on the top rung, and it is a job you get good at by having stood on the lower ones.

What the Lower Layers Still Give You

My colleague Mikko Peltola has written about the two kinds of expertise this shift rewards, and I won’t repeat him here. My part of the answer is narrower. The experience from the lower layers still carries weight, but it no longer shows up as code. It shows up as the detail in the intent and the rigor in the verification.

That is also how we have built our delivery pipeline at A-CX: experienced people define the intent and verify that it is fulfilled, and AI agents write the code in between.

If you are working out where experience fits in your own team’s AI delivery, I’d be happy to compare notes. Contact us at A-CX and let’s talk.