You asked Claude Code to fix a slow query on your Orders
table. It came back with a recommendation: add a GSI on customerId
— index name Orders-customerId-index
, projection type ALL
. Clean, well-formatted, ready to paste into Terraform.
Your Orders
table already has Orders-customerId-index
. Has had it for eight months.
The AI read your code. It saw a .query()
call filtering on customerId
, noticed you weren't explicitly referencing an index name, and concluded one was missing. It never checked your actual DynamoDB table. It couldn't — it had no way to.
infrawise fixes this by reading your real infrastructure first, before any code gets written.
AI coding assistants are good at reading code. They're not reading your AWS account.
When Claude Code or Copilot sees this:
const result = await docClient.query({
TableName: 'Orders',
KeyConditionExpression: 'customerId = :cid',
ExpressionAttributeValues: { ':cid': customerId },
});
It has two choices: assume you're using the table's partition key, or flag a potential missing index. Without explicit index name in the code, a cautious AI will suggest one. It's the right instinct — but the wrong answer, because the index already exists.
The damage isn't just a wasted suggestion. It's the next step: a junior engineer applies the Terraform diff, CloudFormation complains about a duplicate index name, and now you've got an incident ticket. Or worse — the AI generates a second index with a slightly different name (Orders-customerId-gsi
), and now you're paying for duplicate write capacity on every Orders
write.
When you run infrawise analyze
, the DynamoDB adapter calls DescribeTable
on every table in your account. The response includes GlobalSecondaryIndexes
— the full list of indexes that actually exist, right now, in production:
GET / → DescribeTable { TableName: 'Orders' }
Response:
GlobalSecondaryIndexes:
- IndexName: Orders-customerId-index
KeySchema: [{ AttributeName: customerId, KeyType: HASH }]
Projection: { ProjectionType: ALL }
- IndexName: Orders-status-date-index
KeySchema: [{ AttributeName: status, KeyType: HASH }, { AttributeName: createdAt, KeyType: RANGE }]
These index names go directly into the graph as uses_index
edges on the table node. The graph now knows: Orders
has two GSIs, covering customerId
and the status + createdAt
composite pattern.
The MissingGSIAnalyzer
checks for tables with query edges but zero uses_index
edges — tables your code queries that genuinely have no indexes at all. If Orders
has uses_index
edges, the analyzer doesn't fire for it. No false alarm, no redundant suggestion.
Once infrawise dev
is running, Claude Code connects to it and the workflow changes. Before writing any query logic, the first call is get_infra_overview
:
→ get_infra_overview
Tables:
Orders dynamodb
Products dynamodb
UserSessions dynamodb
High-severity findings: 0
Medium-severity findings: 1
→ UserSessions has no GSIs but is queried by 3 functions
Orders
is there. No finding next to it — because it has indexes. The AI sees this and knows not to suggest new ones.
If you then call analyze_function
on the function that queries Orders
, the response includes the existing uses_index
edges:
→ analyze_function { function: "getOrdersByCustomer" }
Services accessed:
Orders (query, uses_index: Orders-customerId-index)
Findings: none
The index name is right there. The AI writes the query with IndexName: 'Orders-customerId-index'
— not because it's smart, but because it's reading real data.
The suggest_gsi
tool is explicit about its own limitation. Its description reads: "Does not verify whether the GSI already exists; check the table schema in get_infra_overview first." It's intentionally a generation tool, not a verification tool. Verification is
get_infra_overview
. The workflow is: look first, generate only if it's missing.The problem isn't that AI is careless. It's that AI is working from code, and code doesn't contain your infrastructure state. A .query()
call doesn't tell you whether the table has an index. A function name doesn't tell you what's deployed.
infrawise bridges that gap by pulling live infrastructure state — DescribeTable
, real index names, real projection types — and exposing it through MCP before any code gets written. The AI stops suggesting indexes that exist because it can now see the ones that do.
npm install -g infrawise
, run infrawise init
in your repo, then infrawise dev
. The first time Claude Code calls get_infra_overview
and sees your actual table schema, the redundant GSI suggestions stop.
DescribeTable
on every DynamoDB table and extracts the full GlobalSecondaryIndexes
list into the infrastructure graphMissingGSIAnalyzer
fires only on tables with get_infra_overview
surfaces existing index names before any code is written; analyze_function
shows which index a specific query usessuggest_gsi
is a generation tool — call it only after get_infra_overview
confirms the index doesn't exist