The hidden cost of replacing junior engineers with AI

A conversation between Norbert Korny, Jeff Allison, and Sean Murphy on the hidden cost of replacing junior engineers with AI tools.

The hidden cost of replacing junior engineers with AI

This conversation is a continuation of “The AI Gold Rush: It Still Takes Teams” where we explore other aspects of AI tools on engineering processes, organizational design, product development. Also the ill-conceived management trend of replacing junior engineers.

Edited Transcript

Norbert Korny: There’s the rush for AI to replace humans, and especially the juniors. Do you see the impact on the job market in Silicon Valley?

Sean Murphy: That’s absolutely going on. I think that’s ill-conceived for a couple of reasons. I don’t think it’s going to work that way. And if you don’t bring on any novices or apprentices, how do you get journeymen and masters 10 years from now? In other words, that’s a recipe for going out of business.

Jeff Allison: Well, it’s the same thing that we did with outsourcing, right? And then all of a sudden, you know, you outsource everything, and and then you go, okay, I need a power guy or I need a signal integrity guy, and you can’t find those guys. They’ve gone somewhere else.

Sean: You didn’t plant them five years ago to let them get better and work their way up.

Jeff: Right. You always assumed that someone else was going to do it, and there’s always going to be an unlimited supply of the talent you need. Sean, you’re right: bringing in young talent should be part of the culture of an organization if it wants to get better over time. We all get stuck in our ways, lapsing into “This is the way we’ve always done it, and it’s always worked.” Some bright kids come in, look around, and say, “Why are you doing it that way?” Which is great. It’s refreshing and gives you a lot of energy. If you don’t bring in new talent, it may look great on the damn Excel spreadsheet for expenses, but fast-forward five years–maybe only three years–it’ll be a very different picture.

The numbers guys look at engineering today as a collection of costs and assume we can develop whatever we need when we need it. But view it as critical that they drive costs down. Well, that’s not necessarily true. Sometimes you have to make a huge investment early on to get a new technology under your belt so that you can reap the benefit in future generations of product. You can’t just add a significant new capability in one step. Trying to cut the cost right at the beginning doesn’t make any sense to me, but I’m not a CFO.

Newcomers bring a fresh perspective and challenge established practice

Sean: I think you made a good point. Newcomers look at things with a fresh perspective and they challenge established practice. Now, perhaps 80% of the time there are good reasons for traditional solutions, and they persist. But about 20% of the time people say, “How about that? The assumptions we made when we put this practice in place no longer hold, and we didn’t notice.” I don’t think that you can get an LLM to challenge you and say, “Hey, it seems like some of the assumptions implicit in your request or plan are incorrect, I think you need to check your premises or the basic assumptions behind your design decisions. Whereas a new person will go, “This doesn’t make any sense to me.” Now, that’s can be irritating, but sometimes it’s a grain of sand you can use to make a pearl.

Jeff: I was thinking about when we used to bring in new guys. They’d gone through the universities and were familiar with new tools and new methodologies. My worry here is that if these guys are learning these AI tools when they get their degrees, it may limit their ability to think outside the box and innovate. We need to be careful not to limit ourselves to what AI tells us. I think we need to watch out for that.

Sean: I agree, but the universities have a challenge there as well. The clock cycle on changes is running very fast right now. If I am teaching first-year calculus, differential equations, or another body of knowledge that’s been debugged over decades, the college-university system works great. But in this situation, where methods are being rapidly obsoleted, I think this argues more for an apprentice model. How do we attach juniors and others to the guys who are breaking the trail? How do we create an apprenticeship system and a community-of-practice model that encourages shared exploration, not just individual tinkering, to create a more effective learning dynamic?

Instead, the labs are selling a “tall thin designer” paradigm where one guy puts on a red cape and blue tights and does it all, encouraging the CFO to believe they can cut costs by letting go of a large chunk of their engineering or customer support staff. But the strange thing is that it’s the older, more experienced engineers who are getting better results. They can spot not only basic errors in generated code but also poor architectural choices the tools make. It’s led to the first example of reverse age discrimination I’ve seen in Silicon Valley in 40 years. Normally they tell the old engineer, “You’re too expensive, we can get a junior guy with twice the energy to do the job for half the salary.” Now we are replacing junior engineers and keeping the seniors

