When implementation becomes cheap

When implementation becomes cheap, engineering judgement becomes relatively more valuable.

We can produce working code much faster, but we still need to decide whether we are solving the right problem, whether the approach makes sense, and whether we understand the consequences well enough to ship it.

I think a founder looking at AI agents is right to ask why the team isn't doing more with them. If a developer can have several agents investigating, implementing and testing at once, there is an opportunity to take on work that would otherwise sit in the backlog, or explore ideas we previously couldn't justify spending time on. It would be strange to have that capacity available and carry on as though nothing had changed.

The part I want to understand before adding more work is how much of it the team can actually think through. Having an agent finish an implementation sooner is useful, but if the engineer responsible for it is still trying to understand the implications of another change, we may just be building up work for them to review. Depending on the decisions already made along the way, some of that work may also need debugging or undoing before it is useful to anyone.

Reviewing the code can already be too late

If the plan was wrong, we may be carefully reviewing an excellent implementation of a decision that should never have been made.

Suppose an agent is asked to add a capability and builds it without first discovering that most of it already exists elsewhere in the application. If we review the result against the request, there may be very little to object to: the code does what we asked, its tests pass, and the agent can give a reasonable explanation of how it works. We might approve all of that and still leave ourselves maintaining two implementations, because we never properly considered whether a new one was needed.

It gets harder when the reason for the existing behaviour isn't obvious from the code we're changing. A condition that looks unnecessary may be there because older records need to be handled differently, in which case removing it could look like a perfectly sensible simplification until we follow one of those records through the system. We might also discover that another workflow relies on the behaviour we were about to remove. Those are things I would want us to understand while deciding on the approach, when we can still question whether the proposed simplification makes sense, rather than first encountering them while reviewing the finished implementation.

For work with consequences like those, I want the responsible engineer involved before execution, with enough understanding of the problem to examine what the agent has found and challenge the proposed plan. If the approach depends on older records behaving a particular way, for example, I want to know whether we have checked that behaviour or simply assumed it. That gives us a reason to investigate further before committing to a change.

The agent can do much of that investigation and help us scrutinise its proposal by finding the relevant code, tracing the behaviour and looking for cases that might undermine the approach. The engineer then has evidence to work through while the decision is still being made, rather than having to reconstruct the reasoning from an explanation attached to the finished implementation.

Nor would I treat an agreed plan as permission to stop thinking about it. If implementation reveals an unexpected dependency, we need to consider whether that changes the approach, and when the work comes back I still want to assess whether it does what we intended in light of what we have learned along the way.

Not every task deserves the same attention

If we are exploring an interface with disposable data, I'm comfortable having several agents try different layouts and interactions. Fifty, if there is a useful reason to explore fifty. I can look at what comes back, try it, and discard the versions that don't work without needing to understand every decision that produced them. There is very little cost to getting one of those attempts wrong.

I would take a different approach to changing a central payment flow that synchronises invoices and payments into customers' accounting systems. Before letting an agent change that behaviour, I want to understand how we handle partially paid invoices and what happens when a request is retried. If the accounting system accepts an update just before our connection drops, for example, we need to know how the next attempt avoids applying the same payment twice. That investigation also needs to account for historical records that may follow different rules, or another job that modifies the same records.

If we have only considered what happens to a newly created invoice, we can produce an implementation that works perfectly in our tests without learning much about those other cases. This is where I want the engineer to slow down and investigate, because discovering the mistake after deployment may mean repairing records in somebody else's system. Reverting our code would stop the new behaviour, but it wouldn't necessarily put those records back as they were.

How much scrutiny I want therefore depends on what we could get wrong and how we would find out. A small payment change may need considerable investigation because an error could be difficult to notice and expensive to repair, while a much larger amount of disposable interface code may be straightforward to assess. The amount of code involved doesn't tell us much about the attention the decision deserves.

A target such as "every developer should run eight agents" tells us almost nothing. We need to know what those agents are doing and what happens if their work is convincingly wrong.

More agents do not have to mean more problems

There is no reason that closer scrutiny has to mean using fewer agents. For that payment change, we could have one tracing the existing synchronisation behaviour while others examine historical migrations or investigate retries and partial failures. We could also ask agents to look for dependencies we have missed, or challenge the proposed approach using what the investigation has uncovered.

The engineer would still need to work through those findings, check the evidence and resolve any disagreements, but they would be doing so while staying with the payment problem. Something found in the migrations might explain the behaviour another agent traced, or give us a reason to question an assumption about retries. The parallel work can help the engineer build a fuller understanding of the same change.

That is very different from asking the same person to supervise unrelated changes to payments, authentication, reporting and permissions, with each agent returning questions and decisions at different times.

