11 September 2026 / Code

What Is Software Development in 2026?

When writing the code is no longer the hard part.

I saw an interesting post on LinkedIn recently.

An experienced software engineer had been experimenting with AI. He’d asked it to build a relatively simple piece of software and ended up with around 3,000 lines of code and another 3,000 lines of tests.

He wasn’t impressed.

In his view, an experienced developer could have achieved the same thing in perhaps 500 or 600 lines. The AI had produced unnecessary abstractions, duplicated information that already existed elsewhere and generally created far more code than the problem required.

So he threw it away and started again.

His conclusion was that AI might be able to produce functional code, but it wasn’t producing beautiful, efficient code.

It made me stop.

Because I’ve been using AI heavily to build software. Not experiments. Not throwaway demos. Actual products that I intend to put in front of customers.

Was I doing something wrong?

Then I remembered one of the oldest expressions in computing.

Garbage in, garbage out.

We’d been shown the output.

But what was the input?

What did you ask it to do?

This is something I find increasingly frustrating about discussions around AI-generated software.

Someone shows you the terrible code an AI produced, but rarely shows you everything they gave the AI to produce it.

What was the specification?

What architectural direction was provided?

What constraints were defined?

What existing code did it have access to?

What conversations happened along the way?

What decisions were delegated to it?

Without knowing those things, I’m not sure what conclusions we can draw from the output.

I’ve recently been developing SSH Teams, a product for managing SSH access using short-lived certificates.

I didn’t tell an AI:

“Build me an SSH certificate management system.”

I already understood the problem.

I knew the architecture I wanted. I knew I wanted to use DPoP. I provided a fairly comprehensive specification of the required solution. I even supplied code from some prototyping I’d already done.

The AI didn’t invent SSH Teams.

I did.

It implemented it.

That’s a very different thing.

And it implemented it in a fraction of the time it would have taken me to sit there and write all the code myself.

Would I have written every part of it in exactly the same way?

Probably not.

Do I care?

Increasingly, no.

Is it functional?

This is where I think being a business owner for a long time has changed my perspective.

Developers like beautiful code.

I like beautiful code.

I’ve been writing software for nearly 30 years. Of course I appreciate a clever abstraction, a clean API and an implementation that solves a problem elegantly.

But businesses don’t buy beautiful code.

They buy solutions to problems.

If I’d employed a developer ten years ago and they gave me 3,000 lines of code for something I thought could be achieved in 500, I’d have questioned it.

I’d probably have asked why they’d done it that way. We might have made some efficiencies over time.

But eventually my business head would have won.

Does it work?

Is it tested?

Is it secure?

Can we ship it?

Because at some point you have to stop engineering and start delivering.

AI hasn’t really changed that principle.

What it has changed is the economics surrounding it.

If something that would previously have taken me weeks to develop can now be built in hours or days, I’m not going to spend another week making it aesthetically pleasing simply because that’s how I would have written it myself.

That isn’t good business.

But what about all that extra code?

The obvious objection is that 3,000 lines instead of 500 means more places for bugs to hide.

More attack surface.

More complexity.

More things to maintain.

Potentially.

But those are things we can test.

If the additional code creates a vulnerability, find the vulnerability.

If it creates a performance problem, measure the performance problem.

If it causes incorrect behaviour, test the behaviour.

If it makes the application unreliable, demonstrate that unreliability.

The fact that an experienced developer looks at the implementation and says “I wouldn’t have done it like that” isn’t, by itself, evidence that the software isn’t suitable for production.

And this is where I’ve realised my own development process has changed quite dramatically.

I’m not the developer anymore

I’m the orchestrator.

I’m the tester.

I decide what I’m trying to build.

I understand the domain.

I make the important architectural decisions.

I define the behaviour I expect.

AI performs an increasing amount of the implementation.

Then the software has to prove itself.

It goes through testing. It goes through security testing. It goes through the same robust process that any other application should go through before being put into production.

I’m not saying:

“The AI says it works, ship it.”

Quite the opposite.

I don’t need to trust the AI.

I need evidence that I can trust the software.

That’s a very different proposition.

And perhaps it means we’ve been placing too much importance on who — or what — wrote the code.

Experience still matters

There’s another argument I hear regularly.

If AI can write software, perhaps anyone can become a software developer.

I don’t believe that either.

AI makes producing code dramatically easier.

It doesn’t magically give you domain knowledge.

I’ve tried getting another engineer to use AI to develop some of my ideas. I expected him to take the idea, work with the AI and manage the process himself.

Instead, he kept coming back to me with questions.

The AI wasn’t the problem.

He still needed someone to make the decisions.

I saw another version of this recently when I spoke to a small team interested in using our Maverick Synergy SSH API.

They described the system they were planning to build.

It was, coincidentally, very similar to SSH Teams, which I was already developing at the time.

They understood the problem they wanted to solve.

But there were significant problems with their proposed architecture.

That’s not because they weren’t capable developers.

It’s because I’ve spent decades working in this particular domain.

AI doesn’t remove that experience.

If anything, it gives me considerably more leverage from it.

AI can remove the implementation bottleneck. It doesn’t remove the knowledge bottleneck.

And I think that’s where things become really interesting.

From software engineering to behaviour engineering

We’ve traditionally trained developers through implementation.

Write this function.

Build this endpoint.

Implement this feature.

Own this component.

Eventually, after enough experience, design the system.

But what happens when implementation becomes the cheap part?

Perhaps we start much further up the stack.

Understand this problem.

Describe the behaviour required to solve it.

Define the constraints.

Decide what must never happen.

Give those requirements to an AI.

Evaluate what it produces.

Test it.

Break it.

Secure it.

Improve it.

Ship it.

I’ve started thinking of this as behaviour engineering.

The important artefact isn’t necessarily the code.

It’s the understanding of what the system is supposed to do and the evidence that it actually does it.

That doesn’t make junior developers obsolete either.

It changes what they’re learning to become.

Tomorrow’s junior developer may spend considerably less time learning how to manufacture implementations and considerably more time learning how to engineer behaviours.

They’ll still make mistakes.

They’ll specify the wrong thing.

They’ll miss edge cases.

They’ll choose inappropriate architectures.

They’ll accept something that appears to work when it doesn’t.

And they’ll learn from those mistakes.

That’s how experience is created.

We don’t need to preserve expensive implementation work simply because that’s how my generation acquired its experience.

The abstraction has moved before.

It’s moving again.

So what is a software developer?

This may ultimately be the bigger question.

Imagine someone builds a substantial commercial system.

They understand the problem.

They can explain exactly what the system is supposed to do.

They understand its architecture and constraints.

They can demonstrate that it is reliable.

They can demonstrate that it is secure.

They can test its behaviour and confidently put it into production.

But they couldn’t sit down and reproduce the entire implementation without AI.

Are they a software engineer?

I think they are.

Or perhaps, by then, the term will mean something different anyway.

After nearly 30 years of writing software, I’ve realised I don’t particularly miss writing all of the implementation myself.

Building something and seeing the result working in hours rather than days is enormously rewarding.

I’m probably building more than I ever have.

I’m just writing less of it myself.

And that’s why I think we’re in danger of judging AI-assisted development using the values and processes of the development model it’s beginning to replace.

Beautiful code is still beautiful.