FORGE
AI Software Engineering Platform
An intelligent engineering workspace for modern development teams.
Know what a change actually breaks before you merge it, across a codebase nobody can hold in their head.
- Symbol index
- Call graph
- Impact analysis
- Convention mining
- Incremental indexing
Repository-wide code understanding, architecture mapping, PR analysis and test generation grounded in the actual call graph rather than in file similarity.
What the product is built around.
FORGE indexes a repository semantically and structurally: symbols, call graph, module boundaries and the conventions actually present in the code. Every answer is grounded in resolved references, so 'what breaks if I change this' is a graph query rather than a guess.
Grounded in the call graph
Symbol resolution and reference graphs mean impact analysis is computed, not inferred from text similarity.
Conventions learned from the repo
Patterns are extracted from the codebase as it is, so suggestions match the project rather than a general training average.
Review that sees past the diff
PR analysis follows changed symbols outward to every caller, surfacing the sibling path a diff-only review misses.
What makes this hard.
Coding assistants see a file and guess at the rest. That works for a function and fails for a system: they miss the second caller that also needs the guard, they suggest a pattern the codebase abandoned two years ago, and they cannot tell you what a change actually breaks.
- 01
Suggestions ignore the call graph, so a change fixes one caller and breaks a sibling
- 02
New code contradicts conventions the codebase already established
- 03
Nobody can answer 'what depends on this' without reading the whole repo
- 04
PR review misses cross-cutting impact because it only sees the diff
- 05
Tests are generated for the happy path and nothing else
What the system does.
FORGE indexes a repository structurally as well as semantically: symbols, call graphs, module boundaries and the conventions actually present in the code. Impact analysis is therefore a graph query rather than a guess, and it surfaces the call sites a diff-only review never sees. Suggestions are checked against conventions mined from the repo rather than a general training average.
Changed symbols resolved to their full reference set, including callers outside the diff
Conventions mined from the repo, reported as 'differs from 41 of 43 modules'
Architecture maps with cycle and boundary-violation detection
Incremental indexing at symbol granularity, so latency tracks diff size
Incomplete index regions marked as incomplete instead of presented as exhaustive
FORGE, as working interface.
Rendered UI, not a mockup — real tables, charts, filters and states. Try ⌘K for the command palette.
Symbols indexed
4.21M
PR review coverage
96.2%
Escaped defects
−41%
Branch coverage
78.4%
PR #2841 — add settlement reference to payment intent
- Author
- Staff Engineer
- Files changed
- 7
- Lines
- +184 / −42
- Symbols changed
- 4
- Callers affected
- 31 across 6 modules
- Risk score
- 72 / 100 · High
- Convention issues
- 2
- Coverage delta
- −1.8pp
Impact analysis — grounded in resolved references
What does this PR actually break, and what did the diff-only review miss?
Retrieval trace
Resolved 4 changed symbols to 31 call sites across 6 modules
Traced type changes through 3 interface boundaries
Compared against 184 repo conventions · 2 deviations
Checked branch coverage on changed paths · 3 new branches uncovered
The PR changes `PaymentIntent.settlementRef` from optional to required. That is a breaking change for 31 call sites, of which the diff only touches 12 1.
The 19 untouched call sites are the real risk. Fourteen construct a `PaymentIntent` through the `intentFromWebhook` helper, which the diff does not modify — those will fail type checking 2. Five are in the `legacy-reconciliation` module, which builds the object from a stored JSON payload where the field may genuinely be absent 3.
The `legacy-reconciliation` path is the one worth attention. It will compile once the type is widened but will produce a runtime error on historical records, and there is no test covering that path 4.
Two convention deviations: this repo consistently validates at the module boundary rather than in the constructor, and the new error uses a bare `Error` where every sibling module uses the `PaymentError` subclass 5.
Suggested sequencing: widen the type in the helper first, backfill `settlement_ref` on historical records, then make the field required in a second PR.
Sources
- [1]call graph · PaymentIntent.settlementRef31 references
- [2]src/intents/from-webhook.ts14 call sites
- [3]modules/legacy-reconciliation5 call sites
- [4]coverage · legacy path0 branches covered
- [5]convention · PaymentError usage41 of 43 modules
Module architecture — dependency map
payments-core- Changed
- Affected
- Unaffected
- Boundary violation
Affected call sites
| Location | Module | Symbol | In diff | Effect | Coverage | Risk | Status |
|---|---|---|---|---|---|---|---|
| src/intents/from-webhook.ts:84 | from-webhook | intentFromWebhook | No | Type error | 92% | High | Blocks |
| modules/legacy-reconciliation/load.ts:212 | legacy-recon | hydrateIntent | No | Runtime error | 0% | Critical | Blocks |
| src/api/intents/create.ts:41 | api | createIntent | Yes | Handled | 96% | Low | OK |
| src/ledger/post.ts:128 | ledger | postIntent | Yes | Handled | 88% | Low | OK |
| src/settlement/batch.ts:76 | settlement | batchSettle | No | Type error | 74% | Medium | Review |
| test/fixtures/intent.ts:18 | test | makeIntent | No | Type error | — | Low | Review |
6 of 31 resolved call sites · 19 are outside the diff · risk weighted by coverage and runtime reachability
Generated test — uncovered legacy path
typescript// Generated from the uncovered branch in hydrateIntent.// Historical records predate settlement_ref entirely.describe("hydrateIntent · legacy records", () => { it("throws a typed error when settlement_ref is absent", () => { const stored = { id: "pi_legacy_0041", amount: "4280.00", currency: "USD", // settlement_ref intentionally missing — 2024 schema }; expect(() => hydrateIntent(stored)).toThrow(PaymentError); expect(() => hydrateIntent(stored)).toThrow( /settlement_ref is required/, ); }); it("hydrates when settlement_ref is backfilled", () => { const stored = { ...legacyFixture, settlement_ref: "st_0041" }; expect(hydrateIntent(stored).settlementRef).toBe("st_0041"); });});Convention conformance
learned from repo- Validation at module boundarydeviates
- PaymentError for domain errorsdeviates
- Naming — camelCase fieldsconforms
- Barrel exports from index.tsconforms
- No cross-module deep importsconforms
- Fixtures via factory helpersconforms
Risk contribution
score 72Repository composition
- TypeScript48.0%
- Rust22.0%
- Python16.0%
- Solidity9.0%
- Other5.0%
Issue investigation
- ISS-1842 · settlement missing on old ordersTraced to hydrateIntent:212 · confidence 0.89located
- ISS-1836 · duplicate webhook processingTraced to missing idempotency check · 0.94located
- ISS-1821 · intermittent batch timeout3 candidate paths · needs a reproductionpartial
- ISS-1804 · incorrect rounding on EURTraced to float arithmetic in util · 0.97located
- ISS-1798 · cannot reproduceNo code path matches the descriptionunresolved
Indexing pipeline
- Convention extractionStage 6
184 patterns mined from the repo · conformance thresholds set
- EmbeddingStage 5
Symbol and docstring embeddings for semantic search
- Architecture derivationStage 4
Module boundaries inferred · 1 dependency cycle detected
- Call graph constructionStage 3
4.2M symbols · 18.4M resolved references
- Type resolutionStage 2
Language servers per ecosystem · 99.2% of symbols resolved
- ParseStage 1
Tree-sitter across 5 languages · incremental on change
Change frequency vs coverage
Interface states
UI statesNo repositories indexed
Connect a repository to build the symbol index and call graph.
Connect repositoryEmpty statePartial index — cannot guarantee impact analysis
Type resolution failed for 12% of the Rust crate due to a missing toolchain. Call-graph answers for that crate are marked incomplete rather than presented as exhaustive.
How it is put together.
Semantic search alone is not enough for engineering questions. The structural index is what makes impact analysis a computation rather than a guess.
- 01
Workspace UI
Code search, PR review, architecture maps and issue investigation.
- Next.js
- React
- Virtualised lists
- 02
Query Layer
Combined structural graph queries and semantic retrieval with ranking.
- Go
- GraphQL
- Hybrid retrieval
- 03
Structural Index
Symbols, references, type relationships and module boundaries.
- Tree-sitter
- Language servers
- Graph store
- 04
Semantic Index
Symbol and documentation embeddings for natural-language search.
- Embeddings
- pgvector
- Chunking
- 05
Convention Miner
Extracts recurring patterns and computes conformance thresholds per repo.
- Python
- AST analysis
- Statistics
- 06
Reasoning Layer
Grounded generation over graph results with citation to file and line.
- LLM
- Tool calling
- Citation binding
- 07
Ingestion
Incremental indexing on push with per-language toolchain execution.
- Queue
- Sandboxed builds
- Incremental diffs
What the product does.
The capability set the demonstration is built around.
Repository understanding
Symbol-level indexing with call graphs, type resolution and module boundaries.
Code search
Semantic and structural search across symbols, usages and patterns.
Architecture mapping
Generated module dependency maps with cycle and boundary-violation detection.
AI code assistance
Suggestions grounded in resolved references and the repo's own conventions.
PR analysis
Impact analysis across callers, risk scoring and convention checks on every diff.
Issue investigation
Trace a report to the probable code path with the evidence that located it.
Test generation
Tests derived from branch coverage gaps and observed failure modes.
Documentation
Generated module docs that stay attached to the symbols they describe.
Challenges, and the MaatX approach.
The problems that actually decide whether a system like this survives production — and how we address each one.
A repository does not fit in a context window, and never will
The index answers structural questions; the model only reasons over retrieved, resolved results. Context is assembled from the call graph, so relevance comes from references rather than from how much text fits.
Suggestions that ignore sibling callers create the next bug
Every changed symbol is resolved to its full reference set before analysis. Callers outside the diff are surfaced explicitly, because those are the ones a diff-only review cannot see.
Generic best practice conflicts with what the codebase actually does
Conventions are mined from the repository with a conformance rate attached. A deviation is reported as 'differs from 41 of 43 modules' rather than as an abstract rule.
Indexing 184 repositories on every push is prohibitively slow
Indexing is incremental at symbol granularity. A push re-resolves only the affected subgraph, so index latency tracks diff size rather than repository size.
An incomplete index silently produces confidently wrong impact analysis
Resolution coverage is tracked per language and per crate. When it drops, answers touching that region are marked incomplete instead of being presented as exhaustive.
Generated tests cover the path that already worked
Generation is driven by uncovered branches and observed failure modes from issue history, so the tests target the paths that are actually untested.
The stack behind it.
Structural index
- Tree-sitter
- Language servers
- Symbol resolution
- Type resolution
- Call-graph indexing
- Reference binding
- Graph store
Architecture & impact
- Graph algorithms
- Reachability queries
- Module boundary inference
- Dependency cycle detection
- Diff-to-symbol mapping
- Caller impact analysis
- Risk scoring
Semantic retrieval
- Embeddings
- pgvector
- Symbol-aware chunking
- Docstring embeddings
- Hybrid retrieval
- Reciprocal rank fusion
Convention mining
- Python
- AST analysis
- Pattern frequency statistics
- Conformance thresholds
- Deviation scoring
- Per-repo rule sets
Reasoning & generation
- LLMs
- Tool calling
- MCP
- Citation binding
- Call-graph context assembly
- Branch-coverage test generation
- Index-completeness guards
Ingestion pipeline
- Queue workers
- Sandboxed builds
- Incremental diffs
- Symbol-granular reindexing
- Git provider webhooks
- PostgreSQL
- Object storage
Workspace & query API
- Next.js
- React
- TypeScript
- Virtualised lists
- Go
- GraphQL
- Tailwind CSS
How it grows with the business.
The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.
One repository indexed, with search and impact analysis working.
- Single repo symbol and reference index
- Semantic and structural code search
- Caller impact analysis on a diff
- Architecture map
Team-wide review assistance grounded in the call graph.
- Incremental indexing on every push
- PR risk scoring and convention checks
- Issue-to-code-path investigation
- Test generation for uncovered branches
Cross-repository intelligence for a whole engineering org.
- Cross-repository impact for shared libraries
- Architecture drift alerts over time
- Migration planning sequenced by dependency order
- Incident-to-commit linking
Where it could go next.
Directions this system would extend into.
- 01
Autonomous refactors proposed as reviewable PRs with impact proofs
- 02
Cross-repository impact analysis for shared internal libraries
- 03
Architecture drift alerts when boundaries erode over time
- 04
Migration planning that sequences changes by dependency order
- 05
Incident-to-code linking that connects production failures to the introducing commit
Trying to make a large codebase navigable rather than just searchable?
We built FORGE to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.