If AI Can Generate Competent Code, What Should We Teach Engineers?

I’ve had a couple of conversations recently that got me thinking about how we are training the next generation of software engineers. One was with an industry expert about how AI is changing software delivery. The other was with my nephew, who is considering studying software engineering at university.

The question I keep coming back to is pretty simple. If AI can already generate competent code, what should we actually be teaching someone who will enter the profession four years from now?

You still need to understand the fundamentals of coding if you are to evaluate, debug, challenge, or make architectural decisions around it. But I do think we need to reconsider what we treat as the center of software engineering education.

For decades, developers acquired judgment through implementation. Over time you learned why certain abstractions worked, why systems became brittle, and why technically correct solutions sometimes failed in the real world.

AI is starting to compress that learning cycle. I think the emphasis needs to move higher up the stack. We should be teaching orchestration. How do you break a complex problem into work that humans, agents, APIs, and systems can execute? How do you provide context, establish constraints, validate outputs, and coordinate multiple pieces into a reliable result?

We should be putting more emphasis on software and architectural principles. Coupling, cohesion, domain modeling, security, observability, failure modes, data architecture, distributed systems, scalability, and the tradeoffs that come with every design decision. And we should be developing creative problem solving. Real business problems rarely arrive as clean requirements. Engineers need to learn how to frame ambiguous problems, challenge assumptions, explore alternatives, and recognize poor design.

AI can generate an implementation. The engineer still needs to know whether that implementation belongs in the system. That distinction matters because someone who cannot recognize poor architecture, bad assumptions, security issues, or unnecessary complexity can now generate bad software faster than ever before.

I would much rather evaluate a new engineer by giving them an ambiguous business problem and asking them to design a solution, explain their architectural decisions, use AI to help build it, validate the output, and defend the tradeoffs they made. That feels much closer to the skill set the profession is moving toward.

The next generation of developers are entering a world where writing code is one of the least scarce capabilities available to them. The advantage will not come from competing with AI at producing syntax. It will come from understanding systems well enough to direct it, question it, and recognize opportunities it cannot see.

We are spending enormous amounts of time discussing how AI changes software development. We should be spending just as much time discussing how it changes the way we educate software developers.