Where Do Senior Developers Come From?
For most of my career, nobody hired a senior developer straight out of school. We hired junior developers. We gave them work they could handle: build this screen, add this field, write this report, fix this bug, create this stored procedure. Then we gave them harder work. They made mistakes and learned from them, and they watched more experienced developers solve problems they didn’t yet understand. Five or ten years later, some of them became senior developers.
At a media company where we ran twenty-five online magazines, one of the copy editors wanted more than the job she had. So I started her on the same beginning work: small tasks where a mistake was cheap and somebody was around to catch it. Three years later her husband was relocated out of town and she left us, and she landed a job as a mid-level developer. Nobody hired her as a developer. She became one.
I’ve spent the last few articles arguing that the valuable part of this job isn’t producing code. It’s judgment: understanding the business, recognizing unnecessary complexity, knowing when the generated answer is wrong. I still think that’s right. The uncomfortable part is that judgment gets built by doing the work, and AI is now very good at the work we used to hand people first.
If we automate the entry-level work, where do the senior developers come from?
The Apprenticeship Nobody Called One
Software development has always had an informal apprenticeship model. A junior developer starts with contained problems, where the consequences of getting something wrong are limited and somebody more experienced is close enough to help. Over time the problems get less contained. Instead of changing one screen, they modify the workflow behind it. Instead of writing one query, they figure out why a report is wrong. Instead of fixing a bug somebody else diagnosed, they investigate why the application occasionally stops working.
Eventually they stop being handed answers and start being handed problems. That transition is where a developer becomes valuable. The syntax was never the goal. The experience was.
AI Is Very Good at Junior Work
Unfortunately, the work that traditionally produced that experience is exactly what AI does well. A CRUD screen, a straightforward SQL query, a unit test, a simple API endpoint. AI can generate all of those.
From a productivity standpoint, that’s fantastic. From a training standpoint, it raises an uncomfortable question. If a senior developer can generate the feature in five minutes instead of spending two hours letting a junior developer work through it, what incentive does the organization have to use the junior developer?
The immediate answer is obvious. Use the AI. The longer-term answer is less comfortable, because eventually that senior developer retires, leaves, or gets promoted. Who replaces them?
Experience Doesn’t Download
There is a tempting answer: that AI lets a developer skip from beginner straight to advanced work. Give somebody a capable enough assistant and they can generate architectures, write complex services, and produce applications well beyond what their experience would normally support. That can be useful. It can also create an illusion of competence, because generating a solution and understanding one are not the same thing. A developer can produce code they could never have written by hand and still have no idea whether the design is appropriate.
The dangerous code isn’t the code that fails. It’s the code that works.
Now the organization has a production system nobody involved really understands. Eventually a data volume increases, an API behaves differently, a certificate expires, or a business rule changes, and the gap becomes visible. Senior developers are valuable partly because they’ve already seen versions of those problems, and you don’t get that by skipping to the answer.
I learned this years ago in an advanced math class. I kept skipping lines in my work because I could see the result three or four steps ahead. The teacher told me that when I got an answer wrong, he could only give partial credit if he could trace my thinking, because sooner or later everybody drops an exponent or a negative sign. The lines I skipped were the only places anyone could find the mistake. That included me.
Junior Developers Still Need Real Problems
If we want experienced developers later, junior developers need opportunities to solve real problems now. That doesn’t mean banning AI, which would make about as much sense as telling developers not to use an IDE because previous generations used simpler editors. AI should accelerate learning, not replace it.
A junior developer can use AI to explain unfamiliar code, ask why a particular approach was chosen, generate test cases and then work out which ones actually matter, compare two designs, or use it as a tutor while debugging. But they still need to debug. They still need to write code, trace data through an application, and sit with a user who says “it doesn’t work” and figure out what that actually means. Occasionally they need to struggle with a problem long enough to understand why the solution works. Efficiency isn’t always the goal when somebody is learning. Sometimes the struggle is the training.
The senior developer’s job is different now. It’s no longer enough to fix the problem faster than the junior developer can. Sometimes the right answer is to use AI and get production running again. Sometimes it’s an extra hour walking somebody through the problem. That was always true, but AI makes the shortcut much more tempting. Teaching may now mean handing a junior developer work you could finish far faster yourself. Not because it’s efficient today, but because somebody needs to know how to do it tomorrow.
Later, at a manufacturing company, I had a developer whose background was entirely web development. The production systems were WinForms applications and he could not support them. Teaching him took longer than doing the work myself would have, every single time, and it was still the right call, because once he could support those applications he could take the 2:00 AM calls too. That stopped being one person’s problem.
Companies Have to Think Longer Term
This isn’t only a developer problem. It’s a management problem. If an organization measures a development team entirely by short-term output, AI creates a strong incentive to cut junior positions. Why pay somebody to learn how to write a feature when an experienced developer with AI can generate it faster? That calculation works right up until the company needs another experienced developer.
The software industry depends on a pipeline. Junior developers become mid-level developers, mid-level developers become senior developers, and some senior developers become architects, technical leads, and managers. Cut off the beginning because the entry-level work is no longer economically attractive, and a few years later nothing comes out the other end. You cannot hire ten years of experience if nobody was given the first year.
The old model produced experience almost accidentally. Junior developers got the simpler work because somebody had to do it. As AI takes more of that work, training has to become deliberate.
In practice that means choosing, on purpose, to do things that are slower than the alternative. Structured mentoring instead of hoping it happens. Rotating junior developers through support, where the problems arrive unfiltered. Requiring them to diagnose something before they ask AI for the answer. Code reviews that ask why a solution works rather than whether it compiles. Ownership of a small production system where the risk is manageable and the responsibility is real.
All of that trades short-term output for long-term capability, which is not an easy argument to make in an industry obsessed with efficiency. Neither is explaining, five years from now, that nobody left knows how the systems work.
Senior Developers Don’t Come From AI
AI is going to make experienced developers more productive. It will let one capable developer accomplish what used to take several people. But productivity and workforce development are two different problems.
AI can write the code junior developers used to write. It can explain concepts they used to learn from books, coworkers, and mistakes. It can solve problems they once spent hours working through. What it can’t do is give them five years of experience. That still takes five years, and the industry has to make sure those five years still happen.
Senior developers don’t come from AI. They come from junior developers who were given enough time, enough problems, enough mistakes, and enough guidance to become senior ones.