Stop reviewing code. Start reviewing systems.

Ingmar Jager
Ingmar Jager
October 30, 2026
Engineering AI
The same pull request twice. On the left, an endless list of changed lines. On the right, a diagram with one new dependency in green, one removed in red and one module that moved in blue.

Many software engineers are going through an existential crisis. Everything that made writing software fun is no longer commercially viable. Hunting an esoteric bug for three days. Going from "this can't happen" to "that shouldn't happen" to "why does that happen?" to "oh, I see... how did that ever work?" All that fun is now eaten by Claude or his buddies. What's left is a five-page report of everything they ran into on its speedrun, plus a list of all the other potential bugs it found along the way.

Or the immense relief of finally winning the battle of lifetimes with the borrow checker, after pulling out most of your hair in frustration. That too is now one-shotted by your flabbergasting AI pal.

And so, little by little, the job of a software engineer is turning into something nobody signed up for: reviewing code. From feeling special and competent, to feeling like... well, someone with a job.

Now what? Seems like we're left with only two options:

  1. Keep doing this until burnout
  2. Start baking bread or doing pottery

I did start learning Tai Chi this year, which could serve as my backup plan. But I'm not quite ready to throw in the towel.

So perhaps there's another option. Maybe we're looking at the problem from the wrong level of abstraction.

Maybe the trick is to stop thinking of ourselves as programmers. Maybe we're system builders, or architects. Instead of writing every component ourselves, we design systems that produce reliable, high-quality software and solve the right problems. AI can help build the individual components. But someone still needs to make sure they fit together, make sense technically and serve the business goals.

So we're stuck reviewing anyway. Fine. Then let's at least review the right things and try to make it a bit more fun.

Code reviews

For now, skipping them is not an option yet. Unless you're okay with blindly shipping vibe-coded slop.

So what are the right things? At the end of 2026, we're less concerned with whether the AI got the syntax right, followed our formatting conventions or picked a sufficiently descriptive variable name. What we really want to know is:

  • Did we make sensible decisions about the architecture and code organization?
  • Did we introduce unnecessary dependencies?
  • Did we leak abstractions?
  • Did we change how data flows through the system?

In other words, we need to review the system.

Enter archdiff

So I built a tool. Well. Claude built a tool, and I reviewed it. You see the problem.

archdiff takes two git revisions and outputs an interactive HTML page that helps you visualize the changes. At a glance you see where the changes landed, and how they shifted the dependencies between modules and on third-party libraries.

From the pull request to the diagrams, on a real firmware PR
  • Green arrows are new dependencies.
  • Red dashed arrows are dependencies that disappeared.
  • A blue box is a module that moved.

Before you've read a single line, you can see what the PR did to the shape of the system.

archdiff Code view of a firmware pull request, zoomed into the storage module. New dependencies are green arrows, removed ones red dashed arrows. Two git dependencies are dashed purple boxes with their old and new commit.
The Code view, zoomed into the module that changed most

A 3,000-line PR almost never changes 3,000 things. It changes two or three things that matter, plus 2,990 lines of plumbing to support them. So archdiff finds those two or three. It starts at the top of the system and zooms in by itself where the structure changed most. From there you can click your way further in.

The System view

But code dependencies are only half the story. You can leave every import untouched and still rewire the whole thing at runtime. So there is a second tab: the running system. It shows the tasks, the queues between them and the message types flowing over each queue.

archdiff System view of RTIC firmware: tasks, interrupt handlers and queues. A removed queue is red, a new queue green, and queues whose message type or capacity changed are orange.
The System view of the same PR, on RTIC firmware

A new task, a queue that got rerouted, a capacity going from 5 to 32, a message type that quietly grew three new fields. They all light up in the diagram.

The System view understands Tokio backend servers and, because we are an embedded shop, RTIC firmware too, including interrupt handlers. The Code view reads Rust and TypeScript, so our Angular front-ends are covered as well.

How it fits into our workflow

archdiff runs as a GitHub Action. Every PR gets one comment with a summary and a link to the interactive diagrams. That keeps the friction of actually using it as low as possible. It's open source, so feel free to try it on your own repo.

The diagrams show you which code is still worth checking and zooming in on. That makes a review faster. And building it was fun.

Turns out, building tools for reviewing AI-generated code can be pretty fun too. Perhaps that's the trick. As AI takes over more of the implementation, we need better tools to focus on the parts that still require engineering judgment.

We'll be testing and fine-tuning archdiff at Jitter over the coming months.

Tai Chi stays the backup plan. For now.