Why Look at Code? Visuals for Code Review
There seems to be a practice on the rise, despite the discomfort many feel about it: using agentic development to deliver code without ever looking at it.
While being able to autonomously deliver code correctly and securely may be the ultimate goal of coding agents, the technology currently isn't at a point where it deserves blind trust.
Code review and verification have become a real bottleneck for software development, but the current diff-based approach just isn't always the right choice. For anything that isn't a change in text (like performance) the real root issue is that unless CI shows it, it's probably not getting reviewed… which means we're actually just hoping it's not getting worse.
Instead of prescribing an approach to managing this, let's instead explore how visual tools can transform the decision from "whether or not to do manual code review" to a more flexible middle way built from having more options.
Part of our vision is that by equipping people with better tools, it both enhances their decision making and makes them better developers by building experience and intuition for working with code.
Code review: more than just changes in text
When most people think about code review, they're thinking about scanning code line by line, but as Simon Willison just recently post, that's neither the best nor the only option.
Reading diffs is the most common way to understand code changes, but diffs aren't always the fastest or best tool for the job, especially when code changes are large. Instead, we turn to the visuals that are built to show the structure of code, such as control flow graphs and call graphs.
These tools allow a high-level understanding that complements the standard diff-based approach, especially when a code change involves adding or removing whole files, where it's helpful to see the structure of a file first before diving into code reading. It also allows engineers the ability to skim the changes, zooming in on the parts that are of most interest or highest in potential risk.
Understanding the ramifications of changes should also include understanding changes in performance, maintainability, test coverage. These are the things that are typically invisible even when reading every line of code, and in the cases they are measured, they're normally boiled down to text reports or numeric thresholds that feel arbitrary and disconnected, like "we require 90% line coverage for tests"... why is that the magic number, and what does that actually get us?
The best way to understand these facets is to incorporate them into visuals that tie directly to the code itself, which is what we've built VizDev to help with. We made it so you can go from code to code-linked interactive visuals in seconds, and incorporate meaningful measures as part of these visuals.
Visuals for code review and working at a higher level
The other side of the bottleneck is refocusing human attention and judgement at a higher level, increasing the demand for skills of understanding architecture and smart decision-making at that level of code. The current consensus is that this is where we really need human review, but how do we grow the skills and competence for working at this level?
One answer is to use tools like VizDev to see high-level views of code, and understand examples of good and bad design practices. These tools make bad design patterns appear as visual patterns that engineers gain the ability to recognize, such as spaghetti code actually resembling spaghetti, and overly complex functions appearing as a jumble.
Comparing a snapshot of architecture across repos is just the starting point though, the real application is in monitoring changes over time. Knowing when to intervene and refactor or rework components is a key skill for working at the architectural level.
As we previously mentioned, there's more to understanding changes than just text diffs, and being able to see the impacts on things like structure, performance, and maintainability give important insight… especially if you are using AI to help write code.
For example, you might notice that a big commit is completely missing meaningful tests or that your performance tanked because the agent inserted what it believed was a completely reasonable multi-second sleep to fix a race condition it inserted (which happened to us). There's a number of ways to address this, but our focus is on making intuitive ways to answer these questions easier.
Visual tools aren't a silver bullet though, an off-by-one error or or a bad regex are location-specific issues that cause real problems. But these kinds of issues are the sort of things that coding agents are best at finding and fixing. What's typically missing are the tools that help give humans the ability to better understand and make judgement calls, where and when they need it.
Feedback in the form of visuals goes beyond just a single fix, they also function as signals to improve processes, such as adding a guardrail on what appropriate performance thresholds are for different parts of a codebase. Further, this kind of feedback is a crucial part of building developer intuition, so their higher-level coding instincts get better over time.
These same practices aren't just the unpleasant programmer equivalent of running up stairs like Rocky, they also provide engagement that helps people feel involved with what they're building, so they feel like less of a meat proxy.
Building Choices and Processes
Using agentic development can be a powerful tool, but it also can encourage habits that are bad for code and bad for people. While the risks are unique to each situation, even if you aren't building high-stakes code, there's a big argument to be made for practices that reinforce human judgement and improve developer skills.
Our goal with VizDev is to give people the tools to gain visibility of different aspects of development so they can make educated decisions about risk and tech debt, rather than push people to believe in opaque layers of AI.
We believe one part of the software development paradigm of the future is giving people the tools they need to understand code at the level they need to work at, which starts with going beyond reading code as text. Check out our landing page to try out a new way of working with code
