@kentcdodds: There was some, but not of the code

@samuelagm There was some, but not of the code

https://t.co/TDUuyQBnBd

TL;DR: Stop relying solely on code diffs for reviews; use AI agents to generate a visual system recap that shows how the whole system changed, based on primitives.

The Code Review Debate Is More Nuanced Than It Seems

Should you still be looking at git diffs? According to Kent, you should probably stop doing that — at least as your primary review mechanism.

The conversation around “reading your code” is more nuanced than many people present it. Some argue you absolutely must read every line and write every line yourself. Others say you should never look at code diffs because it’s a waste of time. The truth is a spectrum. It depends on:

• The situation you’re in
• How important the project is
• How many people’s lives are on the line if you mess up

Still, Kent believes we are trending in one direction: more and more of us can stop reviewing code diffs so much and instead start reviewing the system and how the system is changing.

The Idea: Visual System Diffs

This lines up with something Kent saw recently on X from Steve over at Builder.io. Steve built a skill that generates a kind of “system diff” or visual change of not just the UI components, but the system at large.

Kent tried it out and realized it actually uses a hosted service which you can self-host. It’s open source. But there are a lot of things about that system that don’t work the way Kent wants to work. For example, it’s a GitHub Action that runs automatically on every PR and then spins up an environment where you can play around and see what the system looks like. That’s cool, but Kent prefers having the agent that worked on the work generate those diffs instead. So he built his own mini version of this.

Why Cursor Inspired This Approach

Part of the reason Kent wanted to do it this way is because he’s already getting a lot of value from Cursor and how Cursor handles this with its environment.

When you have a Cursor cloud agent, it has a legit environment that can:

• Pull up your web app
• Pull up a mobile emulator, if you’re doing mobile development
• Take screenshots
• Give you a video of the whole experience

Since the agent is already generating summaries, Kent asked: “Why don’t I also have it generate this system recap?”

The System Recap in Practice

Kent shows a real example from when he was adding MCP support to Cody. MCP lets you add MCP servers to Cody and access those servers all through Cody. Cody acts as a proxy for those MCP servers, in addition to everything else it does.

The system recap classifies the change. For example:

• “This adds a new primitive. This is high risk.”
• “This removes a primitive. Also big.”

This ties into Kent’s other video about primitives and system design. A primitive is a core building block of the system, and understanding primitives is essential to how this whole approach works.

The recap covers:

• The classification of risk based on primitives
• Which primitives were touched
• A system map showing how the primitives are related
• A change flow showing the whole user experience

Change Flow Example

For the MCP feature, the change flow described the user experience in the browser: the user posts an add, the worker has app routes that add a server with a callback URL connected, and then the whole OAuth flow happens.

This helps Kent understand:

• What the agent was thinking
• How the agent interpreted the prompt
• How the agent ultimately built the system it built

That is super helpful. AI code reviewers can still make sure the code isn’t doing weird things, but through the lens of the system, Kent can get a solid understanding of what is actually trying to be changed. When the bot is doing something weird, he can guide it to make the right decisions.

Saving Time With Visual Recaps

Kent admits he could probably derive the same understanding himself by looking at the files changed. The skill does update documentation, so he can get an idea of that. Then he could go through all the code changes, and migrations are often really helpful too. But all of those things are visualized in the system visualizer.

For the MCP change, there was not a small amount of code added. Having an AI reviewer plus a visual look and feel for the UI pieces plus a visual recap of how things are intended to work was super helpful.

Simple Changes, Too

Sometimes it’s actually really simple. For an “add MCP onboarding page and banner for new accounts” change, it was not that complicated as far as the system goes. That change was composing existing primitives, so it was low risk.

The recap showed:

• Classification: composing
• Primitives touching: all made sense for the task
• System map: how the different pieces work together
• Flow: how it’s supposed to work for that user

That makes it much easier than looking through the 18 files that were changed. Even though it was a fairly simple change, most of it was UI stuff, which Kent largely gets out of the demos and things Cursor is going to make for him anyway.

Primitives Are the Foundation

This only really works if you have a good set of primitives to start with. Especially at the beginning of a project, Kent says he is really careful about how he structures things. He makes sure it’s obvious:

• Where new primitives need to go
• What primitives are available
• What primitives need to be combined

He is actively thinking about what primitives to create, combine, delete, or expand. Once you have a really good playground for an agent to play in, you can hand off a skill to the agent. The agent can do the task, then use the skill to generate this report for you.

The durable skill here is having a solid understanding of the system in which your software is operating and your agents are working with, so you can ultimately deliver the product that your users need to do whatever job they hired your product to do.

Published: Visual Recap Skill

Kent has published this on GitHub. It’s under KCD skills on his personal org, and it’s named “visual recap.” It was significantly influenced by what Steve did at Builder.io.

You can follow through, borrow the parts that make sense for you, and have your agents generate this kind of visual diff or visual recap of the changes that have been made. That gives you a much better experience reviewing things.

You might still continue to review the code, and that’s totally fine. But having a system review helps a ton.

Homework

Kent’s homework for this episode of Better with Kent:

• Try the skill
• Or hold off on the skill and just link your agent to this skill, saying: “Hey, can you generate this for me?”
• See how it goes
• Iterate and make your own version of the skill

The beautiful thing about skills is they’re just markdown files. You can copy and paste them. Feel free to try that out.

Source: @kentcdodds: There was some, but not of the code