DEV Community: Siddharth Pandey

Three Commands to Make Claude Code Stop Guessing Your Infra

Siddharth Pandey — Fri, 05 Jun 2026 18:30:45 +0000

You asked Claude Code to add a query for orders by customer status. It generated a .scan() with a FilterExpression. Your Orders table has 50M rows and three functions already hammering the same partition key. Claude Code had no idea — it read your TypeScript files, not your AWS account.

That's the problem. AI coding assistants are literate in your source code. They are blind to your infrastructure.

GitHub · npm

What Claude Code Actually Sees (and What It Doesn't)

When Claude Code reads your codebase, it builds a model of your application: function names, variable patterns, the string "Orders" passed to DynamoDB.DocumentClient. It can follow call chains, infer intent, and generate syntactically correct code.

What it cannot do is describe your actual infrastructure:

It doesn't know which GSIs exist on your DynamoDB tables
It doesn't know how your tables are partitioned or what sort keys you use
It doesn't know that listAllOrders() already does a full scan and costs $40/day
It doesn't know that 5 functions already write to the same partition key on Sessions

So when you ask it to add a new query, it generates something that looks correct. It might use .query() instead of .scan(). But it'll query on an attribute with no index — because it has no way to know which attributes are indexed. It'll write a FilterExpression that reads every item before filtering — which is exactly a scan, just spelled differently.

The code compiles. Tests pass. The problem ships.

The Three Commands That Close the Gap

infrawise gives Claude Code deterministic knowledge of your infrastructure through the Model Context Protocol. Three commands get you there.

1. infrawise init

cd your-project
infrawise init

Runs once per project. Detects your AWS profile and region, asks which databases you use, and writes a single file: infrawise.yaml. That's the only file it creates in your repository — one config, no framework, no SDK changes.

2. infrawise doctor

infrawise doctor

Before you trust any analysis, verify that infrawise can actually reach your infrastructure. Doctor checks every configured adapter — DynamoDB, PostgreSQL, Lambda, S3 — and reports what's reachable.

This step matters more than it sounds. If your AWS credentials are stale or your DB password rotated, infrawise analyze will run against cached metadata from last week and give you confident-but-wrong context. Doctor catches this before you feed stale data to Claude Code.

✓ DynamoDB  Connected (profile: default)
✓ PostgreSQL  Connected
✗ Lambda  credentials expired

Fix what's broken, then move on.

3. infrawise dev

infrawise dev

The command you run while you work. It runs a fresh analysis of your repository and infrastructure, then starts an MCP server that Claude Code queries during code generation.

If no analysis cache exists, it runs one automatically. If your infrastructure changes — you add a GSI, a new Lambda, a new table — run infrawise dev again and the context updates.

claude mcp add --transport http infrawise http://localhost:3000/mcp

From that point, every time Claude Code generates infrastructure-touching code, it queries this server first.

What Claude Code Can See After You Run Them

Here's what infrawise analyze surfaces on a real project:

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
         High access concentration may create hot partition issues at scale.
       → Consider write sharding or DynamoDB DAX for read-heavy workloads.

These aren't generic warnings. They name the function (listAllOrders), the table (Orders), and the exact fix (CREATE INDEX CONCURRENTLY idx_users_email ON users(email)). The GSI recommendation for DynamoDB includes the exact config — attribute name, key type, projection — not a suggestion to "consider adding an index."

When Claude Code queries the MCP server and gets this context:

It won't suggest .scan() on Orders — it knows the table has 50M rows and an existing high-severity finding
It will use the correct partition key and GSI name when building a .query() — because it knows both
It won't recommend adding a GSI on status — because it knows that GSI already exists
It will note that Sessions already has 6 access paths before adding a seventh

You're not getting a smarter model. You're giving the existing model the facts it was missing.

Conclusion

The gap between AI-generated code and production-safe code is mostly an information gap. Claude Code is capable of writing correct infrastructure queries — it just doesn't have your infrastructure. infrawise init connects it. infrawise doctor validates the connection. infrawise dev keeps it current.

Three commands. One config file. No changes to your application code.

Key Takeaways

Claude Code reads code, not cloud — that's the gap infrawise fills
infrawise init runs once and writes a single infrawise.yaml to your project
infrawise doctor prevents you from trusting analysis built on stale or broken connections
infrawise dev keeps infra context fresh automatically and serves it over MCP
Findings are specific: function name, table name, exact SQL or GSI config — not generic advice

Stop AI From Recommending Redundant Indexes on Existing GSIs

Siddharth Pandey — Wed, 03 Jun 2026 17:15:28 +0000

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

How infrawise Catches the DynamoDB Scan You Didn't Know You Were Making

Siddharth Pandey — Mon, 01 Jun 2026 15:12:25 +0000

Your Orders table has 50 million rows. Claude Code wrote a listAllOrders() function that calls .scan() with no filter. It compiled. Tests passed. Friday morning, your DynamoDB bill had a new line item.

The problem isn't the AI — it's that the AI had no way to know. infrawise solves this by building a deterministic model of your actual infrastructure and exposing it through MCP before any code gets written. This post is about how the scan detection actually works under the hood.

Step 1: Scanning the Repository with ts-morph

When you run infrawise analyze, the first pass is a TypeScript/JavaScript AST scan using ts-morph. infrawise walks every source file looking for database client call expressions — DynamoDB DocumentClient.scan, .query, .get; PostgreSQL pg.query; Mongoose model methods.

For each call site it finds, it records three things: the containing function name, the target table or collection, and the operation type. A .scan() call becomes an edge with type scan. A .query() call becomes a query edge. These edges are the raw material for the graph.

The limitation is real and documented: only TypeScript and JavaScript are supported. Dynamically constructed queries — where the table name or operation is assembled at runtime from a variable — may not resolve. infrawise handles what static analysis can handle and flags the rest.

Step 2: Infrastructure Introspection

In parallel, infrawise calls your AWS APIs directly. For DynamoDB it reads every table's actual schema: partition key, sort key, every GSI with its projection type and key schema, item count, billing mode. For Lambda it reads function configurations, memory, timeouts, and event source mappings. SQS queues, SNS topics, SSM parameters, Secrets Manager secrets, RDS instances, and CloudWatch log groups are all pulled the same way — deterministic API calls, no inference.

This is what separates it from passing your Terraform files to an AI. Reading a .tf file tells you what should exist. Calling dynamodb.describeTable tells you what does exist, right now.

Step 3: Building the Graph

The graph engine connects the AST output to the infrastructure metadata. Each DynamoDB table, Lambda function, SQS queue, and RDS instance becomes a node. The call sites from the AST scan become typed edges between function nodes and table nodes: scan, query, get, publishes_to, uses_index.

The result is a queryable graph. You can ask: which function nodes have scan edges pointing to the Orders table node? That's exactly the query the FullTableScanAnalyzer runs.

Step 4: The 24 Analyzers

infrawise ships 24 rule-based analyzers. Each one is a graph traversal or a schema comparison — no model, no inference.

FullTableScanAnalyzer calls getScanEdges, which filters all graph edges where type === 'scan'. For each edge that points to a DynamoDB table node, it records the table and the calling function, then emits a HIGH severity finding. No threshold, no heuristic — any .scan() on a DynamoDB table is flagged:

  1.  HIGH   Full table scan detected on DynamoDB table "Orders"
             The table "Orders" is being scanned without any filter,
             which reads every item. This is expensive and slow for
             large tables. Called from: listAllOrders
             → Replace Scan with a Query operation using a partition
               key or GSI. If filtering is required on non-key
               attributes, add a Global Secondary Index (GSI).

The other analyzers follow the same pattern. MissingGSIAnalyzer finds tables that have query edges but no uses_index edges — tables being queried with no GSI coverage. HotPartitionAnalyzer counts distinct function nodes with edges to the same table; at five or more, it fires MEDIUM. MissingIndexAnalyzer compares PostgreSQL query predicates against the introspected pg_indexes view. NplusOneAnalyzer looks for repeated query edges from the same function in a loop pattern. Every rule is structural.

How This Reaches Your AI Assistant

Running infrawise dev starts a Fastify MCP server on Streamable HTTP. Claude Code connects to it and can query 13 tools — get_infra_overview, analyze_function, suggest_gsi, postgres_index_suggestions, and others.

When Claude Code is about to write a query against Orders, it calls analyze_function first. The response includes the table schema, any existing GSIs, and the scan finding if one was detected. The AI writes a query with the correct partition key instead of a scan — not because it's smarter, but because it now has the same information a senior engineer would check before touching the table.

For Claude Desktop, infrawise stdio starts the same server on stdio transport.

Conclusion

The scan finding is the most visible output, but the real work is the graph: AST edges from ts-morph connecting function call sites to infrastructure nodes from live AWS APIs, traversed by 24 deterministic rules. No LLM touches the analysis path.

If you're running Claude Code against a codebase with DynamoDB tables, npm install -g infrawise and infrawise init in your repo. The first infrawise analyze usually finds something your AI assistant would have gotten wrong.

GitHub · npm

Key Takeaways

infrawise uses ts-morph to parse TypeScript/JavaScript source into a graph of function-to-table edges, typed by operation (scan, query, get).
AWS infrastructure metadata comes from live API calls — not Terraform, not static files — so the graph reflects what actually exists.
24 rule-based analyzers traverse the graph deterministically; FullTableScanAnalyzer flags any .scan() edge to a DynamoDB table as HIGH with no threshold.
Context is exposed through an MCP server (Streamable HTTP for Claude Code, stdio for Claude Desktop) so AI tools see findings before they generate code.
The analysis path contains zero LLMs — every finding is a graph query or schema comparison.

Git Knows Who. AI Knows What. Nobody Knows Why.

Siddharth Pandey — Sun, 31 May 2026 11:24:18 +0000

Modern software development has achieved incredible things.

AI can generate entire features.

Editors can autocomplete your thoughts before you've finished having them.

Agents can open PRs while you're still reading the ticket.

And yet, despite all this progress, there is still one question capable of ruining a senior engineer's afternoon:

Why the hell does this code exist?

Consider this innocent little gem:

if (distance < 50) {
  return;
}

Looks simple.

AI can explain it.

Git can tell you who wrote it.

The PR can tell you when it was merged.

But nobody can tell you why it was added in the first place.

Was it reducing GPS noise?

Was it preventing duplicate events?

Was it added because thousands of devices were rapidly entering and exiting the same geofence?

Was it a workaround for a production incident that woke up three engineers on a Sunday morning?

We may never know.

The Archaeology Phase of Software Engineering

Every mature codebase eventually turns developers into archaeologists.

You discover a mysterious piece of code and begin the sacred ritual:

Check Git blame.
Open commit.
Open PR.
Open linked ticket.
Ticket references a Slack discussion.
Slack link is dead.
Original author left the company.
Team lead moved to another startup.
Nobody remembers anything.

Congratulations.

You have reached the end of the knowledge graph.

The only remaining documentation is a comment that says:

// Don't remove this

Thank you, mysterious engineer from 2023.

Very helpful.

AI Is About To Make This Much Worse

The old workflow looked like this:

Human thinks
    ↓
Human writes code
    ↓
Human forgets why

The new workflow looks like this:

Human writes ticket
    ↓
AI writes code
    ↓
Human edits code
    ↓
Another AI refactors code
    ↓
Reviewer requests changes
    ↓
Code reaches production
    ↓
Everyone forgets why

We have successfully automated everything except remembering our decisions.

We Have Documentation Everywhere

The funny thing is that companies already have mountains of documentation.

The requirement is in Linear.

The discussion is in Slack.

The design is in Notion.

The implementation is in GitHub.

The AI conversation is in Cursor.

The meeting notes are somewhere in a folder named:

Final_v2_Updated_Final_Real_Final

The problem isn't missing information.

The problem is that all the information lives in different universes.

Git Answers The Wrong Question

Git is fantastic.

Ask Git:

Who changed this?

Git:

Bob.

Ask Git:

When?

Git:

February 14th, 2026.

Ask Git:

Why?

Git:

Commit message: "fix stuff"

Fantastic.

Outstanding.

Truly the pinnacle of human knowledge preservation.

The Shortcut We Actually Need

We already have:

Go To Definition
Find References
Rename Symbol

What we don't have is:

Ctrl + Y

Which means:

Why is this here?

Imagine clicking a line of code and seeing:

Reason:
Ignore GPS drift within 50 meters.

Requirement:
TRACKING-123

Discussion:
Customers reported phantom arrivals and departures.

Implementation:
PR #482

Generated by:
Cursor

Reviewer:
Sarah

Business Assumption:
Location updates within 50 meters are considered noise.

Now that's useful.

Because most bugs aren't caused by developers not understanding code.

They're caused by developers not understanding decisions.

The Missing Layer

For decades we've been obsessed with source code.

Then we became obsessed with documentation.

Now we're obsessed with AI code generation.

Meanwhile the most valuable thing keeps disappearing:

The reasoning.

The chain actually looks like this:

Requirement
    ↓
Discussion
    ↓
Decision
    ↓
AI Generation
    ↓
Code Review
    ↓
  Code

Today we only preserve the last two steps.

Then six months later we hold a meeting to rediscover the first four.

Maybe This Is the Next Developer Tool

What if a VS Code extension could answer:

Why does this code exist?

Not by hallucinating.

Not by guessing.

But by building a traceable chain:

Requirement
    ↓
Discussion
    ↓
AI Session
    ↓
Code Review
    ↓
  Code

Click a line.

Press Ctrl+Y.

Get the story.

Not just the syntax.

Future Technical Debt

People think AI-generated code is the next challenge.

I disagree.

The next challenge is AI-generated code with missing context.

Code can be read.

Logic can be reverse-engineered.

Intent is much harder.

And every year we're generating more code while preserving less reasoning.

That's a dangerous trade.

Final Thought

Git knows who.

AI knows what.

Nobody knows why.

And somewhere inside your production codebase is a line that nobody dares delete because the original author left three companies ago and the only documentation says:

// Trust me

Which, historically, has never caused any problems.

How RAGScope Knows Which Chunks Your LLM Actually Used

Siddharth Pandey — Sun, 31 May 2026 09:46:24 +0000

Your retriever fetched 10 chunks. Your LLM only used 3. RAGScope shows a precision score of 30 out of 100. The question every new user asks: how does it know?

There is no OpenTelemetry attribute that says "this chunk was in the context window." RAGScope infers it — and the way it does this is the most consequential piece of engineering in the whole tool.

There Is No "In Context" Attribute in OTel

The OpenTelemetry semantic conventions for generative AI (gen_ai.*) define attributes for model, input/output tokens, and retrieved documents. They do not define anything like gen_ai.chunk.reached_llm or gen_ai.retrieval.used_document_ids.

When your RETRIEVER span fires, you get a list of documents. When your LLM span fires, you get a prompt and a completion. The two spans are connected by a parent-child trace relationship — but there is no attribute that maps which retrieved documents appear in which prompt.

This gap matters. A reranker might drop 7 of your 10 chunks. Your application code might apply a token budget and truncate 4 more. From the trace alone, you cannot tell.

RAGScope needs this information to compute the precision sub-score — the highest-weighted metric at 40% of the overall score. Getting it wrong would make precision meaningless.

The Substring Match — How `assembleContext` Works

RAGScope's answer is in src/enrichment/pipeline.ts, in a function called assembleContext:

function assembleContext(chunks: RagChunk[], llmSpans: ParsedSpan[]): RagChunk[] {
  const llmPrompts = llmSpans.map((s) => s.prompt).filter((p): p is string => !!p);
  if (llmPrompts.length === 0) return chunks;

  let position = 0;
  return chunks.map((chunk) => {
    if (!chunk.content) return chunk;
    const inContext = llmPrompts.some((p) => p.includes(chunk.content!));
    if (inContext) {
      return { ...chunk, inContext: true, contextPosition: position++ };
    }
    return { ...chunk, inContext: false, contextPosition: null };
  });
}

The approach: collect the raw prompt strings from every LLM span in the trace, then check whether each chunk's content appears as a literal substring of any of those prompts.

If your LLM span records its prompt in the input attribute — which TraceAI, Traceloop, and OpenTelemetry's gen_ai conventions all do — and your retriever span records the chunk content in gen_ai.retrieval.documents — RAGScope has everything it needs.

The contextPosition counter assigns an incrementing index to each in-context chunk in the order they are encountered during the chunks.map() iteration — which follows retrieval rank, not prompt position. It tracks which retrieved chunks are in context and their relative order among in-context chunks.

Why substring matching works

Frameworks like LangChain and LlamaIndex build LLM prompts by concatenating retrieved chunk contents, often wrapped in minimal formatting like Context:\n{chunk}\n. The chunk text itself is usually present verbatim. As long as the chunk content recorded on the RETRIEVER span matches what was injected into the prompt string — which it does when both come from the same retrieval call — substring matching is reliable.

The constraint: chunk.content must be non-empty and non-null. RAGScope only stores content when the RETRIEVER span includes it in the documents array. If your instrumentation omits content and only records chunk IDs, assembleContext cannot match, and precision will read 0% until content is included.

What This Means for Your Precision Score

scoreRetrieval in src/audit/scorer.ts uses the inContext flag directly:

function scoreRetrieval(chunks: RagChunk[]): SubScore {
  const used = chunks.filter((c) => c.inContext).length;
  const score = Math.round((used / chunks.length) * 100);
  return {
    name: 'precision',
    score,
    symbol: symbol(score),
    finding: `${used}/${chunks.length} chunks used`,
    recommendation:
      score < 60
        ? `Reduce TOP_K ${chunks.length}→${Math.max(used, 3)} (only ${used} chunks reached LLM)`
        : null,
  };
}

If 3 of 10 chunks appear in the LLM prompt, precision = 30. The recommendation fires automatically: Reduce TOP_K 10→3. The score contributes 40% to the overall — a 30 on precision alone floors your overall score to at most 43, even if efficiency, redundancy, and coverage are perfect.

This is the most common cause of FAIL scores: teams set TOP_K=10 during early experimentation and never reduce it. Ten chunks get retrieved. Three reach the LLM. The other seven waste token budget and push the efficiency score down too.

The --verbose flag makes this explicit. Each sub-score prints with its finding:

   ✗  precision    30/100  3/10 chunks used
   ✗  efficiency   45/100  55% tokens wasted

And the Recommendations section:

 Recommendations
   → Reduce TOP_K 10→3 (only 3 chunks reached LLM)
   → 55% of retrieved tokens never reached the LLM

When precision reads 0% unexpectedly

If your trace has no LLM spans — for example, you're testing your retriever in isolation — llmPrompts will be empty and assembleContext returns all chunks unchanged with inContext: false. In that case, scoreRetrieval sees zero used chunks over a non-zero total, and precision reads 0.

If your trace has no chunks at all, scoreRetrieval short-circuits to a score of 100 with the finding no chunks — the assumption being that a trace with no retrieved chunks represents a non-retrieval query that shouldn't be penalized.

Conclusion

RAGScope's precision score is only meaningful because assembleContext solves the hardest observability problem in RAG pipelines: figuring out which retrieved chunks actually reached the model. It does this by checking chunk content against LLM prompt strings — no extra instrumentation, no special attributes, no embeddings.

The implication for your setup: include chunk content in your RETRIEVER spans. Without it, assembleContext cannot match, precision stays at zero, and the most impactful metric in your audit is blind. With it, you get the exact number that tells you whether your TOP_K setting is costing you context budget.

Try it: GitHub · npm

Key Takeaways

OTel has no "in context" attribute — RAGScope determines LLM context inclusion by checking if chunk content is a substring of the LLM span's prompt string
assembleContext in src/enrichment/pipeline.ts performs this matching; contextPosition tracks relative order among in-context chunks (by retrieval rank, not prompt position)
Precision is 40% of the overall score — a low precision score is the most common cause of FAIL labels
If chunk content is missing from your RETRIEVER spans, precision will read 0%; include content in your instrumentation to get accurate scores
The automatic recommendation (Reduce TOP_K N→M) fires when precision < 60%, giving a concrete action to take immediately

Node.js Just Closed a Major Gap with Deno and Bun

Siddharth Pandey — Sat, 30 May 2026 10:00:39 +0000

Node.js just closed one of its biggest architectural gaps with Deno and Bun, and honestly, as someone who has lost a non-zero amount of life expectancy to node-gyp, I'm happy about it.

As of Node.js 26.1 (May 2026), we finally have an experimental built-in FFI module (node:ffi). 🎉

The old ritual

Need to call a native C/C++ library?

Write a C++ addon.
Fight with binding.gyp.
Install build tools.
Discover that it works on your machine and nowhere else.
Question your career choices.

The new way

const { DynamicLibrary, suffix } = require('node:ffi');

const lib = new DynamicLibrary(`libsqlite3.${suffix}`);

const sqlite3_libversion = lib.getFunction('sqlite3_libversion', {
  result: 'string'
});

console.log(sqlite3_libversion());

That's it.

No wrapper project.

No C++ glue code.

No sacrificing a goat to the cross-platform compilation gods.

Why this matters

Direct access to native libraries from JavaScript.
Easier integration with Rust, C, and existing system libraries.
Smaller dependency trees.
Much nicer experience for IoT, embedded systems, and vendor SDKs.

Before this, reaching native code from Node often felt like opening a side quest you never signed up for.

Reality check

It's still experimental and FFI won't magically outperform optimized N-API addons. If you're calling a function millions of times per second, native addons still win.

But for most integrations?

This removes a surprising amount of friction.

Node has spent years becoming more batteries-included. Native fetch, built-in test runner, built-in dotenv support, TypeScript support, and now FFI.

For backend developers, this is one of those features that won't make headlines outside our bubble, but it will quietly remove a lot of pain.

And if this means I touch binding.gyp less often, that's already a successful release.

Why Runtime Reality Breaks Static Assumptions

Siddharth Pandey — Sun, 17 May 2026 05:48:18 +0000

Most AI systems today reason about infrastructure as if it is static.

A snapshot of:

code
configs
schemas
deployment definitions

But real systems are not static.

They evolve constantly.

Sometimes intentionally.

Sometimes because somebody made a “temporary workaround” 11 months ago and now the company is emotionally dependent on it.

The Gap Between “Declared” and “Running”

There is always a gap between:

What is declared

Terraform
CloudFormation
CDK
configs
architecture diagrams nobody updated since 2023

What is actually running

hotfixes
partial rollouts
deprecated services still somehow alive
environment drift
shadow dependencies
“temporary” scripts promoted directly into production

AI systems mostly reason over the declared layer.

Production lives in the running layer.

That mismatch is where infrastructure assumptions start becoming dangerous.

Drift Is Normal, Not Exceptional

One thing I’ve learned from real systems:

Drift is not some rare edge case.

Drift is the default operating mode of infrastructure.

Schemas drift.
Queues get reused.
Lambda responsibilities quietly expand.
Environment configs diverge.
Feature flags outlive entire product strategies.

And somehow the system still works through a combination of:

operational experience
institutional memory
monitoring alerts
and collective engineering anxiety

The problem is:
AI systems usually do not have access to any of that context.

Why This Breaks AI Reasoning

If an AI agent assumes:

an index exists because Terraform references it
a queue is active because code imports it
a service is healthy because it appears in configs
an API contract is current because docs mention it

…it can confidently generate completely wrong operational decisions.

Not because the syntax is bad.

Because the system model is stale.

And stale infrastructure assumptions are dangerous precisely because they often look reasonable.

Static Context Has a Ceiling

This is why I think purely static approaches eventually hit a ceiling for infrastructure-heavy AI systems.

You can absolutely improve things with:

better retrieval
larger context windows
repo indexing
schema awareness
dependency graphs

All of that helps.

But eventually runtime reality wins.

Because production systems are living systems.

Not snapshots.

Runtime Truth Is Hard

To reason reliably about infrastructure, AI systems eventually need awareness of:

runtime state
deployment reconciliation
drift detection
evolving dependencies
environment divergence
operational anomalies

In other words:

what is actually true right now.

Not:

what was declared six months ago and hopefully still exists.

That is a much harder problem than code generation.

But it is also the problem that matters most once software reaches production scale.

This Is the Direction I Keep Thinking About

A lot of the thinking behind Infrawise started from this gap between:

static infrastructure definitions and
operational system reality

Right now I’m mostly exploring deterministic infrastructure context through:

schema relationships
infra mapping
dependency awareness
static analysis
topology understanding

But long-term I think runtime observability and operational signals become important too.

Because infrastructure awareness is not just:

“what does the code say?”

It is:

“what is the system actually doing?”

Closing

Current AI coding assistants are already very good at understanding source code.

The next generation will need to understand:

runtime behavior
operational state
infrastructure drift
deployment reality
evolving system relationships

Because production systems are not static architecture diagrams.

They are constantly moving targets held together by software, infrastructure, and a surprising amount of engineering optimism.

Why “More Context” Still Doesn’t Fix Infrastructure

Siddharth Pandey — Fri, 15 May 2026 17:11:03 +0000

A common reaction to AI hallucinating infrastructure is:

“Just give it more context.”

More code.
More docs.
More Terraform.
More logs.
More everything.

It sounds reasonable.

But it quietly assumes something important:

infrastructure understanding is a “volume problem”.

It is not.

More Context Doesn’t Fix Wrong Structure

Let’s say you give an AI agent access to:

Terraform
CloudFormation
CDK
schema definitions
deployment configs
API code
docs

It can now “see more”.

But infrastructure problems are rarely about missing visibility.

They are about missing relationships.

For example:

Which service consumes this queue?
Which Lambda depends on this table?
Which schema version is actually deployed?
Which environment is stale?
Which index is required by this access pattern?

These are not text retrieval problems.

These are graph problems.

RAG Works on Similarity, Not Truth

RAG retrieves things that are:

semantically similar
textually relevant
contextually close

But infrastructure requires:

exact state
exact relationships
exact deployment reality

Similarity is not enough when:

a resource exists in dev but not prod
a schema changed but code didn’t
an index was removed but code still assumes it exists
two services are loosely coupled but heavily dependent

The system becomes inconsistent very quickly.

And AI happily reasons over that inconsistency as if it is unified truth.

The Real Issue: No Deterministic Infrastructure Graph

What AI actually needs is not just more text.

It needs a deterministic representation of the system itself:

services
dependencies
data flows
infrastructure topology
runtime relationships

In simple terms:
a graph where nodes are real infrastructure resources and edges are verified relationships between them — not assumptions inferred from code similarity.

Without that, the model is still guessing.

Even if it has access to your entire repository.

Because repos do not fully represent production systems.

Production systems are behavior.

This Is Where Things Start Breaking Quietly

Most infra failures don’t come from obvious mistakes.

They come from:

outdated assumptions
invisible dependencies
forgotten services
implicit coupling
undocumented flows

AI systems are especially vulnerable here because they treat code as the system.

But production systems are not code.

They are behavior.

This Is the Gap I Keep Thinking About

This is the gap that pushed me toward building Infrawise.

The goal is not just:

“give AI more context.”

It is to make infrastructure relationships structurally understandable for AI systems.

Things like:

real schema relationships
actual index existence
service dependencies
infrastructure topology

Derived from infrastructure state and system analysis — not guessed purely from source code patterns.

Closing

A lot of current AI tooling assumes that if the model sees enough files, eventually it will understand the system.

I don’t think that is true.

Because infrastructure problems are fundamentally relationship problems.

Not autocomplete problems.

Not retrieval problems.

And definitely not “just increase the context window” problems.

Current AI coding assistants are already very good at understanding source code.

The next generation will need to understand:

infrastructure topology
operational relationships
deployment reality
system behavior

Because repos do not fully represent production systems.

Production systems are behavior.

AI Generated a DynamoDB Query That Could Never Work

Siddharth Pandey — Wed, 13 May 2026 06:34:02 +0000

I asked an AI coding assistant to generate a DynamoDB query.

A few seconds later it confidently gave me this:

const result = await dynamo.query({
  TableName: "Orders",
  IndexName: "customerId-createdAt-index",
  KeyConditionExpression: "customerId = :customerId",
});

Looks clean.

Looks professional.

Looks like something a senior backend engineer would casually approve during code review while fighting for survival in their 14th Slack thread of the day.

Tiny issue though.

The index did not exist.

And honestly, this is becoming one of the biggest problems with AI coding tools:
they are extremely good at generating things that look correct.

The AI Wasn't Being Stupid

That’s the interesting part.

The assistant actually made a pretty reasonable guess.

It saw:

DynamoDB usage
query patterns
naming conventions
nearby code

…and predicted what probably existed.

Which is exactly what LLMs are designed to do.

The problem is:
production infrastructure is not based on probability.

Either the GSI exists or it does not.

AWS is unfortunately not very emotionally supportive about this distinction.

Infrastructure Is Not Just "More Context"

A lot of AI tooling conversations eventually turn into:

“We just need better RAG.”

Or:

“We just need larger context windows.”

That helps.

But I think there’s a deeper issue here.

Because infrastructure is not just information.

It’s relationships.

The assistant might read:

Terraform
schema files
docs
migrations
configs

…and still not reliably understand:

which indexes are actually deployed
which environments differ
which access patterns are safe
which infrastructure assumptions are outdated

That’s not just a retrieval problem.

That’s a system understanding problem.

DynamoDB Makes This Very Obvious

DynamoDB is actually a great example here because it is brutally honest about access patterns.

With SQL databases, developers sometimes get away with questionable decisions for a while.

DynamoDB basically says:

“No index? That sounds like a you problem.”

And honestly, fair enough.

The entire database is designed around:

partition strategy
access patterns
deliberate schema design
predictable query paths

Which means an AI assistant cannot just generate random “probably correct” queries and hope reality cooperates.

The query either aligns with infrastructure design or it does not.

There’s not much middle ground.

The Dangerous Part Is Confidence

What makes these failures tricky is that the generated code often looks completely believable.

No syntax errors.
No obvious red flags.
No broken TypeScript.

Just confident infrastructure hallucinations.

And that’s much harder for engineers to detect quickly.

Especially in large systems where:

nobody remembers every index
environments drift over time
schemas evolve constantly
infrastructure knowledge is fragmented across teams

Every company has at least one cloud resource held together entirely by:

historical accidents
undocumented assumptions
and collective organizational fear

AI assistants walk directly into these systems with the confidence of somebody who read half the README and decided they understand the architecture.

This Is The Gap I Keep Thinking About

Most AI coding assistants today are optimized for:

syntax
implementation patterns
framework familiarity
autocomplete quality

But production systems need something else:

operational awareness

The assistant needs deterministic understanding of:

infrastructure topology
indexes
schema relationships
runtime dependencies
deployment reality

Otherwise it is just making educated guesses about systems that may cost thousands of dollars per mistake.

That feels slightly important.

This Is One of the Reasons I Started Building Infrawise

This problem is one of the reasons I started working on opensource project Infrawise.

The idea is simple:

Instead of forcing AI assistants to infer infrastructure from scattered code and configs, provide deterministic infrastructure context directly.

Things like:

DynamoDB index awareness
schema relationships
infrastructure mapping
static analysis
AI-consumable infrastructure context

Not “AI magic.”

Just explicit system understanding.

Because hallucinated code is annoying.

Hallucinated infrastructure is how people accidentally discover entirely new AWS billing experiences.

AI Needs To Understand Systems, Not Just Code

Current AI coding assistants are already very good at understanding source code.

The next generation will need to understand:

architecture
topology
infrastructure relationships
operational constraints
deployed reality

Because software does not actually run inside VS Code.

It runs inside infrastructure.

And infrastructure is where “probably correct” stops being good enough.

Why RAG Alone Cannot Understand Infrastructure

Siddharth Pandey — Mon, 11 May 2026 12:04:13 +0000

Every AI tooling discussion eventually reaches the same sentence:

“Just use RAG.”

At this point, RAG is basically the duct tape of AI architecture.

Missing context?
RAG.

Bad answers?
RAG.

AI hallucinating production infrastructure?
Apparently also RAG.

To be clear: Retrieval-Augmented Generation is genuinely useful.

It improves grounding.
It reduces hallucinations.
It helps AI systems access external knowledge.

But there’s a growing misconception in AI engineering right now:

More retrieval does not automatically create system understanding.

And infrastructure problems are usually system understanding problems.

The Problem Is Not Missing Text

Most infrastructure failures in AI coding assistants are not happening because documentation is missing.

The problem is that infrastructure knowledge is relational, fragmented, and operational.

For example, imagine asking an AI assistant:

“Can this DynamoDB access pattern use an existing index?”

That answer depends on:

actual GSIs
partition keys
sort keys
deployed schema state
access patterns
environment-specific infrastructure
workload constraints

That is not just a “retrieve the right paragraph” problem.

A vector database cannot magically infer operational relationships from semantically similar chunks of text.

Infrastructure is not a Wikipedia article.

It is a topology.

The “Looks Correct” Problem

This is where AI gets dangerous.

The generated output often looks completely reasonable.

Example:

await ordersTable.query({
  IndexName: "customerId-createdAt-index",
});

Looks valid.

Compiles.

Very professional-looking.

Tiny problem: the index does not exist.

The AI retrieved enough surrounding context to generate something statistically plausible.

But plausible infrastructure is not the same thing as real infrastructure.

This is the core limitation of relying entirely on semantic retrieval.

RAG helps models retrieve information.

Infrastructure awareness requires understanding relationships.

Those are different problems.

Infrastructure Is a Graph Problem

Modern systems are deeply interconnected.

A single API endpoint might depend on:

DynamoDB tables
GSIs
SQS queues
Lambda functions
deployment environments
feature flags
event consumers
schema versions

Now imagine asking:

“What breaks if I change this schema?”

That is not a chunk retrieval problem.

That is dependency analysis.

The AI needs to understand:

who consumes the schema
where it is used
which systems depend on it
whether environments differ
whether migrations already exist

Most RAG systems fundamentally operate on semantic similarity.

Infrastructure problems often require deterministic relationship mapping.

Very different category of problem.

Bigger Context Windows Do Not Solve This Either

A lot of people assume larger context windows will eventually solve infrastructure awareness.

I do not think that is true.

A 2 million token context window filled with:

Terraform
CloudFormation
CDK
schemas
docs
configs
deployment files

still does not automatically produce reliable topology understanding.

Because the issue is not just visibility.

It is interpretation.

Even humans struggle with this.

Every engineering organization has:

infrastructure nobody wants to touch
queues nobody fully understands
“temporary” resources that became permanent
databases held together by historical accidents and organizational fear

Giving AI more tokens to read does not automatically create operational intelligence.

Otherwise every engineer who read all the docs would already fully understand production.

Which is obviously not how reality works.

Semantic Similarity vs Deterministic Context

This distinction matters a lot.

RAG systems answer questions like:

“What information is semantically related to this query?”

Infrastructure-aware systems need to answer questions like:

Which indexes actually exist?
Which services consume this queue?
Which schema version is deployed?
Which environment contains this resource?
Which APIs depend on this table?
Which resources are connected?

Those answers should not come from probabilistic guessing.

They should come from deterministic infrastructure context.

That is the missing layer most AI coding systems still lack.

This Is One of the Reasons I Started Building Infrawise

One of the reasons I started working on Infrawise was this exact gap.

The goal is not:

“put infrastructure docs into embeddings.”

The goal is to make infrastructure relationships explicit enough that AI systems stop guessing.

Things like:

DynamoDB index awareness
schema relationships
infrastructure mapping
static analysis
AI-consumable infrastructure context
deterministic extraction pipelines

Not just “more retrieval.”

Because honestly, some infrastructure mistakes are too expensive to leave to semantic similarity.

The Future Is Not Just Better Retrieval

RAG is useful.

It will absolutely remain part of AI systems.

But infrastructure-aware AI requires more than retrieval.

It requires:

topology understanding
dependency mapping
deterministic infrastructure state
operational context
relationship awareness

The next generation of AI coding assistants will not just retrieve infrastructure knowledge.

They will need to understand infrastructure reality.

And that is a much harder problem than embedding documents into a vector database.

Your AI Assistant Knows Your Code But Not Your Architecture

Siddharth Pandey — Sun, 10 May 2026 11:03:22 +0000

AI coding assistants are getting dangerously good.

They can refactor code, generate APIs, write SQL queries, explain regex you wrote at 2 AM during a production incident, and confidently suggest changes that look correct.

And that’s exactly the problem.

Because your AI assistant knows your code.

It does not know your architecture.

There’s a huge difference between:

“I read your files”

and

“I understand your system.”

Right now, most AI tools are basically that one engineer who joined last week, skimmed the repo for 20 minutes, and immediately started suggesting database changes in production.

The Confidence Problem

Let’s say you ask your AI assistant:

“Generate a DynamoDB query for customer orders.”

It happily gives you this:

const result = await dynamo.query({
  TableName: "Orders",
  IndexName: "customerId-createdAt-index",
  KeyConditionExpression: "customerId = :customerId",
});

Looks clean.

Very professional.

Tiny issue though.

That GSI does not exist.

The assistant saw patterns in code and statistically guessed what probably exists.

Which is honestly terrifying when you think about it.

Because infrastructure is not autocomplete-friendly.

Your Architecture Lives Outside the Code

Modern systems are scattered across:

Terraform
CloudFormation
CDK
databases
queues
topics
IAM policies
deployment pipelines
cloud consoles
“temporary” scripts from 2022 that somehow became production-critical

Meanwhile the AI assistant is sitting there reading:

await ordersTable.query(...)

and internally going:

“I have absolutely no idea what this system actually looks like, but statistically speaking… vibes.”

That’s how you end up with:

PostgreSQL joins on non-indexed columns
Event flow assumptions based entirely on naming conventions
DynamoDB scans quietly disguised as “optimizations”
APIs generated against schemas that were deleted three migrations ago
Infrastructure suggestions that look plausible but do not match deployed reality

The code compiles.

The architecture cries silently in the background.

Inference Is Not Infrastructure Awareness

This is the core issue.

Today’s AI coding assistants are really good at inference.

But infrastructure requires deterministic understanding.

There’s a massive difference between:

“This probably exists” and
“This definitely exists in production”

Humans already struggle with this.

Every company has at least one production resource that:

nobody fully understands
nobody wants to touch
somehow costs thousands per month
and is protected by pure organizational fear

Now imagine an AI confidently modifying systems like that.

Why Bigger Context Windows Won’t Solve This

A lot of tooling right now is focused on:

larger context windows
better embeddings
repository RAG
more docs ingestion

Helpful? Yes.

Sufficient? No.

Because infrastructure problems are relationship problems.

Questions like:

Which services consume this queue?
Which indexes support this access pattern?
Which schemas are actually deployed?
Which Lambda depends on this topic?
Which environment even has this resource?

These are topology questions.

Not autocomplete questions.

A 2 million token context window still cannot magically understand infrastructure relationships if the information itself is fragmented or ambiguous.

More tokens do not automatically create system awareness.

This Is Why I Started Building Infrawise

This problem is one of the reasons I started working on Infrawise.

The idea is simple:

Instead of forcing AI assistants to guess infrastructure,
give them deterministic infrastructure context.

Things like:

DynamoDB index awareness
schema relationships
infrastructure mapping
static analysis
infrastructure-aware context for AI systems
MCP integration paths

Not “AI magic.”

Just explicit system understanding.

Because honestly, hallucinated code is annoying.

Hallucinated infrastructure is how people accidentally discover new billing tiers on AWS.

The Next Generation of AI Coding Tools

The current generation of AI assistants understands syntax.

The next generation will need to understand systems.

Not just:

functions
files
classes
frameworks

But:

architecture
runtime dependencies
infrastructure topology
deployment reality
operational constraints

Because software does not run inside VS Code.

It runs inside infrastructure.

And infrastructure is where bad assumptions become expensive.

DEV Community: Siddharth Pandey

Three Commands to Make Claude Code Stop Guessing Your Infra

What Claude Code Actually Sees (and What It Doesn't)

The Three Commands That Close the Gap

What Claude Code Can See After You Run Them

Conclusion

Stop AI From Recommending Redundant Indexes on Existing GSIs

Hook — The GSI Your AI Doesn't Know About

Why AI Gets GSIs Wrong Every Time

How infrawise Reads Your Actual GSI Definitions

What the MCP Tools Surface Before You Write Anything

Conclusion

Key Takeaways

How infrawise Catches the DynamoDB Scan You Didn't Know You Were Making

Step 1: Scanning the Repository with ts-morph

Step 2: Infrastructure Introspection

Step 3: Building the Graph

Step 4: The 24 Analyzers

How This Reaches Your AI Assistant

Conclusion

Key Takeaways

Git Knows Who. AI Knows What. Nobody Knows Why.

The Archaeology Phase of Software Engineering

AI Is About To Make This Much Worse

We Have Documentation Everywhere

Git Answers The Wrong Question

The Shortcut We Actually Need

The Missing Layer

Maybe This Is the Next Developer Tool

Future Technical Debt

Final Thought

How RAGScope Knows Which Chunks Your LLM Actually Used

There Is No "In Context" Attribute in OTel

The Substring Match — How assembleContext Works

Why substring matching works

What This Means for Your Precision Score

When precision reads 0% unexpectedly

Conclusion

Key Takeaways

Node.js Just Closed a Major Gap with Deno and Bun

The old ritual

The new way

Why this matters

Reality check

Why Runtime Reality Breaks Static Assumptions

The Gap Between “Declared” and “Running”

What is declared

What is actually running

Drift Is Normal, Not Exceptional

Why This Breaks AI Reasoning

Static Context Has a Ceiling

Runtime Truth Is Hard

This Is the Direction I Keep Thinking About

Closing

Why “More Context” Still Doesn’t Fix Infrastructure

More Context Doesn’t Fix Wrong Structure

RAG Works on Similarity, Not Truth

The Real Issue: No Deterministic Infrastructure Graph

This Is Where Things Start Breaking Quietly

This Is the Gap I Keep Thinking About

Closing

AI Generated a DynamoDB Query That Could Never Work

The AI Wasn't Being Stupid

Infrastructure Is Not Just "More Context"

DynamoDB Makes This Very Obvious

The Dangerous Part Is Confidence

This Is The Gap I Keep Thinking About

This Is One of the Reasons I Started Building Infrawise

AI Needs To Understand Systems, Not Just Code

Why RAG Alone Cannot Understand Infrastructure

The Problem Is Not Missing Text

The “Looks Correct” Problem

Infrastructure Is a Graph Problem

Bigger Context Windows Do Not Solve This Either

Semantic Similarity vs Deterministic Context

This Is One of the Reasons I Started Building Infrawise

The Future Is Not Just Better Retrieval

Your AI Assistant Knows Your Code But Not Your Architecture

The Confidence Problem

Your Architecture Lives Outside the Code

The Substring Match — How `assembleContext` Works