AI and Silver Bullets

Fred Brooks wrote "No Silver Bullet" in 1986, addressing the primary concern that software has no one quick fix, no silver bullet. Lifting from Aristotle, he applies essentialism to software engineering, developing the ideas of "Essential" and "Accidental" complexity. In brief, accidental complexity is not inherent to the problem you are trying to solve, whereas essential complexity drives the fundamentals of a problem.

Let's assume we wanted to write a program that logs data to your terminal. Assuming you use modern-day tooling, such as an IDE and a standard programming language (like JavaScript), this problem is not inherently difficult to solve. However, there is a syntactic complexity. How do I write to the log?

For people who have programmed a bit before, the syntax is straightforward:

console.log({Data}) 

For the uninitiated, this fact is unknown and represents complexity that accidentally occurs due to the nature of our tools at a given moment. You have some goal in mind you are trying to execute. The syntax of the language used is a byproduct of tooling for the problem. It is "by accident." On the other hand, essential complexity is directly concerned with the fundamental problems of our goals. The data structures, algorithms, architecture, and other elements that make the problem difficult are essential. With large codebases in particular, trying to account for a litany of overlapping states is difficult. Applying these states to a UI is even more difficult. These underlying complexities are inherent to the problem or outcome you are trying to achieve.

For instance, if we wanted to build a CRUD application using React and Postgres, the syntax for both JavaScript components and PostgreSQL is accidentally complex. It isn't that they aren't necessary, but they aren't essential to the problem. The essential complexity is the codebase's structure, optimizations, and the database's relational structure. How you structure the DB relationships to scale or how you plan to structure composable components is the essential complexity of the problem.

AI will reduce accidental complexity in creating software. We are extending the march towards software democratization, a long legacy implicit within the construction of modern-day software engineering. High-level languages were seen as a material improvement in reducing accidental complexity. However, as we've continually created abstractions to make engineers' lives easier, cognitive walled gardens have been erected along with these abstractions, which increase the accidental complexity we've been trying to avoid. Fred Brooks correctly predicted this problem:

AI will help deconstruct these abstractions. However, before we explore the future of AI and programming, it's important to examine the past, especially the creation of the first high-level programming language, Fortran.

The democratization of programming began with the introduction of Fortran and its compiler. Developed by John Backus and Team at IBM, software development changed with the introduction of high-level languages. In the 50s, binary and Assembly were the languages that sent us to the moon. Although powerful, the knowledge was held by a select few. These few individuals, acknowledged by John Backus as 'The Priesthood,' were incredibly talented individuals such as John Von Neumann, who, in effect, were human calculators. They didn't see the utility of the compiler. In one particular instance, Von Neumann admonished one of his students at Princeton for using 'valuable computing time' to build an assembler.

In 1954, John Backus recognized that operating in the realm of 1s and 0s was cumbersome and outdated. He commented that working with the machines was a "guessing game" at many points. Committed to his laziness, he and his team developed the Fortran language and, more importantly, the Fortran compiler. This development fundamentally brought us out of the binary era into one of higher-level languages.

Initially, the team faced strong resistance, highlighted by Von Neumann's question: "Why do we need more than binary?". Ignoring hindsight, his opinion was popular at the time. Being "close to the metal" was an important feature of programming, as it enabled them to optimize their processing time. This was partly due to the constraint that computer time could cost as much as $ 1,000-$1,500 per hour, which is approximately $11,000-$16,000 adjusted for inflation. This pricing reflected their scarcity, with fewer than 2,000 machines active in the early 1960s.

However, this narrow sight of optimization on the program missed that building software was not rate limited by processing time of a program but by:

Von Neuman could not have predicted the horizontal scaling of PCs in the 70s, changing the paradigm of renting time on a large mainframe. However, he did underestimate the time aspect of building and debugging software. Given that software is used to drive market outcomes, which rely on profit, ROI on time is important. By decreasing the time-to-build and debugging, "software engineers" of the mid-century were able to drive more impact in tighter feedback cycles.

