I started out writing 6502 assembler. Then 8088. Then 80x86. I’ve shipped production code in C, C++, Pascal, BASIC, Objective-C, Swift, Java, SQL, and a long tail of languages most people under 35 have never heard of. I once closed $200,000 in sales because I understood DOS memory management better than anyone else in the room. I built stock management systems in Borland C++ Builder that ran businesses. I was behind some of Apple’s flagship iOS apps.
And here’s the uncomfortable truth: almost none of that matters to a hiring manager today OR me.
Most people reading this haven’t heard of half the technologies I just listed. Why should they? DOS is a museum piece. Borland Builder is a footnote. Even Swift and Java, which still feel current, are drifting toward the same fate — not because they’re bad, but because every generation of tools eventually becomes the plumbing for the next one.
Do I miss writing assembler? No. It’s still there, under every language I’ve touched since — I just don’t have to think about it. Do I miss hand-rolling Java boilerplate or arguing about Swift protocol conformance? Not really. Those will feel as quaint in ten years as getting 65K out of a 64K CBM64 or hand-managing the 640K PC memory barrier feels now.
And this is the part I want managers and engineers to sit with: AI is not a threat to what we do. It’s the next layer of abstraction.
Assembler hid the transistors. C hid the assembler. Java hid the memory management. Swift hid the Objective-C runtime. Claude Code — and tools like it — hide the language itself. The question stops being “which language should I write this in” and starts being “what am I actually trying to build, and for whom, and how well.”
That’s a much better question. It’s the question we all need to ask.
So when people ask me whether I’m worried about AI taking my job, my honest answer is: the engineers who should be worried are the ones whose entire identity is wrapped up in the syntax. The ones who care deeply about 4 spaces vs. tabs, who treat linting rules as a moral stance, who measure their worth in how elegantly they can express a for-loop. Who obsess over TDD/BDD or MVVM. If your value is in the typing, yes — the typing is being automated.
But if your value is in understanding what the business actually needs, translating that into systems that work at scale (if that’s what’s needed), making good trade-offs under real constraints, and delivering to a standard — none of that is going anywhere. AI doesn’t replace the thinking. It removes the excuse not to do it.
A concrete example: we wanted to migrate our systems from one database to another. Pre-AI estimate: 6 to 9 months for a team of 5+. Actual: 3 weeks for a team of 3.
That’s where the job is now. It was always where the job was — we just had to do a lot of typing to get there.
So no, I’m not going to tell anyone that assembler was best and we should turn off the lights and go back to the dark ages. I’m going to do what I’ve done every other time the ground shifted: master the new layer, figure out the best routes to productivity, teach my team the same, and get on with building things that matter.
The engineers who’ll thrive in the next decade aren’t the ones with the longest CVs. They’re the ones who can look at a vague business problem and ship a working answer by Friday — using whatever layer of abstraction makes that possible. But they’re now competing with QAs, team leads and managers who can also ship high-quality products. The old defense — “they don’t understand coding properly” — doesn’t survive the obvious comeback: “and you don’t understand what the business needs.”
Right now, the top layer is AI coding tools. Next decade it’ll evolve into something else. The job, underneath all of it, is the same. The pool of people who can do it just got a lot bigger — and the number of people it takes to do it just got a lot smaller.