Why Infrawise Uses Deterministic Analysis Instead of an LLM

Ask your AI coding assistant which Global Secondary Indexes exist on your Orders table. It will read your repository, find a few QueryCommand calls, and answer — fluent, specific, and confident. It also has no way to know. GSI definitions live in AWS, not in your source files. The model isn't lying; the fact simply isn't available to it, so it generates the most statistically plausible substitute and delivers it in the same tone it uses for things it actually knows.

That failure mode is why ) — an MCP server that gives AI coding assistants infrastructure context — contains no LLM calls at all. Every answer it serves comes from AST parsing, schema introspection, rule-based analyzers, and graph correlation. The LLM is only ever a consumer of that context, never a producer of it. This post is about why that boundary exists, and what it looks like in code.

Infrastructure questions are lookups, not generation

There are two kinds of questions you can ask a tool. "How should I model sessions in DynamoDB?" is a judgment question — many defensible answers, context matters, an LLM is genuinely useful. "Does the Sessions table have a GSI on userId?" is a fact question. It has exactly one correct answer, and that answer is sitting in a DescribeTable response.

When you route a fact question through a generative model, you convert a lookup with a perfectly accurate source into a prediction with an unknown error rate. The motivating examples in the Infrawise README are all of this shape: an assistant suggesting a .scan() on an Orders table with 50 million rows, recommending a GSI on status that already exists, or not noticing that five functions are already hammering the same partition key. None of these are reasoning failures. They are missing-fact failures, and no amount of model quality fixes them — a better model just produces a more convincing wrong answer.

So Infrawise draws a hard line: facts get extracted deterministically, and the model receives them through MCP tool calls instead of guessing.

What deterministic extraction looks like

Infrawise builds its picture of your system from three sources, none of which involve a model.

Your code, through the compiler's eyes. scanRepository() in src/context/index.ts loads the repo with · npm.

Key takeaways

• A fact question routed through a generative model turns a lookup with a perfect source into a prediction with an unknown error rate. Route facts around the model, not through it.


• AST-level extraction (ts-morph walking CallExpression nodes) catches what schema introspection alone can't see — which function scans which table, and how.


• Rule-based analyzers are unit-testable and fail loudly per rule; model-based analysis is neither.


• A deterministic system can emit a verify severity when it isn't sure. A model can't reliably tell you when it's guessing.


• Put the LLM at the boundary: it consumes structured facts over MCP and decides what to do next — it never gets to invent the facts.