Software Development: The People Building AI Are Exposed Too
Software development is where the argument is loudest, and where the association has a particular interest: its professionals are simultaneously among the most exposed to replacement and the ones building the systems doing the replacing. Nobody is better placed to decide where this technology points. Nobody has more to lose if it points the wrong way.
The real threat is not the one being discussed
Public debate fixates on whether AI will write better code than a developer. That is the wrong question.
Code generation works well on bounded tasks with limited context: boilerplate, conventional tests, translation between languages, first-pass documentation. That is already true and it is not reversing.
What it does not solve — and is nowhere near solving — is everything else. Understanding why the business needs this and not that. Choosing an architecture that survives five years. Diagnosing an intermittent production failure on incomplete data. And answering for the consequences when something goes wrong.
The problem almost nobody is watching
There is a second-order effect that worries the association more than direct replacement, and it is happening now: entry-level roles are disappearing.
The tasks a junior developer traditionally handled are precisely the ones a generative system covers best today. The immediate consequence looks like a saving. The ten-year consequence is that there will be no senior developers, because nobody becomes one without spending years doing the work that is now being automated.
It is a clean example of a decision that is rational for a single company and destructive for the sector. And it is exactly the kind of problem no organisation solves alone — which is the argument for an association existing at all.
The deferred cost of cutting entry-level roles
| Decision | Immediate effect | Effect in ten years |
|---|---|---|
| Automate junior tasks | Visible headcount saving | Nobody has walked the path to senior |
| Stop hiring at entry level | Less supervision to fund | No internal pipeline, and none on the market either |
| Give juniors assisted work with a net | Roughly the cost of hiring them | Professionals trained sooner, on real systems |
What augmentation looks like here
The well-aimed version of this technology is not the one that writes the code instead of the engineer. It is the one that extends their reach beyond what they can hold in their head.
A system that understands a whole repository and warns that a change will hit a module nobody remembers. That spots a modification reintroducing a bug fixed three years ago. That reconstructs the reasoning behind a decision made by someone who has since left. That reviews exhaustively for known risk patterns.
That system does not replace the engineer. It makes them capable of holding larger systems than they can hold today. And crucially, it lets an inexperienced developer work with a safety net — which is exactly what has to exist if the pipeline is not going to dry up.
What industry teaches here
Industry has spent decades on an equivalent problem: how to get an operator with two years of experience performing like one with twenty, without waiting eighteen years.
The answer that worked was not to remove the junior operator. It was to give them systems that make explicit the knowledge the veteran carried implicitly. The result is that the newcomer learns faster by doing the work, rather than never getting to do it.
Applied to software, the conclusion is uncomfortable for a lot of engineering leadership: cutting junior roles because the machine does their work is the decision that guarantees you have no seniors a decade from now.
What we are looking for in this sector
We need software engineers willing to work on two fronts:
- As builders: designing assistance aimed at augmenting rather than replacing, in their own
field and in others. They are the ones who can.
- As exposed professionals: describing honestly which part of their work is execution and
which is judgement, and what happens to a professional's development when you remove the work they learn from.
It is the profile that contributes most here, because it can think about the problem from both sides at once.
If you build software, join the association. You are both the person who can build the alternative and the person who needs it.