Blog: AI writes the code. But engineering is more than coding.

AI is changing how software gets built. AI can now handle many coding tasks much faster, opening up new possibilities for how teams work and what they can deliver. But writing code and engineering software aren't quite the same thing.

Behind every working application are decisions about architecture, integration, testing and maintenance. And as AI takes on more of the implementation work, those decisions don't disappear.

I've been exploring this through research and my own experience with AI-assisted development. While the opportunities are significant, I think there's an important question we need to consider: if AI can increasingly write the code, what becomes more valuable for the people responsible for building software?

The productivity picture isn't straightforward

There's compelling evidence that AI can accelerate development. In a controlled experiment involving GitHub Copilot, developers using the tool completed a JavaScript coding task 55.8% faster than those working without it.

That's a substantial improvement. But the benefits aren't necessarily the same across every development environment.

A 2025 study by METR found that experienced developers working in familiar open-source repositories took 19% longer to complete tasks with AI assistance, despite believing they'd been faster.

That finding needs context. METR subsequently revised its experimental approach and acknowledged limitations in its newer data, suggesting AI tools were likely providing productivity gains by early 2026.

To me, the interesting question isn't whether AI makes developers faster. It clearly can. It's actually understanding when that speed translates into better outcomes, and when the time saved generating code is spent understanding, reviewing or correcting it.

The decisions behind the code

Integration is a good example, because it's where code can look right and still fail: each step works on its own, but the risk sits between the systems. Imagine an application that saves an order to a database and then sends an event to another system.

You can ask AI to generate that process and it might produce something that works perfectly in a demonstration.

But what happens if the order is saved and the event fails to publish? Or if the receiving system processes the same event twice?

These aren't unusual scenarios. They're the kinds of questions engineers need to consider when designing reliable integrations. Patterns such as transactional outboxes and idempotent processing help address them. But knowing which approach to use depends on understanding the problem, not simply generating the code.

That distinction becomes especially relevant in enterprise environments, where applications, data and business processes are often connected across multiple systems.

It's something we encounter when working with technologies such as MuleSoft and Salesforce. As organisations introduce agentic capabilities through Agentforce, understanding how those systems interact becomes even more important.

AI can help accelerate implementation. Engineering knowledge helps determine what the implementation needs to account for in the first place.

What happens after the code works?

I've experienced another side of this while experimenting with an AI-driven orchestrator.

The idea was to automate parts of a development workflow, from receiving a task to generating code, reviewing it and moving it through different stages.

AI helped me build a working solution. But independent code reviews caught issues that successful runs never showed, such as a token exposed to a subprocess and an approval step that could hang indefinitely.The project eventually reached 565 automated tests, yet those tests relied on simulated services rather than real integrations.

I knew enough about architecture to direct the build and recognise when the approach was becoming difficult to maintain. But my limited experience with the programming language made independently reviewing and maintaining the generated code harder. Eventually, I decided to replace the project with a simpler setup.

That experience wasn't an argument against using AI. It showed me how important it is to understand the technology behind what we're building, particularly when we need to change it later.

For organisations adopting AI-assisted development, there's a useful lesson here: productivity isn't just about how quickly something can be delivered. It's also about how confidently teams can test, maintain and improve it over time.

Who develops for the next generation of engineers?

There's another question that shouldn't be overlooked. If AI increasingly handles the smaller, well-defined development tasks that junior engineers traditionally learned from, how will the next generation build the knowledge needed to make more of the complex decisions?

Research into AI's impact on employment is still developing, and we shouldn't draw conclusions too quickly. But the changing nature of entry-level work raises questions about how engineering skills will be developed.

I learned a lot by building small things, getting them wrong and understanding why. And as AI becomes more embedded in development, teams may need to be more deliberate about creating those learning opportunities.

That could mean giving junior engineers greater responsibility for reviewing generated code, questioning requirements, designing tests and explaining technical decisions.

The tools are changing. So how we develop the people using them needs to evolve too!

Engineering still needs judgement

I don't think developers need to compete with AI on coding speed. That's not where our value lies. Our role is changing, but understanding problems, making architectural decisions and taking responsibility for what we build remain essential.

For organisations, that creates an opportunity to combine AI's capabilities with the experience and judgement needed to develop software that works beyond the initial implementation.

AI will keep getting better at writing code. The challenge is making sure we keep getting better at engineering the systems around it.

This article builds on my longer exploration of AI-assisted development, where I examine more of the research, share the technical details behind my experiments and consider what these changes could mean for the future of software engineers. Read my original article: What Remains for Software Developers When AI Writes Code?