Business Insider published a story on August 20, 2024 related to internal comments made by Matt Garman, the recently appointed CEO of Amazon Web Services (AWS), to employees regarding AI and its impact on the role of software developers. The comment was:
If you go forward 24 months from now, or some amount of time -- I can't exactly predict where it is -- its possible that most developers are not coding. Coding is just kind of like the language that we talk to computers. It's not necessarily the skill in and of itself. The skill in and of itself is like, how do I innovate? How do I go build something that's interesting for my end users to use?
Apparently, that comment alone wasn't click-baity enough so the Business Insider article referenced additional quotes from other technology executives over the past year for additional impact.
From Nvidia CEO Jensen Huang: Everyone is a programmer now.
Microsoft CEO Satya Nadella in 2023: We have 100 million software developers in GitHub today with this coding assistance. Now that we have CoPilot, I think there can be a billion developers. In fact the world needs a billion developers.
Stability AI's former CEO Emad Mostaque: I think we always have to look at the unchanging versus the inevitable. The inevitable is 41% of all code on GitHub right now is AI generated. ChatGPT can pass a Google Level Three programmer exam and it will run on a MacBook. There are no programmers in five years.
Hmmmmmm.
A billion developers? No developers? All with the same technology? What's going on here?
When you see glaring contradictions like this from top leaders who, in theory, should know better than us rubes what their technologies hold in store, you can be certain at least some are simply talking their book and you can be certain that none of them have a proper perspective on the larger economic forces being impacted by their technology. Before evaluating these comments in detail, it's worth taking a sidebar to describe the siren song of exponential growth (actual and claimed) and why it consistently poses problems for investors and managers in the technology space.
Exponential Growth, Technology and Investing
It was October, 1999. Shares of Sun Microsystems were sitting at $100. The Internet 1.0 bubble was in full swing and new startups and service providers were buying Sun servers like candy. Sun had incorporated in 1982, went public in 1986 and its stock price had appreciated from the $2 dollar range to $11.40 by the beginning of 1996. In 1996, the stock began growing at a steeper rate, reaching $29.10 by October 31, 1998, at which point the stock began growing exponentially. At the same time, Sun began selling even larger, more expensive "enterprise" class servers for large corporations and sales of those units were looking good as well.
Working in an IT role at the time, seeing how many Sun servers my company was buying at the time and noting how the stock had grown from $29.10 to $100 in the past year, it seemed logical to consider buying stock. Then I did some math to look at Sun's current revenues, unit sales assuming an average server price of maybe $10,000, then the price/earnings ratio. At some point, it became apparent to me that for Sun to justify its existing price, investors had to be counting on revenue to continue growing to a point where Sun would have to be selling one of their pizza box servers to nearly every small business in the United States. Every year.
If the product in question was something like a mobile phone which is INHERENTLY a personal device, that might have made sense. But they were selling SERVERS. Servers are an entirely different product. Servers allow workloads to be combined and shared to save costs. The users benefiting from them never see or touch them. There's no brand loyalty from end-users.
More importantly, they deliver value using technologies that follow Moore's law, doubling in processing power / density every eighteen months. That means if you think the market demand for server WORK is W and you have a product with capacity C, today the market needs W / C = N servers. But if performance is growing 100% every 18 months, in three years, servers three years from now will have (C + C + 2C = 4C) capacity so the same workload W can be handled with ONE FOURTH of the server count. Sure, workloads may grow at the same time as people find new uses for computer technology but still, UNIT VOLUMES will never grow unbounded. So if unit volumes won't grow unbounded, revenue cannot grow unbounded so why are investors betting the stock will appreciate exponentially in perpetuity?
After completing that mental exercise, I decided not to buy SUN shares. In the short term, I was completely wrong. From October 1999 to July 2000, SUNW stock jumped from $100 to $253, another 153% from the point I chickened out. Of course, after July 2000, the stock PLUMMETED and Sun Microsystems never regained its footing and limped on for ten years before being assimilated into the borg that is Oracle.
The takeaway from that story is that any business model dependent upon exponential growth to infinity WILL fail. The corollary to that rule is that any INVESTMENT in a business that depends upon exponential growth to infinity WILL lose money. Investors and business leaders alike should KNOW this intellectually, but they FORGET it emotionally, especially when things are going well in the short term. It's worth reading a message that Sun's CEO at the time, Scott McNealy, sent to Sun investors after Sun's stock collapsed in 2000:
At 10 times revenues, to give you a 10-year payback, I have to pay you 100% of revenues for 10 straight years in dividends. That assumes I can get that by my shareholders. That assumes I have zero cost of goods sold, which is very hard for a computer company. That assumes zero expenses, which is really hard with 39,000 employees. That assumes I pay no taxes which is very hard. And that assumes you pay no taxes on your dividends which is kind of illegal. And that assumes with zero R&D for the next 10 years, I can maintain the current revenue run rate. Now, having done that, would any of you like to buy my stock at $64? Do you realize how ridiculous those basic assumptions are? You don’t need any transparency. You don’t need any footnotes. What were you thinking?
Keep in mind, McNealy was addressing Sun's 10x price/revenue ratio at its peak. For context, here are stock prices and P/S (sales being revenue) ratios for leading AI related stocks as of 8/23/2024:
- Alphabet - share price $167.43, P/S = 6.34
- Amazon - share price $177.04, P/S = 3.00
- Apple - share price $226.84, P/S = 9.04
- Microsoft - share price $416.79, P/S = 12.39
- Nvidia - share price $129.37, P/S = 40.39
Which leads us back to these quotes from those guiding the development of artificial intelligence technology or applying it to traditional business.
Most developers won't be coding in 24 months?
Everyone is a programmer?
We need a billion programmers?
AI generated code is already 41% of all code on GitHub. There are no programmers in five years?
The fallacy in each of these quotes stems from either a mis-representation or misunderstanding of the nature of development work or of the economics of labor markets and the impact of specialization. In all cases, they have the potential to seriously mislead workers and investors who may lack the historical perspective of past boom/bust cycles or familiarity with current economics.
AI's Boundary Problem
All of these comments referenced developers without providing a definition of development work and how AI technologies can contribute to that work. References were made to the "translation" function developers perform by reading "business requirements" and mapping them to logic that can be executed within computers. What does that translation work look like?
Here's an example of a "business requirement" an analyst might collect from an internal "client" in marketing at a financial corporation and give to a developer:
Read a nightly report extract of account balance statistics and send an email to the contact email on each account offering bounced check protection to accounts with balances less than $500 dollars.
The developer would have to read that prose above and write code that might look like this:
logfileHandler = logging.FileHandler("lowbalanceAlertLog.txt")
logfileHandler.setLevel(logging.INFO)
logger = logging.getLogger(__name__)
logger.addHandler(logfileHandler)
# balance field is 4th physical field or #3 when
# array index starts at 0
field_balance = 3
field_account = 0
low_balance_threshold = 500
with open("balancestats.txt") as statsfile:
for statsrecord in statsfile:
fields = statsrecord.split(",")
thisbalance = fields[field_balance]
thisaccount = fields[field_account]
if ( thisbalance < low_balance_threshold):
logger.info("sent alert for account:%s", thisaccount)
SendLowBalanceOfferEmail(fields)
logger.info("Completed nightly low balance check.")
That's a ridiculously simple example and few companies would likely write a batch-oriented routine against millions of accounts using Python. However, it illustrates how "business requirements" in seemingly simple prose require DOZENS of semantic and logical decisions to be made by a developer such as:
- what computer language should be used?
- what variable names should be used?
- where will my input file be delivered so I can read it?
- should I expect a comma delimited file, tab-delimited file or some binary format?
- will the input file be encrypted and, if so, how will my code obtain a key to de-encrypt it?
- what are the field types and size limits of every field in the input file?
- how will the "send email" service be implemented?
- who will provide me the text of the email notice to send?
- should I use a for loop or a while loop?
- who should be notified if the script encounters a fatal error during execution?
It is rare for all of those questions and answers to be resolved up front in a complicated development project. That raises a key limitation with current Large Language Model (LLM) implementations of AI. Any software solution generated by an AI is prone to encountering what I will term here a boundary problem. The problem will be explained by analogy.
Imagine a business arranging all of its current and potential processes and systems across a football field. Some of the field might be empty with no running system. Other parts of the field are occupied with systems tied to other systems that might be adjacent to them or connected via plumbing to a distant corner of the field.
If a business request comes in to implement a process completely unrelated to existing systems, the user of an AI can simply post the prose of that new requirement to an AI prompt, take the suggestion spun out by the AI, build it, then deploy it to a vacant square somewhere on the field. Developers call that a "green field" solution (hey, this analogy is working...).
Most large corporations rarely do anything brand new that has no connection to existing systems. Most projects enhance existing systems or, at a minimum, require moving data in and out of existing systems to do something new. Now the user of the AI has a problem. If the new business need involves a system already present occupying one square yard, the AI can likely a proposed solution that's roughly compatible with the code already running within that square yard, whether it's in the endzone, midfield or the sidelines. However, the AI user trying to implement that one square yard sized solution may find the portions of the solution at the edge of the square yard don't mesh well with the surrounding turf (legacy systems) without major changes to either the AI code or the surrounding turf.
So now what?
Since the AI code was so easy to generate, does it make sense to err on the side of using the AI code suggestion and altering the systems outside the original square (the "legacy" systems)? Well, let's define THAT problem and hand it over to the AI and give it a 2x2 yard square to solve in. That may solve the original "border" problem around the original single square yard but now your "legacy" border touches eight linear yards of "integration" to "legacy" turf.
Do you keep going?
How about a 3 by 3 square yard "solution space"? Now your original enhancement requires careful analysis of compatibility between AI suggested code and legacy code spread across 12 linear yards of border.
When do you stop?
Your legacy systems that keep getting pulled into this project scope might have been implemented ten or twenty years ago. The AI being used was NOT likely "trained" on the source code or original requirements and design documents of those systems. Allowing a larger and larger "scope" for the AI to work in expands the boundary area of exposure to things the AI knows less and less about, making it more likely the solution is becoming LESS optimized for simple integration to the legacy systems.
How big is that software change going to be when you finally deploy it if you allow the AI to suggest a rewrite of half the football field? Put it this way... You don't want to be on call in IT the weekend that change goes live. You'll want to be on vacation somewhere out of cell phone range.
AI's Iteration Problem
The boundary problem described previously raises a second problem with current implementations of AI using large language models. A user interacting with an AI system provides it a block of text that, to the human, represents a question or a direction to provide some "answer" or solution to a problem. However, to the AI, the user's prompt is just text. The AI chops that text into characters and tokens then begins using their sequential positions to identify patterns of characters and tokens it has processed in its training and converted to probabilities to rank the token(s) most likely to be seen next, picks the one with the highest probability, then continues that process until its model reaches a limit that suggests the answer is complete.
This algorithm can produce results that are amazingly on point for the human's request but the algorithm and the internal data models for those probabilities calculated from petabytes of training data pose a key problem. Any arbitrary change in the user's "prompt" text can produce significant changes in the final output. Think of it as a "butterfly flapping its wings in China changing the weather in the Rockies" problem.
If using the AI to write a novel, a prompt might be provided requesting the outline of a novel set in Revolutionary America involving a a couple split between Tory and Patriot sympathies and the AI might generate a four page outline placing the couple in Boston operating an inn frequented by Paul Revere. There might be something in the outline that went in an undesired direction. What can be done? If the original prompt is altered with additional details pointing in the desired direction, that new input may cascade through the quadrillions of probabilities in the model and result in a new outline spit out by the AI that still involves "Revolution" and "Paul Revere" but only because the new output involves a TV show in the 1960s featuring musical performances from Jefferson Airplane ("gotta Revolution") and Paul Revere and the Raiders ("kicks just keep gettin' harder to find"). Definitely not the desired result.
This "butterfly" problem from changed inputs is a huge problem if using AI to create software even in a green field environment. Business users are notorious for not identifying all requirements up front. Adding requirements days / weeks / months after a major development effort has begun is difficult for humans to process now. When AI is being used, every new missed requirement added later has the potential to generate vastly different design output incompatible with prior iterations. So should every mismatch between iteration #1 and iteration #2 be fed in as problem #3 for the AI to solve? Doing so will only create more iteration artifacts until someone pulls the emergency brake. In short, AI may be ideal for supporting development of extremely simple, carefully constrained functions but cannot be used to iteratively design arbitrarily large, distributed systems over periods of weeks / months / years.
How Do You Define Development?
So what about the claim there are one hundred million users of the cloud-based source code repository GitHub that Microsoft acquired in 2018? There are 8,172,041,975 people on the planet. Does anyone seriously believe 100,000,000 distinct humans -- 1.2 percent of the entire population -- not only write software but find the need to keep their code in a cloud repository?
That's highly unlikely. First, many developers might have multiple accounts, one used for work, one used for private hobby experiments and maybe others as they work on projects with friends. Second, engineers working in the software industry know they must continually experiment with new tools to keep current on emerging trends, even if they aren't currently using them at work. This results in a lot of stranded accounts that get created and used for a few weeks as they evaluate new tools and technologies before moving on to the next thing.
From another perspective, the comments from both Satya Nadella (billion developers) and Matt Garman (no developers in 24 months) likely reflect seriously flawed definitions of development work. The nature of development work is inherently blurry, not because existing technologies prevent more exact definitions but because current management philosophies cloud the boundaries with layers of process that have nothing to do with moving the work forward but everything to do with calming the anxieties of managers and executives who feel powerless to manage processes and talent they do not understand. There are a lot of people in "development" jobs today not coding. It all depends on how you define "development."
My prior employer had a total of about 110,000 employees. The IT department employed about 1900 people. There were roughly 600 people working in teams responsible for "development." However, I would estimate that only about 210-300 people actual designed and wrote code -- and that includes final system code, test automation code and operations deployment and monitoring scripts.
And that final pool of "real developers"? There is an apocryphal made-up fact that in most organizations, about 10 percent of the developer headcount completes about 70 percent of the work and the other 90 percent of workers complete the remaining 30 percent. Numbers may vary as different people repeat this "fact" but the underlying point is crucial to understand. Productive coding is still a complex balance of reductive science and artful creativity. Managers and executives understand neither the science or the creative aspects but insist on treating the process like a purely reductive science like physical assembly work and impose layers of administration, tracking and inefficiency which impair actual productivity and make actual productivity measurements impossible.
That observation about management practices has important impacts when evaluating the truthfulness of these CEO prognostications.
When you discuss the impact of AI on "developers", who exactly are you talking about? Those NEAR development work (who are just project managers, business requirements writers, technical requirements writers, etc.) or those actually DOING development? By acting as an automated "babelfish" between normal business prose and code, it might be the case that wider use of AI eliminates "developer jobs" for those who focused on attempting those translations by hand for new systems or enhancements and bug fixes. However, as teams encounter the boundary problem described earlier, many of those would-be reductions might be offset by additional secondary development triggered as a project's scope is allowed to grow to attempt to let AI solve more of the re-integration into old systems.
A Billion Developers?
If the boundary problems and iteration problems described earlier were good arguments for why AI will not succeed at driving the developer population to zero, what are the arguments for AI not creating a world of infinite opportunity employing an unlimited number of developers?
First, has there ever been a case where a manufacturer has spend billions of dollars installing robotic welders in an auto assembly plant or auto-insert machines in a printed circuit board factory then told the displaced workers to stay on, move into a cubicle and help with design work?
Absolutely not. Why?
In any highly industrialized business, the balance between specialized labor and automation has been so highly optimized by competitive pressure in the marketplace that any labor being performed has been simplified so each labor step is incredibly simple and requires LESS expertise than it would if a single worker was doing all of the work. More specialization leads to less expertise required per job which requires less training which allows lower-skilled labor to complete the task and lower-skilled laborers face more job competition, lowering their wages. This dynamic makes it very difficult for any specialized physical laborer to move UP the labor ladder when displaced from a lower rung.
The software development craft is very analogous to the auto assembly plant model. It is safe to go out on a limb and state that, as of 2024, there is NO application on the planet being used by more than 10,000 users that has been written and maintained entirely by a single person. This is not only for the obvious reason that no sane company would allow itself to be held hostage to a single employee with knowledge of a mission critical application. It is also because the stakes regarding data security, performance and uptime are so critical to giant companies that no single developer has the expertise to design and code a so-called "enterprise application." Instead, you have
- browser based user interface developers
- Android smartphone / tablet based user interface developers
- IOS smartphone / tablet based user interface developers
- Windows / Mac user interface developers
- web service developers
- data modelers
- database / big data developers
- test automation developers
- deployment automation developers
Sure, all of these jobs involve understanding systems and writing code to accomplish tasks. It IS possible for one person to perform work in each of those specialties. However, the amount of work in each of these areas for a suite of "enterprise applications" required by a typical corporation is so vast that it is not economical to hire generalists who work across all of those disciplines. There's enough work in each discipline to encourage specialization.
The dynamics of the developer labor market are such that any advancement that reduces demand for work hours in a given specialty A will NOT allow a displaced worker to easily find work in specialty B, even if A and B are closely related work areas. Chances are there is at least a one-year learning curve to be proficient -- even for a "developer" who already knows the mechanics of languages, source control tools, etc. -- and no direct employer or contractor firm is willing to eat the cost of that "lost year" of retraining and lower productivity.
No car maker ever invested a billion dollars buying robotic welders for its plants then told all of the displaced welders to hang around and move into cubicles to help model the next pickup truck. We HAVE modelers, the displaced welders are out of luck. For the same reason, no firm that might successfully use AI technology for development is going to KEEP those displaced developers and use them to dream up new features and uses for AI. They think they already have those idea people. And besides, shareholders and the board expected hundreds of millions in savings if tens of millions of dollars were approved to adopt AI technologies. If those savings aren't forthcoming, heads will be rolling. Everywhere AI is leveraged it will be used as a means to drive down human labor rates for any remaining work still left for humans to do.
Who Is Investing in AI?
The second argument against the "everyone's a developer" model stems from a simple question: who is spending the most on AI technology and has the most to gain?" At this point, the biggest spenders on AI technology are existing oligopoly firms who dominate the online services, cloud computing and hardware markets. An obvious rebuttal to the remaining argument below is that of course these are the firms spending the most money. The nature of the technology requires a huge up-front investment in compute and storage and places to run it and these firms are the only firms with the scale required to jump-start the technology.
That being stipulated up front, the point of the question "who is spending the most and who has the most to gain?" is that AI inherently creates monopoly conditions in an information economy, based upon the vast quantity of information collected for training and the computing power required for training and ongoing operations. Any Econ 101 textbook will explain that any monopoly market condition will produce a sub-optimal quantity of a product at a higher than efficient price. The launching of such a crucial technology in a monopolistic mode from Day One itself is already a dire threat to the overall economy.
AI poses additional risks because the firms establishing monopolistic control over the technology are ALREADY in monopolistic positions that have been further exploited to create the new AI monopoly by using customer data for training. These existing monopolies are positioned to earn additional outsized profits from AI and distribute that wealth according to existing heavily skewed patterns benefiting the already obscenely wealthy. None of the firms involved with AI to date have demonstrated any proclivity towards redirecting profits towards research and activities that would reverse the corrosive concentration of wealth produced by their initial decades of operation.
So what is the correct takeaway from these quotes about the present and future for AI?
The easiest conclusion is that competing claims that AI will eliminate all development work and AI will allow everyone to be a developer cannot both be true. That makes it obvious that at least one of the two claims is either click-bait hyperbole, a reflection of someone completely ignorant about economics or a reflection of someone talking their book to prop up their portfolio.
The most accurate conclusion is that AI is incapable of eliminating ALL "development" work because of unique limitations in probabilistic models based on human languages and written inputs that are inherently imperfect. However, there are enough scenarios in which AI can provide illusions of productivity gains in the short term to lead firms to chase the technology as it evolves. These early adopters will generate bubble dynamics in the market that will continue tempting investors with high growth and punishing those with a poor understanding of exponents and history.
WTH
