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 start

cd your-project
infrawise start --claude

Runs once per project. Detects your AWS profile and region, probes for databases, and writes infrawise.yaml plus a .mcp.json so your editor connects on every future launch. Then it runs the first analysis and opens Claude Code. (--cursor and --vscode write the equivalent config for those editors; with no flag it just writes .mcp.json and exits.)

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 serve

infrawise serve

The MCP server itself. After infrawise start you rarely run this by hand — your editor reads .mcp.json and manages infrawise serve --stdio for you, so from the second session onward you just launch the editor. Run serve directly when you want the HTTP transport instead:

claude mcp add --transport http infrawise http://localhost:3000/mcp

When your infrastructure changes — a new GSI, a new Lambda, a new table — run infrawise analyze. A running server watches its cache and reloads the new analysis on its own, so the editor session you already have open picks it up without a restart.

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 start connects it. infrawise doctor validates the connection. infrawise analyze 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 start runs once and writes infrawise.yaml plus the editor's MCP config
3. infrawise doctor prevents you from trusting analysis built on stale or broken connections
4. infrawise serve exposes the context over MCP, and a re-run of infrawise analyze reloads it live
5. Findings are specific: function name, table name, exact SQL or GSI config — not generic advice

Comments

[EXDEV-ops]

Most people only see the finished product. Looking back, what was the biggest problem you didn’t expect when you first started building it?

[Siddharth Pandey]

Honestly the tool descriptions. I assumed Claude Code would figure out which tool to call based on context. It did not. I had to be really specific about when to use each tool and exactly when NOT to. Once I stopped writing them like code comments and started writing them like instructions for a very literal reader things finally clicked.