These days, AI is reducing the number of entry-level jobs that we have. The trouble is, these are the jobs that are actually training tomorrow’s experts. How do we solve this?
Zoho’s Sridhar Vembu posted something that’s been bugging me. He said that AI makes senior architects more productive and reduces the need for junior engineers. But as Vembu notes, if nobody starts junior, how can anyone become an architect?
The data support his concern. Stanford found that, since late 2022, the employment for 22- to 25-year-olds in jobs well-suited to AI automation, like software, fell by as much as 16 percent compared with older workers who were doing the same jobs. Matt Beane at UCSB also saw this happening in robotic surgery. A similar phenomenon that happened in surgery even before AI came into the picture because robotic consoles allowed surgeons to do what the residents used to do. Therefore, surgeons stopped bothering to train the residents.
But this is not a new problem. Accountants, pilots and chessmasters have faced this problem and have solved it before in three different ways. Here’s why their experiences are important to the entry-level expertise question and how to apply key lessons moving forward.
Where Will the Next Generation of Software Developers Come From?
To solve the entry-level training crisis caused by AI, software teams should adapt based on the risk of AI errors:
- Low-Risk Software: Shift junior roles from writing code to evaluating, testing and catching AI mistakes.
- Mission-Critical Software: Enforce mandatory practice without AI and use automated systems for failure simulation and coaching.
When Errors Aren’t Dangerous, Switch Roles
Spreadsheets made manual ledgers redundant. But manual bookkeeping is how accountants used to learn the practice of accounting. It’s also how they figured out different kinds of possible errors and how they occur. After the introduction of spreadsheets, however, the job of an accountant changed. Very few people were checking the arithmetic anymore. Instead, more people were designing the checks and balances that caught the errors. That is, they switched jobs, moving up one level from doing the calculation to designing and checking the system that does it.
There’s a similar opportunity for junior-level software engineers: Spend less time producing code and more time specifying what it should do, writing tests, reviewing AI-generated code and diagnosing failures. Like accountants after spreadsheets, they can switch from doing more of the routine work to checking and improving the system that does it.
When Errors Are Dangerous, Enforce Practice
Autopilot systems reduce opportunities for pilots to practice manual flying. In 2013, the FAA warned that continuous use of autopilot could degrade manual-flying skills and urged airlines to create opportunities for pilots to practice them in both operations and training.
Surgical simulation centers are doing a similar job today. In one survey, 70 percent required residents to demonstrate simulator proficiency before assisting in or performing robotic surgery. In other words, they enforce practice since being wrong is dangerous.
The same mandate can be applied to entry-level software engineers: make them practice debugging and recovering from failures without AI.
When Learning Is the Goal, Upskill
Chess grandmasters took a different route. Any free phone application today can beat every grandmaster. Chess should have vanished. But instead, chess is now even more popular than it used to be. Chess engines have become the coaches, and the young grandmasters today are much better than those from any previous generation. The goal is not just to find the right move, but to become a better player. They upskilled.
AI and automation are exciting driving forces reinvigorating software engineering. Instead of being deterred from stepping onto the first rung, aspiring entrants should embrace the new opportunities for growth and upskilling. Automation frees up precious time that can be redirected toward honing the vital skills of tomorrow, such as debugging, reviewing AI output and comparing alternative designs.
Which Bucket Is Your Software in?
The simplest test is to ask what happens if the AI is wrong. Commercial software is mostly in the switch bucket. You can live with broken deployments and prototypes and quick POCs. You just catch them and move on.
So, as a result, I have stopped hiring junior developers to write code. Instead, I hire them to catch the things that AI gets wrong. One of my interns goes to client meetings, records the calls, feeds the transcripts to an AI coding agent and builds the solution the client asked for. I’ve told him deliberately not to even try to understand what the clients say. The clients are experts in their domains; the intern is not.
But it turns out that they’re about three times as fast as anyone else with five years of experience because that experience is the bottleneck. That works when errors aren’t risky. For mission-critical software, it is dangerous. Wrong code in a trading system or a medical device can hurt people. In such cases, it’s important to build coding as a skill deliberately by debugging without AI and simulating failures. Using AI as a simulator or as a coach can be really powerful because Bainbridge’s ironies of automation still apply: “The better the machine gets, the rarer the human intervention, and the harder it is to stay sharp for the one time it matters.”
Which bucket your software is in may not be obvious upfront. If we get it wrong either way, it costs us money or harm. Either we overtrain, or we under-enforce.
Choose Your Path
Vembu is not sure how to resolve this. Nor am I. But if you run a software team, you should first find out the impact of being wrong. Where it’s not dangerous, switch juniors from writing code to catching AI’s mistakes. Where errors are risky, make them practice using AI as coaches, simulating rare failures. And throughout your organization, use automated systems to upskill your juniors throughout their careers.
