AI is considered as a threat for developers. Not existential — nobody thinks Skynet is coming for your VS Code. But as a “tool” that makes developers less knowledgeable about the tricks of software development. Less aware of how this or that function works under the hood. Less capable of choosing the right approach in a particular case.
And honestly? I’ve heard this song before.
We’ve Been Here Before. Many Times.
If you look at the path of programming languages evolution — you’ll see the same pattern repeating over and over. We moved from writing raw machine code to assembler. From assembler to procedural programming. From procedural to OOP. Then came additional layers of abstraction — frameworks, libraries, package managers. Each layer made the previous one less visible, less understood by the average developer.
And now so few people can debug real assembler code. And what? Is this a failure?
Really, I do not know how a for loop works on the assembler level — I’m a child of high abstraction level languages. Java, C#, Python — they really discourage you from knowing how it works under the hood. Just build and ship. Use good practices and you will be golden. Nobody asks you to understand memory allocation to write a REST API. Nobody expects you to know CPU pipeline optimization to build a mobile app.
The Pattern Is Always the Same
Every generation of developers lost something and gained something.
We lost the ability to write optimal assembler — we gained the ability to ship products in weeks instead of years. We lost manual memory management — we gained garbage collectors and the ability to focus on business logic. We lost hand-crafted SQL queries — we gained ORMs and the ability to switch databases without rewriting half the codebase.
Each time, the old guard said: “These new developers don’t understand the fundamentals.” Each time, the new generation built things the old guard couldn’t have imagined — because they weren’t spending their cognitive budget on problems that were already solved.
So What Did We Actually Lose?
Let’s be honest about what each abstraction layer took from us:
Assembler -> C: We lost fine-grained control over registers and memory layout. We gained portability and readability.
C -> Java/C#: We lost manual memory management and pointer arithmetic. We gained safety, productivity, and massive ecosystems.
Raw code -> Frameworks: We lost understanding of HTTP parsing, socket management, thread pools. We gained the ability to build a working web app in a day.
Manual deployment -> CI/CD: We lost the ritual of careful manual releases. We gained the ability to deploy 50 times a day with confidence.
Notice something? Each “loss” was actually a deliberate trade. We chose to forget things that were no longer worth remembering at the level of daily work. Not because they were unimportant — but because someone already solved them well enough.
AI Is Just the Next Row in This Table
AI is not doing anything new to us. It’s doing what we always did to ourselves — adding another abstraction layer. The difference is that this layer abstracts not just technical complexity, but the act of writing code itself.
And yes, that feels different. More personal. More threatening. Because previous abstractions still required you to type code — just at a higher level. AI sometimes removes even that step.
But the trade is the same: you lose something (the muscle memory of writing every line yourself), you gain something (the ability to build and iterate at a speed that was previously impossible for a single person).
The Question That Actually Matters
The question is not whether AI makes us “worse” developers. Every abstraction layer made us “worse” at the layer below. That’s the point.
The real question is: what new skill does this layer demand from us?
When we moved from assembler to C, the new skill was structured thinking and algorithm design. When we moved to OOP, it was system design and architecture. When frameworks arrived, it was choosing the right tool and understanding trade-offs.
What does the AI layer demand? I have a theory about that — but that’s a topic for the next article.
Top comments (0)