As is known today, Fortran, after 3 years, would become one of the most important developments in software history. Because of this, a litany of other languages would propagate, including Algol, BASIC, and COBOL, based on the same idea of compiling to 1s and 0s instead of explicitly writing in it. The reduction in accidental complexity was a boon for programmers around the world. But how does this relate to the move from high-level languages to AI tools?

This line from "Fortran: Abstracting Away the Machine" encapsulates how Backus thought about programming, a perspective we should adopt. Our goal is some output, not the inherent attributes of the task to reach the output. If we can achieve our predetermined output in less time and involve ourselves in fewer low-level details, that is a net positive for us. Abstractions and higher-level tools, which fundamentally reduce accidental complexity, are key to productivity. This is what Backus intuitively understood when developing Fortran, which has echoed to Fred Brooks and his dichotomy on complexity.

Utilizing the same argument, AI will provide a similar advancement as Fortran. We won't be involved in the construction of types or data objects, relying solely on our AI agent to do that. If our goal is to create a web application that sells clothing, asking [Insert your preferred AI] to complete that task fundamentally reduces the accidental complexity of knowing Ruby on Rails, NextJS, or any of the other castles in the sky we've created. Because of the abstraction level moving from high-level languages to just language, programming will become more democratized. More code, not less, is going to be written. But what will happen to programmers?

A useful thought experiment is to compare Programmers from the 1950s, 2020s and 2040s. What would they think about each other's work?

If we compared a 1950s programmer to a 2010s programmer, the 1950s fellow would not consider the 2010s fellow a real programmer. He does not operate in Assembly, he can't work with binary, and he can't directly manage the machine's hardware. The man would be a software philistine, not a programmer.

What would the 2020s man say in response? He can do 20 times the work of the 1950s man and scale his work to billions of people. Yes, knowing binary or Assembly may be helpful for some use cases, but that is not required for scaling a web app to billions with a cloud service. Within a week, he can set up a web app with Stripe payments and robust cloud infrastructure, prepped for the onslaught of customers he will undoubtedly receive. The 2020s man would scoff.

Let's walk through the next step; what would the 2040s man say to the 2010s man? The most straightforward question to start is, "What can the 2040s individual not do?"

The 2040s "software engineer," who probably can no longer be classified in that manner, doesn't know how to spin up an Apache server. They probably haven't built something with a Raspberry Pi. He probably doesn't understand bubble sort or implementing a database index. They will understand these as concepts, just as I understand Heidegger. A hazy "knowing" that wouldn't be able to withstand questioning, one that sits at the surface layer of our bones but hasn't cracked deep enough to be felt with our soul.

Hazy knowledge in hand, how does this conversation go? The 2010s man says they can scale to a billion users and write performant code in two weeks. Cloud computing, tied with strong typing and NextJS, gives him unreasonable "agency," as the modern TPOT zeitgeist would say.

The 2040s man would ponder this for a moment. Not an avid historian of his industry, if it can even be considered an industry at that point, he would be shocked complex software took two weeks to write! He would wax poetic about how his tools handle all of the components and the implementation details for him. He is a savant in architecture and the fundamentals of computing, but if he were tasked with implementing many of these details, the time required to execute these tasks would detract from his other dopaminergic activities.

This is a rough outline of where the world is headed for engineers: continual reductions in accidental complexity from abstractions and code with a more focused direction on fundamental architectural trade-offs. What are the knock-on effects of this change?

Assuming we have pushed more complexity down the stack and follow the diagram above, what are the knock-on effects for software? A few things we can expect are more software, changes in Team composition, and heightened competition.

Everyone has mentioned Jevon's Paradox at this point. But let's focus on why this is the case. Programming is an act similar to writing whereby we bring forth something from our mind to the world. Unlimited creativity from individuals across the globe with lowered barriers supplies us with tools to enact a vision in quick succession without deep knowledge. Retail will make up a large bulk of new software being written.