I’m not quite sure how to make the apprenticeship model work. We’ve had this long period of a kind of zero-interest-rate (ZIRP) paradigm, where we got used to things working a certain way. There are learning organizations. NVIDIA seems like one, and I am sure there are many others. I think organizations oriented around learning will be able to digest these new technologies and move faster with them.

I don’t think we’re paying enough attention to how to build on initial breakthroughs. It’s less about the guy who gets the first 10x productivity bonus and more about reducing his insights and methods into an established practice. A learning organization is also a teaching organization, about fostering team-level and organizational practices that are more effective. To your point, Jeff, there’s a tension between encouraging people to compare notes and share what they have learned, encouraging wider adoption and additional refinements and improvements, and measuring just relative personal productivity. I don’t want to share what I’ve learned if I am facing a 20-30% layoff, because I’d be reducing my competitive advantage over my peers. Management is creating perverse incentives for shared exploration and shared learning.

Questions for Planning for a Paradigm Shift

Jeff: Well, I think all of these issues are common to anything that’s early on a paradigm shift. It’s easy if I’m starting from scratch, but if I’ve got a current roadmap, do I intercept what’s going on right now with this new technology, or do I look at something new, get my legs under that, and drive new skills back into other programs? And what’s the timing behind that? And who does that? Companies and organizations have to manage bringing on new talent, providing training, and developing new processes. Management asks questions like:

What’s this do for my current roadmap and product portfolio?
What does this mean for our longer-term strategy?
What new products should I start?
How do I make this technology scalable over time?
How does this affect my architecture?
How does it affect my organizational structure?
How should I evaluate our internal skills inventory?
What mass training do we need to offer to get people up to speed?

There’s just a whole list of things people need to kind of get their heads around. It’s not just about AI and how it’s going to make us magically more productive overnight. I think individuals may get an immediate boost, but figuring out how to make a product development organization more effective will take a while.

Sean: So Norbert, what do you see going on? You’re in a larger organization. How do you see this getting digested?

Norbert: Well, you need to have a deep understanding of systems and system design already, because the tools don’t know how to build better systems.

Jeff: That’s true. Tools don’t develop products, people develop products. They may enable you to develop more easily but you are still doing the engineering. Even with better tools you have to know what you’re doing.

Norbert: There’s a thin line between apprenticeship and blindly copying the response of the ChatGPT into the code. With this rush to embrace AI we have lost some of that and I don’t know if we are encouraging juniors to understand and make improvements on the ChatGPT output. Because at some point we just run out of seniors.

Sean: Early in the development of a new field or discipline information is fragmentary and contradictory. We are working on this hazy frontier, which we think is jagged because of our ignorance, and we need to be organized in translating our exploration and tinkering into new methods that are reliable. You’ve got fragments of understanding you need to verify to untangle the contradictions, mark the blind alleys, and remix to find a reasonably reliable approach.

That’s not something that an LLM is going to help you with because there’s not a knowledge base you can train it on. If you want to teach somebody an established body of knowledge that’s been debugged, something like algebra, then I can use an LLM. But in a rapidly changing field where the frontier is mutating rapidly, there is not a lot of reliable information that’s written down. There are firsthand accounts, but many will contain errors and oversights despite the best efforts of the people involved. You cannot really Google for information that’s not well structured and expressed in common terminology. This is where apprenticeships and community-of-practice models are more effective, because much of the new information is shared only in conversations, emails, and informal briefings and presentations. Or it’s the result of watching someone else do something and gaining insight.

Jeff: So I give an agent a design challenge, and they write a piece of code for me. Part of the problems we used to have in engineering was the lack of reuse, right? So, someone would develop some really smart piece of code or smart circuitry, right? Then we would ask, “Why aren’t other people using it in their products? Why don’t they take what’s been debugged and put into production and use it to save time and effort?”

Well, part of the problem was that it wasn’t packaged in a way they could use. So they’d have to talk to the engineer and quiz them on some critical details they neglected to write down because they were trying to hit a ship date, not develop a reusable design element. And the developer may have worked on this design block two or three years ago and they are on a new project with new deadlines and they are not measured on helping out a different project. Sometimes new test cases have to be developed for a slightly different use case the block will now be applied to, and this involves more questions and perhaps some debugging of why it’s not working.

If the AI tools can not only generate the code but generate accurate documentation that matches it and test cases that enable reuse then it may have something to offer. Do you think AI will help with reuse?