In the developer discussions that prompted this article, people described switching between several agent sessions every few minutes and finishing the day more exhausted than when they wrote the code themselves. What interested me was how little opportunity that left them to stay with a problem. I wouldn't infer a universal limit on concurrency from those accounts, but they do make me question how much sustained reasoning a workflow like that allows.

When an agent comes back with a question about payments, the engineer may have spent the last few minutes thinking about permissions. Before giving it an answer, they have to recover enough of the payment context to understand why the question matters, and they may be interrupted by another task before they have done that properly.

The agent hasn't lost its context. The engineer has.

Part of working through a difficult change is making connections as we go. Something we discover now may explain a condition we read half an hour earlier, or remind us of another path through the system that would be affected by the proposed approach. If we keep leaving the problem, it becomes harder to hold enough of that understanding in mind to notice when a new finding changes what we thought we knew.

My concern is the point at which an engineer stops evaluating a proposal against their own understanding and starts relying primarily on whether the agent's explanation sounds reasonable.

A summary can help someone return to the work, and batching reviews may give them fewer interruptions to deal with. I would use both where they help, while being careful about how much confidence we place in the summary itself. If the agent overlooked a dependency, its account of the work may give the engineer no reason to look for it either. For a consequential decision, I want the person supervising it to have enough understanding to question that account, including the things it may have left out.

The solution is documentation. Or is it?

It is reasonable to argue that agents would make better decisions if we gave them better documentation. I agree, although I think we need to be careful about what we expect that documentation to settle. An architectural decision record tells us why we made a choice at a particular time; it doesn't necessarily tell us whether that choice still applies to the work in front of us.

Suppose ADR-27 says that all payment updates should follow one synchronisation path, but six months later ADR-49 introduces a replacement. If a subsequent migration moves most records across while preserving the old behaviour for some historical invoices, both decisions may still be relevant. Telling an agent to "read and respect the ADRs" leaves it needing to establish which decision applies to which records, whether the migration finished, and whether later work changed any of those assumptions. It could follow either document faithfully and still propose something that is wrong for part of the system.

We can make that investigation considerably easier by marking decisions that have been superseded and explaining where exceptions still apply. Keeping the current guidance up to date, and making the relevant material easy to find, would save both agents and engineers from having to reconstruct that history every time. AI can help with maintaining it too.

Even then, we may come across behaviour that disagrees with the documentation and need to work out why. It could be a mistake in the code, but changing it on that assumption would be a problem if it actually reflects an intentional exception that was never recorded properly. Establishing whether the implementation needs correcting or the documentation needs updating can require exactly the investigation and judgement we were hoping the documentation would spare us.

Better documentation reduces the amount we have to rediscover. It does not remove the need to decide what should happen now.

What we do with the recovered time

More code means more code somebody has to understand, even when AI helps with the reading. If implementation gets faster, it is quite reasonable for a team to spend more of its time reviewing, integrating and testing the result. I would want to understand whether that time is helping us deliver better software or being spent working through changes that needed more thought before they were implemented.

The distinction matters when we assess whether the workflow is helping. If more useful software is reaching production and we can support it without creating an unreasonable amount of work afterwards, that is a useful gain. If the additional output leaves us spending the recovered time debugging and repairing it, the number of active agents or lines of code won't tell us much about whether we are better off.

One of the opportunities I find most useful is having time to investigate questions we would previously have rushed past. We can ask agents to explore an alternative before we commit to an approach, or reproduce a failure scenario that would once have taken too long to set up. That gives the engineer more to work with when deciding how to proceed, and may be a better use of the recovered capacity than immediately taking on another feature.

There will also be work where running more features in parallel makes sense, particularly when the results are straightforward to assess. What I don't want is for every saved hour to become another unrelated task by default, before we have considered whether the engineer needs that time to think through the work already in front of them. As engineering leaders, we have a say in how that time gets used.

If I'm asking an engineer to approve a consequential change, I expect them to be able to explain why we're taking that approach, what we've checked, and what we're still uncertain about. I also need to give them enough time to actually reach that understanding.

The AI isn't putting its name on the production deployment. The engineer is.

If a change damages a customer's accounting data, it is the team that has to work out what happened and explain how it will be repaired. We can use AI to help investigate and fix the problem, just as we used it to make the change, but we are still the people who decided that the change was appropriate to release. That responsibility needs to be reflected in how we organise the work before it reaches production.

I want us to use machine capacity aggressively, including to give engineers better information to think with. Where a result is easy to assess and inexpensive to get wrong, I'm comfortable letting agents run and selecting what is useful. Where the consequences are harder to understand or repair, I'd rather use that capacity to investigate the problem thoroughly and give the engineer room to stay with it. Both can make good use of AI, provided the person responsible for the change has enough understanding to stand behind the decision.

If you are working out how to use AI more extensively in your engineering team, tell me what's going on. We can look at where greater autonomy helps and where the work deserves closer attention.