The entire history of software engineering is that of the rise in the levels of abstraction.
Grady Booch
Abstraction means handling complexities by hiding details from the end user.
When learning OOP concepts in college, I always thought of the end user being a consumer of something I was building. When I graduated and started working in 2020, software engineering, to me, meant hours spent debugging, reading documentation, digging through Stack Overflow, watching tutorials, and trial-and-error, all to fix bugs and build new features. That’s how I learned. That’s how I built judgment. Now, I spend most of my time crafting an environment where AI can do those things while I orchestrate and break down tasks. The work looks completely different from when I started and has undergone a dramatic shift over the past 2-3 years.
Watching how AI is changing the field, keeping up with trends, and experimenting with new tools, I’ve realized that software engineering as I knew it is being abstracted. Developers are the ultimate target audience and end user for AI coding assistants, and the underlying complexities of software are being abstracted from the people who used to build it.
The Progression
low-level languages → high-level languages → frameworks → low code/no code tools → AI tools
Each abstraction increases capacity and narrows/shifts focus and skill set. Within AI itself: prompt engineering → context engineering → context infrastructure → tools managing their own context → agentic development.
Each abstraction increases capacity and narrows/shifts focus and skill set. Each iteration reduces human input. Ultimately, human input and review are the bottleneck in agentic workflows. The system needs autonomy to produce at speed and scale. The human is what’s slowing it down.
The Leak Problem
Spolsky’s Law (2002): “All non-trivial abstractions to some degree are leaky. The underlying complexity will eventually surface and force developers back down a layer.”
With AI, there are multiple layers, and the leak patterns are no longer deterministic, making it hard to build developer confidence and intuition without guardrails in place. The skill you built judgment from, doing the work, is the thing being abstracted away. We’re denying ourselves the experience to build expertise, and then telling models to do the work we’re becoming unfamiliar with. The more divorced we are from the work, the less value our review has. It’s slowing down the process at that point.
Human value is at the abstraction leak points, assuming humans still understand the underlying complexities. If not, AI can fill that gap while the humans lean into their strengths. But the gap between what we understand and what the tools are doing is widening. And the further that gap stretches, the less equipped we are to catch the leaks when they surface.
Designing for those leaks requires a different skill set entirely, one that most of us are still learning. It means thinking in systems, understanding where the model falls short, and building specs and guardrails around those shortcomings. Intention has to translate directly into desired outcomes. That’s the new approach to software engineering.
The Core Question: When Does Abstraction Become Ignorance?
AI can abstract many levels from requirements gathering to implementation. The danger isn’t that you stop writing code. It’s that you lose the ability to evaluate whether the output is good. How will the judgment of a software engineer compare to a vibe coder as these tools advance if neither is actually coding? Right now, the answer is experience, which can drop down a level on demand and actually know what’s happening and how it happened.
Abstraction isn’t the problem. Forgetting what’s underneath it is.