Question 1

My AI coding agent says done but the tests fail. How does Vinv help?

Accepted Answer

Vinv never accepts the agent's own claim. When a fix comes back it restarts the app in a fresh process, requires the port to actually serve, and runs acceptance tests generated before the fix that the agent never sees. Failures feed the next attempt; one click reverts everything the fix touched.

Question 2

How do you find dead code in Python from real usage?

Accepted Answer

Static tools like Vulture, deadcode and Knip can only prove that nothing statically references a symbol, so they miss dynamic dispatch, feature flags and registries and emit candidates a human must adjudicate. Vinv joins a real recorded run to the code graph and reports connected islands of symbols that no capture ever executed, together with the live code that still references them — the difference between 'nothing points here' and 'running code points here and the path was never taken', which lead to opposite decisions. It retrieves the traced neighbourhood a section would wire back into with a Personalized PageRank walk, and asks your own coding agent to judge each section as integrate, reimagine, delete, keep or unclear. It refuses to call anything dead when no trace exists, because with zero captures every symbol is untraced.

Question 3

What does Auto-Pilot exercise today?

Accepted Answer

Services and APIs. Auto-Pilot discovers runnable Python services, brings them up under tracelens, and drives their HTTP and related entrypoints. Plain library or in-process function driving is not the Auto-Pilot surface right now.

Question 4

How does Vinv stop an AI agent's doom loop?

Accepted Answer

Each failed attempt's concrete evidence is fed into the next attempt, and Vinv itself ends runs that hang, stall, or repeat themselves — so retries are bounded, informed, and always finish with a verdict instead of an infinite loop.

Question 5

Is untrusted exercise code sandboxed?

Accepted Answer

Targets a purity guard cannot verify are routed through a containment ladder. Where the host provides one, a kernel-enforced OS sandbox makes a write outside the sandbox root impossible rather than merely intercepted; otherwise a Python process shim is used. Either way the run gets a disposable copy of the repo, redirected home and temp directories, blocked network and blocked subprocess spawning, and POSIX resource limits. Which tier you actually got is decided by a probe that verifies a write outside the root really failed, never by a binary being on PATH, and it is reported honestly. Running with no sandbox leaves that whole set refused and undriven rather than running it loose.

Question 6

Does Vinv work with Claude Code, Cursor, Codex, or Copilot?

Accepted Answer

Yes — Vinv serves its code index and runtime evidence over MCP to Claude Code, Cursor (CLI and chat), Codex CLI, Copilot Chat, and Windsurf Cascade, and can hand fixes to any of them, including Gemini CLI.

Question 7

What languages does Vinv support?

Accepted Answer

Runtime evidence — tracing, the oracle swarm and verified fixes — is Python today, for services and APIs. Other stacks still get the semantic index, code graph, and grounded QnA. TypeScript and Go are next.

Question 8

How does Vinv decide which kind of test to run next?

Accepted Answer

One budget is allocated across every armed oracle by Thompson sampling over the action space of target by technique by oracle, instead of driving each oracle exhaustively. Cost is measured — wall-clock normalized to probe-equivalents plus subprocesses spawned — so an oracle that takes forty seconds to find what another finds in one second loses. Credit is paid once per defect signature, within a run and across runs, so a deterministic oracle cannot re-earn credit for the same bug forever. Posteriors persist, so which technique pays on your particular repo is learned. Separately, each endpoint has its own bandit over input strategies rewarded by oracle violations, with new coverage worth only a quarter as much so a coverage treadmill can never outrank actually finding something.

Question 9

Can a cheap commodity model really out-fix a frontier model?

Accepted Answer

On five real issues in fastapi/full-stack-fastapi-template, a cheap commodity model holding Vinv's runtime evidence fixed all five. A frontier model working blind fixed one, and the same commodity model working blind fixed zero, with identical issues and prompts, graded by Vinv. The point is not the model ranking: a model holding the failing frame, the caller chain and the real argument values beats a stronger model guessing from static code. The same discipline found and benchmarked an allocation fast-path on huggingface/smolagents — tracemalloc 36.27 KB to 0.00 KB on a 4 KB log line, about 37,137 times less — upstream as PR #2572.

Question 10

What is Vinv's context graph?

Accepted Answer

Vinv builds three things from your own repo and run — the indexed code, the traces, and the metrics derived from them — and joins all three on the exact function that handled each request. That single graph is what your coding agent queries instead of guessing how separate tools connect.

Question 11

Does Vinv send any data anywhere?

Accepted Answer

There is no telemetry, no analytics, no usage pings and no crash reports. Traces, the code map, embeddings and episode history are written under your project and your home directory and are never uploaded. The extension makes exactly one outbound request of its own: a GET of a static JSON file at notices.vinv.ai on activation, so a release that leaves your install broken has a way to tell you. It carries no query string, no identifiers and no version, nothing is uploaded, all filtering happens on your machine, it fires at most once every 12 hours, and a single setting turns it off. The only other network activity is the install step you run explicitly and whatever your own coding agent CLI does under your account.

Dead code detection that knows what actually ran

two questions, two answers

why runtime beats static here

more