Tool Comparisons

You need to explain an appointment booking system. A customer uses the booking service, the service sends a confirmation through an email provider, and someone reviewing the diagram needs to know where your system ends, because the email provider belongs to somebody else.

I'd start with that boundary. For a README, Mermaid is my first choice. If several diagrams need to describe the same system, I'd look at Structurizr before maintaining each view separately.

Pick the workflow before the tool

Before I trust an architecture map, I pick an arrow and try to explain it. If it says checkout depends on accounts, I want to open the importing file, see what it imports, and check that the map describes the revision I'm working from. That's a more useful starting point than the size of the graph.

For this shortlist, I'm looking at tools that recover structure from implementation, plus one that maps how code changes together over time, because those relationships answer different questions. The candidates are dependency-cruiser, Sonargraph, Lattix, NDepend, CodeScene and Pharaoh (ours). I build Pharaoh.

Decide what a connection means

A code dependency graph gives you a place to start. Before comparing tools, write down what you need an edge to represent, whether that's a file import or a function call, and decide how far you need to trace it. Don't assume every graph answers the same question.

For explaining a design, use architecture diagram and diagram-as-code tools, and for rules about allowed dependencies, see tools that check architecture conformance and drift, keeping this trial focused on recovering the relationships you want to inspect, before deciding which ones to allow.

Tools to put through a repository trial

Say your domain code imports an HTTP handler. The import resolves, the application builds, the tests you ran pass, and the dependency still violates the boundary your team agreed to keep. Where does that agreement get checked?

That's the question I'd use to choose architecture analysis software. I want a finding I can trace to a rule, or a reason to spend refactoring time in one module before another.

If you need to discover the structure first, start with mapping architecture from code, inspect the modules it reveals, decide which dependencies your team intends to allow, and then return to the rule checks here.

Choose by the question you need answered

For this comparison, conformance means checking implementation against an explicit rule, drift means tracking departures from that agreement as the code changes, and risk analysis helps decide where to investigate or change code first. Those jobs need different evidence.

The caller list for checkAdminOrOwner spans four modules, with an API service, a connected-apps helper, a tRPC handler and four web components. Before changing its permission logic, I'd inspect all seven.

That's the kind of answer I want before an assistant starts changing code.

I build Pharaoh. It maps repositories into a graph that an assistant can query over MCP, with functions and their callers, module dependencies, endpoints and cron jobs available as structural context.

What architecture intelligence means in software

My working definition of architecture intelligence is queryable information about how a codebase connects, tied to a known revision, detailed enough to guide an edit, and explicit about what the map doesn't cover.

A useful answer should let me open the relevant code. If it names a dependency, I want the file behind it, the direction of the relationship, and enough detail to check whether the proposed change affects that dependency.

I use a code knowledge graph to inspect those relationships before changing an export.

There's a judgment call left over. A caller relationship tells me where to investigate, but deciding whether an authorization rule belongs in a shared helper, for instance, requires an explanation of the intended behavior.

Cody Free and Pro ended on July 23, 2025, and Enterprise Starter workspaces lost Cody the same day, so a small team that relied on Cody needs a replacement, even if the assistant worked well, and even if nobody wanted to change tools. Cody Enterprise wasn't affected by that announcement, and the same post named Amp as the path forward for Free and Pro users; Sourcegraph announced on December 2, 2025 that Amp would become a separate company.

The browser changed too. Sourcegraph's 7.0 changelog of February 25, 2026, says Deep Search is replacing Cody in the browser for Deep Search customers, while Cody continues as a coding agent in the editor, which matters if you remember using Cody on the web or you're following an older setup guide.

I'd start by writing down what you used it for. A team that needs to locate an implementation has a different shortlist from one that wants an agent to edit it.

Choose the job before the replacement

Take a proposed change to formatBillingDate. The implementation might look reasonable, the reviewer might suggest a useful fix, and you can still finish the review without knowing which invoice path needs testing, because that caller wasn't part of the discussion.

I'd start there when choosing among the best AI code review tools. Can the reviewer explain the consequences outside the diff, and can you check its answer?

I build Pharaoh. It supplies structural repository context over MCP and offers PR checks on Pro. I've included it as a companion to AI review below.

Diff-only review is a scope choice

A diff-only review asks whether the changed lines look wrong. A context-aware review also inspects the surrounding implementation and its consumers. You can ask either question badly.

The products below document context beyond changed lines, so calling all PR bots diff-only would misrepresent them, and calling a reviewer repository-aware doesn't settle whether it found the caller you care about, or understood the behavior you're changing.

Ask for the affected consumer and its assumptions. Then inspect the code the reviewer cites.

AI code review tools worth shortlisting

Each vendor link documents the capability in that row. The final column is what I'd

Replacing Greptile with a security scanner might leave you without the review workflow you wanted. Replacing it with another reviewer might leave your original problem untouched. Before choosing a replacement, I'd name the thing I want to change, whether that's a finding I can't act on or an agent making edits before checking the callers, because those lead to different trials.

I build Pharaoh, which appears below as a partial alternative for that last problem. It isn't a substitute for every reviewer on this list.

What you would be replacing

Greptile builds a graph index of the repository and uses it during AI code review. Its cross-repo context can include related repositories. Calling it a diff-only bot would make this comparison easier, and wrong, because repo context is already part of what you're buying, not a capability you necessarily gain by switching.

With greptile review, Greptile's CLI compares your current branch with the default branch before you push, reviewing committed changes that haven't merged and ignoring uncommitted edits, so commit your latest work before you test it, as the CLI documentation explains. greptile config prints the effective review configuration for a repository or file. Greptile also has an MCP server