The Last Generation of Masters?

The Faster Path

There's a moment I run into more often now. I'm planning the next increment of a project, and I can see two ways to get it done. In one, I bring in a junior developer, explain the context, walk through the decisions, review the changes, and leave room for the mistakes that come with learning. In the other, I open an AI assistant and build it myself, probably in less time than the explanation alone would take.

Measured by this week's throughput, the second path wins almost every time. That's what worries me.

I'm wary of romanticizing what came before. In more than thirty years, across organizations of very different sizes, I rarely saw software develop its people through anything like a formal master-and-apprentice system. A few companies ran multiyear development programs. Most of what I learned came from my own initiative, short courses, a colleague willing to look at my code, experiments that broke, and production failures I had to live with. Mentoring usually happened in spite of utilization targets and billing pressure, rarely because anyone had budgeted for it.

What the routine work did provide was a steady supply of small decisions with consequences. Writing a plain data-entry screen didn't build judgment by itself. The decisions inside it did: testing an assumption, getting it wrong, chasing the failure, hearing from a reviewer, and revising what I believed. AI removes many of those chances along with the routine work. So what's at risk was never a well-run apprenticeship system. AI is changing the economics of an already inconsistent way of building engineering expertise, and every individual decision to skip the junior developer is rational. Add enough of them up and you get a profession that stops producing masters.

A Rational Choice With a Collective Cost

I believe in teams. No one person should be the only one who understands a system. Shared knowledge gives a project resilience: someone can go on vacation, take another job, or get hit by the proverbial bus, and the system survives them. As a delivery leader, I've always pushed for that.

I still feel the pull in the other direction. Mentoring costs attention, which is the scarcest thing I have on a busy project. With AI tools I'm more productive on my own than I've ever been, so the gap between doing it myself and teaching someone else has never been wider.

That's not a criticism of junior developers. It's a genuine conflict between individual throughput and organizational capacity, and AI widened it. A sprint velocity chart rewards the feature I finished today. It has no column for the successor I didn't train.

It's also a legitimate business consideration. Clients pay for solutions and outcomes, and they shouldn't be expected to quietly subsidize their technology provider's workforce development. An organization that depends on future engineering expertise has to treat building it as an intentional investment, with a cost someone has decided to pay. Today that cost mostly lands on busy senior developers as an invisible personal obligation, which is exactly the kind of cost AI makes easiest to skip.

How I Learned, and What It Never Taught

My own path tracks how technical learning has changed. I started in a multiyear corporate development program, the kind few companies still run. After that came technical books and a lot of experimenting, weeklong classroom courses, online instructor-led classes, on-demand platforms like Pluralsight, Stack Overflow, and now AI assistants that work inside the editor. They overlapped more than they replaced each other, but the direction never changed: each one made it faster and more convenient to find out how to build something.

What strikes me most is who adapts to whom. A book or a course had its own structure, and I had to translate my problem into its examples. A Stack Overflow answer came closer, but it still answered someone else's question. An assistant in the IDE can read my actual application and take part in solving my actual problem.

None of those steps taught me much about why something should be built. That came from other places: sitting with the people paying for the software, watching a feature nobody used, living with a design that met the requirement and missed the need. For thirty years the industry has kept accelerating how without an equivalent investment in why, and AI is the largest acceleration yet.

It helps me to separate three capabilities. Understanding the problem means knowing what the business is trying to accomplish and why it matters. Evaluating solutions means knowing what alternatives exist, what each one trades away, and what risks come with it. Implementing a solution means building, testing, operating, and maintaining the approach that was chosen. Training and tools have mostly served the third. AI multiplies the third. Judgment is what connects all three, and being able to build software is a different skill from knowing what software should be built.

"Teach Everyone How to Do That"

People sometimes watch how much I get done with AI and tell me I should teach everyone how to do it. I can teach the mechanics: how I set up the tools, how I structure a request, how I break work into pieces an agent can handle. That part transfers in an afternoon.

It also isn't where most of the productivity comes from. What I can't hand over is the pile of decisions, mistakes, stakeholder conversations, outages, and trade-offs that shape how I look at a problem before I ever write a prompt. Thirty years of judgment won't download into somebody else.

A small example. When an AI agent hands me a change, the first thing I look at is the delta. What changed, why did it change, and why is a file that has nothing to do with the request suddenly in scope? That instinct didn't come from a course. It came from years of watching small, apparently harmless changes cause problems far from where they were made. A developer without that history sees a feature that works. I see a diff that touched something it had no business touching.

The questions before the code work the same way. A junior developer tends to ask how to implement a requirement. An experienced architect asks why the requirement exists, what business outcome it serves, what simpler option was dismissed, and what happens when the assumptions behind it change. Copying my prompts doesn't copy that thinking. The prompt is the last step of a reasoning process the learner never saw.

Faster at What?

AI is a multiplier, and a multiplier works on whatever it's given. A developer who questions assumptions and understands the system can use it to do thoughtful work much faster. A developer who tends to build unnecessary complexity can now build unnecessary complexity much faster. The same tool in different hands produces very different results.

