I was reading Jeff Raikes on the disappearance of entry-level work, what he calls talent debt, and the comment threads under it insisting that companies must keep hiring early-career people. It is an interesting question, and is really guidance for the kids going through school right now, deciding what to study in college or trade school. I am blessed to have two children who came through the system and landed in careers that, for now, look AI-enhanced rather than AI-replaced: one an athletic trainer for a D1 school, helping athletes recover and be their best, and one a consultant at a major firm, and the world will always need consultants; especially as the tools underneath them change. Some of my thinking here also comes from time spent with Loyola University New Orleans, where they are figuring out how to educate the full person rather than teach people a set of knowledge, the cura personalis.
But the fastest way I can explain what I believe is a story from a customer support desk thirty years ago.
The Jenga years
When I started in customer support in the early 90s, at Attachmate, we hired people who could get creative with how DOS ran underneath the Windows shell, shifting drivers around in limited memory just to let Windows 2.1 run at all. Our product, Extra, connected PCs to mainframes, which meant drivers for every connection protocol and network card, and all of it had to coexist in memory. We had base, extended, and expanded memory. You moved things around between them until everything fit, wrapped it up, tied it with a bow, and it worked for a while, as long as the customer didn’t change anything. It was some serious Jenga.
To be a support tech, you had to know everything about DOS, how Windows sat on top of it, a bit about memory registers, and how our application and its drivers played between all of it. That knowledge was the job.
The guy who did not know what an autoexec.bat was
Then Windows 95 shipped, and Windows became an operating system instead of a shell running on DOS. Then we hired our first support hire who did not know what an autoexec.bat or a config.sys file was.
I remember thinking: he is never going to make it.
He did. He had a long, fruitful career there. I was wrong.
That is the whole point. The thing I was certain was foundational was actually temporary. What lasted was not the DOS knowledge; it was the ability to figure out how a system fits together and where it is breaking. The need for specific things changes over time. What you are trying to build is the pattern.
Six times eight
I had a great conversation with my friend James Wilkins a while back about the value of rote learning, and times tables are the perfect example. Does it matter that I know six times eight cold? (It is one of those middle-of-the-table ones I still have to think about.) I have calculators. I have computers. At some point spreadsheets became where all the math happens anyway. The fact is data. What mattered was learning how multiplication works and how to look things up: the pattern that transferred to everything after it.
Same with the geometry class where we memorized over a hundred theorems by number. I have never once needed theorem 78. I use the actual skill constantly: how to stack logical steps into a proof, how to take known pieces and build an argument that holds.
And here is the thing: that rhymes with programming. Programming is a logic exercise, not a language exercise. Knowing how to break a problem into routines and functions, what belongs in a reusable chunk, how the chunks call each other: that is the valuable skill. Whether I know Python inside and out matters less every month, because access to data and the tools to build solutions has gone from scarce to free. AI hands me ten thousand experts. The valuable ability left is discernment: out of everything those experts offer, what is the pattern, what is unique, what is the thing nobody else has seen or thought of that I can go create?
What the panic gets right, and what it gets wrong
Back to the comment threads insisting companies must keep hiring early-career people. The decline Raikes describes is real and measured: Stanford’s Digital Economy Lab puts entry-level employment in AI-exposed occupations down roughly 13 percent on a relative basis since late 2022. Raikes says “talent is grown, not coded,” and he is right. The question is what you grow it on. Half of that argument I agree with completely. There is massive value in bringing new people along: teaching them how to operate in a workplace, how to count on others, teamwork, the thoughtful matching of prior events to new ones. That half is hyper-valuable and I am fully on board.
But the other half, the idea that a company owes it to the pipeline to hire a 21-year-old and train them up as a C# or Python programmer, is training someone on technology that is becoming a dead end. The point of a company is to build a talented, almost entrepreneurial workforce. Let the AI do the entry-level programming; invest the humans in understanding how it all fits into the bigger picture. And honestly, the hiring part sorts itself out: new grads are cheaper, they carry new ideas, and if academia does its job, they will arrive with deeper fluency in the new tools than old fogies like me.
One comment on Jeff’s post stuck with me, and it points at the actual self-inflicted wound. Leading companies are not investing in the talent pipeline at all; they are shedding the people with domain experience and broad context to save money in the race toward AI. Read that against everything above: the people worth keeping were never the ones who knew a particular language. They are the ones who understand the patterns. Companies panicking toward AI are cutting exactly the people the AI needs standing next to it.
Teaching someone basic programming so they can pull apart what the AI wrote? In 12 months that won’t be the job either. The tools are just going to keep getting better at writing programs.
The Rivian problem
I used to change my own spark plugs. I could tune the car, change the oil, all of it. Put me in front of a Rivian or a Lucid and I have no idea what a tune-up would even mean. Do I clean the brushes in the electric engine? The technology has gotten to a point that the skills I built stopped being required, and that is fine.
That is exactly where programming is headed, and I am living the transition in miniature. Twelve months ago I wrote my first Replit app and it was spaghetti: slow, repetitive, no functions, no reuse. My apps today are none of those things. Not because I learned to code, but because I learned to put my experience and expertise into language the tools understand. And I guarantee the platforms are folding those same structures into themselves as defaults. Eventually nobody will need to know what a function or a runtime or a procedure is, but we’ll always need to know how to break down a problem into components and first principles to solve it.
I did not learn to code. I learned to put my experience and expertise into language the tools understand.
The counterargument I owe you
The honest tension. A month ago I argued the opposite side of this. Someone I know with no computer science background, using the same vibe-coding tools as everybody else, built some genuinely terrible agents. Terrible because she had no mental model of a loop, no instinct for error checking, no sense of when three copies of the same thing should become one function. The tools did not save her, and my conclusion then was that foundational skills still matter.
I think both are true. As data, the syntax you memorize in a specific language is already dying; the tools handle that. As pattern, as the instinct to decompose a problem, to spot repetition, to check what happens when things go wrong, they are the transferable thing; the same skill as the geometry proof. She did not lack the syntax. She lacked the pattern. (well…she lacked both, but the pattern was the killer) Today the pattern still has to live in the human. The tools are getting better every quarter, and I will not pretend I know exactly where that line stops moving. But whatever the tools absorb next, the person who learned patterns adapts, and the person who learned data is stuck in the cold.
Teach the pattern
We have been here before. The slide rule. The rotary phone. The stick shift. Skills we once considered critical for everyone, until the technology removed either the need or the criticality. Imagine forcing a late-80s engineering student to do an entire project on a slide rule after the calculator was cheap. That is what training the next generation on disappearing technology amounts to: it is yesterday’s technology teaching no pattern that today’s tools cannot already carry.
The biggest difference this time is pace. The DOS-to-Windows transition gave that support hire years to grow past the skills he never learned. Today the world changes under our feet monthly, weekly, soon daily. Will it take five years before our current view of entry-level, routine, white-collar work looks like tinkering with an autoexec.bat file? I don’t think so.
So here is the nut. You want to teach people the patterns and frameworks with current technology, in a way that transfers to tomorrow’s technology, versus teaching them the data and knowledge that is chained to yesterday’s. The panic about entry-level work is real, and talent debt is real. But the answer is not forcing companies to keep hiring for roles that are dissolving, or yell into the wind when they don’t. The answer is making sure what we teach, in schools and in those first jobs, is the half that transfers. The era of entrepreneurship is upon us, and the people, and the societies, that succeed in it will be the ones that teach their people how to think, reason, create, communicate, and connect…regardless of the toolset.
This is why the time at Loyola left such a mark on me. Cura personalis, educating the whole person, is this exact idea with centuries of practice behind it. You are not producing a graduate loaded with a set of knowledge; you are developing a person who can think, reason, create, and connect. The knowledge set expires on a schedule nobody controls. The person transfers.
The autoexec.bat guy made it just fine. He was never going to make it as a DOS tech. He made it as someone who could figure things out, and nobody has automated that yet.
Signal, not Sentiment 