My 3 Cents on the Future of Software Engineering Jobs.

We’ve been making the decisions all along

An email from Matt Pocock landed in my inbox, and now I feel obliged to contribute to the discussion about the future of software engineering. Apparently, there weren’t enough opinions on the internet already.

Will AI make engineering jobs disappear?

My bet is quite the opposite. And to folks in other roles: be aware. We’re coming for you.

Mostly joking. Mostly.

Matt’s email got me thinking about what’s left for engineers when agents do more of the coding. My answer starts with something we’ve been doing all along, often without getting much credit for it: making hundreds of creative decisions every day.

Because requirements have gaps. Designs have gaps. That beautifully organised ticket with the reassuring “ready for development” label? Also gaps.

What happens when there’s no data? When someone doesn’t have permission? When the customer uses the feature in a way nobody considered? Should we ask for confirmation here? Does this rule actually make sense?

Someone has to decide.

Very often, that someone is the engineer, halfway through implementing a supposedly well-defined feature.

We’ve been filling in the blanks between what people ask for and what a working product actually needs. Some decisions are technical. Plenty are about behaviour, usability, priorities, or what the business meant when it said “just a simple export.”

A classic.

The trouble was that we also had to write all the code

Every decision came with implementation work attached. Sometimes five minutes. Sometimes three days, a dependency upgrade, and a brief reassessment of our career choices.

A huge part of the day went into turning decisions into working software. That left less time to question the problem, explore alternatives, or get involved earlier, when changing direction was still cheap.

Now we can hand more of that implementation work to agents. There’s still work in guiding them, checking the result, and dealing with whatever creative interpretation they’ve contributed. But when that goes well, we get time back.

And I think the interesting question is what we choose to do with it.

More time, more responsibility

Sure, we can finish more tickets. There will always be more tickets. Humanity seems to have solved that particular supply problem.

But we can also take responsibility for a bigger part of the process.

Talk to the customer ourselves. Understand why their workflow is painful. Challenge the requirement before it becomes a requirement. Explore a few options. Build something, put it in front of someone, and find out whether it helps.

Then own what happens next.

That’s where I think engineering jobs can grow. We already make decisions across those boundaries. Now we have more room to make them deliberately, with better context, instead of quietly patching the gaps during implementation.

About that “we’re coming for you” bit

This is also where my “we’re coming for you” comment becomes slightly less of a joke.

Some responsibilities currently spread across product, design, analysis, and engineering could sit with one person, or a much smaller team. An engineer who understands the problem, can work with people, and can deliver a solution has a pretty interesting opportunity here.

Of course, having an agent doesn’t magically give you good product judgment or design taste. Those take work. If you want more responsibility, you also have to learn the parts of the job that someone else used to handle.

And you have to accept that “I built exactly what the ticket said” becomes a fairly useless defence when you helped decide what should be built.

We already have examples of engineers working across these boundaries. Forward deployed engineers, working directly with customers and taking on problems that reach beyond implementation, are one example. The role predates the current wave of coding agents, but to me it points towards the kind of responsibility more engineers could take on.

Will this apply to every engineer?

Nope.

Some people enjoy a clearly defined scope and want to focus on implementation. Others want to get involved in the messy conversation about what to build, why it matters, and whether it should exist at all.

The opportunity I’m describing will appeal most to people with the engagement, energy, and passion to follow a problem beyond their assigned part of it. People willing to learn, make a call, and take responsibility when that call turns out to be wrong.

Those people have always existed in engineering. They’ve also spent a lot of their time writing code.

I’m excited to see what happens when they have more time for everything else.

Good times ahead.