Are LLMs the Silver Bullet?

In No Silver Bullet, Fred Brooks makes the claim that no technology will come about that will solve the essential problem of software engineering. The essential problem in software is getting specification, design and testing of the conceptual construct right. The conceptual construct is the combination of requirements, data model, and separation of concerns. And it is so difficult to get right because you have to keep getting it right. The requirements keep changing. The data model keeps evolving. The interfaces keep growing.

Can Github Copilot make this all easier? I don’t think so. I’ve been using it regularly for about 6 months. It is great for helping me write code when I know what I want to write. It can even help me come up with algorithms if I describe the problem. However, a lot of my job is figuring out what problem to solve. For example, lets say I pick up a ticket whose acceptance criteria is

“Make sure all clients of the API keep receiving the magic string with the . in the middle even though we are transitioning magic strings in our codebase to use _ in the middle. When we update the clients to expect the _ we wont need this anymore”.

What’s the problem to solve? There’s finding all the places in our codebase where we respond to API requests with the magic string. A project wide search can help you solve that. There’s deciding where in the process of preparing the response do you transform the strings . Do you do it at the last possible moment? Do you do it sometime before? How do you implement this? What’s the implication of one option vs the other? Is there a pattern in the codebase already that you can follow? Are you going to have to create a new pattern? Does it matter that this new pattern is exemplary so that if others see it they copy the pattern or can it be a hacky workaround? Are you on a team with people experienced enough to tell the difference between a hack and good code? How long will this transition take? How does the amount of time you expect the transition to take affect how you implement your solution?

After years of programming I can usually answer all these questions and more in a couple minutes to a couple hours. It depends on how long I’ve been on a team and how familiar I am with the codebase. All of the questions asked above are about separation of concerns. How can I make this change so that it is easy to remove when it’s no longer needed? Part of the answer is technical and part of it is social. It’s not just about what will work, but what will work on this team.

The insight that Brooks had in 1986 still holds up today.

In short, the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product.

So far, I don’t think LLMs can deal with the essential complexity of making software.