We have all been through this. You join a new company, usually a software company with a large codebase behind the product, and you need to get onboarded. Either someone senior helps you understand the codebase, or you are left to read the documentation. If you are in a non-technical role, a PM or GTM for example, you are often left out of these discussions. Some people assume you would not understand enough; others assume the standard material is good enough for you. But software is best understood from the source of truth, not from someone’s opinion in a blog post or a marketing piece.

And in most cases the documentation is written for developers who want to contribute to the codebase, not for someone who just wants to understand what it does. So what if there was a tool that let you understand a product through its codebase, without having to understand the code itself?

Introducing Sonar.

Sonar creates local-first, source-grounded codebase briefings tailored to a persona you select. If you are a product manager or in business development, Sonar gives you a briefing tailored to your role. If you are an engineer or a CTO, it gives you a very different briefing, one that is more technical and deeper in the code.

Demo Link to heading

How Sonar Works Link to heading

You point it at a GitHub URL or a local folder, click Generate Briefing, and that is it. It takes some time depending on the model you are running locally, and then it gives you a fully grounded briefing. The idea is that you get in a few minutes what would otherwise take you more than two weeks. Sonar gets you onboarded on a product as quickly as possible.

Here is how Sonar is different from other tools. The common failure mode of LLM codebase summaries is confident prose that may or may not be correct, with no way to check it. Sonar is built differently:

  • First, it builds a deterministic inventory of the repository. It is not just looking at the documentation.
  • Then it asks the connected model to inspect the specific source files that matter.
  • It generates a source-backed memory graph before writing anything.
  • It traverses that graph to produce a source-grounded briefing.
  • And finally, it adds citations to the briefing and verifies them.

The main takeaway is that the citations are the trustworthy layer. Every claim Sonar makes is one you can click to check. You go straight to the file and line number and see for yourself whether the claim is correct.

And just as important, Sonar runs on your machine. Many proprietary enterprise codebases cannot be exposed to cloud-based models. That is why Sonar is local-first. You run a local model on your machine, whatever your hardware allows, and Sonar works with it as long as it exposes an OpenAI-compatible API. I have tested it with llama-server running on my MacBook Pro M4.

This local-first approach also matters when you are just getting started at a company. If they do not have frontier-model subscriptions for everyone, you still get to use AI to understand what you want. You do not have to wait for a subscription. You do not have to send the code to the cloud. It is just free.

To be clear, Sonar is built for orientation, not implementation. If you want to contribute to the codebase, you would use an agent like Claude Code or Codex. If you want to understand a codebase for free, using a local model, tailored to your role, Sonar is probably the best out there.

Sonar is live on GitHub. I have distributed it by source, so you can clone the repository, follow the setup documentation, and you are good to go. You do not have to pay for it. You do not have to download it from anywhere. It is open source, and contributions are most welcome.