Trends

What is being automated

LLMs have fundamentally changed the job of a software engineer. They have solved the manual task of writing code, but there is more to software engineering than writing code. If we group a software engineer's job into five broad categories, roughly in the order software gets delivered (Discovery, Design, Implementation, Delivery, and Maintenance), we can see that automation has happened in the latter three, essentially wherever code is written or managed:

• Writing code: done; ever-increasing capability.
• Reviewing code: starting to happen, with low-risk changes approved without a human.
• Deploying code: mostly automated before LLMs, and it is now trivial for an agent to monitor a release pipeline.
• Routine maintenance: also starting to happen, with small refactors and well-understood alerts.

The trend of automating this work will continue, because it's cheaper and faster for the business, unless LLMs become too expensive or degrade in quality.

What will slow automation?

As things stand today, automated agents are effective where codebases are smaller and newer. Generally I think this means start-ups will have codebases which suit agents, whereas large, well-established businesses will have accumulated technical debt, varying standards, and inconsistencies.

There are at least two technical areas that slow down agents currently:

• Scale: I think the difficulty comes with anything at scale. If you want to build something complicated which involves high uptime across multiple services, databases, UIs, and CDNs, then it is hard to currently imagine a world where there is not an engineer involved. Someone in a non-technical role could ask an agent to design changes to a multi-service codebase, but could they validate the changes?

• Legacy code: LLMs are prone to unnecessary output. Engineers will be familiar with them writing too many comments in code, and even including context from their sessions in those comments, which makes no sense out of context. LLMs are also prone to copying the style and form of the codebase they are writing in. These two tendencies mean that agents left to implement code in existing codebases are unlikely to improve them, and by default they really make them worse by increasing their imperfections.

Directed, though, agents are good at migrations, especially internal ones where client-facing behaviour doesn't change. Writing code, and therefore paying down technical debt, is now cheap, which lets older businesses gradually reshape their codebases into something more suited for agents.

There are business reasons that slow automation too. In the extreme, if millions of clients rely on your API contract, you can only move as fast as the slowest one. And if they gain nothing from the change, you have to ask whether it's worth doing at all.

Not every company cares about software as a primary priority. Some companies obviously have physical products, where software is a means to an end and the product itself is their moat. They will only care about optimising their software delivery pipeline as the tooling becomes mature and the cost-saving benefit is obvious enough.

Conclusion

From my personal experience, my conclusion is that for software engineers, the job as we know it is gone. And companies without a physical moat will have to improve their codebases for agent suitability or risk being outmanoeuvred by their competitors.

In the short term I think there will be a slow tail-off of software engineering jobs as we know them, as companies start to make efficiency gains. The job will probably shift towards a more specific skill set: those who have good judgement, can understand the domain, and architect the software.