{"slug": "stop-ai-from-recommending-redundant-indexes-on-existing-gsis", "title": "Stop AI From Recommending Redundant Indexes on Existing GSIs", "summary": "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.", "body_md": "You asked Claude Code to fix a slow query on your `Orders`\n\ntable. It came back with a recommendation: add a GSI on `customerId`\n\n— index name `Orders-customerId-index`\n\n, projection type `ALL`\n\n. Clean, well-formatted, ready to paste into Terraform.\n\nYour `Orders`\n\ntable already has `Orders-customerId-index`\n\n. Has had it for eight months.\n\nThe AI read your code. It saw a `.query()`\n\ncall filtering on `customerId`\n\n, 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.\n\n[infrawise](https://github.com/Sidd27/infrawise) fixes this by reading your real infrastructure first, before any code gets written.\n\nAI coding assistants are good at reading code. They're not reading your AWS account.\n\nWhen Claude Code or Copilot sees this:\n\n``` js\nconst result = await docClient.query({\n  TableName: 'Orders',\n  KeyConditionExpression: 'customerId = :cid',\n  ExpressionAttributeValues: { ':cid': customerId },\n});\n```\n\nIt 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.\n\nThe 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`\n\n), and now you're paying for duplicate write capacity on every `Orders`\n\nwrite.\n\nWhen you run `infrawise analyze`\n\n, the DynamoDB adapter calls `DescribeTable`\n\non every table in your account. The response includes `GlobalSecondaryIndexes`\n\n— the full list of indexes that actually exist, right now, in production:\n\n```\nGET /  →  DescribeTable { TableName: 'Orders' }\n\nResponse:\n  GlobalSecondaryIndexes:\n    - IndexName: Orders-customerId-index\n      KeySchema: [{ AttributeName: customerId, KeyType: HASH }]\n      Projection: { ProjectionType: ALL }\n    - IndexName: Orders-status-date-index\n      KeySchema: [{ AttributeName: status, KeyType: HASH }, { AttributeName: createdAt, KeyType: RANGE }]\n```\n\nThese index names go directly into the graph as `uses_index`\n\nedges on the table node. The graph now knows: `Orders`\n\nhas two GSIs, covering `customerId`\n\nand the `status + createdAt`\n\ncomposite pattern.\n\nThe `MissingGSIAnalyzer`\n\nchecks for tables with query edges but zero `uses_index`\n\nedges — tables your code queries that genuinely have no indexes at all. If `Orders`\n\nhas `uses_index`\n\nedges, the analyzer doesn't fire for it. No false alarm, no redundant suggestion.\n\nOnce `infrawise dev`\n\nis running, Claude Code connects to it and the workflow changes. Before writing any query logic, the first call is `get_infra_overview`\n\n:\n\n```\n→ get_infra_overview\n\nTables:\n  Orders          dynamodb\n  Products        dynamodb\n  UserSessions    dynamodb\n\nHigh-severity findings: 0\nMedium-severity findings: 1\n  → UserSessions has no GSIs but is queried by 3 functions\n```\n\n`Orders`\n\nis there. No finding next to it — because it has indexes. The AI sees this and knows not to suggest new ones.\n\nIf you then call `analyze_function`\n\non the function that queries `Orders`\n\n, the response includes the existing `uses_index`\n\nedges:\n\n```\n→ analyze_function { function: \"getOrdersByCustomer\" }\n\nServices accessed:\n  Orders  (query, uses_index: Orders-customerId-index)\n\nFindings: none\n```\n\nThe index name is right there. The AI writes the query with `IndexName: 'Orders-customerId-index'`\n\n— not because it's smart, but because it's reading real data.\n\nThe `suggest_gsi`\n\ntool 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\n\n`get_infra_overview`\n\n. 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()`\n\ncall doesn't tell you whether the table has an index. A function name doesn't tell you what's deployed.\n\ninfrawise bridges that gap by pulling live infrastructure state — `DescribeTable`\n\n, 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.\n\n`npm install -g infrawise`\n\n, run `infrawise init`\n\nin your repo, then `infrawise dev`\n\n. The first time Claude Code calls `get_infra_overview`\n\nand sees your actual table schema, the redundant GSI suggestions stop.\n\n`DescribeTable`\n\non every DynamoDB table and extracts the full `GlobalSecondaryIndexes`\n\nlist into the infrastructure graph`MissingGSIAnalyzer`\n\nfires only on tables with `get_infra_overview`\n\nsurfaces existing index names before any code is written; `analyze_function`\n\nshows which index a specific query uses`suggest_gsi`\n\nis a generation tool — call it only after `get_infra_overview`\n\nconfirms the index doesn't exist", "url": "https://wpnews.pro/news/stop-ai-from-recommending-redundant-indexes-on-existing-gsis", "canonical_source": "https://dev.to/siddharth_pandey_27/stop-ai-from-recommending-redundant-indexes-on-existing-gsis-5lo", "published_at": "2026-06-03 17:15:28+00:00", "updated_at": "2026-06-03 17:42:16.389473+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-products", "ai-infrastructure"], "entities": ["Claude Code", "Copilot", "AWS", "Terraform", "CloudFormation", "DynamoDB", "Orders", "infrawise"], "alternates": {"html": "https://wpnews.pro/news/stop-ai-from-recommending-redundant-indexes-on-existing-gsis", "markdown": "https://wpnews.pro/news/stop-ai-from-recommending-redundant-indexes-on-existing-gsis.md", "text": "https://wpnews.pro/news/stop-ai-from-recommending-redundant-indexes-on-existing-gsis.txt", "jsonld": "https://wpnews.pro/news/stop-ai-from-recommending-redundant-indexes-on-existing-gsis.jsonld"}}