This is the practical campaign plan for getting Software Brain Engine in front of developers.
The positioning should stay technical:
Stop sending entire codebases to AI. SBE turns repositories into semantic graphs for precise code context retrieval.
Do not lead with vague AI claims. Lead with the problem developers recognize: context waste, dependency guessing, and slow code understanding.
Primary goals:
.sbeignore, and watch mode.What to ask for:
Try it on a TypeScript repo and tell me where the graph is wrong.
Use these URLs:
GitHub: https://github.com/sarathkumar1207/software-brain-engine
Website: https://sarathkumar1207.github.io/software-brain-engine/
Downloads: https://github.com/sarathkumar1207/software-brain-engine/releases/latest
Demo doc: https://github.com/sarathkumar1207/software-brain-engine/blob/main/docs/demo-hono.md
Core proof:
Hono middleware demo:
Without SBE: 12-16 files, ~22k-30k tokens
With SBE: 5-7 files, ~5k-7k tokens
Estimated reduction: ~68-78%
Use the proof carefully:
This is a realistic simulated demo, not an upstream Hono bug claim.
Checklist:
rusttypescriptclideveloper-toolsai-toolsllmcode-intelligencesemantic-graphtoken-optimizationPost only after the GitHub page looks complete.
Title:
Show HN: SBE, a Rust CLI that builds semantic graphs for AI code context
Post:
I built Software Brain Engine, an open-source Rust CLI for TypeScript/TSX repositories.
The problem: AI coding tools often read too much code before they understand a focused change. They search broad folders, open unrelated files, and burn context reconstructing dependencies.
SBE scans a repo locally, stores a .sbe index, extracts symbols/imports/references, and lets you query the semantic graph:
sbe scan ./repo
sbe graph createUser --json
sbe impact createUser --json
The output is meant for both humans and coding agents: impacted files, dependencies, dependents, code ranges, and context/token estimates.
I also added a Hono middleware demo showing the workflow:
Without SBE: 12-16 files, ~22k-30k tokens
With SBE: 5-7 files, ~5k-7k tokens
This is production-alpha. It is syntax-based Tree-sitter analysis, not a TypeScript type checker. I am looking for feedback on graph accuracy, benchmark methodology, and whether this helps real AI coding workflows.
GitHub: https://github.com/sarathkumar1207/software-brain-engine
Website: https://sarathkumar1207.github.io/software-brain-engine/
Downloads: https://github.com/sarathkumar1207/software-brain-engine/releases/latest
First comment:
Limitations:
- TypeScript/TSX only for now
- syntax-based, not type-aware yet
- token estimates are approximate
- small projects can show 0% savings because metadata overhead can be larger than the focused context
I want the benchmark to show misses honestly. The goal is not magic compression; it is graph-guided context selection before an LLM reads code.
Publish one long-form article on Medium or daily.dev. Use:
docs/articles/medium-sbe-launch.mddocs/articles/daily-dev-sbe-launch.mdTitle:
Stop sending entire codebases to AI: building a semantic graph CLI in Rust
CTA:
Try SBE on a TypeScript repo and share where the graph is wrong.
1/ AI coding tools often waste context before they understand the actual change.
They search broad folders, open unrelated files, and reconstruct dependencies manually.
I built SBE to attack that problem.
2/ Software Brain Engine is an open-source Rust CLI that turns TypeScript repos into semantic graphs.
Run:
sbe scan ./repo
sbe graph createUser --json
sbe impact createUser --json
3/ The goal is not to replace a type checker.
The goal is to retrieve the code that matters before an LLM reads source:
- symbols
- dependencies
- dependents
- files
- source ranges
- impact paths
4/ Demo shape:
Hono middleware lifecycle issue
Without SBE:
12-16 files, ~22k-30k tokens
With SBE:
5-7 files, ~5k-7k tokens
5/ Current limits:
- TypeScript/TSX only
- syntax-based analysis
- approximate token estimate
- production-alpha
Feedback wanted from backend engineers and AI coding tool users.
GitHub:
https://github.com/sarathkumar1207/software-brain-engine
Downloads:
https://github.com/sarathkumar1207/software-brain-engine/releases/latest
Use only communities that allow project feedback posts.
Title:
Feedback wanted: Rust CLI that builds semantic graphs for AI code context
Post:
I am building Software Brain Engine, an open-source Rust CLI for TypeScript/TSX repositories.
The problem I am trying to solve:
AI coding tools often read too much code before understanding a focused change. They load broad folders and unrelated files, then manually infer dependencies.
SBE scans a repo locally and builds a semantic graph:
- functions/classes/methods/interfaces
- imports and best-effort references
- file and symbol relationships
- source ranges
- impact paths
Example:
sbe scan ./repo
sbe graph createUser --json
sbe impact createUser --json
I added a Hono middleware demo to show the intended workflow. It is a realistic simulated case, not an upstream bug claim.
The rough result:
- normal workflow: 12-16 files, ~22k-30k tokens
- SBE workflow: 5-7 files, ~5k-7k tokens
Current limitations:
- TypeScript/TSX only
- syntax-based, not type-aware yet
- token estimate is approximate
I am looking for feedback on:
- whether this would help your AI coding workflow
- graph accuracy
- benchmark methodology
- what output an AI agent should receive
GitHub:
https://github.com/sarathkumar1207/software-brain-engine
Downloads:
https://github.com/sarathkumar1207/software-brain-engine/releases/latest
I am building Software Brain Engine, an open-source Rust CLI for AI-assisted software development.
The problem: AI coding tools often read too much code before understanding the actual change.
SBE scans a TypeScript repository locally and builds a semantic graph. Instead of sending broad folders to an LLM, you can ask:
sbe graph createUser --json
sbe impact createUser --json
It returns relevant symbols, files, dependencies, dependents, and source ranges.
The goal is simple:
give AI systems the code that matters, not the entire repository.
Current alpha:
- Rust CLI
- TypeScript/TSX first
- local .sbe index
- impact analysis
- graph queries
- benchmark/demo docs
Looking for feedback from backend engineers, TypeScript teams, and developers using AI coding assistants.
GitHub:
https://github.com/sarathkumar1207/software-brain-engine
Downloads:
https://github.com/sarathkumar1207/software-brain-engine/releases/latest
Do not repeat the launch post. Share what feedback you got.
One useful question from the SBE launch:
"Does it skip node_modules?"
Yes. SBE skips node_modules, .git, .sbe, dist, build, target, .next, and coverage by default.
Next improvement I am considering: .sbeignore, so projects can add custom ignore rules like generated folders or vendor code.
Would you prefer SBE to read .gitignore too, or keep a separate .sbeignore?
Not yet. V1 is syntax-based through Tree-sitter. That keeps it fast and simple, but it means the graph is best-effort. Type-aware resolution is a future milestone.
No. SBE skips node_modules and common generated/build folders by default: .git, .sbe, dist, build, target, .next, coverage, etc.
ripgrep is great for text search. SBE is trying to provide graph-shaped context: symbols, dependencies, dependents, source ranges, and impact paths that an AI agent can consume directly.
No. Current token estimates are approximate. The benchmark is meant to compare full-project context vs focused graph context. Exact tokenizer support is on the roadmap.
Not yet. V1 focuses on TypeScript/TSX. The workspace is modular so more parsers can be added later.
Track:
Good early result:
10 useful technical comments > 100 generic likes
Avoid:
Use:
SBE is graph infrastructure for focused AI code context.