Sustainable AI Engineering

The previous paper argued that capable coding models change software engineering in a subtle but important way. When implementation becomes inexpensive, understanding becomes increasingly valuable.

That paper focused on principles rather than process. A natural question follows: what does this actually look like during an ordinary week of software development?

This paper is one possible answer. It does not describe a methodology, nor is it intended to prescribe particular tools, models or organisational structures. Instead, it illustrates how the principles from the previous paper increasingly appear during everyday engineering work.

Different teams will organise themselves differently. Some will use specialised coding agents. Some will use several engineers. Others may rely on one engineer deliberately separating different kinds of work across multiple conversations. Those details matter less than the responsibilities being separated.

The workflow described here is therefore an illustration rather than a recommendation. Its purpose is simply to make the earlier ideas concrete.

The work usually begins with something unremarkable. A bug report. A feature request. A refactoring. Perhaps a failing integration. Nothing about the ticket itself suggests a different way of working.

The temptation is also familiar. Read the ticket. Find the affected files. Start making changes. That instinct served software engineering well for many years. These days I find myself resisting it.

Not because implementation has become more difficult. Almost the opposite. Implementation has become inexpensive enough that spending it too early often creates more work than it saves.

The first question is no longer:

"How should I implement this?"

It is:

"What problem am I actually trying to solve?"

That distinction appears small. In practice it changes almost everything that follows.

A technical briefing is only useful if someone thinks about it. That responsibility still belongs to the engineer.

Alternative approaches are considered. Trade-offs become explicit. Questions that were previously implicit are answered deliberately. Perhaps most importantly, verification is discussed before implementation begins.

How will we know that the change is correct? What evidence should exist before the work is considered complete?

Thinking about verification this early often changes the implementation itself. Sometimes the simplest solution is also the easiest to verify. Sometimes a more ambitious implementation introduces uncertainty that the ticket never required.

The result of planning is not certainty. It is a shared understanding of what change is actually intended.

Only now does implementation begin. By this point, much of the difficult engineering has already happened. The uncertainty has been reduced. The trade-offs have been discussed. The intended behaviour is understood well enough that implementation becomes comparatively straightforward.

The builder's responsibility is no longer to explore the problem. It is to realise an agreed direction. The work remains deliberately bounded. Small changes remain easier to understand, easier to review and easier to verify.

Planning and independent judgement solve different engineering problems. Planning separates understanding from implementation. Independent judgement introduces a perspective that did not participate in the work.

That distinction existed long before modern coding tools introduced dedicated planning modes. Many teams already separated architecture from implementation, design from review, and testing from development. Sometimes this happened through different engineers, sometimes through different conversations, and sometimes simply by allowing time to pass before revisiting a decision.

Modern coding tools increasingly appear to be evolving in a similar direction. That is an interesting observation, not proof that any particular workflow is correct.

Independent judgement has always been valuable. Anyone who participated in an implementation naturally shares many of the assumptions that emerged while doing the work. Someone approaching it independently may not. That difference often matters.

Architecture reviews. Code reviews. Testing. Pull requests. They all introduce a degree of independence.

The purpose is not to prove the implementation wrong. It is to expose assumptions that the original implementation may no longer notice.

Eventually the question changes again. No longer "What should we build?" Nor "How should we build it?" Instead:

"What evidence do we now have?"

Tests execute. Review comments are resolved. Behaviour is observed. Existing functionality remains intact.

Sometimes additional investigation is required. Sometimes assumptions made during planning turn out to be incomplete. That is not failure. Verification exists precisely because implementation can still surprise us.

The goal is not to eliminate uncertainty completely. It is to replace as much of it as possible with evidence.

Executable evidence is especially valuable because it can be repeated tomorrow. And next week. And by someone who was never present during the original implementation.

Very little in this workflow is actually new.

Architecture reviews are not new. Code reviews are not new. Requirements discussions are not new. Testing is not new. Pull requests are not new. Independent review is certainly not new. Mature engineering organisations have relied on these practices for decades.

What has changed is their importance.

When implementation was expensive, it was tempting to shorten or skip some of these activities in the interest of delivery. Today the economics are different.

Implementation has become dramatically cheaper.

The cost of misunderstanding has not.

As implementation becomes less scarce, understanding, judgement and verification become proportionally more valuable. In that sense, AI has not replaced established engineering. It has increased the value of it.

Eventually there comes a point where no further work appears justified. Not because the software is perfect, but because the remaining uncertainty has become acceptable.

The code is merged. The ticket is closed. The responsibility does not disappear. The team now owns the change.

That ownership is ultimately what the entire workflow has been working towards: understanding before implementation, planning before coding, bounded change, independent judgement, verification through evidence.

None of these exist to slow development. They exist to ensure that increasing implementation speed does not reduce understanding.

The workflow described here is intentionally ordinary. There is no dependency on particular tools, no prescribed number of engineers and no requirement for particular models.

Only a recurring observation.

As implementation became dramatically less expensive, many established engineering practices became increasingly important.

The exact workflow will undoubtedly continue to evolve. The tools certainly will. Modern coding environments already appear to be moving towards clearer separation between planning and implementation, much as many teams had already begun to do through experience. That is an interesting observation, not validation.

The principles matter more than the tooling. Different organisations will almost certainly express them differently.

If this paper succeeds, I hope the reader does not finish it believing they have learned a new methodology. Instead, I hope something quieter happens.

That they recognise familiar engineering practices becoming steadily more valuable in a world where writing code is no longer the most expensive part of software development.