Rethinking engineering for efficiency

Across some engineering teams I see, it’s becoming clear to me that we're starting to see the limits of our current way of working with AI.

At the moment we're largely using AI to do what we’ve always done, but faster. We’re generating more tickets, writing more code, releasing more fixes. But as a result of this, we’re also switching context more often, reviewing more code than ever before, and in some cases struggling to even understand AI-generated code in those reviews.

The result can be more cognitive load rather than less. More work in progress, more context switching, more code to review and less confidence that we properly understand everything moving through the system. That simply isn't the outcome we want from using AI.

The opportunity that I believe AI presents is not simply to accelerate the current process. It is to rethink the process to allow us as engineers to focus on the most important, highest-impact parts of our work. That likely means finding ways to reduce our input on routine engineering work, while allowing more attention to go into understanding whole problems, designing good systems, setting constraints and making the important decisions.

To do this though I think there are two things we need to do; build an environment that increases confidence and trust, and centralise our engineering context around a shared platform.

Build an environment that increases confidence

We shouldn't treat all AI-generated code equally. Some changes must have close human review (financial transactions, high-volume order routing); others should eventually become safe enough to fully automate because we've built the right guardrails around them. Guardrails such as robust tests, automated checks, clear standards, good observability, controlled permissions and appropriate rollback mechanisms.

If we can build those guardrails, it should allow us to worry less about specific lines of code and focus more on the problem, the behaviour of the system and whether the engineered solution is the right one. Trust then comes from the evidence surrounding the change: tests, checks, observability and appropriate controls, rather than somebody having to manually understand every line.

Centralise our engineering context

There’s a huge focus right now on personal AI agents. They’re incredible and certainly have their place, but I think today we’re making things harder for ourselves by all having our own preferred way of working, our own preferred models, tools and markdown files.

A primary engineer on a system can build a lovely environment which makes them really efficient. But as soon as someone else has to pick it up, they’re not only having to learn the system context, but also a completely different way of working with AI.

Our engineering principles, coding standards, repository knowledge and structure, system architecture, testing expectations, release processes and product goals should increasingly become shared infrastructure. Improvements made by one person should improve the system for everyone, and every development environment should feel familiar.

If we can capture our principles and ways of working and automatically share them through every repository, the actual tool or model a developer uses becomes less important, because they’re all then working from a shared context.

Where should we start?

We’ve spent the last year or so playing and experimenting with AI, and we’ve integrated it into our daily work with varying levels of success. This has been really useful and has shown that there is genuine value here. I think now the next conversation shouldn’t be about which tools we should use. It needs to be about what a more efficient engineering model looks like. Not a faster one, or an automated one, but a more efficient one.

As a starting point, I think the following questions hopefully prompt some useful discussion:

  1. What engineering work should humans stop doing?

  2. What work remains (or becomes more) important for humans to stay in control of?

  3. What needs to be true before we can trust AI with more autonomy?

The goal here isn't more code or tickets. It's less work in progress, less cognitive load and context switching, more reliable systems and more engineering capacity that can be applied to the problems that actually need us.

I personally think the role of engineering is changing as a direct result of AI, and that over time we'll spend much less of our time manually writing code. But I also don’t think that writing code was ever intended to be the primary task (even though it often took the most time). That has always been solving problems. Engineers are great at developing solutions to problems, a job which involves understanding the company and product context, knowing what’s technically possible, asking questions to get to the best solution, and caring about the quality of your work.

All of that is more important now than ever.