Subtitle: A local semantic graph engine that helps AI coding tools retrieve the right code, reduce token waste, and understand software dependencies faster.
Website: https://sarathkumar1207.github.io/software-brain-engine/
GitHub: https://github.com/sarathkumar1207/software-brain-engine
Downloads: https://github.com/sarathkumar1207/software-brain-engine/releases/latest
AI coding assistants are becoming part of everyday software development. They help write code, debug issues, explain unfamiliar systems, and speed up refactoring.
But there is one serious problem:
Most AI coding workflows still treat the repository like a text dump.
When you ask an AI system to fix a bug or make a change, it often starts by searching broad folders, opening unrelated files, and trying to reconstruct architecture from raw source code.
That creates four problems:
This is especially painful in backend systems where a single change can cross controllers, services, DTOs, middleware, database models, routes, and tests.
For example:
"Change JWT authentication to Passport"
"Fix createUser validation"
"Refactor saveUser"
"Find what breaks if this middleware changes"
These are not simple text-search problems. They are dependency and impact-analysis problems.
That is why I am building Software Brain Engine, or SBE.
Software Brain Engine is an open-source Rust CLI that turns TypeScript and TSX repositories into a local semantic graph.
Instead of sending the entire repository to an LLM, SBE helps retrieve only the relevant code context.
In simple terms:
SBE scans your codebase, builds a graph, and answers:
"What code matters for this change?"
Basic commands:
sbe scan ./repo
sbe graph createUser --json
sbe impact createUser --json
sbe benchmark ./repo --query "jwt to passport"
SBE returns:
The goal is not to replace the developer.
The goal is to give AI systems better code context before they start reading source.
A normal AI coding workflow often looks like this:
User asks for change
AI searches files
AI opens many files
AI guesses dependencies
AI edits code
SBE proposes a better workflow:
User asks for change
SBE queries semantic graph
SBE returns impacted symbols and source ranges
AI reads focused context
AI edits code with better dependency awareness
This matters because context is one of the biggest bottlenecks in AI-assisted software engineering.
The future of AI coding is not just bigger context windows. It is better context retrieval.
Developers do not need another vague AI tool.
Developers need infrastructure that makes AI coding workflows more reliable.
SBE is designed for:
If you are working with large TypeScript backends, SBE is meant to help answer questions like:
Which files are affected by this function?
What calls this service method?
Which controller depends on this middleware?
What code should an AI assistant read before changing this symbol?
How much context can we avoid sending?
To explain the workflow, I added a realistic demo based on honojs/hono, a TypeScript web framework.
The simulated issue:
Middleware post-processing after await next() should still mutate an error response created by onError.
Example:
app.onError((err, c) => c.text('failed', 500))
app.use(async (c, next) => {
await next()
c.header('x-request-processed', 'true')
})
app.get('/users/:id', () => {
throw new Error('database unavailable')
})
This is the kind of issue that requires multi-file understanding:
Without SBE, a coding assistant might inspect:
src/hono.ts
src/hono-base.ts
src/compose.ts
src/context.ts
src/request.ts
src/router.ts
src/types.ts
src/helper/factory/index.ts
src/compose.test.ts
src/hono-base.test.ts
docs/guides/middleware.md
Estimated broad context:
12-16 files
~22k-30k tokens
With SBE:
sbe scan ./hono
sbe graph compose --json
sbe impact compose --json
SBE can produce a focused file/range packet:
src/compose.ts:18-102
src/hono-base.ts:210-275
src/context.ts:120-175
src/types.ts:40-88
src/helper/factory/index.ts:12-44
src/compose.test.ts:1-90
src/hono-base.test.ts:300-370
Estimated focused context:
5-7 files
~5k-7k tokens
Estimated reduction:
~68-78%
Important note: this is a realistic simulated demo, not a claim that Hono currently has this bug. Before opening an upstream issue or PR, the behavior must be reproduced against a specific Hono commit with a failing test.
That honesty matters. SBE should prove where it helps, not exaggerate results.
SBE is currently a production-alpha developer tool.
Current capabilities:
.sbe/index.bin binary storageExample:
sbe scan ./repo
Output:
SBE scan complete
indexed files : 214
graph : 918 symbols, 301 imports, 1440 edges
storage : ./repo/.sbe
elapsed : 682 ms
SBE is designed to index source code, not dependencies or generated output.
It skips common unwanted folders by default:
node_modules
.git
.sbe
dist
build
target
.next
coverage
This matters because scanning node_modules would destroy the value of the tool. The purpose is to understand your project code, not installed packages.
A future .sbeignore file can make this configurable per project.
SBE is not a magic AI brain.
Current limitations:
The current token estimate is approximate:
tokens ~= source characters / 4
That is enough for early full-context vs focused-context comparison, but exact tokenizer support is planned.
SBE is a local CLI and indexing engine.
Rust is a strong fit because it gives:
The project is organized as a Cargo workspace:
common - shared types
scanner - repository traversal
parser - Tree-sitter TypeScript extraction
storage - .sbe binary index
symbols - symbol registry
graph - dependency graph
impact - reverse traversal
query - context and benchmark reports
indexer - scan/parse/store pipeline
cli - user-facing commands
This modular structure is important because SBE is meant to grow as infrastructure, not as a one-file script.
ripgrep is excellent for text search.
SBE is trying to solve a different problem:
graph-shaped code context
For AI coding workflows, the useful output is often not:
Here are all files containing "createUser"
The useful output is:
Here is createUser.
Here are its dependencies.
Here are its dependents.
Here are the exact code ranges.
Here are the impacted files.
Here is the minimal context packet.
That is the difference between search and code intelligence.
I do not want to claim that SBE always reduces tokens.
It does not.
Small projects can show 0% savings because metadata overhead can be larger than the focused code slice.
The honest claim is:
When a change maps to a focused dependency path, SBE can reduce unnecessary AI context by retrieving graph-relevant code before the model reads source.
That is the product.
Not hype.
Infrastructure.
SBE is useful for:
If your AI assistant often opens too many files before solving the issue, SBE is built for that pain.
Near-term roadmap:
.sbeignoreThe long-term goal is simple:
Make codebases queryable as semantic graphs for AI systems.
Website:
https://sarathkumar1207.github.io/software-brain-engine/
GitHub:
https://github.com/sarathkumar1207/software-brain-engine
Download:
https://github.com/sarathkumar1207/software-brain-engine/releases/latest
Platform artifacts:
| Platform | Artifact |
|---|---|
| Windows x64 | sbe-0.2.0-windows-x64.msi |
| Linux x64 | sbe-linux-x64.tar.gz |
| macOS ARM64 | sbe-macos-arm64.tar.gz |
Install from source:
cargo install --path crates/cli --force
Run:
sbe scan ./your-typescript-project
sbe benchmark ./your-typescript-project --query "jwt to passport"
The most useful feedback is not:
Looks cool.
The most useful feedback is:
I ran SBE on this repo, and the graph was wrong here.
If you work on TypeScript backends, AI coding tools, code intelligence, LLM context retrieval, or developer infrastructure, I would love your feedback.
SBE is open source and MIT licensed.
Give it a try, open an issue, or tell me where the graph breaks.