The End of Software Engineering?
A nuanced take on agentic programming - examining both sides of the debate about AI coding tools and what it means for the future of software development.
If you’ve been on LinkedIn or X lately, you’ve likely seen the AI programming wars unfold on your feed.
One side declares it’s all slop, that it’s a junior programmer at best and a recipe for the destruction of your code base at worst. If you're using these tools, you must be a bad developer and nothing you produce can ever be trusted.
The other side proclaims that software engineering as a profession will disappear within two years, that we're all cooked and if you don't have your unicorn idea now, you're done.
Both sides have valid and flawed perspectives. As a user of these tools and an experienced engineer, I’ll present arguments for each side, share nuanced opinions and predictions for the future.
It’s not 2024 anymore.
Many of the folks who espouse the flaws of LLM programming are not using modern tools. Using Claude/OpenCode with Opus 4.5 is nothing like pasting a snippet into ChatGPT 3 and asking it to finish off your function. Given a well-constructed Claude.md and properly articulated skill crafting, agentic systems are a powerful steroid for a seasoned developer. What could be achieved in 3 days a few years ago now takes 3 hours.
The following statement might offend some people, so here's your warning - 95% of software engineering is CRUD apps. There are interesting architectural decisions to be made, data design, code base construction for future extensibility, trade-offs, and caveats. But a bank’s core is still a double-entry bookkeeping system with some database locking. An online shop with a million users is still just putting a series of records in a database to represent an order. With a technical mind behind the keyboard, Claude, Codex, and Gemini are more than capable of crafting these systems.
The train has already left the station.
Agentic programming, in its current form or wherever it evolves to, is going to become the de facto standard of operation for software engineering within the next few years. The increase in production velocity is going to be too great to deny - and we’re still at the relatively early stages of tooling development. What was an acceptable, achievable pace by a senior engineer 4 years ago simply isn’t going to cut it anymore. We accepted the increase in speed with better IDEs, CI/CD pipelines, one-tap cloud deployments, etc. This is no different.
If you haven’t touched Claude Code/OpenCode/Amp/Cursor - have a play with them. If you’ve already had a go but haven’t gone beyond the surface, have a look at Claude Skills, OpenCode Agents, and MCP. Understand how these tools can boost your productivity, whilst not sacrificing quality. Be open in your communication about their use. It’s not something to be ashamed of, it’s another skill to have on your tool belt - and soon enough, it will be part of the accepted core skillset.
The bottleneck isn’t coding speed.
So far, I've advocated for what's good in these tools, their potential for productivity gains.
However.
In pretty much every project I’ve ever contributed to or led, the speed of programming has not been what delayed a release. What delayed a release was:
- Changing requirements
- “Wait, are we even building the right thing?”
- “Trends have changed, we must build the other thing.”
- “Steve’s on holiday, we’re not going to get the chance to do that user research until next week.”
- Quality gating
- Budgets
- Communication breakdown
- Slow release chains
I’m sure AI is going to help with all of these things as well - but they’re not going away overnight. And until we stop building products that are for humans, there’s always going to be some human friction in there.
A better metric is entropy reduction.
“Look how much code Claude wrote for me,” the midwit engineer proudly announces over their Sorcerer’s Apprentice empire of JavaScript.
Much like how coding speed is not a useful metric for the efficacy of a software engineer, nor is the number of lines of code. In fact, it is quite the opposite - an engineer who is able to reduce the entropy of a system, who can deliver a new feature whilst actually reducing the lines of code that we as engineers need to hold in our mental context, is far more revered.
When prompting this tooling to implement a feature, it has never said “actually, whilst I do this, i’m going to restructure and add a builder pattern here, and where you’re sending the same message to 5 different queues is very inefficient, i’m going to introduce an eventbus so we don’t need to do that”. Would you even want that in all scenarios? There’s a whole side subject of economics around token consumption (should you be charged for it doing a thing you didn’t directly ask it to do, even if it’s the ‘right’ thing?). But that would warrant its own separate article entirely.
The REAL metric is features in users' hands.
The ability to churn out code more quickly says nothing to whether this is the right thing to be building in the first place. A language model is not going to say “no, I don’t think it’s a good idea to build this feature” because, despite the nomenclature of this suite of tooling, they don’t have agency. Humans do. A good human engineer who knows your product inside and out will tell you when you’re building the wrong thing and will suggest alternatives. Better features will land in the hands of users, and that is ultimately the end goal.
Project managers aren’t going to become software engineers.
I’m going to let you in on a little secret. I’ve been generating loads of code at work for YEARS. Here’s one of the secret tools I’ve been using to speed up my workflow at Fatsoma (shhh, don’t tell my boss).
The skills of a software engineer are not simply putting code into GitHub. There’s:
- Database design
- Data architecture
- Failure states
- Resiliency
- Communication
- Stakeholder management
And hundreds of other skills. Sure, I can get Claude to do an analysis of my repo, maybe all of my repos together, if that fits within a few context windows. But what it will output will still be done in technical language - and if you tell it to output in layman’s terms, much of the nuance of how the system works will be lost. To say that a non-technical driver of this technology could end up at a similar destination is to say that you don’t need to understand how your product is built to trust your product.
Would you be willing to ship a pacemaker that a family member used if you didn’t know how it worked? How about a train's braking system? Would you allow users of your e-commerce platform to input their GDPR protected details and payment information into your systems?
There is one thing we ultimately hire professionals for:
Trust.
Individual proven track records that they do what they say they can do. Consistently. Over extended periods of time, in multiple domains and scenarios.
And if the recent tldraw, curl, and zig controversies are anything to go by, we’re a long way from non-technical folks whispering a few prompts into the AI tool of the day and producing quality software.
You can only learn by doing.
I would not be the engineer I am today if I had not learned under the mentors I have had throughout my career. Supportive leaders who allow mistakes, turning them into teachable moments. Having them direct the path and show the right way to do things.
There is no silver bullet for learning programming. You have to get in there, bare bones, do it wrong, and work it out yourself until those neural pathways are second nature. Those pathways do not get developed by reviewing code. I challenge anyone to open up the Kubernetes repo, read it, and then understand how a container orchestration system works. Even if you were to read it commit by commit, having the author explain it to you in detail, it still wouldn’t stick anywhere near the same way as doing it does.
This comes into conflict with economics. Are companies going to mandate that junior engineers not use AI assistants to do their engineering? Of course they’re not - what ultimately matters is the bottom line - and doing things at a comparatively slow pace to facilitate learning isn’t going to fly in the world we’re heading towards. But that’s where those tools are sharpened, and the real learning is done. You walk early so you can fly later.
I don’t have a solution for this - but I do have a prediction.
The barrier to entry for a “junior” position is going to be much greater. No longer will you be able to breeze in with a take-home test of “reverse this string”. The new junior engineer will need to be able to show they can use the agentic tooling of the day, whilst also having an understanding of everything it is producing. Previously, a portfolio really made you stand out. In the future, it’s going to be mandatory, and you'd better have the receipts to prove your knowledge.
Software engineering isn’t over, but it’s changing.
Ultimately, the majority of the core skills that make a good, trustworthy software engineer aren’t going anywhere any time soon.
Unfortunately, I do think headcounts will shrink initially. It will take fewer software engineers to hit a maintainable velocity. As other bottlenecks get reduced and the potential velocity increases, we will then see another increase in the number of “technology professionals” in whatever form that takes in the future.
What can you do in the meantime? The same thing the best software engineers were doing five, ten, twenty years ago.
Embrace new technologies. Master them.
Utilise your skill set to be of most value to whom you want to be most valuable to.
And if I'm wrong and all knowledge work gets reduced down to unmonitored LLM prompting by the select elite - then I look forward to our battle in the Thunderdome.