I spent the past week using Claude Code — an AI coding agent that works inside your terminal — to build out features on this site. Not occasionally, but as my primary workflow. Write a description of what I want, watch it read the codebase, write the files, check the results. And I noticed something that took me a day or two to fully process: I wasn't really writing code anymore. I was specifying behavior and reviewing outcomes.

That's not a complaint. It was genuinely faster, and the code it wrote was fine. But it raised a harder question: if the AI can do the typing, the file manipulation, and a lot of the thinking about how to implement something — what exactly is left for the human?

The short answer, I think, is: the same thing that was always left for the human, just one level higher up. And this is not the first time that's happened.

Every Era Raises the Floor

Computing history is, in a very real sense, a history of abstraction. Each generation of tools takes something that previously required deep technical expertise and turns it into a given — a capability you can invoke without thinking about its implementation. And each time that happened, people predicted the end of the technical profession. Each time, the profession evolved instead of disappeared.

The visualization below steps through five eras of software development. In each one, a new abstraction layer was added beneath the human, raising the floor they stand on. Step through it and notice two things: the job title barely changes, but what fills the day completely changes.

The Rising Floor of Software Development
Hardware & Physical Circuits
Assembly Language
High-Level Languages (C, COBOL, FORTRAN)
Object-Oriented Languages & Frameworks
AI Coding Assistants
🧑‍💻

Notice what happens each time: the abstraction layer below you gets thicker, and your job description moves one step up the value chain. Electrical engineers didn't disappear when high-level languages arrived — they moved into chip design, systems architecture, and hardware engineering specialties that simply didn't exist before. COBOL programmers weren't replaced by Java developers; the profession expanded to include more people solving harder problems.

The Abstraction Thesis

Here's the pattern, stated plainly: abstractions don't replace human judgment — they reposition it. When assembly language arrived, EE professionals who had been manually programming machine instructions suddenly had to think at a higher level: what algorithm do I want, not how do I encode it in binary. When object-oriented frameworks arrived, the programmers who had been carefully managing memory allocation suddenly had to think about architecture: how do these systems relate to each other, not how do I free this pointer.

AI coding tools are doing the same thing. They're absorbing the implementation layer — the translation of a design into working code — and pushing the human's job upward into design, judgment, and validation. The question is no longer "how do I write a function that does X?" but "what should X actually do, and is this right?"

The pattern: Each abstraction automates the layer of work that felt most mechanical. What's left is what required judgment to begin with — it just wasn't visible through all the mechanical work surrounding it.

What AI Can't Abstract Away

Two things remain stubbornly human, and I don't think this changes for a long time.

1. Translating intent from the humans who have it

Someone in an organization has a goal. A business analyst wants to understand customer churn. An executive wants to know why revenue dropped last quarter. A product manager wants a checkout flow that feels less confusing to users. These goals exist in human language, are shaped by political and organizational context, involve unstated assumptions, and are often only half-formed when first expressed.

AI can help implement once the goal is clear. But the translation from "what the business wants" to "a clear enough specification that anything can implement it" — that remains a deeply human act. It requires sitting in a room with stakeholders, pushing back, asking the uncomfortable clarifying questions, and making judgment calls about what matters most when requirements conflict. No model today can substitute for that process, because the model isn't in the room, doesn't know the organization's history, and can't read the politics of why a particular feature got prioritized.

Software engineers were always doing this, but it was hard to see. It looked like their job was writing code. Their job was actually being the interface between human intent and executable reality — the code was just the output of that process. AI takes over the output. The process is still human.

2. Validating that "working" means "correct"

Unit tests are useful but bounded. They verify that a function behaves as specified. What they can't verify is whether the specification itself was right. And this is where software development has always had a gap that only humans can close.

"Correct" in software means "matches expectations." But expectations are famously nebulous. They live in the minds of users who may not know what they want until they see it. They drift as the business changes. They're often contradictory across stakeholders. You can write a perfectly passing test suite for software that completely fails to do what anyone actually needed.

The engineer who sits down with a working build and thinks "this technically runs, but does it make sense?" is doing something irreplaceable. That judgment — grounded in domain knowledge, user empathy, and an understanding of what "good" looks like in context — is the thing that AI tools currently lack the grounding to perform. They can generate tests; they can't generate taste.

A Different Kind of Engineering

What I'm describing isn't the end of software engineering. It's the elevation of it. The parts of the job that were frankly mechanical — typing boilerplate, looking up syntax, translating a clear design into file structure — those are going away. Fast. What's left is the parts that required the most experienced engineers to begin with: understanding the problem, designing the solution, and validating the outcome.

This is good news for engineers who are already good at the hard part. It's a real disruption for workflows built around the mechanical part. The profession will contract in some dimensions and expand in others — just like it did when C replaced assembly, and when frameworks replaced bare C.

The floor keeps rising. The humans keep standing on top of it. The view from up there just keeps getting better.