# Stop AI From Recommending Redundant Indexes on Existing GSIs

> Source: <https://dev.to/siddharth_pandey_27/stop-ai-from-recommending-redundant-indexes-on-existing-gsis-5lo>
> Published: 2026-06-03 17:15:28+00:00

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