Stop AI From Recommending Redundant Indexes on Existing GSIs

A developer created Infrawise, an open-source tool that prevents AI coding assistants like Claude Code from recommending redundant DynamoDB indexes by reading real infrastructure data before generating code. The tool calls AWS `DescribeTable` on every table in a user's account to retrieve existing Global Secondary Indexes, then provides this information to AI assistants so they can verify an index already exists before suggesting a new one. Infrawise's `MissingGSIAnalyzer` only flags tables that genuinely lack indexes, eliminating false alarms that could lead to duplicate index creation and wasted write capacity.

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 https://github.com/Sidd27/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: js 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 graph MissingGSIAnalyzer 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 uses suggest gsi is a generation tool — call it only after get infra overview confirms the index doesn't exist