Three Commands to Make Claude Code Stop Guessing Your Infra

Claude Code, an AI coding assistant, generates infrastructure-touching code without awareness of actual cloud resources, leading to costly errors like full table scans on 50M-row DynamoDB tables. A new tool called infrawise solves this by giving Claude Code deterministic knowledge of infrastructure through the Model Context Protocol, using three commands: `infrawise init` to configure project settings, `infrawise doctor` to verify live connectivity, and `infrawise dev` to run a local MCP server that surfaces real-time findings such as detected full scans, missing indexes, and hot partition risks.

You asked Claude Code to add a query for orders by customer status. It generated a .scan with a FilterExpression . Your Orders table has 50M rows and three functions already hammering the same partition key. Claude Code had no idea — it read your TypeScript files, not your AWS account. That's the problem. AI coding assistants are literate in your source code. They are blind to your infrastructure. When Claude Code reads your codebase, it builds a model of your application: function names, variable patterns, the string "Orders" passed to DynamoDB.DocumentClient . It can follow call chains, infer intent, and generate syntactically correct code. What it cannot do is describe your actual infrastructure: listAllOrders already does a full scan and costs $40/day Sessions So when you ask it to add a new query, it generates something that looks correct. It might use .query instead of .scan . But it'll query on an attribute with no index — because it has no way to know which attributes are indexed. It'll write a FilterExpression that reads every item before filtering — which is exactly a scan, just spelled differently. The code compiles. Tests pass. The problem ships. infrawise gives Claude Code deterministic knowledge of your infrastructure through the Model Context Protocol. Three commands get you there. 1. infrawise init cd your-project infrawise init Runs once per project. Detects your AWS profile and region, asks which databases you use, and writes a single file: infrawise.yaml . That's the only file it creates in your repository — one config, no framework, no SDK changes. 2. infrawise doctor infrawise doctor Before you trust any analysis, verify that infrawise can actually reach your infrastructure. Doctor checks every configured adapter — DynamoDB, PostgreSQL, Lambda, S3 — and reports what's reachable. This step matters more than it sounds. If your AWS credentials are stale or your DB password rotated, infrawise analyze will run against cached metadata from last week and give you confident-but-wrong context. Doctor catches this before you feed stale data to Claude Code. ✓ DynamoDB Connected profile: default ✓ PostgreSQL Connected ✗ Lambda credentials expired Fix what's broken, then move on. 3. infrawise dev infrawise dev The command you run while you work. It runs a fresh analysis of your repository and infrastructure, then starts an MCP server that Claude Code queries during code generation. If no analysis cache exists, it runs one automatically. If your infrastructure changes — you add a GSI, a new Lambda, a new table — run infrawise dev again and the context updates. Register it with Claude Code once: claude mcp add --transport http infrawise http://localhost:3000/mcp From that point, every time Claude Code generates infrastructure-touching code, it queries this server first. Here's what infrawise analyze surfaces on a real project: Findings 3 total 1. HIGH Full table scan detected on DynamoDB table "Orders" listAllOrders scans without any filter — reads every item in the table. → Replace Scan with Query using a partition key or add a GSI. 2. MED PostgreSQL table "users" has no index on column "email" Filtering on "email" causes sequential scans. → CREATE INDEX CONCURRENTLY idx users email ON users email ; 3. MED DynamoDB table "Sessions" accessed by 6 distinct code paths High access concentration may create hot partition issues at scale. → Consider write sharding or DynamoDB DAX for read-heavy workloads. These aren't generic warnings. They name the function listAllOrders , the table Orders , and the exact fix CREATE INDEX CONCURRENTLY idx users email ON users email . The GSI recommendation for DynamoDB includes the exact config — attribute name, key type, projection — not a suggestion to "consider adding an index." When Claude Code queries the MCP server and gets this context: .scan on Orders — it knows the table has 50M rows and an existing high-severity finding .query — because it knows both status — because it knows that GSI already exists Sessions already has 6 access paths before adding a seventhYou're not getting a smarter model. You're giving the existing model the facts it was missing. The gap between AI-generated code and production-safe code is mostly an information gap. Claude Code is capable of writing correct infrastructure queries — it just doesn't have your infrastructure. infrawise init connects it. infrawise doctor validates the connection. infrawise dev keeps it current. Three commands. One config file. No changes to your application code. Key Takeaways infrawise init runs once and writes a single infrawise.yaml to your project infrawise doctor prevents you from trusting analysis built on stale or broken connections infrawise dev keeps infra context fresh automatically and serves it over MCP