That's why handing everyone an AI license doesn't solve the problem. Generated output can hide shallow understanding. A novice can deliver a working feature without recognizing the architectural weakness underneath it, or the business consequence it creates six months from now. For a while their output looks just like a senior developer's, which makes the gap harder to see.

A workshop on prompting improves tool proficiency, and that's worth doing. It can't compress years of engineering experience into a day. The risk I worry about most is an organization that watches output climb and mistakes it for better engineering.

Learning in Public

Stack Overflow was never an apprenticeship program, but for about fifteen years it was where a large share of developers learned in public. You could see competing answers to the same question, the corrections that followed, the arguments in the comments, and the explanation that finally made it click. Nobody assigned the lessons; you went looking for them. I relied on it heavily during its peak years, almost entirely as a reader.

It was never a gentle classroom. The few times I submitted something, the experience was bad enough that I rarely tried again. Plenty of other newcomers ran into the same thing, and question volume was already falling years before ChatGPT. AI finished the job. By mid-2026 the site was getting about 1,400 new questions a month, against more than 200,000 at its peak. I look at the business side of that collapse in Momentum Is Not Propulsion.

AI-enabled IDEs now provide many of the same interactions privately, and with far more context about the application in front of the developer. The answers still arrive, often faster and more patiently than any forum delivered them. The knowledge isn't necessarily lost, but it no longer lands anywhere the next developer can find it: the correction, the debate, the reasoning behind the fix. Researchers studying the decline have made a related point, that these tools reduce the very public data they were trained on. That's a good reason to capture engineering reasoning on purpose, which I come back to below.

Moving Judgment Earlier

There's a hopeful side to this. AI also removes much of the mechanical burden that used to keep junior developers out of the interesting conversations. Developers have traditionally spent years mastering syntax and frameworks before anyone invited them into discussions about architecture, trade-offs, and business outcomes. Some of that time went to fundamentals they still need: how code, tests, dependencies, and failures actually behave. A lot of it was just waiting their turn. What's worth preserving is the experience of deciding, testing, failing, and revising, and the mechanical tasks were only where that experience used to happen.

AI can help with more than the typing. A learner can use it to explore alternative designs, get an unfamiliar concept explained three different ways, pick apart a failure, or argue through a trade-off. The line I care about runs between using AI to support reasoning and handing the reasoning over entirely. Whether AI can actually shorten the road to judgment is an open question, and one worth investigating rather than assuming either way.

The apprenticeship I'd want to build looks something like this. I'd give a junior developer a real business problem instead of a toy exercise. Before any code, I'd ask them to state the problem in their own words, list the assumptions, sketch two designs, and say how they'd know the work succeeded. Then AI can help with the implementation, and they review every change, explain the result, and validate it: what changed, why, and what they checked. I review the reasoning as hard as the code. Does the solution fit the problem, or does it just pass the tests?

The mentor's job shifts too. Instead of handing over answers, I try to narrate the thinking behind them: what I noticed, what I ruled out, what made me suspicious. When I walk through an agent's work with someone, the useful moments are the stops. Here's a decision point; what are the alternatives, what would you check, and why? Debugging, production feedback, and design changes all belong in that loop, because that's where judgment gets built.

Then I'd have the reasoning written down where the rest of the team can find it: in the pull request description, a short decision record, or the team wiki. Why this design, what was ruled out, what the learner checked. It's a small, local version of what the public forums used to provide, a trace the next person can follow after the conversation is over.

The measure of progress changes as well. I care less about how fast a learner produces code and more about whether they can challenge a wrong assumption, explain why a design fits, diagnose a failure without a lucky prompt, and make a decision, see the result, and update what they believe. Every so often I'd want to see them reason through a problem without the assistant, as a check that the understanding is really theirs. People learn at different speeds, and decades on the job aren't the only route to good judgment. But producing code and acquiring wisdom run on different clocks, and AI only speeds up one of them.

The Cost Is Real

I won't pretend this is free. It slows me down today. Every hour I spend explaining a decision is an hour I could have spent shipping the next thing, and on a project with a deadline that trade is visible to everyone.

The return is slower and harder to put on a chart: people who understand business problems and have enough technical competence to take responsibility for the solutions they create. Faster code generation was never the goal.

AI cuts both ways here. It can hide shallow understanding behind impressive output, or it can bring developers into meaningful problems and decisions earlier than any path I had. Preserving the way developers learned thirty years ago isn't the job; finding better ways to build the judgment they'll need thirty years from now is.

I don't want to be part of the last generation that understands how software actually works. I'd much rather the next generation become better problem solvers than mine, and that only happens if someone takes the slower path often enough for them to learn.

Explore More

• Momentum Is Not Propulsion — the companion piece: how AI changes the economics of skilled work, and why the quality argument isn't the one that decides it
• The Art of Making Yourself Replaceable — why sharing what you know is how a career grows
• The Balanced Equation: Crafting the Perfect Project Team Mix — what a mix of experience levels gives a project
• Mountains of Misunderstanding: The AI Confidence Trap — the gap between AI confidence and real competence
• Shift Left Into Planning — giving planning its own deliberate space before engineering begins