A Good Time

It’s a good time for AI in software development.

I have been a software developer for 40 years, an architect, and much of whatever else it takes to build good, reliable software. Over that time, our tools have improved enormously. At the same time, the world we use them in has grown ever more complex.

I’m mainly talking about enterprise software: system landscapes that have grown over decades, with countless interfaces, different generations of technology, and business processes that stretch across many applications.

A new service talks to a twenty-year-old system. REST meets SOAP, JSON meets XML. In between sit databases, message queues, file transfers and in-house builds whose original authors moved on long ago. Much of it still does its job reliably today. Taken together, it forms a landscape that hardly anyone can see in full anymore.

Even a seemingly small change can set off a journey through several systems, teams and decades of software history.

On top of that comes everything we have to master today, or at least understand well enough: libraries and frameworks, containers, Kubernetes, CI/CD, monitoring, security and compliance. And of course the business domain. Because in the end, the software has to solve a real problem.

Outside the developer bubble, this complexity is barely visible. A new input field appears on the screen. Behind it, perhaps five interfaces, three data models and an authorisation concept change.

And now AI comes around the corner.

It writes code, explains unfamiliar implementations, drafts tests and helps with debugging. Tasks that used to cost us a lot of time suddenly become easier. Ideas that never found room in day-to-day project work can finally be tried out.

That excites me. But I also understand why it unsettles developers. If an AI produces in a few minutes the code I would once have spent a day on: what does that mean for my work?

The question is legitimate. Our profession is going to change. Which tasks and jobs will be affected is not something anyone can simply promise away.

But software development was always more than writing code. We have to find out which problem actually needs solving. We have to understand business requirements, recognise trade-offs and make decisions that still hold up in production. In a grown enterprise landscape, that often takes knowledge that no ticket ever fully describes.

When we program, we translate this understanding into a working solution. And we keep learning along the way: one idea holds, another fails on a detail nobody had seen before.

AI can enrich this process enormously. It can suggest alternatives, build prototypes and help us test assumptions earlier. We gain the chance to seriously explore several possible solutions instead of implementing the first halfway viable one under time pressure.

Of course it makes mistakes. It overlooks constraints, makes wrong assumptions and occasionally delivers convincing-looking solutions that don’t work. Especially in grown systems, something can be locally correct and still wrong in the bigger picture.

This is where experience and judgement count: What requirement really lies behind a request? Which dependencies do we need to take into account? Where is a new abstraction worth it? What can we simplify? And which change would we be better off not making?

I want more time for these questions.

At the same time, we should resist one temptation: just because code can be generated faster doesn’t mean we automatically need more of it. An additional service is quickly written. It still has to be operated, secured and understood. The biggest gain may lie in using AI to find a simpler solution.

For decades, we have used libraries, frameworks and development tools because they extend what we can do. AI continues that story and opens up new forms of collaboration.

For me, that is the big opportunity: As developers, we can build more of what we believe is worth building.

For that, we have to keep responsibility for the solution. We should understand what we build, assess the results and decide together with the users whether we are actually solving the right problem. Generated code alone cannot replace that responsibility.

After 40 years of software development, I find this prospect genuinely motivating. There are still so many bad processes, clunky applications and unsolved problems. We are being handed a tool that lets us take on more of them.

Let’s use it to build software that works more simply, runs more reliably and helps people more.