Why software development is changing for good

In 2003, I founded DCSL Software, which later became One Beyond. I exited in 2023 after taking the company international and growing it to more than 300 people. Since then, I’ve founded a robotics start-up and raised over £4M in seed funding.

I never expected to be writing production software again. I stopped coding day-to-day in 2014, not because I couldn’t do it, but because that’s what happens when a company scales. You hire people who are better than you at execution, you focus on leadership, and gradually the keyboard gets further away. For nearly a decade, that felt entirely natural.

What I didn’t expect was that, almost ten years later, I’d find myself back in the developer’s seat, not nostalgically but practically. Not dabbling but building a genuinely complex robotics platform. And not by relearning every framework or language that had passed me by, but by working in a fundamentally different way.

For me, that personal shift is the clearest signal that something structural has changed in software development.

How we used to design software, and why

When I started out, we were firmly in the waterfall era. That wasn’t ideology, it was economics. Software was slow and expensive to build, so the only sensible approach was to think very hard up front.

We wrote detailed specifications because we had to. Contracts depended on them. Delivery depended on them. Writing a good spec was a specialist skill, and one I happened to be reasonably good at. I could visualise what the finished product might look like before it existed, foresee areas of complexity, and describe behaviour with enough precision that a team could build against it.

That ability was rare, and difficult to teach. Many people struggled with it because imagining a complex system that doesn’t yet exist is genuinely hard. But it mattered, because getting things wrong late in the process was painful and expensive.

Over time, the industry moved towards Agile. Publicly, this was framed as a better way to respond to change. Quietly, it was also an acknowledgement that for large, long-running systems, no specification survives intact. Businesses change, users change, technology changes, and pretending otherwise often caused more harm than good.

Agile was pragmatic, but it came with a cost. We largely abandoned deep up-front design and replaced it with incremental discovery. That worked, but it also normalised a mindset where thinking too far ahead was seen as unnecessary or even risky.

What changed, and why I started building again

The reason I’ve been able to step back into hands-on development isn’t that I suddenly found the time or the desire to relearn a decade’s worth of tooling. It’s because AI has fundamentally changed the cost of experimentation.

This is the part that is often misunderstood. The real shift isn’t just that code is faster to write. It’s that trying things is now cheap, fast and largely reversible.

Things that would once have taken developer-weeks can now be attempted in minutes. You can explore an approach, see how it feels, discard it entirely, and try a different direction with very little penalty. That simply wasn’t possible before.

In the past, there was a strong emotional and financial attachment to code. If something took two developers three weeks to build, you were understandably reluctant to throw it away. Decisions hardened early, not always because they were right, but because reversing them was too costly.

That constraint has gone, and this is what pulled me back in. I can now operate at the level I’m strongest at, understanding the problem, shaping the system, spotting when complexity is creeping in, while AI handles much of the mechanics. I’m not writing code in the way I did in my twenties. I’m directing it, refining it, correcting it, and occasionally stopping it from going in entirely the wrong direction. In practice, this feels much closer to leading a team than writing code. You are effectively the boss, setting direction, reviewing output, spotting lazy shortcuts, and pushing back when something doesn’t feel right.

Why design still matters, more than ever

It would be easy to assume that this new freedom makes design less important. In reality, it makes it more important.

Having a clear, detailed idea of what you’re trying to build is still hugely valuable. In fact, it actively improves AI output. The clearer the intent, the better the results. Vague thinking simply produces vague systems more quickly. What’s important to understand is that AI behaves very much like a person. It wants to be helpful. It wants to give you an answer. If you’re vague, it will fill in the gaps. If you’re careless, it will make assumptions. If you don’t challenge it, it will confidently carry on down the wrong path.

The difference is that design is no longer a brittle, one-off artefact that must survive unchanged for years. It has become a guide for experimentation rather than a constraint on it. You can hold a strong vision of where you’re heading while still being willing to try, discard and evolve the path that gets you there.

The new skill is knowing when exploration is productive and when it’s just noise. AI will happily keep generating structure long after it should have been simplified. It doesn’t know when a file has grown too large, when an abstraction is leaking or when something that “works” today will cause pain later. Those instincts still come from experience.

How this reshapes the industry

Once experimentation becomes low-cost, many long-held assumptions stop holding. Planning is no longer about locking everything down in advance. It’s about setting intent, constraints and boundaries.

Estimation becomes less about predicting effort and more about understanding the space you’re exploring.

And our relationship with code changes entirely. There is far less attachment to specific implementations and far more focus on behaviour, structure and outcomes.

This is why the software development industry feels unsettled. Many people are trying to apply old mental models to new tools. That works for a while, but it misses the point.

The real shift

The reason I’m confident this change is permanent is simple: I wouldn’t be building again otherwise.

The only reason I can credibly return to hands-on development after a decade away is that the barriers that pushed me out in the first place no longer apply. Software can now evolve through guided experimentation in a way that simply wasn’t possible before.

This doesn’t mean experience matters less. It means it matters differently. The value is no longer in remembering syntax or frameworks. It’s in judgment, structure, and knowing when to stop.

This is not the end of software development. But it is the end of the old model. And once you’ve worked this way, there’s no going back. 

This article is published as part of the Foundry Expert Contributor Network.
Want to join?