'AI' Software Crisis: Software Developers have been promoted into incompetence
Developers have been promoted into incompetence
With the age of “AI” and agents, software developers have been promoted into incompetence.
And it all comes down to comedy and satire.
Sort of.
That probably requires some explanation.
If you’re actually working in an industry – any industry – reading about management theory is often indistinguishable from reading comedy.
Not just because the reality of how you experience “management” is frequently absurd or grotesque, which the theories often fail to address, but also because the alternative to laughing at the mess, is to cry and despair.
When we – as people working in a deeply flawed industry – read about management theory and practice, most of us won’t recognise any of the “good” practices, but we will be intimately familiar with all the “bad” practices. We could even probably list a few more “bad” examples so awful that they have hitherto been unknown to science or sanity.
We’ve all had bad managers. Sometimes we’ve even been the bad manager.
Occasionally you do get a management book that leans into the inherent comedy of the farce that is the reality of the modern corporation.
Like the book Management of the Absurd by Richard Farson. It doesn’t take itself seriously, has a few useful pointers, and is appropriately mocking at times.
But comedy has also made genuine contributions to both the theory and practice of management.
One of those being The Peter Principle, which has its origin in a satirical book of the same name.
The principle it describes is that people tend to rise through organisations through promotions until they reach a level of respective incompetence.
What it means it that you or I might work, say at coding, at an organisation, and we get good at our entry-level job. Our skills get noticed so we get a promotion that involves more important coding. Same skills, just better and more important. It builds on our skills, which is recognised, so we continue to rise through promotion.
Until, that is, we get promoted to a manager position that doesn’t involve coding. This position instead involves a bunch of skills we haven’t practiced at all.
At this point, it’s entirely possible that we might be worse at the managerial job than we were in the entry-level job where we started.
And because we are now incompetent, we no longer get promotions. We’re stuck. Our career has reached a dead-end because we’ve been promoted into incompetence. We’ve become bad at our jobs through no fault of our own.
Why software industry career ladders have been different
This has especially been a problem for software companies. The job of a software developer has traditionally been very different from that of a manager.
- Coding lends itself to a singular focus during each task. Management requires juggling tasks.
- That singular focus means coding is very light on the kind of monitoring work that can be a big part of management.
- Coding lends itself to unambiguous communication that deliberately strips nuance and ambiguity away. You mean just what you say and nothing else. Management communication is almost entirely nuance and ambiguity.
- Management is all about coordinating unruly “processes” to make sure the work they do is delivering value to the organisation. Busywork of no value is worse than idleness because idleness actually reduces delays and shortens task queues. You can’t react quickly to an unexpected need, if you’re occupied with busywork. But you can react immediately if you’re idle.
Management is all about maintaining a constant vigilance towards the bigger picture: the queues, the delays, where value is being created and destroyed, avoiding both over- and under-optimisation, and coordinating things that are unruly and chaotic.
And, normally, somebody who manages coders rarely codes themselves.
The two jobs are very different. Promoting a coder into a manager frequently means the company is losing a good coder and gaining a bad manager.
The consequences of gaining a bad manager are also quite different from what many imagine. The result of bad management isn’t that work won’t get done, it’s that the wrong work gets done – that everybody is running around, overworked and busy, but none of what gets done has any meaningful value to the company.
Busywork.
This is why many software companies have historically had a separate career ladder that doesn’t involve management. That way the company can give a talented software engineer a respectable career trajectory without losing access to their valuable skills.
“AI” and the changes it has brought to software, have together thrown all of that out the window.
The “agentic” decline
With “AI”, the software development job involves:
- Constant monitoring of unruly and chaotic “agents”.
- That are coordinated using ambiguous and nuanced language that never seems to be completely “understood” by any of the participants.
- Constant juggling of a variety of tasks.
- And it no longer involves focused work but instead requires outlining, commanding, and specifying.
And, despite managing a lot of code, developers now rarely seem to code themselves.
Software developers is a field so universally recognised as being poor managers that many of the stiffest and most conservative organisations on the planet gave up and just gave them their own career ladder. And we, as a field, have all at once been promoted into management without any preparation or training.
Because the processes a developer is managing are nondeterministic and chaotic – more so than any human – this new management job is in many ways harder than that of a regular manager.
We’ve taken an entire industry that was so-so at its job – at best – and pushed it into outright incompetence.
The result is very similar to what happens when you have a bad manager.
- Busywork increases.
- Nobody has any visibility into where value is being created or destroyed.
- Pressure and stress increase because of the added uncertainty.
- More busywork means less slack in the organisation.
- This actually increases delays, lengthens task queues, and magnifies costs.
- Communication becomes harder.
- Concrete and actionable information becomes scarce.
And nobody has any time left to spare, to figure out what it is they’re doing wrong. Nothing improves.
Because – remember – the consequences of bad management isn’t that nothing gets done but that there’s too much of the wrong work getting done.
That’s not the worst part.
The worst part is that even though this new job many of us have landed in is similar to management, it still isn’t actual management. It’s a new thing made up of some of the worst parts of the managerial job.
The worst part is that it’s automation, and that comes with a bunch of fairly insidious downsides.
Deskilling from automation
People have been studying the effects of automation for decades. One of the core ideas from that research is the paradox of automation.
Paradoxically, the human contribution tends to become more important the more reliable the automated part gets.
This means that better automation can lead to worse outcomes, because it shifts the work of the human from tasks they’re good at, to tasks they aren’t.
The 1983 paper that originally coined the paradox, Ironies of Automation by Lisanne Bainbridge covered a number of different “ironies” that each independently undermine the value of automation, but the irony that’s the most relevant to the software industry today has to do with the cognitive effects.
One of the concerns she raised all the way back in 1983 had to do with deskilling.
Quite a few of the skills we have are perishable. What that means is that once we stop practicing a skill, some of it begins to fade away. That’s why we talk about “being rusty” at something if we haven’t practiced in a while.
One of Lisanne Bainbridge’s observations was that cognitive skills that rely heavily on both memory and a coherent mental model of the job are more vulnerable to this decay than the skills that don’t.
Human memory relies on repetition and regularity and mental models need to be built and then maintained.
Once automation kicks in, that regularity, repetition, and maintenance disappears.
Memory and mental models are a major part of the programming skill set of a software developer.
It seems likely, to me at least, that the kind of automation presented by agents – where our existing triggers for reinforcing memory and building mental models now instead trigger external automated processes – will lead to the steady deskilling of the developers who rely on them.
This matters because many of the other parts of the new job that developers have – the monitoring and the reviewing, specifically – rely on us continuing to have those skills.
In addition to destroying value through busywork, poor coordination, delays, and longer queues, this new automation is also lowering quality in the long term by removing the skills we need to monitor that quality.
All this, while being charged by the token.
This should matter to us – the developers who are facing a changed industry – because this process is genuinely quite unpleasant to live through.
It takes away the enjoyment we had in the job. It adds stress. It increases the odds of burnout. All at a time when layoffs are still in fashion among the executive class and jobs are precarious.
There are a few things we can do about this. Not many and not all of them great. But we do have a couple of options.
What can you do?
The most sensible “AI for software development” strategy over the past four years has always been the same: wait and see.
This has been the most sensible strategy, in general, for software firms over the decades.
This industry has a tendency to adopt innovations too quickly and recklessly, before their flaws come to light. Much of it flames out in crappy products.
Then the same people who caused the problem make money again by fixing it.
It doesn’t matter whether it was NoSQL databases, GraphQL, or SOAP network protocols, it’s always been sensible to wait and see what the long term downside to a technology was before adopting. First mover advantage is non-existent when it comes to adopting new techniques or tools for making software.
So, the most sensible strategy is to wait and see. And the second most sensible one is to stop. Just pull back, regroup using regular software development approaches, and then wait and see.
If deskilling is really a thing, you’ll end up with an advantage over your competitors.
If agent-using developers really have been promoted into incompetence, you end up with an advantage.
If somebody discovers fixes to all of these downsides, you can adopt the fixed workflow without ever having experienced the downside yourself, and you end up with an advantage.
That obviously isn’t possible in an organisation that measures volume of work instead of the value of work. And it doesn’t help if your clients are organisations intent on shipping features instead of making good products or services.
In those cases, you need to find ways to maintain your skills and develop those new management-adjacent skills, if they are at all possible. And you need to do it at the same time as you’re working what is probably more than a full-time job.
This is obviously much harder than just doing the job as you’re told and letting both quality and your own skills degrade. And if your self-improvement is seen as taking time from your job of churning out slop, all you’ve accomplished is put your own job on the chopping block.
Good managers and executives with a focus on long-term growth wouldn’t put you in this spot.
So if this is happening to your workplace you already know that the people you’re working for are either themselves incompetent, or are letting their short-term greed harm the company they’re running.
A competent executive would not have created a system that promoted a big chunk of their workforce into incompetence.
This means that, if nothing else, you can take from all of this one hard fact:
Whatever happens next – to your employer, to the software, to the market – is not your fault.
That may not seem like a comforting thought today.
But there’s a good chance that thought might bring you some satisfaction – even joy – over the next two or three years, as events unfold in the industry.
Patreon
If you want to support my work and want me to make more of these videos, essays, and podcast episodes, the best thing to do is to become a member of my Patreon.
But I’m also trying to provide a service with my Patreon. With the state of social media and search as it is, keeping up can get quite difficult. There’s so much noise and so little signal.
One of my strengths, because of my background and training, is that I’m quite good at researching and reading, so one of the things I’m offering to Patreon members are regular updates where I recommend things to read, with context and commentary.
I post these reading updates every other day or so, and I’ve got plans for more member-exclusive features, some of which I think might even be a bit exciting, but I’m obviously quite biased.
I’m also open to suggestions, so send your suggestions my way, either on Bluesky or Mastodon, but I’ll try and monitor the comments on YouTube as well.
点赞
收藏
点踩
分享