My mother spent her career writing assembly for embedded hardware systems. When she briefly tried Java, she said it “wasn’t as enjoyable” – it took the fun out of coding. Memory management, direct hardware access, bit-level optimizations – all the intellectually stimulating problems she loved were abstracted away.
Sound familiar?
Today I hear the exact same sentiment from developers talking about AI coding tools. They’re not wrong, AI does remove certain challenges, just like Java removed the need to manually manage memory. But they’re missing the bigger picture.
Every abstraction layer in programming history has faced identical resistance. The same arguments about “dumbing down” programming, losing control, and performance penalties were made about FORTRAN in the 1950s, about high-level languages in the 1970s, and about frameworks in the 1990s.
AI isn’t the end of programming. It’s just the next abstraction layer.
The Pattern We Keep Missing
In the early days of FORTRAN, assembly programmers complained that compilers couldn’t optimize as well as hand-written code. They were right. Early compilers generated suboptimal machine code, just like early AI tools generate suboptimal solutions.
But here’s what happened next: compilers got better. Much better. Today, modern compilers consistently outperform hand-optimized assembly for most use cases. The programmers who initially resisted FORTRAN weren’t replaced, they became the ones writing compilers and building the tools that everyone else used.
This pattern repeats with remarkable consistency:
- 1950s: Assembly programmers resisted FORTRAN and COBOL, claiming high-level languages were “too slow” and removed programmer control
- 1970s-80s: C programmers dismissed Java and Python as “toy languages” with unacceptable performance overhead
- 2000s: Systems programmers mocked web frameworks as bloated abstractions that hid “real” programming
Each time, the resistance followed the same script: concerns about performance, loss of control, and the dumbing down of programming. Each time, the new abstraction found its place not by replacing the lower level, but by enabling new possibilities.
The Current Déjà Vu
Today’s AI coding tool debates sound eerily familiar. Recent data shows that the majority of developers use AI tooks, but also don’t trust AI-generated code. This mirrors exactly the trust issues we saw when developers first started relying on compilers instead of hand-assembling machine code.
The productivity paradox is playing out in real time. Developers report feeling more productive with AI tools, but studies for specific tasks they’re actually slower. This isn’t evidence that AI tools are useless, it’s evidence that we’re in the learning curve phase, the same adjustment period we saw with IDEs, frameworks, and cloud platforms.
The most revealing statistic: AI tools show a 26% productivity increase for junior developers but a 19% decrease for experienced developers. This is exactly what we’d expect from a new abstraction layer. Experienced developers resist because they’ve optimized their workflows around lower-level tools. Junior developers embrace it because they have less to unlearn.
Where the Pattern Breaks (And Where It Doesn’t)
There are legitimate differences with AI that make this abstraction layer unique:
Speed of improvement: AI capabilities improve monthly, not yearly. The gap between “obviously inadequate” and “surprisingly capable” is compressing from decades to months. Though we are seeing these improvements plateau, we may eventually hit the limit of LLMs we are not there yet.
Natural language interface: Previous abstractions required learning new syntax. AI works with human language, dramatically lowering the barrier to entry.
Capability breadth: A single AI can handle multiple languages and frameworks simultaneously, something no previous abstraction achieved.
But the fundamental dynamics remain the same. AI-generated code shows a 322% increase in security vulnerabilities compared to human-written code. Early compilers also generated buggy code. The solution wasn’t to abandon compilers, it was to build better compilers and better processes around them.
The Coexistence Reality
My mother’s assembly skills didn’t become worthless when Java emerged. They became more valuable. Even after retirement, companies tried to pull her back to work for specific projects and initiatives. Yes, higher-level languages replaced some of the coding requirements of low-level languages, but both were still required and both continued to grow.
Today’s landscape already shows this coexistence pattern:
- 80% of embedded systems still use C
- Assembly remains essential for bootloaders, device drivers, embedded systems, and safety-critical systems
- Python dominates machine learning despite massive performance penalties
- Developers accept only 44% of AI suggestions, maintaining significant human oversight
Just like FORTRAN didn’t kill assembly – it just moved assembly to where it was truly needed – AI won’t eliminate programming. It will push human programmers toward the problems AI can’t solve: novel algorithms, system architecture, performance optimization, and domain-specific challenges that require deep expertise.
What This Means for Your Career
The question isn’t whether AI will replace programmers. It’s which abstraction level you’ll choose to work at, and for which problems.
If you’re an experienced developer, your deep knowledge isn’t becoming obsolete just more specialized. Understanding how code actually works will be your competitive advantage in an AI-assisted world.
If you’re new to programming, you’re entering the field at the perfect time. You can learn to leverage AI tools without the psychological baggage of feeling like they’re “cheating.” You’ll develop intuition for when to trust AI suggestions and when to dig deeper, just like experienced developers learned when to trust compilers, libraries, or frameworks.
If you’re making technology decisions, resist both the hype and the fear. AI tools won’t immediately 10x your team’s productivity. They also won’t make programming obsolete. They’re powerful new tools that require thoughtful integration, better code review processes, and realistic expectations about their current limitations.
The Historical Vindication
Here’s the uncomfortable truth: every generation of programmers thinks their level of abstraction is the “real” programming and everything above it is somehow cheating. Assembly programmers thought machine code was real programming. C programmers thought assembly was too high-level. Java programmers thought C was unnecessarily complex.
My mother was right that Java wasn’t as enjoyable – if your enjoyment came from the specific challenges that Java abstracted away. But Java enabled entirely new categories of applications and made programming accessible to millions more developers. The craft of programming didn’t disappear.
AI tools represent the same evolution. They’re abstracting away certain types of programming drudgery, boilerplate code, syntax lookup, basic algorithmic implementation, so we can focus on higher-level problems. Instead of syntax we can spend more time on system design, user experience, business logic, and novel solutions to complex problems.
The developers who thrive in the AI era won’t be those who resist the new abstraction layer. They’ll be those who understand when to use it, when to work around it, and when to dive below it. Just like the best developers today know when to use Python for rapid prototyping, C for performance-critical code, and assembly for hardware interfaces.
Embracing the Pattern
Every powerful abstraction in computing history has followed this pattern: initial resistance, gradual adoption, eventual coexistence with lower levels, and new possibilities that weren’t practical before.
AI coding tools are no different. They’ll find their place not by replacing human programmers, but by handling the routine parts of programming so humans can tackle the novel, complex, and creative challenges that still require genuine intelligence, intuition, and expertise.
The craft of programming isn’t disappearing. It’s evolving. Again.
And that’s exactly what it should be doing.