The new leverage of software engineering

Engineering teams have been investing heavily in AI and there are clear benefits emerging. Engineers move faster. Boilerplate takes less time. Tests are easier to write. Documentation is less painful to maintain.

But if the headline impact is that the same team gets through the same backlog a little faster, that isn't the transformation we were promised. It is ultimately a pretty poor return on the investment.

Software companies are built around a familiar constraint: engineering capacity. Developers can only do so much, so everything queues behind them.

A designer wants to test a new dashboard component? Add a ticket.

A support lead wants to improve an internal workflow? Ticket.

Someone in operations wants to automate a repetitive task? Ticket.

The bottleneck has rarely been coming up with ideas. It is that every change to the software must flow through a small number of people. But if agents can understand a system, generate code, wire up an interface and explain the errors, hasn't that bottleneck gone away?

Now I know what you're thinking, but hang on - you're not a developer yet. The lazy version of this argument is: "AI makes everyone a developer now." It doesn't, and it shouldn't. Letting anyone vibe-code straight into production isn't empowerment. It's arson.

Engineers are right to worry about low-quality code, missing tests, accessibility problems and security holes. Those concerns separate "works on my machine" from "safe to run our business on."

But the answer can't simply be that only engineers are allowed to change software. The more interesting question is: what would need to be true for more people to change it safely?

Engineers as change architects

The higher-leverage role is designing an environment where software can be changed safely by more people: clear service boundaries, automated tests, feature flags, approval workflows, observability and automatic rollbacks.

Engineers then stop being the sole code owners and become change architects. They build the tracks and infrastructure that let more trains run.

The best place to start with this is somewhere low-risk and high-friction: internal tools, dashboard components, onboarding flows and admin interfaces. Let someone propose a change. Let AI refine the idea and draft code, run the checks and then create a preview. Require approval where needed, and roll back if it misbehaves.

A product manager shouldn't be able to edit authentication because they had an idea on a Tuesday afternoon. A designer shouldn't be able to rewrite payment logic.

But should a designer be able to create a product-card variant, run visual and accessibility checks, preview it, launch it to 20% of users and measure the outcome? Sure. Why on earth not?

And this isn’t just about letting non-developers write code. This is as much about a front-end developer being able to own a complete problem by having enough confidence in an otherwise unfamiliar system to make required changes.

The obvious difficulty with this is that these guardrails are exactly what most engineering teams struggle to build and maintain. For many organisations, that means months of work that rarely reaches the top of the backlog.

This is where the second-order effect of AI gets interesting. The same capability that makes engineers faster at writing features also reduces the repetitive work involved in building the foundations: drafting tests, configuring integrations, extending delivery pipelines and fitting existing tools together.

The first wave of AI tooling makes engineers faster. The second, more important wave helps them build systems that let other people contribute safely. Better tooling makes better guardrails affordable, and better guardrails expand who can contribute.

That doesn't make engineers less important. It makes their judgement more important: what should change, where the risk sits, what standard a contribution must meet and how success will be measured.

That is the new leverage of software engineering. Not clearing the queue faster, but building a system in which fewer changes need to join it.