# Three Commands to Make Claude Code Stop Guessing Your Infra

> Source: <https://dev.to/siddharth_pandey_27/three-commands-to-make-claude-code-stop-guessing-your-infra-2onj>
> Published: 2026-06-05 18:30:45+00:00

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
