Stop AI From Recommending Redundant Indexes on Existing GSIs

Stop AI From Recommending Redundant Indexes on Existing GSIs

Tópico: Stop AI From Recommending Redundant Indexes on Existing GSIs
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------

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

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.

What the MCP Tools Surface Before You Write Anything

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.

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, 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.

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