A little background on me. I've been a software engineer for over ten years. In that time I've worked in startups of all shapes and sizes, doing everything from native app development to scaling services that handle millions of daily requests. I've run my own businesses, pitched for investment and even done sales. You really do wear many hats in the startup world.

I'm saying all this because I don't think anything prepared me for just how much AI is changing the software industry.

Just over a year ago, it felt like the were getting good enough to help with some of the more complex parts of my daily coding. For me, this was when I became a prompt engineer and glorified babysitter. Give it a task, watch it work, steer it back when it went off track, then check what it had actually done.

This continued for a long time, at least in AI years, and I felt like I was keeping up.

Boy was I wrong.

I was still thinking about better prompts while the tools were becoming capable of handling much larger chunks of the work. Front-loading an epic and a list of tasks helped, but there was more to figure out: what context to give an agent, which tools it needed, how to check the result and when to step in.

What happens to everything we've learnt

Traditionally, you learnt the coding principles, then the syntax and frameworks, then the cloud platforms. Years went into knowing how to build and run things properly.

Now an agent can write code in a language you've barely touched. Tools like already let us describe infrastructure in code, and agents can help write and maintain that too. The amount you need to type yourself to get from an idea to something running has changed massively.

But does that mean the result is right? I don't think so.

It can feel like all that knowledge is becoming irrelevant. Then you have to review what the agent has built. Has it given a service more access than it needs? Will a slow request hold everything else up? Can you recover if a deployment goes wrong?

That's where experience still counts. Remembering every bit of syntax matters less when a tool can produce it for you. Understanding the consequences of that code still matters a great deal.

So what does this mean for software engineers

I don't think anyone knows exactly where this lands. But I don't see an industry running out of things to build.

You can start experimenting with an AI subscription and an idea. That opens the door to people who couldn't previously build something themselves, and to projects that were too expensive to justify. I think there's a lot of opportunity there, especially in businesses with manual processes that nobody has had the time or budget to improve.

I mean, who doesn't want to automate the boring and monotonous parts of their job?

The difficult bit is understanding that job well enough to improve it. A business might ask for a dashboard when the real problem is that three people are copying the same information between different systems. Someone still needs to ask the questions, work through the awkward cases and decide what is worth building.

That's work an engineer can do, provided we're willing to get closer to the people using the software.

Learning to orchestrate the work

My advice to engineers right now is to make time to learn these tools properly. If your workplace will support training or give you room to experiment on the job, start there. They stand to benefit from what you learn. A small personal project is useful too, if you have the time.

Try out . There are plenty on GitHub and in developer communities. Read what they actually do before giving them access to a project. A lot of stars can help you find something interesting, but they don't tell you whether it's suitable for your codebase.

Then think about how the work fits together. You might use a skill to clarify the requirements, another to guide implementation, and a separate review to challenge the result. Tests need to check the behaviour you wanted, including what should happen when something goes wrong.

You're taking on more of an orchestrator's role: deciding what to delegate, setting boundaries and checking the output.

There's a balance to find. Split every small change between a dozen agents and you can spend more time and money passing context around than doing useful work. Give one agent a vague instruction to build everything and you can end up with a lot of code that's difficult to trust.

Keep an eye on , but include the time you spend correcting the result. A cheap run that leaves you with two hours of repairs wasn't much of a saving.

The rise of the forward deployed engineer

The phrase “forward deployed engineer” predates the current AI boom. What interests me is how closely it matches the broader role engineers are moving towards.

OpenAI describes engineers working directly with customers to understand their workflows and take solutions into production. Microsoft has also invested in embedding engineering teams with customers through its Frontier Company business. The details vary, but both put engineers close to the problem they're being asked to solve. OpenAI's FDE role and Microsoft's announcement give a useful sense of that work.

In simple terms, it sounds a lot like being a small startup inside a bigger company. You're talking to the customer, understanding the problem, helping decide what to build and making decisions about how people will use it. You stay involved as it reaches production and people start relying on it.

That doesn't make you an expert in every discipline. You still need to know when to bring in someone with deeper knowledge. But AI gives you more room to work across those boundaries and try things that would previously have needed a much bigger team.

How I've found the transition

Coming from an entrepreneurial background, a lot of this feels natural to me. Working out what someone needs, making trade-offs and wearing a few different hats are all familiar territory.

The hardest part has been letting go of some of the hands-on coding. Every now and again I still slip in a few lines and feel like a champion. There's satisfaction in writing something yourself, and I don't think that disappears just because a tool can do more of it.

I've enjoyed the learning, though. It gives me a reason to revisit how I work, rather than assuming the habits I've built over ten years are still the best way to do everything.

A few things I'd encourage anyone to try

  • Start with a small, real problem. Finish it, use it and find out what you missed.
  • Learn how to review and debug the output. You'll need those skills even when you're writing less of the code yourself.
  • Put yourself out there. Talk to people, share what you're learning and give a technical talk if you get the chance. Being able to explain a decision will take you far.
  • Become more of a jack of all trades. Learn some UX principles, understand deployment decisions and get comfortable asking business questions.

I still want to build things. That's what got me into this in the first place. The way I do it is changing quickly, and I'd rather spend my time learning what works than trying to preserve every part of the old job.