I built Codewalk because I kept seeing the same engineering problem repeat itself.
A pull request could look perfectly reasonable, and still feel risky.
The code in the diff might be fine. The tests might pass. But the harder questions were still unanswered:
- What else depends on this file?
- Is this a safe refactor or a hidden high-risk change?
- Are we touching a critical part of the system or an isolated leaf?
- What should a new engineer read first to understand this module?
Most tools are decent at the local patch. They are much weaker at the codebase context around the patch.
That gap is why I built Codewalk.
Codewalk is an open-source codebase intelligence layer. It analyzes a repository from real imports, builds a dependency graph, adds semantic search and graph analysis on top, and turns that foundation into practical workflows for review, onboarding, refactoring, and exploration.
Developers can use it three ways:
- Through a local web UI for visual exploration.
- Through a REST API for scripts and CI/CD.
- Through an MCP server inside VS Code, Cursor, and Claude Code.
Blast Radius Demo
What Codewalk actually gives you
Codewalk starts with a codebase model, not just a text index.
That model powers a set of features that work together:
Core intelligence
- Module detection groups files into logical modules.
- Dependency graph extracts imports across the repo and builds the real map of the system.
- Blast radius answers "if I change this file, what breaks?"
- Reading order helps new engineers understand what to read first.
- Execution flow traces module and file relationships.
- Graph intelligence uses DuckDB and igraph for signals like centrality, risky files, and dependency importance.
Search and exploration
- Semantic search finds relevant code by meaning, not just by string match.
- RAG + AI chat helps answer broader repo questions with grounded context.
- Doc indexing lets code and team docs live in the same knowledge layer.
Review layer
- Review without mandatory indexing works on any git repo from the diff, changed files, and static analysis.
- Architecture-aware review gets stronger when graph data is available.
- Batched review keeps large PRs focused by reviewing a few files at a time.
- Custom rubrics let teams shape review by language, framework, and guidelines.
- Severity levels separate blockers from errors and suggestions.
- Re-review after fixes starts a fresh pass that hides findings you rejected and verifies the fixes.
In other words: Codewalk is not only a review tool. Review is the most visible workflow, but it is built on top of a broader intelligence layer.
Why review is the daily-use layer
The reason I highlight review is simple: it is the workflow developers touch most often.
Every team reviews code every day. Not every team runs architecture analysis every day. Not every team opens a graph view every day. But review is constant.
That made review the right place to expose the value of the whole system.
Most review tools answer a narrow question:
- Is this diff locally reasonable?
Codewalk is built to answer the more useful questions:
- How important is this file in the system?
- What is the blast radius if this change is wrong?
- Is the patch touching shared infrastructure, a base model, or a fragile dependency edge?
- Does the reviewer have enough context to understand the real risk?
Why Codewalk review is different
Codewalk's review engine sits on top of the intelligence layer.
That means it does not just lint the changed lines. It can use the dependency graph, blast radius, caller context, and graph-derived risk signals when they exist.
It also works in two modes:
- Without index: useful review from the diff, changed files, static analysis, and team guidelines.
- With index: richer review with architecture-aware context layered on top.
That matters because the reviews you care about most are often time-sensitive. Hotfixes and legacy cleanup cannot wait for a long indexing workflow before the first pass starts.
Review Demo
Where the foundation helps most
The same foundation helps in a few recurring scenarios:
- New engineer onboarding — understand module structure and reading order faster.
- Refactor planning — see blast radius before touching shared code.
- Cross-team work — understand an unfamiliar module without waiting on tribal knowledge.
- PR review — review a diff with more than just local patch context.
That is why I think of Codewalk as a codebase intelligence layer first, and a review workflow built on top of it.
Under the hood, briefly
Under the hood, Codewalk combines a dependency graph, graph analysis, semantic retrieval, and review orchestration.
The graph is backed by DuckDB and analyzed with igraph. Search and chat are powered by semantic retrieval and RAG. Review uses that intelligence layer when it is available, but it does not require it to get started.
For users, the important part is simpler: safer changes, faster onboarding, and more useful review.
Try it
git clone https://github.com/gupta29470/codewalk.git
cd codewalk
python3 -m venv .codewalk-env
source .codewalk-env/bin/activate
pip install -r requirements.txt
uvicorn src.codewalk.api.main:app --reload --port 8000
Then analyze the repo and run review:
curl -X POST http://localhost:8000/analyze \
-H "Content-Type: application/json" \
-d '{"index_mode": "auto"}'
curl -X POST http://localhost:8000/review \
-H "Content-Type: application/json" \
-d '{}'
Open source
Codewalk is MIT licensed. I built it to be inspectable, self-hostable, and useful to teams that want better context during review.
- GitHub: https://github.com/gupta29470/codewalk
- Landing page + docs: https://codewalk.xyz/
- Demos: https://codewalk.xyz/feature-demos
If you try it, the workflow I most want feedback on is review: what part of your current review process still feels blind, and what context do you wish your tools surfaced automatically?
Top comments (0)