Norbert: It might.

Jeff: How do we have conversations around design reuse and standardization? How do we introduce methods for libraries and standard practices that align with our culture? How do we manage the security issues: both in terms of leakage of important intellectual property outside of the organization and risks introduced by subtle defects in the code that is generated?

Moving from Breakthrough to Beaten Path

Sean: I think the challenge we are talking about is moving from breakthrough to beaten path, from an artisanal proof of concept or prototype to an industrial-strength process. You have people exploring in many different directions, making unique discoveries and gaining distinct insights. But they are not necessarily compatible because they proceed from different perspectives and can diverge further over time.

What I’ve seen is that shared methods are typically negotiated outcomes. You need to get it documented, and then people have to look at that and say, “Okay, here are the strengths and weaknesses of this approach. Here are the strengths and weaknesses of that approach.” You can support multiple methods depending on the problem domain you’re working in.

Norbert: Right, but if AI can help facilitate that, it’s a good thing. The goal is better methods that yield better products faster, not smaller teams.

Jeff: Business guys are going to drive the businesses. They’re going to give engineering the amount of dollars they think engineering needs, which is rarely enough. So the engineers say, “Well, we can do this now, but it’s going to take longer. Or we won’t come out with full functionality in six months, we can only hit 60% at this level of funding.”

But those conversations always happen. What I’m trying to figure out is how does engineering become more efficient using this technology? My other concern is if you have something generating lots of code, how do you test all of it? Because you don’t want AI developing test programs for the code that it generated; that’s basic engineering practice. If someone develops a circuit block or a piece of code, you can have them write a basic unit test, but you need others also to write tests. So having AI test its own code doesn’t make sense. So I don’t know how all of this will work out: a lot of code is being developed very quickly now. How do you develop a test process around that to verify that all these new modules work together? They may work on their own, but what about at the system level?

Norbert, say a build fails at 1 a.m. because someone checked in a piece of code that broke something, or you have all these conflicts. Now someone has to wake up, go through all the logs, look at the code, and untangle it. Will AI help there, or make it worse, or how are people going to struggle with that?

AI is Tireless Diligent Intelligence

Sean: I think we should look at “AI” more as a tireless or diligent intelligence; I think in the break-the-build case, a simple set of rules could be applied consistently to catch basic mistakes. You attack the bottom 20-30% of the problem with AI instead of trying to achieve a breakthrough. Ask it to do the bookkeeping and basic blocking and tackling.

My fear with the labor cost savings focus is that I have never worked in an engineering organization where the leader gathers everyone together and says, “This is a great team. We set very high standards, so I want to let you know that a year from now, only 60% of you will be here.” Salespeople are used to that. When you bring in a new sales force, it’s kind of implicit that if they don’t make their numbers, they’re gone. But engineers are not normally managed that way because they’re working in teams, and you can’t always trace who contributed what. There are ways to assess contribution, but it’s more at the team level. I worry that this focus on cost reduction is going to prove extremely corrosive to leveraging the breakthroughs the pioneers make, using them to build on the early guys, and actually raising the standard of performance.

Jeff: Don’t you think this will work it’s way out over the next nine to eighteen months? We’ve seen people come in with a new business model they claim will dramatically cut costs. At some point they realize it’s not going to work. It’s going to be painful, right?

Sean: I think it’s going to take a couple years and it’s going to be very bad in the interim.

Cost reduction thesis has no basis in reality

Jeff: I’ve been through headcount reductions, not because we brought them on ourselves but because of things that happen in the market or the national economy. It’s very difficult when you commit a program to develop a product that you promise to customers or a market, you need to size it correctly up front. When you don’t, you are in for a lot of pain through the whole development process. My concern is people have been advancing this cost reduction thesis that has no basis in reality.

Sean: There’s a category of algorithm that’s called a greedy algorithm: essentially, you look at the choices that are immediately available and choose the best one. Typically it’s the lowest cost or shortest distance. You don’t look ahead multiple moves or consider the consequences; you pick the best move and keep picking it at each turn. For certain problems, these algorithms are optimal. But in general, you cannot cost-cut your way to greatness, which seems to be what some firms are trying to do. We are also starting to realize the implications of a code base that’s been auto-generated, but I don’t think we’ve seen the full consequences of that yet.

