When Was the Last Time You Did Old-School Programming
Old-school programming is, by now, something of a derogatory term. Not using an agent, typing everything out line by line — it sounds like you’ve fallen behind. And with the help of coding agents, people like us have gradually become the thing we used to look down on — a kind of technical manager who doesn’t really understand anything.
But what actually gives me the chills isn’t this.
Experience, intuition, the judgment of whether an approach is any good — they all come from things you’ve done with your own hands. With Fable 5 in hand, you often slip into the illusion that “I can beat 99% of my peers.” But over this past year and a half, how much have I actually grown? Have I grown at all? Or has it just been the model getting stronger?
Microsoft’s 2026 Work Trend Index surveyed 20,000 employees across ten countries and found that only 16% can move fluidly between “directing AI” and “doing it themselves.” These people are classified as Frontier Professionals. They share one common habit: deliberately leaving some work to be done without AI, to keep their skills sharp.
This doesn’t prove that old-school programming prevents skill atrophy. But it reminds me that doing things by hand may carry a value that doesn’t show up in any single delivery.
As for those even worse off than me — the recent graduates who haven’t yet built up much of a foundation — where are they supposed to start accumulating?
The Task Is Done, but the Learning May Never Have Happened
In the past, onboarding a newcomer followed a fairly clear path. You started them on a small, well-scoped task: fix a bug, add an endpoint. They’d gradually get comfortable with the code, understand the business, and only then move up to systems and architecture.
The value of these tasks came in two parts. One was getting the work done; the other was letting the newcomer go through a complete feedback loop: understand the problem, propose an approach, implement it yourself, discover what you missed, and revise your own understanding.
These days it’s more like: a senior colleague hands you a glider with no engine and says, go fly.
This isn’t entirely a matter of responsibility. A lot of the time, even people who genuinely want to mentor others face an awkward choice — do I spend a few sentences having an agent write this module, or do I spend the better part of a day explaining the background to the newcomer, spelling out the requirements, waiting for them to finish, reviewing the work, and then pointing out the problems?
It gets worse. You hand the task to the newcomer, and the newcomer hands the whole thing to AI. Ask them why it’s implemented this way, and odds are they can’t answer.
The task is done, but the learning may never have happened.
This is also where last month’s coffee chat started: AI is taking over a slice of the entry-level tasks, and those tasks used to double as the newcomer’s training ground.
Output and Cultivation Used to Share the Same Work
A disclaimer up front: not all menial work deserves to be missed. Some repetitive labor teaches you something the first time through and is just burning time by the fiftieth. AI taking that over is something to welcome, plain and simple.
What actually needs to be recognized are the tasks that look simple but carry real feedback. They’re usually small enough for a newcomer to own end to end, real enough that getting it wrong exposes a problem, and they still have someone checking, questioning, and backstopping.
That’s also where the mentor comes in: pick the right problem, help when the newcomer gets stuck, point out what they missed just as they’re sure they got it right, and then decide when to hand them something bigger.
This training has always had a cost. The mentor’s time, the newcomer’s trial and error, the team’s tolerance for inefficiency — someone has to bear all of it.
It’s just that, in the past, that cost was folded into the production process.
The CRUD a newcomer writes is part of what ships; the bug they fix is a real problem. The project moves forward, and the person grows along with it. The company gets both today’s output and a more skilled employee for tomorrow, without having to book every bit of coaching as a separate training expense. Day-to-day work really did absorb a huge amount of training that was never priced on its own.
What AI changes is the accounting: the same delivery can be completed with less junior labor. So the organization gets a choice — keep the output, skip the cultivation that used to happen alongside it.
Output and cultivation have been decoupled.
The cultivation half didn’t disappear. It just lost its host, becoming something that must be funded separately, scheduled separately, and produces no direct return.
That’s what I mean by decoupling. It hasn’t happened across every task, and it may never happen completely — but it’s already enough to change how organizations allocate work.
The “cultivation system” we thought existed is, to a large degree, a byproduct.
Talent Debt: Who Will Pay for Tomorrow’s Judgment?
In a Fortune article, Jeff Raikes gives this long-term risk a name: “talent debt.”
The employment data offers some warning signs as well. In its August 2026 update, the Stanford Digital Economy Lab finds that in AI-exposed occupations, employment among 22–25-year-old workers is about 19% lower than what the trend among their low-exposure peers would predict — with no such gap among senior workers. The researchers also stress that this is a descriptive difference, not something to be read directly as a causal estimate of AI-driven job loss, nor evidence of economy-wide job displacement.
If the entry points into an industry shrink first, where will the senior people it later needs come from?
Answering “companies should value cultivation” isn’t enough. The harder question is: under what conditions will companies keep paying for cultivation?
In the past, the output a newcomer produced while learning covered part of the cost; once they grew, the company benefited again from their higher capability. Now, if the task at hand can be handed to AI more cheaply, cultivation has to justify itself even more on future returns.
And future returns are uncertain. How much will they grow? How long will it take? And will they leave for another company once they do?
The benefits of cultivation accrue to the individual, their current employer, and their future employers; the company that bears the cost of mentoring gets to keep only part of it. This mismatch existed before — AI just makes it harder to hide behind near-term output.
So I’m reluctant to chalk all of this up to “companies getting less patient.” For some companies, hiring fewer newcomers and leaning on AI more may genuinely be the more cost-effective choice under current constraints.
But if a large number of companies make that choice at the same time, learning opportunities across the industry could keep shrinking.
In the short run, every company raises its per-person productivity. In the long run, everyone hopes to hire people who already have judgment from the outside. As for where those people actually made the leap from newcomer to senior — the job description won’t say.
What Cultivation Can Actually Change
Before discussing how to patch this path, there’s a prerequisite question: how much can we actually cultivate in a person?
Craft, domain knowledge, and analytical methods are relatively easy to break down into concrete training tasks. Curiosity, initiative, a sense of responsibility, and the willingness to keep exploring amid uncertainty — not so much.
I’ve genuinely seen a few young people with high agency who, amplified by AI, accomplish things their peers can barely manage. But more often, what I see is struggle and confusion.
Are we cultivating these tendencies, or simply discovering people who already have them and then giving them the right environment? I don’t have an answer. And I’m not willing to sort people into “has agency” and “doesn’t have agency” buckets on that basis. Someone who appears passive in an environment with no context, no support, and no feedback proves very little.
Maybe reality is still cruel.
At the very least, we can narrow the question: Can we design an experience that lets someone make a judgment, see the result, and then revise that judgment?
The four directions below all start from here. They require different conditions, and none of them amounts to a complete answer.
1. Finding tasks where output and training are still bound together
“Deliberately preserving some inefficiency to train newcomers” is hard to sustain as a long-term arrangement. More worth looking for are tasks where simply doing the work requires understanding context, making trade-offs, and touching the results.
For example, I’ve observed that some people who write code are being sent to customer sites to do Forward Deployed Engineer (FDE)-type work.
On the surface, the boundaries between engineering, product, and delivery blur together. But from another angle, real customer needs rarely arrive in the form of a complete spec. Facing real customers, being accountable for outcomes, and getting yelled at on the spot when you get it wrong — these are precisely the few roles where the bundling still holds. This may not be chaos; it’s a category of role being rediscovered.
But “going to the field” by itself isn’t cultivation. If nobody helps explain the context, you have no authority to adjust the approach, and all you get when something goes wrong is blame, then you’re just exposing newcomers to pressure earlier.
2. Shifting from “doing” to “judging” requires closing the feedback gap
One natural answer: newcomers no longer need to write so many leaf tasks — they can go straight to reviewing AI’s output and learning to make judgments.
But what exactly is someone who’s never fallen into the pit themselves looking at when they review?
You can’t simply say “you have to have made mistakes yourself to have judgment.” Human experience also comes from observation, cases, and other people’s feedback. What matters more is whether, after making a judgment, you get a chance to learn why you were right or wrong.
Judge → predict consequences → verify → explain the deviation.
The aviation industry’s flight simulation training offers a reference point: people can practice operations and decision-making without bearing the full risk of real flight. In software, some localized problems are equally well suited to becoming training environments — fault localization, data consistency, and missed permissions, for example.
But “will this architecture turn into technical debt five years from now?” is hard to answer reliably with a single simulation.
3. Letting the payer capture the returns on cultivation
If companies are expected to pay for cultivation on their own, historically it has only happened under three conditions:
-
Extremely high employee-turnover costs — people can’t be poached, or poaching them costs too much;
-
Extremely long cycles — semiconductors, for instance: if you can’t afford to wait, there is no next generation;
-
Safety-critical, externally mandated — aviation and medicine: no license without training.
Software hits none of the three. Turnover is high, product cycles are measured in weeks, and when a bug ships you just roll back. Expecting software companies to pay for this on their own is unrealistic.
So only two paths remain: either wait for some kind of “crash” to forcibly internalize the cost, or have someone outside the company pay for it.
4. Sharing what no single company can bear
What remains is probably collective funding.
This slot has always existed throughout history — guilds, apprenticeship systems, professional associations. The very reason they exist is that no single employer has an incentive to cultivate general-purpose talent, but the industry as a whole needs it.
The open-source community has actually been quietly playing this role all along, providing both output and feedback, with the cost shared across all participants.
Growth No Longer Happens Just as a Byproduct
Back to decoupling itself.
All of our past default assumptions about growth — schools teach the fundamentals, companies provide a training ground, time naturally produces seniority — rested on a single assumption: that cultivation would happen incidentally.
AI makes that relationship far less dependable: delivery can keep growing even as people experience independent judgment and self-correction less and less.
What AI is dismantling is precisely that default — the one where cultivation happens as a byproduct.
Going forward, growth may demand more deliberately designed tasks, time set aside, and clarity about who bears the cost.
A line I’m fond of:
Every flower blooms in its own time, and only you know what kind of flower you are.
In the era when “incidentally” still held, this line was a comfort. Now it reads more like a reminder: as ready-made growth paths grow fewer, you need to know, more actively, what you want to grow into.
But that half alone isn’t enough. Knowing what you want to grow into still requires a place that lets you grow.
Places willing to give a little time to those who haven’t bloomed yet will no longer appear incidentally.
Recommended Reading
How AI assistance impacts the formation of coding skills
The Impact of Generative AI on Critical Thinking
Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence
Jeff Raikes: The talent debt I warned about is now showing up in the data
When Work No Longer Lets Us Learn
The Young People No Longer Needed, and the Middle-Aged Workers Who Do Their Work for Them