Put the engineer back in software engineering.
Agents write the code now. Enscrive Code puts the skilled engineer back at the whiteboard to defend it: every flow, hop by hop, with the evidence it has and the evidence it lacks.
The rush to generate code sidelined the engineer who understood it. That engineer is the point.
Writing code was never the bottleneck. Understanding the system around it was, and it still is. A skilled engineer earned that understanding by building the system, and answered for it at the whiteboard. In the rush to accelerate development with generative AI, the writing went to agents, and the engineer who could answer for the system was pushed to the margin: reviewing diffs they did not write, faster than anyone can read them, and asked to sign off anyway.
The standard did not move. Anyone who ships a customer-facing system should be able to be pulled aside and explain it. Not line by line: a few questions, answered with confidence. Skilled engineers have been asking these of each other for decades; Mitchell Hashimoto wrote them down in September 2026.
Why did you do X instead of Y?
On the board: the decisions attached to the hops of a flow
What happens if this actor is malicious?
On the board: the gates on the request edge, and the hops after them that touch untrusted input
What data structure is here, and why?
On the board: the types that cross each edge, one click from their fields
Where does this fail?
On the board: the fallible hops, the blind spots, and the boxes no test reaches
Enscrive Code exists so those four questions have a place to be answered, by a skilled engineer, about code that engineer did not write. It puts that engineer back at the whiteboard with the authority the whiteboard confers: understand it, defend it, know what is missing. That is the whole mission, and it is why the product is a whiteboard and not a chat window.
Your codebase, drawn the way an engineer would draw it.
Not a node graph. A stack of whiteboard cards, one per journey through the system, sharing one grammar at every depth so you can flip down into a file and back up without losing your place.
Walk a real board: one journey through Atuin, an open-source codebase we did not write.
The board Enscrive Code drew from the code alone, the story an agent wrote on it, and how both were checked. Read-only, nothing to install.
Open the live demoOn our own ingest journey the real card showed the request passing five gates before its handler, crossing into the embedding service at the tenth hop, and sixteen functions that no test reaches. The board said so before anyone did.
The systems, the journeys, the concerns
The front page is a story, not a graph. Which repositories work together. Which journeys a request takes through them. Which engineering concerns those journeys carry: tenant isolation, disaster recovery, data portability, money, security, resilience.
One journey, hop by hop
A card is one flow at one depth. Left to right is the order a request moves. Top to bottom is layer: gate, interface, execution, persistence, boundary. Lanes are services. The request edge comes first, so the gates a call passes before the handler are drawn before the handler.
Flip down, step sideways, climb back
Open a box and the card flips to the functions inside it on the same hop axis, with the neighbouring files as ghosts at the edges. Click a ghost to step into that file. The trail at the top brings you back up. Position is preserved across every flip, so you never lose your bearings.
Three kinds of truth, drawn differently
A solid edge is observed: resolved by structure, or confirmed by the compiler. A dashed edge is inferred, and prints its probability. A recorded hop is one a real run passed through, with the values it carried. Nothing is smoothed over: a call the graph cannot see is drawn as a counter, not omitted.
What is missing, per hop
Every box says which of its functions no test reaches, which are unreachable from any entry, which are stubs, and how dense its unwraps are. Every card totals them. The gaps are the second mission, and they are what an agent can be told to close.
Lenses, from a shared vocabulary
Pick a concern and every box that does not carry it fades. The concerns come from an engineering dictionary: fourteen categories, sixty-six leaves, each with the story a good system tells, the questions an engineer must answer, and the evidence a card must show. The dictionary is versioned and yours to extend.
A skilled engineer can defend any flow of the system from the whiteboard.
Every hop a request takes, every gate it passes, every boundary it crosses, every durable write it makes, in the order they happen, with the types on the wire and the decisions attached. Enough to answer the four questions without opening a file, and the file one click away when you want it.
The whiteboard says, per hop, what evidence is missing before that defense is honest.
No test reaches it. Nothing can reach it. It is a stub. It unwraps where it should handle. It was never recorded running. The concern it carries has no evidence on this card. A gap is a specific thing, and a specific thing is what an agent can be told to close.
Every line on the board says where it came from.
Structure and recorded runs are fact. Heuristics are provisional and look provisional. Definitions are authored, versioned and editable. Anything a model says is cited to a hop or it is not shown. The interface labels each of these, on every card, with live counts.
| Kind | Source | What it contributes |
|---|---|---|
| fact | Parsed structure | tree-sitter items, containment, routes and middleware read from source. Deterministic, no model. |
| fact | Compiler-verified edges | call targets confirmed by the language server’s index. Where the compiler disagrees with a name match, the name match loses. |
| provisional | Inferred edges | receiver names, unique method names, RPC names across services. Dashed, with a probability, until confirmed or demoted. |
| provisional | Lens membership and layers | cue matching against paths, names and docs. Replaced by calibrated labels the moment they exist, and marked until then. |
| Engineering dictionary | concern, pattern, role and layer definitions with stories, questions and evidence. Written once by a reasoning model, versioned, human-edited. | |
| fact | Biographies | model-free prose per item, generated from graph facts. The text behind search. |
| model | Neural search | biographies embedded through the provider you configure. Used only to find things, never to draw a card. |
| model | Calibrated labels | typed decisions from a classification model: role, layer, membership, risk, each with a probability. Optional; never overwrites a structural fact. |
| model | Reasoning | anything a frontier model says about a card is cited to hops, or it is not shown. |
| fact | Recorded runs | spans captured while the flow’s own tests ran. The only source that says a hop executed with real data. |
One standing instruction: make sure I understand this.
Hand the binary to your coding agent with that sentence, and it has what it needs. It reads the same cards you do, over MCP, as the same JSON. It cites the same box addresses. When a card needs a recorded run, the tool tells the agent which hops to instrument and how; the agent adds the spans, runs the flow’s own tests, and hands the recording back. The binary never instruments your code itself. Before it runs anything, the agent can ask which tests defend the change it just made: each comes with its path back to the changed code, and the answer says when to run everything instead.
The engineer directs and defends. The agent writes and records. The whiteboard is the language they share.
# what the engineer sees, as JSON enscrive_code_flows enscrive_code_card flow=J01 enscrive_code_card flow=J01 file=api/v1/job_runner.rs # find, then read exactly the item enscrive_code_search "where is the budget reserved before admission" enscrive_code_context "budget_gate::enforce_or_reason" enscrive_code_read "budget_gate::enforce_or_reason" # which tests defend this change, and why enscrive_code_tests base=origin/main # turn a gap into a recorded run enscrive-code trace plan --flow J01 enscrive-code trace absorb trace.jsonl --flow J01
One binary. Your machine. Your code stays yours.
Enscrive Code runs locally against a Postgres it can provision for you with podman or Docker. Point it at directories or git URLs, absorb, name a journey by its entry, and open the deck in your browser. Rust is verified by the compiler today; Python, TypeScript, Go and C are parsed structurally.
Early access is by request: the repository and its signed releases are private for now. Write to us and we will send the build and the one-line instruction for your agent.
Request early access$ enscrive-code init $ enscrive-code scope add ../api-service $ enscrive-code scope add https://github.com/you/embedding-service --ref main $ enscrive-code absorb --all $ enscrive-code flow infer $ enscrive-code flow build --name ingest \ --entry api::v1::ingest::ingest_job --route "POST /v1/ingest" $ enscrive-code serve --open
What is released, and what is ahead.
A product about evidence should hold itself to the same standard. This page is updated when the state changes, not before.
- Absorb five languages into a structural store
- Keyword and neural search, context and exact source reads
- Liveness: reachable, unreachable, gated, declared-but-unregistered
- MCP tools for agents
- The deck: flows, cards, gaps, lenses, the story front page
- Compiler-verified resolution for Rust
- Trace plan and trace absorb
- Projects: switch, create, reset, and watch a build run
- Scope, bring-your-own keys, the shipped concept dictionary
- Test selection: which tests defend a change, the path from each test to the changed code, the commands to run them, and when to run everything instead
- Test selection measured against every failed CI run, in shadow, before it is trusted to skip anything
- Calibrated labels on a real codebase
- The first recorded run bound to a card
- Answers to the four questions, cited to hops
- Compiler verification for the other languages
Enscrive Code is built by Enscrive, on Enscrive’s own twenty-repository stack, and the deck above was first drawn from that stack. The platform behind it, enscrive.io, provides the embedding, storage and neural search Enscrive Code uses when you turn them on.