In the business context, businesses without software as a core competency can build smaller, bespoke solutions to automate their processes. Smaller groups of business specialists can now create APIs, interact with various data formats, and develop cron jobs that were previously unavailable. Cloud, along with AI, will make a dynamic duo to automate and ship more code.

Technical ability will extend up the funnel and open up more "Technical Business Specialists" who can develop and deploy microservices while embedded in business-focused teams. Along with cloud deployments, reducing accidental complexity created through complex syntax and leaky abstractions via AI will enable more business problems to be solved using simple software.

The positive aspect for software engineers, as we know them today, is that they won't be as bothered by more business-focused domains. No longer is the software engineer subject to poorly scoped requirements within their Jira tickets. No! They, then technical business specialists, will deal with that problem now. Architecture and advanced algorithmic work will become the norm for most technically inclined engineers. The era of an underequipped frontend engineer requiring a ticket to "change a button color," as was seen in the late 2010s, is gone.

Software engineers will have to decide to move up or down the skill stack based on their core competencies.

Team compositions will change with the rise of the technical analyst. Let's assume we have the following software Team today:

What happens to this team as the barrier to entry for small programming tasks drops? Product Managers, UX designers, or Analysts can work on simple APIs, small microservices, and minor design changes. A typical "2-pizza team" will adjust to look something more like the following:

Most importantly, Product Managers and UX designers will stick around, to the chagrin of some engineers. However, their scope of work will expand to small engineering tasks. We also introduce an Analyst who will be more technically inclined than the PM or UX designer but not as much as a senior engineer. They'll be primarily business or product-focused but able to speak the lingo of Senior Engineers. Building small microservices to support the Product or implementing analytics on the client will be delegated as most of these tasks aren't particularly difficult.

I have also jettisoned levels for the engineers. Moving forward, you will want individuals who can edit, think, and architect code at just one level deeper than a junior today. The most crucial point is that engineers must be in-depth experts on computing principles, not React or NestJS merchants. The simple task of adding a NestJS method will be delegated to the analyst or project manager.

QA will be mostly automated, along with manual testing of the Product. DevOps also falls out of the picture when AI tools are integrated into the cloud or CI/CD pipelines.

The last effect is the intense competition that will spring about for developing software. Given how quickly software will be built, there will be no moats in design or tech stacks. Designs will be reproducible. CRUD logic will be easy to copy. That means a range of small applications fighting for the same user base will be devalued to $0. Business propositions, network effects, and sales functions become more critical to creating something worth investing meaningful capital into. Those who choose not to build out some of these functions will likely copy the Microsoft model due to the speed increases and the desire to create an "ecosystem" of interconnected products.

Microsoft has not been an innovator in its software suite over the past few decades, copying new popular SaaS products and incorporating them into its ongoing offerings. Small SaaS companies will do the same to generate lock-in to a specific product. From a VC perspective, you can already see this taking place with Bending Spoons, which is acquiring disparate small SaaS businesses and slowly pulling them together. Another example is that Notion has begun building out a "Microsoft"-esque suite with forms, note-taking, databases, and email.

We stand on the edge of a new era in software development. AI is coming to blow down the barriers of accidental complexity, similar to Fortran, reducing software to its essential complexity: data structures and algorithms. Without accidental complexity, more and more people will develop incredible new apps on the inevitable road to the first single-person billion-dollar company. Or the change will be as simple as creating small applications to be shared amongst family and friends.

All actors in this space will need to maintain fluidity with the continuous changes each day or even every hour based on the flurry of announcements. Competition will increase. Team structures are going to change. Although it feels that we have stagnated as a culture, this will bring along changes that are hard to predict.

The stability that once characterized the tech industry is fading. A bastion of stability and easy money through the 2010s and early 2020s will no longer stand; the essence of creative destruction in capitalism will not allow anyone to rest on their laurels. Who will adapt to these changing circumstances?