What changes for engineering leadership as decisions get cheaper?

If you lead an engineering team, how do you decide which decisions need your involvement and which the team can try for themselves? If AI makes it easier to rewrite the code and try another approach, what should we spend less time trying to prevent, and where does our judgment matter more?

A big part of the value of engineering leadership has been helping teams avoid decisions that would take months to recover from. Choosing the wrong approach meant spending people’s time building it and then spending more time replacing it. There was a clear reason to think carefully before committing.

I think we need to revisit that now. Where AI makes the implementation easier to reverse, some of the cost we were trying to avoid has fallen, so the time we spend trying to avoid it should change too.

It’s easy to be worried about what could go wrong without actually counting the cost. I think writing down the failures we're concerned about and what each would mean for the team and the business is a useful place to start. That gives us a list we can start working through, one problem at a time, instead of stopping at the possibility that things could go badly.

What does being wrong actually cost?

Security failures and lost or exposed data are clearly expensive, and a rewrite may do very little to repair the damage. Alongside those risks, I’d look at these costs:

• Detection: How long before we realise something is wrong?

• Interruption: What can customers or the business no longer do while it's wrong?

• Recovery: What does diagnosing, replacing, testing, and deploying the correction require?

• Coordination: Who else needs to change something or wait for us?

• Lost time: What useful work did the team postpone while building and correcting this?

A checkout problem may take minutes to fix after customers have been unable to pay for hours. If another team also needs to change an integration, we have to account for their time. The rewrite is only part of what the mistake has cost us.

To compare those costs before we commit, we have to estimate them. In this article, an estimate means our expectation of the time, effort, and disruption involved in recovering from a decision if it turns out badly. How long would it take to find the problem, who would need to fix it, and what would customers or other teams be unable to do while we recover? That's broader than an estimate of how long it takes to write the replacement code.

Once we have that list and our estimates, we can decide which problems to address first, what protection might help, and what would tell us it works. The list gives us somewhere to start, and the work we do after that determines how much risk remains.

Are we still using old estimates of what recovery takes?

By old estimates, I mean expectations based on how we worked before using AI to help build and change software. Those expectations shape how much time we spend reviewing a design before anyone starts building, even when we've never written them down.

For example, we might hesitate to let a team try a different internal API design because we expect replacing it later to take two engineers several weeks. That estimate might include rewriting the implementation, updating callers, testing the changes, and coordinating a rollout. If agents can now help with the rewrite and caller updates, we should check how much of that estimate still holds. Testing, coordination, and the consequences for anyone using the API still need to be accounted for.

When we look at code built with agents, duplicated code, an awkward abstraction, and a checkout that fails intermittently can all need fixing, but we should be able to explain the cost of each.

If a team builds a prototype quickly, learns from it, and replaces it without much difficulty, I think we should count that learning when judging whether it was a bad use of time.

Before saying a refactor will take weeks, I’d want us to break down the work and check that estimate against a small, representative change with the tools we use now. How much time goes into changing the code, and how much goes into understanding the behaviour, checking it, and rolling it out safely?

The same applies when we say an agent can just rewrite it. We need to understand the problem, know what should happen instead, and be able to check the result. Otherwise, we can spend a lot of time generating different versions of something we still don’t understand.

Which concerns are still as costly as they were before, and which ones have become less relevant because we can recover more easily? What are we treating as an expensive mistake mainly because we would have built it differently?

What can teams try for themselves?

For me, a decision is safe to test when we know who and what it affects, can tell whether it works, and have a way to stop or reverse it. Before starting, we should agree on how much disruption customers and other teams could face, including anything a rollback would leave behind. Restoring the old code doesn't undo every consequence.

Trying an implementation in a test environment with disposable data gives us room to get things wrong. Changing an interface that other teams already use needs more coordination. We should be explicit about that difference before deciding how much room the team has to proceed.

If we can answer a question by building and testing something in less time than we would spend discussing it, I'd rather do that. We still need to think through the consequences, but we should compare the time spent debating with the cost of actually finding out.

With those conditions in place, I think teams should have more room to try things. Requiring the same approvals for every decision can cost more time than the mistake we're trying to prevent.

What's happening to reliability?

I think reliability needs more attention as teams push to ship faster. Even large companies are having failures that disrupt the businesses depending on them. Are we putting the same effort into using agents to keep systems reliable as we are into using them to ship more?

We should be as deliberate about using agents to improve reliability as we are about using them to ship features. I'd have fresh agents challenge the implementation and test how it could fail, using the requirements as their starting point. They should be able to show when a concern is real and when the behaviour is actually correct.

That review can help us find problems the builder missed. Giving it to different agents is a useful start, but they still need to run checks that can expose an assumption they share with the builder.

I put a lot of weight on running the actual system and checking the result. After a change, I want us to exercise the affected behaviour, check what depends on it, and try the failure cases we have reason to expect.

The checks should follow the consequences. An internal page layout and a customer balance calculation need different levels of attention, even if both take an agent a few minutes to change.

I think we should judge that work by whether it checks the important failure cases and gives us evidence of what happens, including when requests time out or operations run twice.

Where are teams using agents this way, and are they seeing fewer failures? Which teams are shipping faster while keeping their systems reliable, and what are they doing differently? I’d like to have a roundtable with engineers who can share what's happening in their own systems.

What should engineering leaders spend more time on?

I want us to try more things where we can afford to be wrong, then check what we learned and stop work that is no longer useful. Someone still has to decide which attempts are worth continuing.

Once we've agreed on what can be tested and reversed safely, I think teams should be able to make those decisions with less approval. Engineering leaders can spend more time on the choices that affect other teams or customers, and on checking whether the work is producing the result we wanted.

I also think senior engineers should build systems around agents so the mistakes we catch become harder to repeat. That includes anticipating other ways the work could fail and putting checks around those too. I’ll write more about that in a separate article.

What has changed in your own team? Where are you comfortable accepting more mistakes now, and where has the ability to move faster made good judgment even more important?