Helix, change intelligence that survives the refactor

Role creator · Where: personal (cege7480/helix) · Built: July–August 2026, ongoing Stack: TypeScript (CLI + MCP server) · .NET + React/Vite (dashboard) · Docker · Authentik SSO · VS Code extension

Helix ties a requirement (a GitHub issue or a Jira ticket) to the exact span of code that implements it, stores that link as a small JSON file committed alongside the code, and keeps it pinned to the right lines as the code moves. No database, no server, no per-language parser. Links are files under .helix/, so they branch, merge, and revert with your code.

Two properties make everything else possible:

It survives the refactor. A six-stage re-anchoring engine follows a span through edits, reindentation, renames, and blocks cut into new files. It gives up only when the code is genuinely rewritten, and then it says so, loudly, instead of quietly pointing at the wrong lines. Traceability that breaks on the first refactor is traceability nobody trusts by month three.

It tells you when it doesn't know. null means unmeasured. 0 means measured, and the answer is zero. The two never render the same way, no number is an average of two things that mean different things, and a forecast whose back-test fails is withheld rather than dressed up.

The sixteen-year version of this idea

In 2010 I published a CodePlex project called Requirements to Code Mapper for Team Foundation Server. Internally it was named Helix. It introduced two new TFS work-item types, let you drag a work item onto a span of code in Visual Studio, and called the results design points and code implementation items. Its stated future vision was, verbatim:

"a service to move function point location based on a merge."

The 2010 tool anchored by character position and changeset, and the write-up says out loud why that wasn't good enough:

"…subsequent changesets would likely move the character position. We have plans to deal with this. Just nothing done yet."

That parenthetical is the whole sixteen years. The 2026 six-stage re-anchoring engine: trimmed-window context hashes, symbol paths, follow-the-block-into-a-new-file, is the "something" that was never done. And the part that finally made the whole idea viable rather than merely possible is that agents now maintain the links, instead of a human remembering to drag a work item.

Same problem. Same name. Same vocabulary. Different decade.

Read the 2010 write-up, with its original screenshots →

How it was built, the AI angle

Helix is the largest of these projects and the one where agents did the most autonomous work.

Built for agents, by agents. Helix ships an MCP server so coding agents can create and maintain traceability links themselves: helix_research_packet, helix_propose, helix_apply_proposal, helix_trailers. helix onboard registers the MCP with claude or copilot and installs a session hook so agent work is recorded as it happens.
Named research agents ship in the repo. helix-tracer takes a ticket plus a code scope, computes the deterministic part itself, then reasons about the rest and writes a proposal, it creates nothing directly. refinement-analyst turns a refined ticket into a recorded estimate before any code is written, so estimate-vs-actual drift is measurable rather than remembered.
Agent output is never trusted blind. apply re-validates every proposed span against HEAD and stamps provenance: agent. The CI gate (helix reanchor --verify) exits non-zero if anything moved or orphaned. The cross-file ticket-only fallback explicitly refuses unreviewed agent-mined design points. Machine-written JSON is re-validated by the same gate humans go through.
Helix plans the agent fan-out. helix plan-paths models vertical (one agent per story), horizontal (one agent per layer), and hybrid decomposition, sweeps the lane count, and reports the capacity the dependency graph can actually keep busy, so you stop guessing how many parallel agents a piece of work can absorb. It emits a self-contained prompt per lane and suggests an executor: clean single-story tasks go to the Copilot coding agent, harder ones to an isolated Claude lane.

Measured 1,736 commits across all branches in ~6 weeks, 1,203 of them (69%) AI-attributed, of which 185 were authored by a coding agent outright (copilot-swe-agent[bot], Copilot, Claude). A further 200 commits come from the project's own helix-bot CI automation and are deliberately not counted as AI.

The screens

All screenshots show the generated Nova Freight Lab demo project: fictional repos, fictional tickets, and 26 weeks of backdated history from a generator script. No real engagement data.

The requirements explorer, a whole epic in one sky

Helix explorer, Universe layout: requirement NF-300 at the center, repos on an inner orbit, anchored files on an outer one, with design and impl flows colored differently

/projects/{id}/explore is a VS Code-style workbench over one project. The left sidebar holds the requirements tree, epics with their child stories nested the way they read in Jira, each row carrying its own coded progress. Selecting a story traces its path through the codebase; selecting an epic unions its stories into one picture. Violet is design that hasn't landed yet.

Note the header: CODED 100% · SHIPPED 100% · VERIFIED 53%, and proven end-to-end 47%. Four separate facts. The gap between coded and verified is the one worth an argument, an average would have hidden exactly that.

Focus a file and it blooms

Helix explorer with a single file focused: its anchored symbols appear, the direct path stays bright, and other requirements touching the same file show as ghost rings

The anchored symbols appear, the direct path stays bright, and other requirements that touch the same file show up as ghost rings you can pivot to. Views also draw the interdependency between the files themselves, a handler that injects ITariffCache depends on TariffCache.cs; they are not equals. Every derived edge is labeled inferred and never counts into drift or progress.

Cross-repo trace

A Sankey diagram tracing one requirement from tracker key, through repositories, down to individual code files, with design, impl, and verify as separately colored flows

A requirement that spans repositories joins on the tracker key. One Sankey, every repo, design (predicted) vs impl (actual) vs verify (proven) as colored flows: trace and drift in one picture, and deep-linkable.

"Is it done?", the proof ladder

The proof ladder: three un-blended lenses plus a four-segment strip counting each design point once at the highest rung it earned

Three people ask "is it done?" and mean three different things. The engineer means the code is written. The PM means it's in front of users. QA means something proves it works. A single percentage answers one of them and misleads the other two. Helix reports all three, never averaged, plus a ladder that counts each design point once at the highest rung it earned, none < coded < verified < observed.

Forecast that admits what it can't see

Monte-Carlo forecast with P50 and P85 ticks, the full distribution, and an explicit split between designed scope and tickets still awaiting design

A Monte-Carlo forecast of when a requirement will be done and visible in an environment. It splits designed scope from tickets still awaiting design and gives the all-in date once they're folded, rather than quietly forecasting only the part that happens to be legible.

Timeline

Project timeline of git-derived created and re-anchored events

Git-derived created / re-anchored events across the project. Everything here is derived from commits and anchor files; nothing depends on anyone remembering to update a status field.

Why it matters

Delivery tooling is usually confident because it has stopped checking. Helix is deliberately the opposite: it refuses to blend lenses, refuses to publish a forecast that fails its own back-test, says 5/90 design points unreachable instead of silently forecasting the 85 it can see, and it still works when you hand it a four-year-old repository where nobody has heard of it, by mining the history backwards.