What Code Review Really Means

My idea of what a code review is has changed considerably over a career spanning more than twenty-five years. At Thoughtworks, we practice trunk-based development, test-driven development, and pair programming rigorously, which means code review isn't a distinct ceremony. It has always been light and low-effort for us because the benefits you would otherwise get from it happen organically during pair programming. When you develop on trunk, you don't hold a branch for weeks, and when you write tests sufficiently, a passing pipeline is a strong signal.

Earlier in my career it was the reverse: as a junior developer, someone with far more context, knowledge, and experience would review my code, suggest better approaches, and use the moment to teach. I valued that, and all of it remains relevant and valuable.

The disruption now is the sheer volume of code we can generate and the question of how to keep this practice meaningful without clinging to older beliefs about how it should be done.

Code Review Beyond Pre-Integration

The trajectory has been that code review once meant something broad, and now, by default, everyone treats it as something that happens pre-integration. That is the only place we do it — not before, not after. It has become almost muscle memory: that is the stage we review at, and we assume it is the only stage we should.

There has long been thought leadership arguing that this shouldn't be the only place, but there was never a forcing function to put it into practice. Now that powerful agentic AIs and agentic IDEs help us produce far more code, everyone is reconsidering it. These agents write code so well that, for the most part, its correctness and integrity hold up.

The gap most often originates at the moment the developer expresses intent to the IDE. That is where you want to catch it.

And we know how expressing intent tends to go; it’s often ten or twenty markdown files per feature. How do you review that? Most of the time we don't even version-control those files. So the definition of what is worth reviewing has shifted: some people review only the specs, some review specs and code, and others simply test the running system because the volume is so much greater.

Managing the Volume

How we review is changing too, purely because of volume. Anyone accustomed to reviewing changes knows that once a change spans more than five pages, it becomes difficult for a human to connect what was intended with the changes across several files. Now imagine that multiplied at least tenfold.

The way we visualize change has to evolve. It is no longer just the diff and the ticket; a human now needs far more inputs to review to the same standard as before.

You want to see the original intent, the path the agent took,  the agent traces,  and the resulting code. Did it follow the ADRs, and where are the ADRs in the workspace? You begin to need a broad dashboard simply to review at all. Some teams apply the lever at the front end, reviewing only the spec and trusting the rest. Others still review every artifact, while acknowledging that doing so is becoming a bottleneck in itself.

From Teaching Agent to Code Review Agent 

I built an agent that wasn't really about code review; it was designed to catch anti-patterns and explain them to the developer against my team's archetype. Knowing that archetype, I could instruct it to review code against the practices in our reference document, identify where the team was deviating, and explain why the deviation would be detrimental. I built it as a teaching agent more than a review agent, though it gradually evolved into one.

It then occurred to me that this shouldn't be caught late, after the commit. Code review, whether done by a human or an agent, has to happen much earlier, and it need not even be a review. It can be rubber ducking or a teaching moment.

It also gives developers the space to ask basic questions of an LLM, which so far does not judge them. The aim is to pull this as far left as possible, reducing the work required further down the line. 

Visualizing Front-End Change

I've observed something similar across front-end work. I have a number of teams doing front-end and mobile development, and what has fundamentally shifted is their ability to visualize changes with modern tools like Figma and Replit. They can build concepts and prototypes far faster, and the assets from the prototyping stage can be developer-ready.

So reviewing UX and UI changes is shifting too, because you can now visualize them directly using other tools.

The Return of Collective Ownership

This is a moment of reckoning. Practices people have written and spoken about for years are finally coming to fruition, and collective code ownership is among them. We have always said that no single person on a team should hold all the knowledge and that work shouldn't stall if that person wins the lottery. But few teams truly worked toward it; we were often content with one person holding all the context and enjoying the attention.

Now the knowledge everyone once kept in their heads is going into markdown files or knowledge graphs and being fed as context to whatever model is doing the work. Collective ownership is returning so we can get more mileage from the models.

There is a real trade-off, though. Capturing tribal knowledge as enterprise context — for instance, that a date-handling library has existed for years and should be used — scales well, but it also removes an opportunity for collaboration that once sat with the humans.

Harness Engineering: Platform Engineering for the AI 

This all comes back to what Birgitta Böckeler at Thoughtworks calls harness engineering. You harness your system so well, both before code is written and after it is deployed, that the amount of review any individual has to do is drastically reduced.

The way I explain it to my teams is that it is simply platform engineering for the AI era. We all have platforms; we know how a pipeline should look, which security gates it needs, and how many stages it should have depending on the industry and the software. Harness engineering applies an AI layer on top of that.

For example, you can run Claude Code as a GitHub Action in your pipeline, so that every piece of code the agent emits is checked. When a security scan or a SonarQube run finds a vulnerability, that finding is fed back to the agent writing the code, and the repeated errors and patterns stop recurring.

In the past, feedback only moved forward:  if a test failed, you stopped. You never returned it to whoever wrote the code, because that was a human. Now an agent can receive those logs and alerts, correct itself, and avoid repeating the same mistakes.

Harnessing the pipeline and harnessing the IDE together form the practice of harness engineering. It is a natural progression: we have done platform engineering for years, and this is how it evolves for the AI era, when far more code will flow through the pipeline. The question becomes who catches it and how.

Anthropic and OpenAI have given us the means to do this, but it remains the engineering teams' responsibility to assemble, guardrail, and harness it and to prevent it from becoming a free-for-all, because once that happens, it is difficult to reverse.

Rather than thinking about building software, think about building the machines that build software.

The Next Evolution of the Platform

A colleague and I were building a team topology diagram for a client engagement. There is always a platform layer, and until now it has meant delivery infrastructure — a CI/CD team or a cloud infrastructure team. We began drawing an entirely separate box, still called platform, for the agentic developer platform: where developers are guided toward the right frameworks and models, where cost controls live, and where the guardrails for agentic development sit.

We soon realized it won't stay two separate boxes for long. It will compress into a single platform covering CI/CD, runtime infrastructure, and the guardrails for agentic development,  except it will extend further left in the lifecycle, since the platform previously began at the first commit.

Until recently, the platform space was highly automated and relatively untouched by AI; there wasn't much hand coding to be done there. Now that AI code is being generated at scale, teams are recognizing that platform engineering is where the answer lies. That is where the controls sit, and it is the next evolution. Now is the time.