You asked Claude Code to add pagination to your order history endpoint. It generated a clean function — listOrdersByUser() — using a DynamoDB Scan with a Limit parameter. It compiled. Tests passed. You shipped it.
Three days later your AWS bill had a line item you didn't recognize: 47 million read capacity units consumed in 72 hours. The Orders table has 50M rows. Scan reads every one of them regardless of Limit — Limit only controls how many results come back, not how many items DynamoDB reads.
Claude Code didn't know your table had 50M rows. It didn't know you had a GSI on userId. It guessed, and the guess was expensive.
What AI Assistants Don't Know About Your Infrastructure
AI coding assistants read your source files. They understand function signatures, TypeScript types, and import chains. What they cannot see is the infrastructure those functions run against.
When Claude Code looks at a file that calls dynamoClient.scan({ TableName: "Orders" }), it has no idea that:
- The Orders table has 50M items
- There is already a GSI named
userId-indexon theuserIdattribute - Three other functions are already using
Queryagainst that same GSI - The
Sessionstable is accessed by 6 separate code paths, making it a hot partition candidate
Without that context, the assistant fills the gap with generic patterns. It recommends Scan because it has no reason not to. It suggests adding a GSI on status because it doesn't know one exists. It writes SELECT * because it has no idea which columns are expensive to pull.
This isn't a bug in the model. It's a missing input. The model was never given your infrastructure.
What Happens When infrawise Is in the Loop
infrawise statically analyzes your codebase, your DynamoDB tables, and your PostgreSQL schemas, then exposes that context to your editor through MCP. Claude Code gets 15 tools that answer questions like: which tables exist, what are their partition keys and sort keys, which GSIs are already defined, which functions are already scanning, and which patterns are flagged as high severity.
The difference in output is concrete. Here's what infrawise surfaces before any code gets written:
Findings 3 total
1. HIGH Full table scan detected on DynamoDB table "Orders"
listAllOrders() scans without any filter — reads every item in the table.
→ Replace Scan with Query using a partition key or add a GSI.
2. MED PostgreSQL table "users" has no index on column "email"
Filtering on "email" causes sequential scans.
→ CREATE INDEX CONCURRENTLY idx_users_email ON users(email);
3. MED DynamoDB table "Sessions" accessed by 6 distinct code paths
Hot partition risk — multiple functions hammer the same key.
→ Review access patterns and consider partition key design.
When Claude Code has this context, its suggestions change. It knows userId-index exists and recommends Query against it instead of Scan. It knows the email column has no index and includes the exact CREATE INDEX CONCURRENTLY statement rather than a generic suggestion. It knows which functions are already hitting a partition hard before it adds another one.
The recommendations become specific to your actual tables, not generic advice copied from documentation.
infrawise does none of this with an LLM. The analysis is entirely deterministic: TypeScript AST parsing via ts-morph for the code graph, schema introspection for the database layer, rule-based analyzers for pattern detection, and graph correlation to connect code paths to tables. No model is involved in the analysis — models are only consumers of the output.
Wiring It Up — infrawise start --claude
npm install -g infrawise
cd your-project
infrawise start --claude
On first run, infrawise asks a few questions and generates infrawise.yaml. It then scans your AWS services, databases, and codebase, writes .mcp.json so your editor auto-connects, and opens Claude Code with all 15 MCP tools ready.
Every session after that:
claude
No infrawise command needed. The editor manages the MCP connection. Analysis is cached for 24 hours; when the cache goes stale, infrawise stdio — spawned automatically at session start — refreshes it. File changes are detected within the session and the code graph updates automatically without re-running AWS extraction.
For PostgreSQL, infrawise uses a read-only connection. Create the user with these four statements:
CREATE USER infrawise_ro WITH PASSWORD 'yourpassword';
GRANT CONNECT ON DATABASE yourdb TO infrawise_ro;
GRANT USAGE ON SCHEMA public TO infrawise_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO infrawise_ro;
If you want to check findings without opening an editor:
infrawise analyze --severity high
infrawise analyze --severity high --output report.md
The --severity flag accepts high, medium, low, or verify. The --output flag saves findings as a markdown report.
Conclusion
The problem isn't that AI coding assistants write bad code. The problem is that they write code for an infrastructure they've never seen. A Scan on an empty dev table and a Scan on a 50M-row production table look identical in source — the model has no way to tell them apart unless something provides that context.
infrawise makes that context available deterministically, before the code gets written. The assistant stops guessing about your GSIs, your partition keys, and your missing indexes because it no longer needs to guess.
Key Takeaways
- AI coding assistants have no knowledge of your actual infrastructure — they infer from source files and fill gaps with generic patterns
- A
ScanwithLimitstill reads every item in DynamoDB before applying the limit — the model won't know this unless it knows your table's access patterns - infrawise exposes your exact schemas, GSIs, partition keys, and flagged patterns to your editor through MCP — 15 tools Claude Code can query before writing a single line
- All analysis is deterministic: TypeScript AST parsing, schema introspection, rule-based detection — no LLM in the analysis path
- Setup is one command:
infrawise start --claudegenerates config, writes.mcp.json, and opens your editor with full context ready