When code becomes cheap, design has to become easier to review

Wed, 19 Aug 2026 00:00:00 +0000

In my previous post, Software solutions do not start with code, I wrote about the work that comes before implementation: understanding the real problem, finding the constraints, and keeping a useful mental model of the solution alive.

I have been thinking about what follows from that when code is much cheaper to produce.

Listening to Gergely Orosz’s conversation with Charity Majors, I kept returning to one idea: as AI makes code cheaper to produce, code may become a less useful primary artifact for review. Majors points toward lessons from operations and QA, where confidence comes from evidence that a system behaves correctly, not only from reading its implementation.

That made me think about the work that needs to happen before a large diff appears.

An agent can turn a short conversation into a large pull request. That is useful, but it changes where the bottleneck sits. The team may be able to generate more implementation than it can properly understand, review, and support.

Code still matters. It is where the system becomes real. But a large diff is not always the best first artifact for a team to review.

The review bottleneck moves upstream

For a long time, writing code was expensive enough that the code itself carried much of the design conversation. A careful engineer spent days or weeks producing a change. By the time it appeared in a pull request, many of the decisions had already been made along the way.

That was never ideal. Important assumptions could still stay hidden until late in the process. But the pace gave people time to discover them.

AI removes some of that delay. It can generate a reasonable first implementation very quickly, sometimes before the engineer has fully tested their own understanding of the problem. The result may compile, look familiar, and include tests. It may still solve the wrong problem, preserve the wrong assumption, or add complexity that the next person will have to untangle.

This is why I do not think the answer is to ask reviewers to read faster or to approve more code. The answer is to make the decisions behind the code easier to see earlier.

A shared model gives the team something better to discuss

Before starting a meaningful change, I increasingly want a small, reviewable description of the solution. Not a heavyweight document and not an architecture diagram for its own sake. The useful form depends on the work.

For one change, it might be a short note that answers a few questions:

What user or business problem are we solving?
What must stay true when the change is complete?
Which existing systems, contracts, or data are affected?
Where are the risks or unknowns?
What would make us change direction?
How will we know, in production, that the change behaves as expected?

For another change, the right artifact might be a sequence diagram, an API contract, a migration plan, or a short prototype. The point is not the format. The point is that the people involved can look at the same model, challenge it, and improve it before an agent produces hundreds of lines around it.

The same principle applies when directing an agent: the useful context is more than a prompt. It is the problem, constraints, relevant history, and checks the agent needs to work within. I explored that in In agent systems, context matters more than the prompt.

This makes the questions in review better. Instead of only asking whether a particular class, condition, or query looks right, we can ask whether the proposed change protects an important invariant. We can ask whether a migration is reversible. We can ask whether the behaviour would still make sense when a dependency fails or a customer has unusual data.

Those are the questions that shape the system. They are also much easier for a team to answer together when the intent is explicit.

Turning assumptions into validation points

My team took on a cross-team task: building a pipeline whose input came from the RAW layer of a layered data warehouse (RAW, CLEAN, CORE, and MART). Its output had to land in the CORE layer, where another team would use it to build further MART tables.

Before we wrote code, we had to clarify many questions. That work may have taken more effort than the implementation itself.

We had to work out which business process the pipeline supported, and what the source data actually represented: how the data was created, and what separated a valid record from an erroneous entry. Then how the output would be used, which systems it would affect, and which data contracts we had to honour.

The pipeline implemented a data-science method. It communicated with an external LLM and an external predictive model. From the rest of the system’s perspective, it appeared as a black box, but its nodes and internal milestones still had to meet data-validation requirements.

This was a greenfield development, so we could not predict its performance or scalability in advance. Before implementation, we agreed with stakeholders on the load it had to carry: 3 million input records per month, with peak days rising to between 200,000 and 300,000. The peak mattered more than the total. It is two to three times the daily average, and it was the number that shaped the design. From there we defined within the team what good performance meant, and what we would treat as unacceptable.

Capturing these conditions gave us stable validation points once the code had been generated.

Code review still matters, but it cannot carry everything

I do not see this as a replacement for code review. The implementation can still introduce bugs, miss edge cases, or fail to follow the team’s conventions. Tests, static checks, and a careful review remain useful ways to catch those problems.

But code review is already asked to do too many jobs. It is expected to validate correctness, teach less experienced engineers, enforce conventions, catch security issues, confirm operational readiness, and make sure the change solves the original problem. More AI-generated code will make that pressure stronger.

Some of those concerns are better handled by shared guidelines and automated checks. Others need a conversation before the implementation exists. The reviewer should not have to reconstruct the entire product and architecture decision from a diff.

This is how I now understand the earlier idea that judgment is the job: judgment should show up in the design, the checks, and the evidence behind a change, not only in a final read-through of the diff.

This is also where a good engineer can help the whole team, not only the change at hand. When a recurring decision becomes visible in a design note, a test, an agent instruction, or a team convention, the next engineer starts with better context. The next review starts from a stronger position too.

Production belongs in the design conversation

There is one question I want to see more often before implementation: how will we know that this works after release?

The answer is not always a dashboard. Sometimes it is an acceptance test, a log record, or a clear rollback condition. The important part is deciding it while we can still influence the design.

This matters more with AI-assisted work. The faster we can produce changes, the easier it becomes to create more behaviour than we can hold in our heads. Production feedback gives us a way to test the model we had when we wrote the change against the system customers actually use.

I find this part of engineering increasingly interesting. It connects the early work of understanding the problem with the later work of owning the result. It also gives AI a useful place in the process: it can help explore options and implement a chosen direction, while the team stays responsible for the model, the evidence, and the trade-offs.

I am still working out what the smallest useful version of this practice looks like. I do not want every change to require a design ceremony. I do want us to be more deliberate when the decision is expensive, difficult to reverse, or likely to affect people outside the team.