When AI Can Code, What’s Next for Engineers?

A few days ago, I was speaking to a friend who has spent almost 15 years in software engineering. He has coded, built systems, worked on large enterprise projects — pretty much what a good engineer is supposed to do.

And like many experienced engineers right now, he is thinking about one uncomfortable question:

what next?

We started here

The obvious answer is: learn AI. Become an AI-native engineer. Learn coding agents. Get stronger at architecture, system design and AI-assisted development.

That was actually my first response to him.

But while saying it, I stopped myself.

Today AI is already writing code remarkably well. It is improving at testing, debugging, code review and increasingly at larger parts of system design too. Maybe not perfectly. Maybe not everywhere. But the direction is clear enough.

So I asked him: if you keep moving one level above what AI can currently do, aren’t you simply running up the same staircase?

We laughed. But neither of us had a particularly good answer.

For a while, we went around in circles. Maybe architecture. Maybe AI engineering. Maybe product management. Maybe consulting.

And somewhere in that conversation, I realised we were probably asking the wrong question.

The question is not which skill should an engineer learn next. The better question is: where does scarcity move when producing software becomes easier?

Then things got uncomfortable

Think about graphic designers before Canva.

Knowing Photoshop and Illustrator itself had value. Creating layouts, working with layers, formats, exports and typography required someone who knew the tools.

Then Canva came along.

Suddenly, someone like me could make a reasonably decent poster.

Did designers disappear? Of course not. But the value of simply being able to produce a design came down.

At the same time, the difference between an average designer and a genuinely great designer became even clearer. A great designer understands spacing, hierarchy, typography, composition, brand consistency and visual judgment. Sometimes they move something by a few pixels and suddenly the whole design feels right.

Canva compressed the value of average execution, while increasing the premium on exceptional expertise and judgment.

I think AI may be beginning to do something similar to software engineering.

For decades, knowing Java, Python, APIs, databases, cloud infrastructure, deployment and debugging created scarcity. You could not simply tell a computer, “Build me this application.” Someone had to know how.

That barrier is now falling quickly.

This does not mean engineers disappear. But it may create something like a barbell.

On one side will be genuinely deep technical specialists: people who understand distributed systems, cybersecurity, databases, algorithms, AI infrastructure, performance optimisation, compilers, model architecture or hardware-software systems deeply enough that their understanding itself is scarce.

On the other side will be engineers who move outward. They keep their technical capability, but add domain understanding, customer context, problem selection, product thinking, trade-offs and outcome ownership.

The part that may get squeezed is the middle: “Give me a reasonably well-defined requirement and I will convert it into reasonably good software.”

Because AI is becoming very good at assisting exactly there.

That’s when something clicked

At this point, my friend challenged me — and rightly so.

Engineers already have judgment. Which database? Which architecture? How much scalability? What happens if a service fails? Do we optimise for performance or development speed?

A good senior engineer develops enormous technical judgment over 15 years.

So saying engineers need to “develop judgment” is also incomplete. The more interesting distinction is where that judgment operates.

A lot of engineering judgment begins after someone has already decided: we are building this. The engineer then decides: how should we build it?

But what about the questions before that? Should we build this at all? Whose problem are we solving? Is this important enough? Will customers care? Which trade-off makes business sense? What happens if our assumption is wrong?

Those decisions have traditionally sat more with product managers, founders, business leaders or customers.

That is where something clicked for me.

Judgment gets sharper when you carry the consequence.

I have spent years evaluating startups. Today I can sometimes meet a founder and pick up signals quickly. Does the market make sense? Is the founder genuinely obsessed with the problem? Is something not adding up?

That judgment did not come from a course on startup evaluation. It came from seeing hundreds of companies, making calls, getting some right, getting others badly wrong, watching companies I liked fail and companies I underestimated grow.

Over time, the mental models improved.

That is what judgment really is: decision → consequence → reflection → better decision.

And perhaps this is the experience many engineers have not been forced to develop outside the technology boundary.

If a product failed commercially, an engineer could still legitimately say, “The system worked exactly as specified.” There is nothing wrong with that. That was the job.

But AI may now force the boundary of that job to expand.

And this is where we landed

So what should a 15-year engineer actually do?

I do not think the answer is simply, “Become a product manager.” Nobody is suddenly going to value your product judgment because you completed a product-management certification.

There are probably two real directions.

If you genuinely love technology, go deep. Become exceptionally good at something technically difficult. Deep enough that your understanding itself becomes scarce.

If that is not you, start moving outward.

If you have spent ten years building systems for banks, do not casually throw those ten years away. Start understanding banking beyond the technology stack. How does the bank make money? How does credit work? What frustrates customers? Where does risk enter? What makes one lending product work and another fail?

Move closer to the actual problem.

And then start owning one.

This is also why I keep telling engineers: build something.

But not to prove that you can code. After 15 years, nobody needs that proof.

Build something because it forces you to make decisions you may not have had to make before. Which customer? Which problem? What should I build, and what should I not build? Will anyone actually use it? Would someone pay? Was my assumption wrong?

Suddenly, you are no longer just building software. You are carrying consequences.

And consequences are what sharpen judgment.

You do not even need to quit your job and become a founder. Take ownership of one small problem inside your company. Talk to users. Sit with sales. Spend time with operations. Take one problem from discovery all the way to outcome.

Not just: did the software work?

But: did anything improve because we built it?

I am not saying software engineers are going away. We will probably need brilliant engineers more than ever.

But AI changes where scarcity sits.

When producing reasonable code becomes easier, simply producing reasonable code becomes less differentiated.

Value starts moving toward two ends: exceptional technical depth, or context, judgment and ownership.

For the first 15 years of your career, perhaps someone else could tell you what needed to be built, and your value came from figuring out how to build it.

AI is becoming increasingly capable at helping with the how.

Maybe the next 15 years are about expanding your ability to answer: what should we build, why does it matter, what trade-offs are worth making, and am I willing to own what happens after we build it?

Stay grounded. Stay curious. The concepts aren't as hard as the jargon makes them sound.

-----

This is part of our ongoing work helping managers build an AI mindset—practical ways to think, decide, and work in the age of AI. It's not about mastering tools, but understanding how to work intelligently with intelligence. Looking forward to your feedbacks