prod-code

Ten coding agents in ten worktrees means ten analyzers and ten cargo builds on one machine. We moved the analyzer, the builds and the tests to Linux nodes on the LAN, mirror the checkout there by content hash, and let the laptop do the one thing it is good at: editing.

Two agents on two worktrees of one repository, sharing one analyzer database, answer each other's questions. A benchmark that forks four worktrees and asserts what each should see, and why we stopped trying to share anything writable.

The analyzer runs on a node across the LAN and needs your code there. Not over a network filesystem, and not by uploading the tree every time: a manifest of hashes, a watermark per node, and a watcher that syncs only when something changed.

LSP is positional: to ask who calls a function you must first know its file, line and column. Agents get that by grepping, and grep does not know what a symbol is. We made every tool take the name instead.

An agent writes a file, runs a build, reads the errors and tries again. The database that answered its last hover could have told it in 100 ms, without writing anything. What that takes, and the one error class rust-analyzer stays silent about.

A 32-core node sitting at 2% load, a one-millisecond network, and half the queries taking 40 ms. Three things we found while measuring instead of guessing, including one optimisation that did not work and one that deadlocked.

Every agent harness runs the same loop: write a candidate fix into your checkout, run the tests, revert, try the next one. We moved that loop into overlay shadows of the mirrored workspace, mounted at the workspace's own path, and it got faster, not just cleaner.

An agent that knows what it wants but not what it is called has nothing to ask. We gave it a question box, then measured what decides whether the answer is any good: not the ranking, the prose your team did or did not write above each function.

A structural rewrite that found nothing, twice, for two unrelated reasons in two different layers. What it takes to tell an empty answer from a broken one, and why the fix was tracing rather than thinking harder.

An agent asked to change one function opens three files and spends most of its context on code that has nothing to do with the task. A slice is the other shape of the same question: the declarations the function depends on, and nothing that merely lives beside them.

A struct with eleven fields shows ten, so any test value built from that answer is missing one and nothing says so until a build. What it takes to generate a fixture you can trust: read the declaration rather than the summary, and type-check the result before handing it over.

Rename is everywhere; changing what a function takes is nowhere. Building it meant letting the declaration write the rule, checking the result against the analyzer's own reference list, and refusing to write anything that does not compile.

Cross-language schema rename needs semantic edits for identifiers and separate text edits for wire names. A polyglot fixture shows how prod-code plans the change, validates it, and reports what remains.

prod-code v0.3.19 expands workspace detection, but a detected language is not proof of semantic support. The marker matrix and release artifacts show what the version provides.

In a multi-agent coding fleet, running separate rust-analyzer instances for every Git worktree multiplies memory consumption. Here is how an in-memory VFS overlay shares a single analysis database across worktrees, the Salsa concurrency traps we encountered, and our proposal to upstream.

In a mixed Go/JavaScript checkout, impact analysis reported zero changed functions and claimed every edit fell outside all functions. Why root manifests blind polyglot analyzers, how arrow functions hide from LSP kinds, and why missing symbols must be a gap rather than a verdict.