Is AI a Silver Bullet?

Like previous attempts to find a silver bullet such as 4GLs, it does not seem likely that LLMs as a software authoring tool will be succeed. In particular, like 4GLs they suffer from the problem that because software spends most of its life in maintenance, the cost of change makes most improvements to the cost to author irrelevant; in fact, some rapid authoring techniques make maintenance harder and increase the lifetime cost of software.

Source:?Is AI a Silver Bullet? — Ian Cooper – Staccato Signals

The term ‘silver bullet’ might be familiar to you. Legendarily the way to kill vampires, it was coined in this context by Fred Brooks, author of the?Mythical Man Month?(a foundational text in software engineering.)

Brooks observed in 1986

there is no single development, in either technology or management technique, which by itself promises even one?order of magnitude?[tenfold] improvement within a decade in productivity, in reliability, in simplicity

No Silver Bullet—Essence and Accident in Software Engineering

For the last couple of years, give or take, we’ve been barely able to move without talk of “AI”. Our conferences too have featured numerous (I hope judicious, well chosen, hype minimising and valuable) talks on the topic. AI as I have remarked before is what really drew me toward computer science, around the time Brooks was writing No Silver Bullet.

For now leave aside the question of the broader impact of these technologies (important conversations to be sure), and focus on their impact on what a lot of our audience does–software development. Anecdotally, many developers are finding the use of these technologies beneficial (I certainly do, as I’ve observed more than once).?Amazon recently reported very significant cost and time savings?in upgrading Java applications from older versions of Java. Folks I respect and trust like?Simon Willison?(co-originator of Django, co-founder of Lanyrd) speak in very positive terms of the benefits even someone as deeply experienced as they are has gained from the use of these technologies.

I don’t think they can simply be dismissed when it comes to their use in software development. But I do think we’re only beginning to understand how to work with them, and the impact they will have on our profession and the practice of writing software. And the quality of what we produce.

Recently others have clearly been thinking in similar terms. Ian Cooper, who we opened with, is not optimistic. And let’s face it he’s drawing on over half a century of lessons from software engineering. He begins by observing

When it comes to LLMs as a developer tool or replacement of software developers, popular opinion seem predicts one of three main outcomes to the current boom:

AI Developers: Under this model, software developers no longer need to write code. Instead that task is now done by an AI coder. Subject matter experts interact with an AI that does all the work of writing the code.

AI Assistant: Under this model, software developers get assistance from common or repetitive tasks from an AI assistant. This increases their productivity; by how much becomes the concern. Does this reduce developer headcount?

AI Winter: Under this scenario, the LLM revolution fails to deliver the advertised gains, and may even lower productivity because in the longer run it gets in the way as companies who outsourced their code to an AI are forced to do so much remedial work it would have been less expensive to hire a software engineer write high quality code.

My instinct is we’ll see the second of these possibilities at least in the short to medium term. It’s certainly been my experience and that of folks like Simon Willison, and the reports from Amazon.

In which case Cooper asks

This increases their productivity; by how much becomes the concern. Does this reduce developer headcount?

An important question. But perhaps we should be thinking more deeply still. A few weeks back Steve Yegge (an extraordinarily experienced and respected software engineer) pondered what impact these technologies might be having on junior developers (and juniors is many professions, such as law).

As someone once observed, we get good at things by doing the thing. 10,000 hours is a number that is tossed around. We get mid level and senior developers because they were juniors who wrote code, and learned over time–from their seniors and peers, from their own efforts and mistakes.

But if generative AI largely obviates the need for juniors, if we’re making more experienced developers much more productive, taking the sort of repetitive grunt work off their plates like upgrading from Java 8 to 17, as in the case at Amazon, what place is there for juniors? And if we have fewer juniors now, where will our mid level and senior developers come from in 3, 5, 7 years?

In response, Forrest Brazeal begins by summarising Yegge’s post

We still need developers, says Steve, but they’ve got to be experienced enough to keep the AI code-generators honest and on track. Juniors simply can’t keep up.

But he goes quite a bit further

Now, since we’re being precise with our words… I actually think Steve doesn’t go far enough in calling out the death of the junior developer. I think that AI has killed, or is about to kill, pretty much every single modifier we want to put in front of the word “developer.”

Forrest continues

For awhile I thought the only useful modifier AI has left us with is “fullstack”. For years now we’ve all been complaining about these “fullstack developer” job postings that seem to demand half a dozen skillsets in one: front end, back end, cloud, data, DevOps…?

Very plausible. But I’m not so sure. In my experience with these technologies, they can do things on average very well. They’ve learned from say 15 years of front end development. So when you ask them to create a web based layout, they’re far more likely to use an approach like floats then flexbox–until you expressly ask them to. Well trodden paths like upgrading from Java 8 to 17–they do such things well.

But, expertise really does matter. Knowledge matters. And as we’ve seen over the last decade with an increasing obsession with the fullstack developer, in depth knowledge suffers when we’re expected to know a vast array of things across many domains. Poorly performant, inaccessible, hard to maintain front ends abound.

In other fields experts specialise. Lawyers specialise. Doctors specialise, engineers specialise. It’s curious in our field unlike so many others we expect such breadth of knowledge, often trivialising aspects of that knowledge, despite their importance.

AI used poorly will lower the overall standard of software engineering, allowing us to spread ourselves ever thinner. AI in service of cost reduction and productivity in the short term will see more average code produced, more quickly–code that is less well understood, less robust, less performant, less secure.

It doesn’t have to be like this, but it will be, unless we as individuals and as a profession push back against their use in this way. And learn how to use these technologies in ways that help us create better code, build better products. Use them like power drills, not 3D printers.

In the short term productivity above all else is powerfully attractive–we build incentive structures for managers and companies around it. Investors love a sweet round of job cutsproductivity improvements.

In the long term place productivity above all else gives us the 737 MAX.

To me the single great challenge facing software engineering right now is addressing this issue.