Three Commands to Make Claude Code Stop Guessing Your Infra

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.

GitHub · npm

What Claude Code Actually Sees (and What It Doesn't)

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:

• It doesn't know which GSIs exist on your DynamoDB tables
• It doesn't know how your tables are partitioned or what sort keys you use
• It doesn't know that listAllOrders() already does a full scan and costs $40/day
• It doesn't know that 5 functions already write to the same partition key on 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.

The Three Commands That Close the Gap

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.

What Claude Code Can See After You Run Them

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:

• It won't suggest .scan() on Orders — it knows the table has 50M rows and an existing high-severity finding
• It will use the correct partition key and GSI name when building a .query() — because it knows both
• It won't recommend adding a GSI on status — because it knows that GSI already exists
• It will note that Sessions already has 6 access paths before adding a seventh

You're not getting a smarter model. You're giving the existing model the facts it was missing.

Conclusion

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

1. Claude Code reads code, not cloud — that's the gap infrawise fills
2. infrawise init runs once and writes a single infrawise.yaml to your project
3. infrawise doctor prevents you from trusting analysis built on stale or broken connections
4. infrawise dev keeps infra context fresh automatically and serves it over MCP
5. Findings are specific: function name, table name, exact SQL or GSI config — not generic advice