Hi all,
Wanted to share two tools we’ve been building plus a request for friendly users — the request is at the bottom.
Surveyor (Mix project): point it at a codebase, walks you through system context, containers, components, generates a C4 diagram, calls out to an LLM for the inferential parts but flags everything with a confidence level so you can accept / edit / retry. Output is a workspace.dsl you can render in Structurizr, with each component decorated with assay.specs and assay.schema properties.
Assay: small behavioral spec runner. *.assay files in plain text, component-scoped step matching (so step namespaces don’t collide across bounded contexts), pre-check before execution (no half-run scenarios leaving test data behind), and per-scenario state in the process dictionary. Bindings are just Elixir modules — bring whatever you need (Req, AMQP, System.cmd, …). The same spec runs against --target legacy and --target new. Green on both = the rewrite is behavior-equivalent for what you covered.
Write-up: Surveyor
Companion piece on reading legacy code: field guide
The ask.
We’re running a friendly user trial. Sweet-spot profile is Phoenix + Ecto backend, a JS SPA (React, Vue, Svelte, anything) on the frontend, with a LiveView migration either in active planning or in the “we keep talking about it” stage.
You can continue to use the tool afterwards, and you walk away with three artefacts you keep:
- C4 architecture diagrams of your system — context, containers, and components per container
- MADR style decision records extracted from your codebase
- Detailed behavioural specifications per bounded context, in plain text your PO can read and your engineers can run against the live system
- An automated rewrite estimate, broken down by bounded context, grounded in what’s actually in your codebase — not gut feel
If that’s roughly your situation, please DM or reply. Happy to answer anything about the design choices in either tool.
