A friend recently posted a message on LinkedIn for “older programmers.” It suggests, gently, that we pair up with younger programmers to learn how this AI stuff works. It was written with kindness, which somehow makes it worse, because underneath the kindness is an assumption: that picking up new technology is a young person’s skill.

My first exposure to a computer was in college writing COBOL on punchcards. Since then, the dominant way software gets built and shipped has been replaced ten times: personal computers, GUI desktops, client-server, the web, the dynamic web, cloud, mobile, serverless, microservices, and now AI-assisted development. Spread ten shifts over forty-four years and one arrives roughly every four and a half years, which means “the ground is moving under my feet” has been the normal working condition of my entire career. The languages churned just as fast. I’ve written code in COBOL, Pascal, Fortran, assembly, C, C++, Perl, shell script, Java, JavaScript, and Python, and most of them weren’t mainstream, or didn’t exist yet, when I learned the one before.

In the 1980s I typed programs onto a deck of cards, walked them to the computer center, and got a stack of paper back hours later, but the decade was just getting started: UNIX on Sun workstations, the DEC VAX, 6502 assembly on C64/Apple II, the PC running Windows. The Mac showed up in 1984 and turned programming inside out: instead of a program that ran top to bottom, you wrote code that sat there waiting for the user to click something. Just like that, event-driven programming plus a mouse made every user interface skill I had obsolete. Client-server pulled the data out of the mainframe and spread it across networked databases, and suddenly you weren’t a programmer unless you knew SQL.

But the biggest change was when Mosaic shipped in 1993. Two years later Java and JavaScript both appeared and Amazon was taking orders. Software went from your desktop to a place you visited, and everything downstream changed: distribution, pricing, release cycles, what “done” meant. I bet my career on that shift, starting a load-testing company in 1999, because web applications failed in a way shrink-wrapped software never could: under the simultaneous weight of a few thousand strangers. Cloud arrived in 2006 when Amazon started renting servers by the hour, and capacity planning gradually switched from leasing hardware to mere API calls. The iPhone in 2007 put a computer in everyone’s pocket and a new platform on everyone’s roadmap. Docker in 2013 and Lambda in 2014 made servers first disposable, then invisible, while the microservices wave was busy chopping monoliths into network calls. Every one of those changes meant relearning my profession.

All that churn is why the latest push to give college graduates “practical skills,” which these days means certifications in very specific technologies, worries me. There’s nothing wrong with actually building things in college; that’s how you learn. The problem is nothing in my electrical and computer engineering degree survives in my day job. The Fortran is gone, the assembly is gone, the punchcards are in a landfill. What survives is the thing the degree was actually for. ECE sits at the seam between hardware and software, so it taught how a computer works from the transistor up: what an interrupt really is, why the disk is the slow part, what the compiler did to your loop. It taught how to decompose a problem you’ve never seen, and how to pick up a spec for a part that didn’t exist last year and have something working by Friday. Engineering school never promised the tools would last. It taught the opposite: use the best tool for the job, and expect the job to change. Getting a certification in a technology that will only be in demand for another three to five years helps you get a job, but it doesn’t help a career.

What the certification actually does is make it easier for large-scale recruiters to fill seats. A recruiter gets a req listing a stack, the screening software matches the req’s keywords against resume keywords. It produces absurdities everyone has seen, like listings demanding five years of experience in a three-year-old technology; the creator of FastAPI once found a job posting requiring four years of experience with the framework he had released a year and a half earlier.

But the deeper damage is the incentive: golden keyword handcuffs. If jobs are awarded for stack depth, someone who spends a decade being “a Java engineer” or “a React engineer” isn’t failing to grow. They’re doing exactly what the market pays for. Then the technology fad fades, the reqs move on, and the industry ignores the stranded engineers and moves on to the next arbitrary certification. The industry builds the handcuffs, then blames the people tied to them for getting older.

Which brings us to AI: the most radical, swift change in software engineering in my lifetime. The invention of the web is the next closest in magnitude, but it meant more opportunity for programmers; it didn’t threaten to replace them. But my response is to treat AI exactly like every single one of the other seismic shifts in technology: catch up on the theory, experiment, measure, and integrate what works into a professional engineering workflow. Over the past year I have shipped twenty-plus major revisions modernizing a 25-year-old, 550,000-line codebase using a multi-agent AI workflow I designed and refined: spec-driven planning, multi-model review panels, hand-curated tests. I wrote up the whole process here. I didn’t pair with a younger programmer to learn any of it. I did what I did when confronted with each previous shift in technology: got curious, read everything, and started building.

The LinkedIn post gets one thing right: AI is not optional. Every working engineer needs to learn this, and some, at every age, will refuse and be left behind. Attitude sorts people, not birthdays. But the letter’s premise runs history backward, because the engineers it politely offers advice to are the only people in the room who have already done this nine times. We’ll do it a tenth the same way we did the others: grumbling, reading, building, adapting. Adapting was never the hard part of this job. It is the job.