UnspoolCode

Dependency graph · dead-code detection · migration execution

Untangle your VB6 codebase — and let AI agents query it, not guess at it.

UnspoolCode turns a legacy VB6 project into an interactive dependency graph, finds the dead code nobody's touched in a decade, and gives coding agents like Claude a 37-tool MCP server so they can call the graph directly instead of reading raw files. When you're ready to move off VB6, it doesn't just plan the migration — it executes it, batch by batch — destructive edits sit behind a preview-then-confirm step — with a COM interop bridge for the C# target. It's real, working software you can self-host against your own codebase today — a managed, hosted version is what's pre-GA.

Self-host it yourself today · hosted early access is by waitlist · no spam, ever.

613,884 edgesmapped on a real 348-file production VB6 codebase
37 MCP toolsread, write & migration control your agent calls directly
1.6ms medianwarm graph query latency, at millions of edges
2M linesstress-tested ceiling — 419,580 nodes, 7.7M edges, under 8GB RAM

01The problem

Legacy VB6 doesn't fail loudly. It fails when you touch it.

Nobody left who knows why it works

The engineers who wrote it moved on years ago. What's left is a form-and-module tangle nobody wants to be the one who breaks — and VB6 itself is long past end of life, with a shrinking pool of people who can even read it.

AI agents can't read their way through it

Point a coding agent at a legacy VB6 tree and it starts grepping and guessing at call graphs from raw source — burning context on files it doesn't need and hallucinating dependencies it can't see.

Rewrites stall for years

"Just rewrite it" proposals die in committee because nobody can prove the new version behaves like the old one before the cutover — so the VB6 system keeps running, and the risk keeps compounding.

02What you get

Understand it safely. Then actually get off it.

See the whole system

An interactive dependency graph of every module, form, and call

Click a module and jump straight to it in an integrated editor. Dead-code detection flags procedures that are unreachable from any entry point automatically — the analysis that used to take an engineer a week of careful grepping runs as a query.

Dead code on a 7.7M-edge graph: 1.2sExact-name lookup, warm: 1.6ms median
Built for coding agents, not just humans

A 37-tool MCP server so Claude queries the graph directly

Instead of an agent reading raw files and reconstructing a call graph in its head, it calls purpose-built tools — references,call_path, module_summary,impact_analysis, dead-code removal, and more — both read and write.

Measured, clean-comparison subset: 96% fewer bytes, 60% fewer tool calls than raw file reads
Not just analysis — actual execution

Batch-orchestrated migration to TypeScript or C#

Draft a migration plan in dependency order, review and approve translations, then run batches with a scheduler that resumes cleanly after a restart. The C# target generates a COM-visible interop bridge (ComVisible attributes, deterministic GUIDs/ProgIds) so migrated code can call back into VB6 COM components mid-transition — it compiles clean today; full Windows-side COM activation and VB6 round-trip call-parity verification is in progress. Destructive graph edits — dead-code removal, in-place replace, scope-advice fixes — sit behind an explicit preview-then-confirm step before they apply; direct source writes are hash-checked against the last-read version to catch anything stale.

338 units drafted, real project: 7.2sService RSS across a full batch run: 519MB
Numbers we can show you, not numbers we made up

Proven on a real codebase, stress-tested to 2M lines

Every figure on this page is measured, not estimated. 41,335 nodes and 613,884 edges on a real 348-file VB6 codebase, byte-identical across successive engineering milestones. A synthetic stress corpus at 2M lines (4,070 files, 419,580 nodes, 7.7M edges) holds peak memory under 8GB and starts the service in 404ms.

Service start, populated 2M-line DB: 404msPeak RSS at 2M lines: <8GB

03How it works

From a raw VB6 tree to a graph your agent can drive.

01

Point it at your project

The parser reads your VB6 source with ANTLR and builds the semantic call/dependency graph — no manual mapping.

02

Explore & understand

Walk the interactive graph, find dead code, and jump to any definition in the built-in editor before you change a line.

03

Let your agent drive

Connect Claude or any MCP client to the 37-tool server. It queries the graph and proposes changes instead of guessing from source.

04

Migrate on your terms

Draft a plan in dependency order, approve translations, and batch-execute to TypeScript or C#, with destructive edits behind a preview-then-confirm step.

04Measured, not marketed

We publish the benchmark methodology, not just the headline number.

Real project: 41,335 nodes / 613,884 edges. Stress test: 419,580 nodes / 7.7M edges.

Both are measured, reproducible runs — one against a real 348-file production VB6 codebase, one against a synthetic 2M-line corpus built to find the ceiling before you do. Query latency, memory, and dead-code timing are all recorded from the same runs.

Hosted early access

Be first to run it on your codebase.

UnspoolCode is real, working software you can self-host today. Prefer a managed, hosted version instead? Join the waitlist and we'll reach out when hosted early access opens — no commitment, no spam.