Software Has Its Lean Manufacturing Moment
A Historical Analogy for the Arrival of Coding Agents
I have spent January running a continuous improvement process for my skills with Claude Code. The transformation in software development practice has been dramatic. Many engineers effectively don’t read code anymore, and just manage multiple agents in natural language in a multiplexed terminal.
Software can develop so much more quickly now that it’s impossible not to see an analogy to the introduction of Lean Manufacturing in the automotive industry. Indeed, insights from the story of Lean have helped me inform three convictions about the future of software engineering:
Code generation, like Lean Manufacturing, turns a bloated spreadsheet-driven process into a throughput-oriented process;
People are reacting to this change with understandable apprehension, and unfortunately there’s nothing new about this;
Increased similarity between software and hardware production processes will reconfigure talent allocation and unlock new possibilities.
My hope is that productivity gains from new AI tooling will create new bandwidth to solve pressing industrial problems. Today’s post is my exploration of this analogy, to the best of my historical and economic understanding.
Previous articles have discussed Lean Manufacturing and the history of the Toyota Production System. I have also written about a topic germane to some themes in this article: the difficulty of eliciting expertise about existing processes. These provide additional context.
Lean Manufacturing
Conviction number one: code generation, like Lean Manufacturing, turns a bloated spreadsheet-driven process into a throughput-oriented process.
Old software companies are like Ford, and new AI companies are like Toyota. Shorter time to deliver new products means iteration speed and design processes become the name of the game. Incumbents are forced to improve speed to market, which is usually where they have no competitive advantage.
Ford in the 1960s ran on spreadsheets. Robert McNamara and his “whiz kids” had put the company in the hands of accountants. The name of the game was lowering costs by exploiting economies of scale, delaying equipment upgrades, and improving margins where legible on the balance sheet. The common complaint was that none of the men in Detroit even bothered to visit production sites. This caused problems that competitors would exploit. For example: a plant in Chester, Pennsylvania famously received a dictum to reduce quarter-end inventory and achieved this by dumping parts into the Delaware River. It was a world of high profits and employees living large, and the firm was able to get away with excessive behavior because of its dominant position in the world market.
Toyota came onto the scene with a new production method developed for an economy with limited avenues to fast growth. One that was able, on this account, to receive enormous investment from the state and the business community. They did more with less: labor was expensive, input materials were limited and the company had little influence over the producers of them, and the domestic market wasn’t large enough to support globally-competitive enterprises.
(By the way, Toyota’s early predicament coarsely describes the situation we’re in with US wages, the price of copper and electronics components, and US versus Chinese populations. In short, constraints that can be seen as motivations for the scale of AI investment that we are currently making.)
Toyota was able to clobber Ford by implementing Lean Manufacturing and providing new products faster and better. They gave product managers the power of the purse and told them to deliver new models based on market segments. When they released new models, Ford couldn’t compete because it would break up the large uniform purchase orders that kept their economies of scale going.
Ford was slow to respond. They told themselves a fable for many years that Japanese cars were “cheap.” The fact was that quality at American automotive companies had been suffering for years. Structurally there was no incentive to guarantee quality: workers and executives alike had come to expect that work would be highly-compensated and low-risk.
Ford did adapt in the end, after years of pain, by learning from its Japanese competitors. As much as they find themselves in a strategic conundrum today, the company has transformed radically before. Salesforce can too. Microsoft has accomplished a transformation to a SaaS business model under Satya Nadella and is undergoing another one to become AI-first with Github Copilot and other offerings.
Ford’s old operation was eventually replaced by a design-as-process regime. They empowered product managers and embraced a continuous design process. Supplier prices became a collaborative continuous improvement process rather than a stand-off negotiation. Fabrication became a commodity and the modern supply chain was born. Now new designs would flow down several tiers of supplier.
Toyota demonstrated that a faster process that can deliver tailored products at smaller scale will win in the medium term. Incumbents will be forced to adapt. For Ford, it was their dependence on economies of scale. For enterprise SaaS vendors, it’s dependence on generalized software modules that are supposed to fit a broad market segment. AI-first companies might be “slop” but they have advantages where it matters. Who wins and loses is incidental, of course. The point is that the game has changed.
Salesforce serves as a comparison to Ford: they’re the best-in-class CRM, their revenue per employee is around $500k, and they’re a highly enviable place to work and attract graduates of top universities every year. Quality is okay, despite ubiquitous complaints from end users, but in their dominant position Salesforce has little incentive to make serious improvements. In the last two years, the world has changed: sales teams have completely changed for many companies, in a number of cases going majority-AI. Agents don’t need to use the Salesforce GUI. In other cases, companies are experimenting with developing their own CRMs using coding agents.
Most companies are not going to in-house their own CRM development. They will still buy Salesforce, but they may expect it to be able to make changes as quickly as they can modify their proprietary software. There are AI-native vertical-specific CRM startups now that can, like Toyota, iterate quickly to corner niche market segments. Salesforce has to respond to them, even if the competitors are immature. The fact is, regardless of its dominant position within the current market, Salesforce has no competitive advantage against AI-first vertical-specific CRM software. It is, like Ford in the 1960s, structurally committed to an entrenched business model.
Salesforce, like Ford, does have a lot of assets: existing high-quality software, a lot of data about sales, and quite a bit of human capital on retainer. Benioff has read the writing on the wall. He has been aggressive in getting the engineering team to move over to code generation, for instance. And, true to the concern that productivity expectations will just increase, he promised not to expand engineering headcount at at all in 2025.
Here’s an example of the kind of AI-native competition that legacy vendors have to contend with: the corporate spend manager Ramp is now able to ship substantive software changes to their clients with a SLA of three hours. This is what the software profession of the future entails: setting up CI/CD processes that can deliver concierge changes in basically minutes. The software becomes a process, just like how automotive models became a process. The resulting competition is likely to eliminate bloat, although it may take a lot of the concomitant high wages with it.
It is natural to look at this kind of expectation, coupled with generally lower margins across the board, and worry about what software engineering is becoming.
Fear, Uncertainty, Doubt
Conviction number two: people are reacting to this change with understandable apprehension, and unfortunately there’s nothing new about this.
Like with all new technology, there’s the fear that code generation is going to destroy jobs. Specifically, increased competition lowers margins and thereby headcount, and this causes a loss of expertise and wages. I think this concern appears in both immediate and macroscopic contexts.
The immediate fear is not just about layoffs. Yes, there have been a lot of layoffs in part thanks to the Big Tech hiring spree of 2021-2022. People are concerned about being laid off now, but they’re also concerned about the nature of their role changing.
With the increased velocity of code generation, the essential qualities of the software engineering job have transformed. Salesforce is trumpeting a supposed 30% increase in code generation productivity. We’re not even writing code anymore in many cases. The rate-limiting constraint on software delivery velocity has shifted to requirements discovery, writing architecture, and managing dependencies and stakeholders. Engineers are showing off how they just manage eight agents in a multiplexed terminal without even reading code.
Starting now, engineering demands process ownership of the thing that used to be individually contributed. This is remarkably different from the kind of work that engineers have enjoyed and taken pride in in the past. Adapting to the new tools can genuinely be exhausting. Jason Lemkin has been warning for months that the pace of AI-native work is burning people out. I myself have spent the last two months retooling in a low-stakes environment and the results are a complete transfomation.
To be clear: this as an enormous, world-changing opportunity. Lean Manufacturing was such an opportunity as well. Like all opportunity, it requires uncertainty, experimentation, and grit. This is not how most software engineering jobs were advertised back in 2019.
It can be an uncomfortable adjustment. Anecdotally, I have watched engineers step up to the LLM chat interface, asked to do a certain task, and struggle to delegate it. Not because they’re afraid of the chat interface, but because the task used to be something they had tactile control over. Now they’re being abruptly asked to verbalize what they used to do, abstract it, and evaluate the work that gets done by a statistical model. This is the immediate apprehension, I believe.
The macroscopic concern is what this new type of engineering role means for the profession overall, and for wage expectations across the board. Here I think Lean Manufacturing gives us a direct point of comparison: it’s going to get leaner.
I have seen the act of writing code described by distraught engineers as a “craft” we are losing. I empathize with the feeling and there’s some truth to this claim. We lost a lot of industrial expertise during the period of offshoring after 1979. However, seeing things this way can go in the same direction as the nostalgia for 1960s Ford described above. It’s not particularly different from imagining the old drafting process for Ford models as a “craft.” Yes, it predated Lean and CAD. It was, just like writing code, still part of a highly-specific industrial mass production regime.
We can read the tea leaves from manufacturing history: legibly high wages went elsewhere. These days, jobs in manufacturing such as precision machining don’t obviously pay well at first. And the terms of employment are communicated poorly enough that young people often find McDonald’s to be a more comprehensible bargain. Understandable is the fear that software could go from the 2018 situation—a BS in Computer Science all but secures a stable six-figure salary—to a situation involving apprenticeships, specialized skills that aren’t easily transferred elsewhere in the economy, and a loss of prestige relative to more clearly-high-wage fields.
Unfortunately, I trust the tea leaves here. The profession is likely going to get leaner, even at the expense of losing substantial expertise. For the industry as a whole, this unlocks opportunities and can have benefits for future innovation. I describe a few of these below. But for individual jobs, it’s highly likely that there will be leaner and more competitive years ahead. It’s disappointing.
The silver lining is that the American economy tends to be pretty good at employing people. Since 1946 we have efficiently allocated willing workers to present-need roles, even if this has involved relocation or pay cuts. In a lot of cases it might resemble the “McDonald’s instead of machining” scenario: failing to account for the value of expertise, or not perfectly informing candidates about medium-term compensation prospects. I suspect, for example, that many eliminated software engineering roles will be partially offset by the creation of quality engineering roles at organizations that have to test software on production systems. There are a lot of organization where a lack of non-production testing is a bottleneck. This is a diversion from the software engineering career as we have known it, it probably involves a diminishment of living software engineering expertise, and it likely won’t be as lavishly compensated as FAANG was in 2019.
The economy makes no assurances. Even in Japan, where the Lean Manufacturing zaibatsu provide lifetime employment to salarymen, they can’t make guarantees about the strength of the currency or their ability to compete with Chinese manufacturers. Disappointing shifts in industries are normal and real.
In summary: there are understandable concerns in the immediate term and macroscopically about the nature of software engineering jobs. Lean Manufacturing gives us a point of comparison to help imagine how the industry will change. It may be foreboding, but it has historical precedent. And it does unlock new opportunities and possibilities.
Convergent Evolution
Conviction number three: increased similarity between software and hardware production processes will reconfigure talent allocation and unlock new possibilities.
By transforming software development into a code-generation process that involves fast iteration, design as a process, and continuous improvement as tools rapidly change, we have converged the practice with how manufacturing is currently done. Although this means we can expect dour predictions for the labor market, it also suggests that software talent can spill over into the somewhat-deprioritized world of manufacturing. This presents opportunities to employ good brains on important industrial problems.
I speculate three possible consequences here: that this can lead to financialization the way that the transformation of manufacturing did; that it will cause hard asset prices to rise in a way that opens up opportunities for software talent to solve physical procurement problems; that it will create software roles directly within factories that allow solutions like production planning to go online with significantly less friction.
First: financialization. What happened to American industry after the 1970s can be summarized as offshoring and rolling up financial instruments to create liquid debt markets. This created a lot of wealth but arguably came at the cost of losing a lot of domestic manufacturing expertise. Hence the “craft” comparisons. The same thing could happen to software.
There’s a conceivable asset class here, one with sub-VC but supra-Treasury returns that could come from financing portfolios of vertical SaaS solutions. Claude Code enables this. A quick search for “AI-powered rollup” reveals that private equity is trying to create a playbook where input capital becomes tokens become annual efficiency gains. A few human operators rework the factory workflows to use the AI platform, post financial results, and take home some amount of performance-based carry. Opportunity for many people, but overall not a high-wage-creation engine.
This outcome does not assuage concerns about the shift away from high-wage software engineering jobs. Unfortunately it has historical precedent and financial rationale.
Second: hard assets are getting more expensive or strategically important, and thereby create opportunity for software engineers to solve physical production problems. Thanks to AI demand itself, commodity prices such as copper are up, VRAM prices are up, and supposedly GPU prices will go up enough that Twitter users are recommending consumers buy now before the cards become unaffordable. On top of that, there are many electronics components that are raising concern over geopolitical risk. For instance, we don’t make LED screens anywhere in North America and a conflict in the Pacific could completely cut off the American supply chain from digital displays.
Our inability to produce domestically is a complex topic that deserves elaboration in a future post. However, it has much to do with profit margins: LED displays return annual margins of about 3.5%, well below the S&P 500 and even slightly below today’s Treasury bill yields. Software talent, as it converges to lean techniques, will have opportunity to approach these physical production problems. If a new injection of talent can bring process innovations that can clear profitability hurdles, this would create new high-wage jobs for today’s software workers.
Third: factories can just hire software engineers to do software. Manufacturing founders are using Claude Code to build bespoke software. Software has to provide 10x the savings in order for the manufacturer to pay the price tag. If Claude Code can make you even 5x more productive building software for factories, suddenly there’s an IT job for you in house with manufacturers. With that increased productivity, manufacturers can actually now afford to pay your salary in-house.
As I claim above, homebrew ERPs are not likely to replace SAP, but it changes the game in terms of how software companies can provide a comparative advantage. It won’t be in just having the software. So software engineers at vendors will have to work harder and develop expertise about delivery, and software engineers at factories will get paid to own integrations and homebrew when appropriate. This fits much better with the fixed-cost model of procurement that factories are familiar with.
On a personal note: If we can get over this hurdle, I will experience the catharsis of production planning software finally becoming a priority in a lot of American shops. That would be very exciting.
The convergence of software and hardware processes is a historical novelty that opens up many opportunities to use talent in new ways. I’m eager to hear from my readers as they make their own speculations.
Conclusion
The story of Lean Manufacturing and the reckoning it caused for American industry is a profitable comparison for several trends that converge today in the rise of code generation. We fear a loss of high-wage jobs, a wave of burnout, and expectations across the board of higher productivity from workers that will accumulate only as increased asset prices. There are good reasons to have these concerns even as we adapt in the immediate term. That being said, the personal experience of making this adaptation has been terrific. And there are new possibilities unlocking as we converge hardware and software development processes.
At the end of the day, the new technology is increasing productivity, gains in which are in aggregate an asset for the economy. It remains to be seen if we can harness the productivity gains in software to deploy our talent to solve pressing strategic problems such as copper procurement or reshoring consumer electronics. I’m cautiously optimistic.