It's Never Been About the Code

If you have any role in engineering right now, you would be forgiven for having a mild existential crisis.

Apparently AI has already taken your job. Or it's about to. Either way, you may as well pack up your laptop and go learn to be a plumber.

I couldn't be a plumber. I once tried taking a radiator off a wall and ended up calling an actual plumber at 9pm and paying emergency call-out rates because I was dangerously close to flooding my living room.

However, I do understand how you feel.

Eighteen months ago, models were completing your code, badly. Twelve months ago, they were building components, less badly, but still not particularly well. Six months ago, they could build functions, classes and tests, traverse a codebase, and make surprisingly intelligent decisions.

Today?

Combined with services like Supabase and Vercel, I built a fully event-driven system that integrates with APIs and booking systems, takes payments, sets up direct debits, runs recurring payment schedules, and sends email and SMS updates. I built it in a weekend.

Everything runs in sandboxes and test accounts, so I would never claim it is production ready. But the fact that someone who is time poor and has spent the last decade leading engineering teams rather than writing code every day can achieve that in a weekend says a lot about where these tools are heading.

If this is the path of travel over the last eighteen months, what do the next eighteen months look like?

I can understand why engineers are worried. I can understand why engineering leaders are worried. If we don't need engineers anymore, why would we need people to lead them?

The mistake is assuming that software engineering is the act of writing software.

It isn't.

Writing software is simply one mechanism by which engineers solve problems. We've become so accustomed to code being the bottleneck that we've confused the tool with the profession.

This wasn't just a weekend prototype held together with optimism and a README. It had row-level security, full unit test coverage, error handling, message queues with replay, observability and monitoring, autoscaling out of the box, PCI compliance, and more. The remarkable part wasn't that the models could generate code. It was how much of the surrounding engineering work they could help accelerate.

The thing about engineering, and what I hope this side project demonstrates, is that it's never been about the code.

Engineering has always been about solving problems with technology, whether that's software, mechanical systems, electronics, or something else entirely. That's the value engineers bring to an organisation. It always has been.

Writing the code was part of the process, but never the purpose.

The process remains remarkably familiar. You start with a problem. You design a solution. You build it. You test it. You adjust it when reality inevitably disagrees with your assumptions. Then you ship it.

What is changing is the balance of effort.

There is less emphasis on the act of building and more emphasis on understanding the problem, designing the system, evaluating trade-offs, and adjusting with consideration for the wider environment in which that system operates.

Engineering leadership follows the same pattern.

The problems leaders solve are rarely technical implementation problems. They are problems of organisational design and operation. They are questions of strategy, focus, alignment, incentives, communication, and risk.

If anything, those challenges become more important in a world where experiments are cheaper and velocity is higher. When anyone can build something quickly, deciding what should be built becomes more valuable. When delivery accelerates, poor decisions reach production faster. When barriers to creation disappear, judgement becomes the scarce resource.

Leaders need to think about how organisations are structured for continuous change. They need to help teams extract value from these new capabilities without burning out their people, destabilising their systems, or creating costs that only become visible months later.

None of that is new. The tools have changed. The speed has changed. The cost of experimentation has changed. But the fundamental challenge remains exactly what it has always been: understanding a problem well enough to design a solution that works in the real world.

For a while, writing code was the scarce skill. Increasingly, it won't be. Judgement will be.

The engineers and leaders who thrive won't be the ones who can type the fastest. They'll be the ones who can understand systems, navigate trade-offs, manage risk, and direct these new tools towards meaningful outcomes.

AI is automating implementation faster than it is automating judgement.

And that's why engineering still matters.