Be a Luddite

Successful organizations know that developer experience is an essential factor when AIs write code, and structure their teams accordingly.

“Luddite!”

It’s a word we fling at people who resist technical change. It’s pejorative; technical change is inevitable, and luddites are always going to lose. Most of us probably even know the origin of the word—the Luddites were a group of workers in the north of England who went around destroying knitting machines which were taking their jobs.

Then I read an article in the Smithsonian magazine which changed the way I viewed the movement.

The article argues that the Luddites were not against technology. Instead, they were against the way it was introduced. They wanted to be trained in its use; they wanted apprenticeships. They didn’t want to stop progress; they simply wanted to be integrated into the inevitable change.

AI is today’s knitting machine. It automates many things that previously required people. The jury is still out, but it is likely it can do much of it more cheaply.

I read predictions that AI is going to lead to mass unemployment. We’re already seen reports of large layoffs, particularly of more junior staff. For what it’s worth, I believe that those layoffs were a ridiculously short-sighted move that will come to haunt the companies that made them.

Mechanical knitting machines needn’t replace people; if you train people to use them it increases those people’s productivity and effectiveness. Similarly, blinding firing people and replacing them with AI will never be as effective as investing in bringing the two together.

There’s one obvious problem with the strategy, and three others that are less obvious and less clear cut.

Mommy, Where Do Developers Come From?

The first issue is obvious: by firing your junior devs, you’re effectively eating your seed corn. Senior developers—the ones you want to keep—are just junior developers who’ve learned a bunch of lessons. With no pipeline, you’re going to have to go to the market to find new seniors. And, guess what, they won’t come cheap.

A process that trains juniors on the job not only gives you a supply of seniors who are known quantities; it also gives you a pool of employees who know your business.

Risky Math

I don’t know the ratio of junior to senior developers: 3:1, 5:1? Whatever it is, companies who shed their juniors are assuming that a senior augmented with an AI will out-perform the same senior plus n juniors.

If you believe the 10× hype, then the math seems easy.

The reality, though, is that it depends what the 10× is measuring (assuming it’s even true).

If you’re measuring lines of code, or the modern analog, pull requests, then I guess the number could be justified. AI’s seem to like nothing more than writing code, code, and more code. A throwaway command line utility that converts a CSV file into SQL insert statements can easily end up with 200 lines of argument parsing; code that you don’t need or use. And that’s the tip of the iceberg. I regularly see PRs come through with tens of thousands of lines of code; the actual change they’re effecting would take a good developer less than a thousand.

If instead you measure business value delivered, that 10× starts to look ridiculous. I’ve seen teams deliver literally millions of lines of code only to have the business folks complain it is missing the basic functionality they asked for.

So canning your juniors on the basis that a senior + AI will outperform them might not make much sense.

The TCO Trap

Unlike most forms of manufacturing, the majority of the cost of making and owning code comes after delivery, when the code is maintained and updated. In the short term, AIs reduce these costs, too: they seem to work well when given a code base and told to “fix this” or “change that.”

Here’s the thing: AIs don’t know your code. They may have created it, but when they come back to it after a month, they basically treat it as something foreign they have to investigate to understand. Sure, they can keep notes from the previous time, but these typically act as signposts: a full explanation of the code would likely be as long as the code itself.

Current AIs are effective at creating code that works, but at the cost of producing a lot of code. And the more code there is, the more of an AI’s attention it takes to understand it. No AI is currently capable of keeping even a medium sized application all in context.

This means that as time goes on, the code will become larger and larger, and the AIs will become increasingly less effective at maintaining it. Although the cost of initial production might seem attractive, I worry that the overall cost of ownership will start to skyrocket.

You’re trading a short-term gain for a long term liability.

The Human Factor

Real progress doesn’t come from stitching together stuff from the past. Instead it comes from crazy ideas and mistakes that turned out to be beneficial.

We people are really good at being crazy and making mistakes. We’re constantly exploring the edge. Three year olds and junior developers both have the same superpower: they constantly ask “why?”. They force us to reexamine our understanding and justify our assumptions. If AI takes over the so-called junior work, we’ll lose that, and I fear that innovation will suffer.

What’s To Be Done?

I don’t know, but I have some strong opinions.

First, if you’re a developer, I suggest you refine your thinking about AI. If you fall into the “AI is the work of the devil, and I’m never using it” camp, then now’d be a good time to rethink things. Alternatively, if you’re in the “my loop ran for 36 hours and produced 2 million lines of working code” school, then I’d ask you to come back to reality.

AIs make writing code easier and faster. They enable you to realize ideas quickly, write and discard prototypes in minutes, and are possibly the world’s best pair programmer. If you don’t use them, you’re going to be out of a job.

On the other hand, if you have ceded all your development to an AI that you guide, I worry that you’re also heading for a crash. Your role with AI is not to give it a goal and then get on with something else; that’s exactly why Big Design Up Front never really worked. Code isn’t written from a spec, it evolves as we learn stuff along the way.

And For Companies?

AI is a tool that will help you get somewhere faster. You can write good systems faster, and you can write bad ones faster still.

The difference between the two outcomes currently comes down to the informed curation of skilled people, guiding and monitoring the progress made by the AI. In that way, AI is not much different that any other technical advance.

Your developers are not a cost center. They cannot (yet) be replaced by machines, but their productivity and reach can be enhanced by AI. The chances are that they are the source of your ability to innovate. And, if there was ever a time when you need to be able to innovate, well….

The trick is to train them. You need a solid policy that recognizes that the systems produced by AI have exactly the same constraints as those produced by humans. All the principles of good development we’ve learned over the years still hold. Teach your people how to apply them using this new, miraculous tool.

It shouldn’t be about cutting costs. It’s about increasing value.