The best AI coding tools are impressive. They complete your code, explain your tests, and suggest refactors that often look exactly right. But impressive is not the same as trustworthy, and in engineering infrastructure, trustworthy is the harder bar.
The reproducibility test
Here is a simple test: ask your code intelligence tool the same question twice. Does it give you the same answer?
For probabilistic models, the answer is usually: mostly. The answers will be semantically similar but not byte-identical. Temperature, sampling, and model state all introduce variance. This is fine for suggestions. It is not fine for infrastructure, for deploy gates, for security audits, for compliance checks.
Determinism means: same input, always same output. No exceptions, no drift.
Why it matters for real use cases
Blame and audit: if your tool told you a change was safe and it wasn't, you need to know what analysis it performed. A deterministic graph traversal produces an auditable trace. A probabilistic inference does not.
CI gating: deploy gates that rely on non-deterministic analysis will be gamed or ignored. Teams quickly learn to retry until they get the answer they want. A deterministic threshold, blast radius > 30 triggers mandatory review, is unambiguous.
Security analysis: source-free code analysis (where the graph is shared without source code) requires that the shared artifact is stable across runs. If the representation drifts, the privacy guarantee breaks down.
Incremental analysis: deterministic builds can be cached. Only changed nodes need recomputation. Non-deterministic analysis cannot safely be cached, you cannot know if the cached result is still valid.
What determinism costs
Determinism trades flexibility for reliability. A deterministic parser cannot reason about what code means, it can only compute what the code is. It will miss the clever architectural pattern that a language model would catch in a comment.
This is the right trade for infrastructure. You want your deploy gate to say "this function has 34 callers and 8 of them lack test coverage", not "this function seems to be widely used, based on the surrounding context."
The two-layer model
The right architecture uses both: a deterministic graph layer for structure, and a probabilistic layer for semantics. Spiderbrain follows this model: the base graph (import edges, call edges, community membership) is fully deterministic. Semantic enrichment (clustering by topic, extracting intent) is an optional AI layer on top.
The deterministic layer is the foundation you build on. The semantic layer is the intelligence you add. Mixing them, letting probabilistic inference contaminate the structural layer, is where code intelligence tools lose the trust of the teams using them.
The receipt model
Spiderbrain's graph is built from a hash-chained commit fingerprint. Every brain corresponds to exactly one commit. If the commit changes, the brain changes. If neither changes, the brain is identical across every machine, every run, every engineer.
This is what makes "brain as API" possible: when you share a brain with a teammate or a CI system, they know exactly what codebase state it represents. It is a receipt, not a snapshot.