Jeff: It’s going to take time to play out. I hope most companies are starting to put this technology in play internally on smaller projects or a subset of projects to get it ironed out. Then they’ll understand the cost structures and what’s needed to use AI in their mainstream product line.

Sean: I don’t know how much controlled experimentation is being done. It does not seem like many companies are used to acting as learning organizations. It’s certainly not the forte of most IT organizations, who are more comfortable with vendor-supplied cookbooks and predefined migrations. The challenge many companies now face is that the rate of change in the industry has increased by at least an order of magnitude, and their internal control and planning structures aren’t set up for that.

Norbert: As far as testing goes, you can make another AI model to test the codebase just to have a different point of view, but the bigger problem is that humans need to review that code.

Most of us are just not wired for that. We are wired for writing code, and now suddenly we need to read a lot of it.

Jeff: Yes, read it and understand it.

Hallucinations and Psychosis

Norbert: Another challenge is that a few hallucinations, sometimes more than a few, are mixed into all of this generated code. There is a strong temptation to skip climbing the mountain and get there in one jump, but it rarely works out. Hallucinations are intrinsic to LLMs.

I think LLM-induced psychosis is going to be recognized as a problem. Mr Dunning and Mr. Krueger will be excited because sometimes the LLM hallucinates exactly what you would expect, just to validate your worldview. You can get caught in a feedback cycle where your false beliefs are reinforced, further distorting your thinking..

Jeff: Do you think so? Aren’t companies going to create their own standards and their own learning modules? First, for security reasons; second, for proprietary information; and third, in the belief that we’ve created it so we know what’s in it.

Norbert Security concerns for malicious code will be a big part of this. Another risk that’s getting more attention: how do you protect your source code when you build using a mainstream AI model, how do you prevent them from stealing it? From what I’ve read, this has already happened multiple times. You just can’t rely on some AI provider.

Jeff: But if I were running a company and had to invest in creating my own LLM model that’s going to take some headcount and a serious investment, won’t it?

Edge or On Premises Models

Norbert: You may not need to build your own model. You may be able to protect against data and IP loss by running a model on premises. We moved everything to the cloud on the theory that data was stored safely and redundantly for disaster recovery. But the AI firms may face different incentives than the SaaS vendors.

Jeff: Reminds me how social media firms told us everything we posted remained our data and no one else could use it. Now we find out the AI companies were strip mining all that content plus all of the books and artwork for their generative models.

Sean: I wonder if there’s a pattern match to the web server code that’s now essentially all open source for Internet-facing stuff for a variety of reasons. I think the other thing that happened was the big providers had a good enough business, and it would have been obvious if they were stealing from their customers. So, for the most part, as far as we know, they didn’t steal our data or code: Amazon hasn’t launched 40 other applications that look a lot like those that were formerly hosted on AWS. But the incentive set facing the large model guys, I think, is very different, and you’re going to see more people running open-source models locally for a variety of reasons.

Jeff: But if they run numbers on what it would take to do this internally, I’m sure that’s more than just a handful of people, right?

Sean: So the basic model can be a barn raising, a group collective project, and then you feed it your own data privately to extend it. And if I use an open source model and then extend it, then that may not cost a billion dollars. There’s a lot to play out here, and I think we have at least one round of bankruptcies or reorganizations here before 2030 or so.

Jeff: But it’s the same thing though. At the end of the day, this technology needs libraries and a whole stack of supporting tooling and data. We know that historically companies created software libraries, hybrid libraries, corporate standards, and everything else. I mean, that’s a huge investment, right?

Norbert: Basically, it’s libraries of the skills, and anyone can publish a skill, some may be malicious but they get included by default.

Jeff: Another thing, I want to ask: let’s take Company A and Company B who are competitors. They’re competitors, and they’re using the same toolset. Where’s the competitive edge? How does Company A become more innovative than Company B if they are both using the same libraries, the same tools. The outputs are, in my mind, probably going to be the same, not so different because it’s all based on the same thing. So where’s the innovation, and where do I get competitive advantage?

Norbert: Well, this is a great question because what’s stopping you from building something like Facebook when you have all the tooling at your hands?

Sean: But it turns out that building the Facebook application is not the barrier to the next Facebook. It’s the fact that they’ve got a massive installed base.

M	T	W	T	F	S	S
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

The hidden cost of replacing junior engineers with AI