Or: What Twenty Years of Experience Is Actually Worth When the Machine Learned It in Twenty Seconds

Last month, a junior engineer shipped a feature in one afternoon.

Not a toy. A real feature. Async job orchestration, retries with backoff, idempotency keys, decent tests. The kind of thing that would have taken me a week in 2010, and taken him a month — if the year were 2022.

He used an LLM, obviously. He prompted, reviewed, adjusted, shipped. And while I was reviewing his PR, a very quiet, very uncomfortable thought crawled into my head:

Everything I spent twenty years learning, this thing spits out in twenty seconds.

I write on a blog subtitled "Notes of a Technosaur." I picked that name as a joke. Lately the joke has started looking back at me.

In this industry, nobody retires. You just stop getting tagged in incidents. Then one day someone writes a migration guide away from you, and that's the funeral.

So let's do what engineers do when something scares us. Let's debug it.

The Fossil Record

First, honesty. Some of my skills are dead. Not dying. Dead. And there was no funeral for them either — one day the job postings just stopped asking.

Syntax fluency. I used to write correct C++ template code from memory, and I was proud of it. That skill had market value. Today it has the market value of knowing Morse code. Impressive at parties. Nobody's paying.

API memory. I knew the Microsoft Graph endpoints by heart. Every permission scope, every $filter quirk, every pagination token. The LLM knows it better, never sleeps, and never confuses beta with v1.0. It also doesn't ask for a raise, which my clients have definitely noticed.

Boilerplate speed. Setting up a FastAPI service, wiring the Pydantic models, writing the hundredth CRUD endpoint. I was fast at this. Being fast at this in 2026 is like being fast at long division.

Stack Overflow digging. Taking four half-wrong answers from 2013 and building a working solution out of them. A whole discipline, gone in three years. Somewhere out there is a guy whose entire career was this. I hope he's okay. I suspect he's not.

That's the fossil layer. If your career is built entirely on that layer, I won't insult you with optimism. The asteroid already hit. What's falling now is just dust.

But Here's the Thing About Legacy Systems

In our industry, "legacy" is an insult we use for code we didn't write.

But walk into any bank, any airline, any telco, and ask which systems actually make the money. It's not the greenfield microservice with the beautiful README. It's the legacy system. The one nobody fully understands. The one that survived four rewrites of everything around it. The one that runs.

Legacy doesn't mean old. Legacy means load-bearing.

So the real question isn't "am I old?" — I own a mirror, thank you. The question is: which parts of my twenty years are fossil, and which parts are load-bearing?

What the Machine Learned in Twenty Seconds

Here's what I've noticed after a serious year of working with LLMs — mine, my team's, my clients'.

The model learned everything that was ever written down.

Every tutorial, every doc, every design pattern, every conference talk. It compressed the entire written output of our profession. That is genuinely impressive, and I refuse to be one of those people who pretends it isn't.

But twenty years of engineering produces two kinds of knowledge, and only one of them ever got written down.

The written kind: how to implement a retry. How to structure a service. What CAP theorem says.

The unwritten kind:

  • That the customer asking for "real-time sync" will be perfectly happy with a 30-second poll, and the difference is six months of your life you don't get back.
  • That the beautiful event-driven architecture will be maintained by two people, and one of them is already interviewing elsewhere.
  • That this database "supports" that feature the way my knee "supports" running a marathon.
  • That when the logs are clean, the metrics are green, and the customer is still screaming, you go check the load balancer config — because a distributed system has gaslit you before, and you recognize the pattern.
  • That the correct answer to a third of all feature requests is a well-argued no, and knowing which third is the entire job.

The model didn't learn any of that, because nobody wrote it down. We couldn't. It's not knowledge. It's scar tissue. And scar tissue doesn't compress.

The Junior's Afternoon, Revisited

Back to my junior and his one-afternoon feature.

Here's what actually happened in that PR review. The code was good. The retries were correct. And the idempotency key was built from the request payload — which included a timestamp.

Meaning: retry the request, get a new timestamp, get a new key, get a duplicate job. The exact failure the idempotency key existed to prevent, implemented with complete confidence by man and machine together.

Twenty seconds to write it. Twenty years to smell it.

I didn't catch it because I'm smarter than him, and certainly not because I'm smarter than the model. I caught it because in 2014 a system I built double-charged a customer for the same reason, and I spent a weekend writing the incident report. Some people have childhood memories. I have incident reports.

This is the part the AI think-pieces skip: the model makes everyone faster, but it makes errors fluent. Wrong code used to look wrong. Now wrong code reads like documentation. The skill of the next decade isn't writing code. It's smelling it.

What's Actually Load-Bearing Now

So I'm running my own migration. And like any honest migration, it starts with admitting what I'm deprecating: my identity as the guy who writes the code. That guy peaked years ago. Nice guy. Good typist. Rest in peace.

Here's what got promoted to load-bearing instead:

Commanding the army. I don't have three seniors anymore. I have an army of juniors and mids, each one wired to an LLM, each one capable of producing more code in a day than my whole team produced in a 2015 sprint. Someone has to keep that army from confidently marching off a cliff. That someone reads every plan, smells every design, and says "no" a lot. The model gave everyone a rifle. It didn't give anyone aim.

Being the glue. No real feature lives in one service anymore. A "simple" feature touches the API layer, two backend services, an async worker, and someone else's half-documented integration. Five PRs, three repos, four people who've never spoken to each other. Somebody has to hold the whole picture in their head and make those pieces land as one working thing instead of five green pipelines and one broken product. That's not in any job description. It's also the difference between shipping and pretending.

Architecture and judgment. Looking at a perfectly plausible plan and saying "this will fall over in production, and here is the specific way it will fall." The model proposes. Someone has to be accountable for what happens at 3 AM. Accountability, it turns out, doesn't tokenize.

Building the SDLC that actually works. Everyone is designing their AI-era development process right now, and the first drafts are always beautiful. Agents reviewing agents, elegant diagrams, everything automated. I've drawn those diagrams myself — it's the natural first step, and we're all learning this in real time. The hard part is the second draft: the process that looks boring on paper but actually ships. Where the AI does the typing, humans do the judging, and nothing merges on vibes alone. Getting from the beautiful version to the working version — that's the craft. Pretty processes get applause. Working processes get releases.

The Utilization Problem

Here's my honest confession, and it took me a while to say it out loud.

I can still write code. I can judge code faster than I can write it. I can ship fast — faster than ever, actually, with the machine doing the typing.

And doing that all day would be a waste of me.

Using a twenty-year engineer to crank out endpoints is like using a production database server to store your wedding photos. Does it work? Perfectly. Is it what the expensive machine is for? No.

The best utilization of a technosaur isn't output. It's making sure the enormous output of everyone else — human and machine — actually becomes a product, instead of a very fast pile of confident garbage.

Twenty Years of Uptime

One last contradiction, since you've come to expect one.

The engineers most threatened by AI aren't the old ones. They're the shallow ones — at any age. The ones whose entire value lived in the written-down layer. The model ate that layer first, and it's still chewing.

And the best positioned for this era? Strangely, it's us. The technosaurs. Because we've done this before. I've already survived the death of my skillset — twice. C++ died and I mourned it. On-prem infrastructure died and I mourned that too. The third time, at least I'll know what to wear.

The juniors are living through their first extinction event. We're on our third. That's not obsolescence.

That's uptime.

Twenty years in production. Survived every rewrite of the stack around me. Still handling the traffic nobody else knows how to route.

Call me legacy. In this industry, that's the highest compliment there is.

What did you deprecate, and what did you promote to load-bearing? Tell me in the comments — preferably before the next extinction event.