ai code audit

What to Do When Your AI Agent Ships Something You Don't Recognize

The AI built something. It works. But you don't fully understand the architecture it chose. Here's the audit workflow: use Deepview to read the structural story, find the decisions worth preserving or reversing, and rebuild your mental model from the graph.

It happens to everyone who works with AI coding agents seriously: the agent ships something that works, passes tests, and solves the problem, but you look at the diff and realise you don't fully understand the architectural decisions it made. You don't know if the new utility function is a liability or an asset. You don't know if the refactor introduced a new community boundary violation. You don't know whether to be impressed or alarmed.

This is not a failure of engineering judgment. It is the natural consequence of working with a capable agent at speed. The audit workflow is how you close that gap.

Step 1: Read the structural story, not the implementation story

The diff shows you what lines changed. Deepview shows you what the architecture looks like now.

Open Deepview's Map view first. Look at the overall community structure: does the layout look significantly different from before the agent ran? Are there new clusters that weren't there before? Are there nodes sitting far from where their module name implies they should be?

This takes about 90 seconds and gives you the architectural gestalt: "something significant changed in the auth area" or "the changes were mostly within existing communities, no new cross-boundary edges."

Step 2: Find the structural decisions

Open Web view and navigate to the files the agent touched. For each significant file:

  • What is the blast radius now? (Compare to what it was before.)
  • Is it in the community you expected?
  • Did it gain any cross-community edges?

The structural decisions the agent made are visible in the graph topology changes. A new import that crosses a community boundary is a structural decision. A utility function that accumulated 10 callers is a structural decision. A refactor that moved a high-spikescore function into a new module is a structural decision.

None of these appear clearly in the diff. They all appear clearly in the graph.

Step 3: Rank what matters

Not every structural change is a concern. Some are improvements, the agent consolidated a god-object, or extracted a clean utility from tangled code, or decoupled a module that was over-coupled.

Rank the structural changes by significance:

  1. New cross-community edges (highest concern): these are explicit team-boundary violations or architectural decisions that affect multiple modules
  2. Spikescore inflation (medium concern): files that became significantly more central than they were
  3. New high-blindspot files (medium concern): new utilities that have accumulated transitive reach quietly
  4. Internal community changes (low concern): refactors that stay within community boundaries

Step 4: Decide what to preserve and what to reverse

For each concern, a decision:

  • New cross-community edge: is this intentional? If yes, document it in the Memory Tree. If no, refactor it out.
  • Spikescore inflation: is the new central utility appropriate? Add it to the keystone inventory. Flag it for test coverage.
  • New blindspot file: add a Memory Tree note: "This utility has high transitive reach, treat it like a keystone in review."

The decisions you make here become Memory Tree entries. The next AI session works from these constraints.

Step 5: Rebuild your mental model

After the Deepview audit, you should be able to answer: what was the architectural story of this session? What structural decisions did the agent make? What is the current community structure of the modified area?

If you cannot answer these questions, the audit is not complete. The goal is not "I reviewed the code", it is "I understand what was built structurally."

This understanding is what enables confident PR descriptions, accurate code reviews, and productive next sessions. "The agent added auth middleware that integrates with the existing session community, here's the blast radius of the middleware and here are the callers we need to verify" is a sentence that comes from structural understanding, not from re-reading 400 lines of diff.

The time investment

A thorough structural audit of an AI build session takes 15, 20 minutes. A quick structural check (Map view, boundary edges, spikescore changes) takes 5 minutes. The investment scales with the session's scope, a 2-file change needs a quick check; a cross-module refactor needs the full audit.

The time is worth it. What you're buying is the ability to extend the work confidently in the next session, explain it to reviewers accurately, and catch architectural decisions that would otherwise compound into problems quietly.

Webby
Spiderbrain's support assistant
Hi, I'm Webby. What are you building, or what brought you to Spiderbrain today?