Stop AI From Recommending Redundant Indexes on Existing GSIs

Hook — The GSI Your AI Doesn't Know About

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.

Why AI Gets GSIs Wrong Every Time

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.

How infrawise Reads Your Actual GSI Definitions

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 }]

Each index goes into the graph as a node behind a uses_index edge on the table, carrying its key schema — index type, partition key, sort key, projection. The graph now knows not just that Orders has two GSIs, but that one is keyed on customerId and the other on status + createdAt, which is what decides whether a given query can use them.

That detail reaches the tools directly: get_table_schema returns the key schema alongside each index name, and suggest_gsi checks it before proposing anything — ask it for an index on customerId and it answers alreadyIndexed: true with the existing index name to pass as IndexName, instead of handing you a duplicate.

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.

What the MCP Tools Surface Before You Write Anything

Once the MCP server 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.

Conclusion

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, then run infrawise start --claude in your repo. The first time Claude Code calls get_infra_overview and sees your actual table schema, the redundant GSI suggestions stop.

GitHub · npm

Key Takeaways

• AI suggests GSIs based on query patterns in code — it has no visibility into indexes that already exist in your AWS account
• infrawise calls DescribeTable on every DynamoDB table and extracts the full GlobalSecondaryIndexes list into the infrastructure graph
• MissingGSIAnalyzer fires only on tables with zero GSI coverage — tables that already have indexes don't trigger it
• get_infra_overview surfaces existing index names before any code is written; analyze_function shows which index a specific query uses
• suggest_gsi is a generation tool — call it only after get_infra_overview confirms the index doesn't exist