How developers can keep their jobs (2)
Well-known people in the software industry have made the warning about the drying-up talent pipeline mainstream. Agreeing is comfortable. So the second part of this series takes the other side seriously instead.
Software architecture
Here are links to the posts in this series:
- Part 1: What companies are betting on with AI
- Part 2: What the optimists say and what I make of it
- Part 3: My recommendations for you as a developer, and for you as a leader
Apparently I'm not the only one who sees the problem: people's coding muscle will weaken the less they use it. The "HR pipeline" will stop turning juniors into seniors if companies stick with the idea of not hiring juniors any more.
Two years ago, Charity Majors, co-founder and CTO of honeycomb.io, pointed to the same trap in her essay on the Stack Overflow blog. So I could just feel vindicated and enjoy it, right? But that would be too easy.
The optimists' argument
Simon Willison argues that shipping worse code with agents is a choice, and that refactoring is an ideal task for agents.
Simon isn't just anybody: he co-created the Django web framework. He also coined the term prompt injection. He's an advocate of agentic coding, but with a critical eye.
Like me, Simon draws a sharp line between two things: vibe coding, where you no longer check the code, and responsible AI-assisted development. (Sadly, many people now use the name "vibe coding" for the latter too, which waters the term down.)
Charlie Graham, a founder, is even more optimistic and goes further still: debt that today's model misses, the next one finds, so it only lasts a few months.
Technical debt used to be something that piled up and quickly outgrew people's capacity to refactor. Simon and Charlie say that AI has changed this. If they're right, the crisis I'm predicting simply won't come.
How far the optimists are right
Duplication, overlong functions, missing tests and inconsistent naming are local problems. Models can fix them well today and are getting better at it. I concede this point: my original hypothesis was too broad.
Models are good at tasks like these:
1. Merging duplicated code. A model notices the same validation logic, slightly varied, in five controllers and pulls it into a shared function. You can check the change file by file, because the behaviour is meant to stay the same and existing tests prove it.
2. Breaking up overlong functions. A 300-line method is split into named steps, such as checking the input, calculating and saving. For that the model only needs to understand this one function and its direct callers, not the whole system.
3. Adding missing tests. For an existing function, a model writes unit tests that cover the normal case, edge values and error cases. That works well, because the expected behaviour can be read from the code itself, and running the tests shows right away whether they're right.
4. Making naming and style consistent. When the same thing is called "customer" in one place, "client" in another and "user" in a third, a model renames it consistently across the whole project. That's tedious grunt work across many files, but it needs no design decision, and mistakes show up right away in the compiler or linter.
What all four examples have in common: the information needed is in the code, and the result can be checked automatically.
My argument is more about architecture: structures that are fundamental and need a lot of experience, overview and judgement, sometimes even taste. You can't work those out from one local spot in the code.
Charlie Graham admits that most technical debt isn't about architecture:
But most technical debt is not architecture. It is imperfect implementation around an unproven idea. The slightly wrong abstraction. The feature built before anyone knew if users wanted it. The elegant system designed for a scale that never arrived.
But he assumes models could solve this too, as early as 2027.
I disagree. A broken architecture isn't a messy file. It's a wrong decision. The information you need to correct it (upcoming requirements, real constraints, design and evolution principles) simply isn't in the code. So an experienced human has to tell the AI, or it can't know.
My hypothesis, now revised
The optimists forced me to sharpen my hypothesis, and I'm grateful to them for that. On one point they're right: models already clean up duplicated code, overlong functions and missing tests today, and they're getting better at it. Anyone expecting the big crisis here will wait in vain.
So my hypothesis now reads: Better models will clear up the local mess. But for now they won't decide what the system should become. The reason is missing information. Which requirements will come next year, which constraints are real and which just grew over time, what the business can bear during a rebuild, and so on: none of that is in the code.
That decision needs someone with judgement who understands the architecture and has mastered the tools. The model carries out the rebuild. A human has to answer for where it's heading.
The shrinking supply
If that's true, the most valuable engineers of the next decade are exactly the ones companies have just stopped training. In the next part: who wins, where I might be wrong, and what developers and companies should watch out for.