Defining my own path as a software engineer in a world changed by AI

Thoughts on software engineering and career paths from Khadija Al-Selini, Lead Engineer

For a while, AI gave me a lot of anxiety about my career.

Over the last two years, we’ve seen software engineering become one of the first professional fields where AI’s impact is painfully clear. It is automating much of what we once considered core engineering work: turning product requirements into software architecture, writing and maintaining code, optimising systems, and making them resilient to changing business requirements and dependencies.

Work that once required large engineering teams can increasingly be handled by a much smaller group of people. The ones who guide LLMs and check that their output is sane.

So for me, I imagined the future splitting into two paths.

Two paths I saw ahead of me

You could go further down the stack: build a deeper understanding of what’s happening beneath the abstractions – operating systems, compilers, database internals, and infrastructure – until you’re one of the relatively small number of people still needed to solve the hardest technical problems.

Or you could go up the stack: manage the people who still get to solve these problems, or sell the solutions they create.

The second path (admittedly a simplified perspective shaped more by anxiety than by the reality of my options) scared me.

What I loved about engineering was being given a blank page and the space to think. Someone has a problem. You sit with it. You understand it. You design something. Then you build the thing.

So if I didn’t somehow future-proof myself, would I eventually be pushed away from the kind of work I loved doing?

My response to that question was to do the most logical thing.

Learn everything.

Trying to learn my way out

Dive deep into distributed systems. Revisit computer science fundamentals. Build stronger mental models of how the web actually works.

But every answer seemed to uncover another layer I felt I needed to understand. Networks led to operating systems. Operating systems led to compilers. Databases led to storage engines, replication and distributed consensus.

There was always something further down the stack.

And somewhere in my head, depth had become synonymous with defensibility: the more of the machinery I understood, the stronger an engineer I would become, and the harder I would be to replace.

So the reading list kept growing.

Then something became clear

Somewhere in that chaos, though, something became clear.

I don’t actually want to spend my career solving problems at that layer.

Most of the work I love sits somewhere between the business and the system: taking messy requirements and turning them into models other engineers can reason about, and into products that end users can rely on and actually enjoy using.

Going further down the stack shifts the centre of gravity. The problems move further away from the people using the system and closer to the machinery underneath it: memory, concurrency, hardware behaviour, latency, resource utilisation.

It rewards a different kind of curiosity.

And that raised a harder question: even with all the uncertainty in the industry, would going further down that path actually preserve the kind of work I love?

The answer was probably not.

Could the tides be turning?

But amid all of this, I started noticing new intersections of engineering emerging.

Forward-deployed engineers, product engineers, miscellaneous engineers. Roles that blur some of the traditional boundaries around what an engineer does. Working closer to customers, product and the business, while still actually building things.

Perhaps engineering isn’t collapsing into a smaller set of paths after all. New combinations of skills are emerging, and the future may not be as binary as “become exceptionally specialised, or get pushed further from the actual building.”

Planning around the most pessimistic version of the future felt like a way to protect against obsolescence. But in reality, it mostly meant operating from anxiety and paying less attention to the other possibilities: greater demand for multidisciplinary skills, or even the ability to spend your spare time developing viable solutions to problems your acquaintances and local businesses face.

What I’m optimising for instead

So rather than optimising around one imagined future, a simpler question feels more useful: assuming the future economy hasn’t completely collapsed, what do I want my day-to-day to look like?

What brings me the most joy is being in the middle of it all: talking to customers, understanding the business, shaping the product, figuring out how to make it work technically, and then turning all of that into something real and commercially successful.

So that’s what I’m going to optimise for.

Right now, that means strengthening my foundations in web scalability, query performance and high-throughput systems, especially as we have a lot of exciting things coming up at Vouchsafe.

The takeaway

But my biggest takeaway from all of this is that you can’t know which version of the future you’re preparing for. You can only understand the possibilities, accept the trade-offs, and keep moving towards the kind of work that gives you energy.

Or maybe the true lesson is that this is a Wendy’s and I should get back to work.

Vouchsafe is looking for exceptional product engineers to join us in London, and help us build the world’s first real-time fraud bureau. See open roles.