DEV Community: Siddharth Pandey

Your AI context gets worse the longer you work

Siddharth Pandey — Sun, 06 Sep 2026 17:48:07 +0000

I had my own infrastructure context server running behind my editor, the way I do every day, and noticed it was telling me to re-run the analysis on almost every response. Not occasionally. Almost every request.

My first guess was that I had set a threshold too low. I had not. The refresh hint was doing exactly what it was configured to do — warn after six hours, with a twenty-four hour cache behind it. Those numbers were fine. What had actually happened was that the session had been running long enough for the context layer to quietly empty itself out, while still answering every question in a well-formed, confident-looking way.

That bug is worth writing about, not because the fix is interesting, but because I have now shipped the same class of bug four separate times, and I do not think it is specific to my tool. If you give an AI assistant a live connection to your infrastructure, you have not built a data source. You have built a long-running process. Long-running processes fail in ways one-shot fetches never do, and the AI-shaped version of that failure is unusually quiet.

A context layer is a process, not a fetch

The mental model most people have — mine included, for longer than I would like — is that infrastructure context is a lookup. The assistant needs to know your DynamoDB partition key, something goes and gets it, the answer comes back. Under that model the only interesting question is whether the data is correct.

That is not what actually runs. What runs is a server that boots once, reads your cloud account once, and then stays alive for as long as your editor does — hours, sometimes days — answering from what it has while incrementally updating parts of itself. It watches your source files. It rebuilds a graph on save. It re-checks its cache before every tool call. All of that incremental machinery exists because the alternative is hitting your AWS account on every question an assistant asks, and assistants ask a lot of questions.

Every one of those incremental paths is an opportunity for the long-lived state to drift away from what a fresh start would have produced. Here is the same failure, four times, from one repository's history.

The analyzer that stopped running. An issue filed against the project reads: LambdaMissingTriggerDLQAnalyzer is in the analyzer list used by the full analysis, and absent from the one used by the file-save refresh. The consequence, quoted from the issue: "After the initial infrawise analyze, every file-save triggers runCodeRefresh. From that point forward, all trigger-DLQ findings permanently disappear from the live MCP server's finding set." One missing line in a second list. Save a file once, and a category of finding is gone for the rest of the session.

The server that answered from its boot snapshot. For a while, running a fresh analysis in a second terminal changed nothing for the editor session already open. The fix commit puts it plainly: "a session served its boot snapshot indefinitely and re-running analyze appeared to do nothing."

The caches that expired at different rates. The analysis is stored as several entries — the graph, the findings, the cloud metadata, the record of what was read and when. These used to expire on different clocks: the graph at twenty-four hours, the metadata and provenance at one. A session that ran past an hour served a graph whose companion entries had silently gone null.

The most recent one. Same shape, longer fuse. The file-save refresh rewrites the graph but reads no cloud API, so it rewrites three cache entries and not the other two. That resets the clock on three of them. Past the twenty-four hour mark, a session where you keep editing code holds the graph alive indefinitely while the metadata underneath it expires — after which the rebuilt graph contains no cloud facts at all, and the timestamp saying when the cloud was last read goes null. And a null read-time is treated as "cannot vouch for this", which pins the refresh hint to true on every subsequent response. Which is the behaviour I opened with.

Four bugs, one shape: the incremental path diverged from the full path, and nothing noticed because the divergence produced a valid-looking answer.

Why nobody catches these

Every one of those failures degrades toward a well-formed response.

A missing analyzer does not throw. It produces a findings array that is shorter. An empty findings array is exactly what a healthy account looks like. Expired metadata does not throw either — it produces a graph with fewer nodes, and a graph with fewer nodes is exactly what a smaller account looks like. A null timestamp does not throw. It produces a response where one field is null, in a payload where plenty of fields are legitimately null.

None of that trips an alarm, because from the outside a degraded context layer and a simple environment are byte-for-byte indistinguishable. The tool call succeeded. The JSON parsed. The schema validated.

And then the failure gets laundered through an LLM, which is where it stops being a data problem and becomes a correctness problem. An assistant handed an empty findings list does not say "this list is suspiciously empty for a repository this size." It says your infrastructure looks clean. Handed a graph with no tables in it, it does not ask where the tables went — it writes the query anyway, guessing at a schema, in exactly the confident register it uses when it does know. The whole reason to wire real infrastructure into an assistant is to replace guessing with facts. A silently emptied context layer removes the facts and leaves the confidence.

This is the part that makes it worse than having no integration at all. An assistant with no infrastructure access hedges: I do not have visibility into your tables, you may want to check. That hedge sends you to the console. An assistant with a broken infrastructure integration does not hedge, because as far as it can tell the integration answered.

What to actually check

If you run any long-lived context server — mine, someone else's, or one you wrote — these are the questions worth asking of it. They are the ones I got wrong.

Does the incremental path produce the same thing as a cold start? This is the single highest-value check, and it is testable: build state the slow way, build it the fast way, compare. Two of the four bugs above are exactly this and nothing more. If your refresh path maintains its own list of anything — analyzers, extractors, sources — that list will drift from the authoritative one, because nothing forces someone adding an entry to one to add it to both.

Does related state expire together? If your cached analysis is several pieces, they describe one moment and they must live and die as one. Independent expiry does not produce an error, it produces a chimera: half of Tuesday's read, half of nothing. The fix in my case was to re-stamp the entries the refresh path does not rewrite, so all of them stay on one clock.

Can it distinguish "nothing there" from "did not look"? Every layer between the cloud API and the model needs to preserve this, and by default none of them do — a failed call and an empty account both reduce to [] the moment someone writes a catch that returns a default. If the answer reaching the model is an empty array either way, the model will report an empty account. Carry the failure alongside the data, all the way to the response.

Does a response say when its facts were read? Not when the object was assembled or when the cache file was written — those move for reasons that have nothing to do with your cloud. Rebuilding a graph from cached metadata produces a brand-new object full of old facts, and dating it by its construction time is a lie in the most convincing possible format.

Have you run one session for a full day? Every bug in this article requires uptime to reproduce. A test suite starts fresh, does its thing, and exits in milliseconds. None of these would ever appear there. The most recent one needs twenty-four hours of continuous uptime plus file edits — a combination that occurs constantly in real use and never once in CI.

The uncomfortable conclusion

Feeding an assistant real infrastructure data raises the ceiling on how good its answers can be. It also raises the floor on how bad a silent failure is, because you have removed the reader's reason to double-check. Every bug above made an assistant more confident and less correct at the same time, and the increase in confidence is the part you cannot see.

So the interesting engineering in an AI-aware infrastructure layer is not the extraction. Reading DynamoDB key schemas is a solved problem, and any competent developer can wire up the AWS SDK in an afternoon. The interesting engineering is everything that keeps the layer honest about its own state over a workday: making the fast path agree with the slow path, keeping related state on one clock, refusing to let a failure decay into an empty list, and dating every claim by when it was actually read.

I build this in the open at GitHub — it ships on npm — and the commit history is a fairly honest record of getting each of these wrong first. If you are building something similar, the four checks above will save you the versions I shipped.

Key takeaways

Treat your context layer as a long-running process, not a data source. Its worst failures require uptime to reproduce and will never appear in a test suite that starts fresh.
Test that the incremental path matches a cold start. Any refresh path holding its own list of analyzers, extractors, or sources will drift from the authoritative one.
Expire related cache entries as one unit. Independent TTLs on pieces of a single snapshot produce a half-and-half state that looks valid and is not.
Never let a failed read decay into an empty result. An empty list and a failed call are the same value; only one of them means "nothing is there."
Date every fact by when it was read, not when it was assembled. Rebuilding from cache creates a new object holding old facts, and timestamping it by construction is the most convincing lie available.

Your agent trusts the first match. Should it?

Siddharth Pandey — Tue, 01 Sep 2026 09:09:03 +0000

Someone left a comment on one of my posts describing a bug I had not written about, in a tool I did not build.

They had been working with an MCP codebase-intelligence server. They asked it about a symbol. It answered with a file path, a definition, and a list of references, all well-formed. The answer described a shadow definition sitting in experiments/, not the real one in src/. Nothing errored. Nothing was stale. The tool had found two definitions with the same name and returned whichever one it reached first.

I went and read my own code. analyze_function is the tool an assistant is supposed to call before writing a handler: it reports which tables that function queries, how it queries them, which permissions its role is missing, and the exact event shape of its trigger. It looked like this:

const funcNode = currentGraph.nodes.find(
  (n) => n.type === 'function' && n.name === functionName,
);

.find(). First match wins, silently. That is issue #103, and the person who caused me to open it was describing someone else's product.

The failure mode that has no error to report

I had already thought about two ways infrastructure context goes wrong, and shipped fixes for both.

The first is unread. A source fails to extract, the tool returns an empty list, and an empty list reads exactly like "there is nothing there". Ask whether a queue has a dead-letter queue after the SQS extractor threw a permissions error, and "no DLQ configured" is a sentence the tool has no right to say. That is issue #101, and the fix was to attach a per-source status to every response so a failed read is never mistaken for an absent resource.

The second is stale. The data was read correctly, and then someone ran terraform apply. The snapshot is internally consistent and describes an account that no longer exists. That is issue #102: every response now carries when the infrastructure was read and how long ago, so a caller can judge a three-day-old answer against the question it is answering.

Issue #103 is neither. The extraction succeeded. The data is seconds old. Every field in the response is a real value read from a real source. The response is simply about a different function than the one you asked about, and there is no signal anywhere in it that says so. Freshness metadata does not help. Source status does not help. Both report, correctly, that everything worked.

This is the part I want to argue about, because it changes what a tool owes its caller. Staleness and read failures are conditions you can attach metadata to. Wrong-candidate resolution is a property of the function signature. A lookup that returns one thing when two things matched has already destroyed the evidence that a choice was made. No amount of metadata bolted onto the response can reconstruct it.

Why the wrong answer is the confident one

Function node IDs in the graph are file-scoped. They are built as function:${op.filePath}:${op.functionName} (src/graph/index.ts:452), so getOrder in src/handler.ts and getOrder in experiments/handler.ts are two genuinely distinct nodes with two distinct sets of outgoing edges.

The lookup matched on n.name alone. Which node came back depended on the order the AST scan happened to walk the file tree.

Now trace what an assistant does with that. It calls analyze_function for getOrder because it is about to modify src/handler.ts. It gets back found: true, a real file path, a real list of table accesses, real findings. Suppose the scan reached experiments/handler.ts first: that scratch file queries public.users, while the real handler scans public.orders and has a high-severity finding attached to that scan. The assistant now believes the function it is editing touches users, has no scan problem, and needs no index work. Every downstream decision it makes is coherent, well-reasoned, and built on the wrong file.

Compare that to a tool that fails loudly. A permissions error is annoying and it is honest. You retry, you fix the role, you move on. A well-formed answer about the wrong file is worse than an error, because nothing in your workflow is designed to catch it. You are not going to double-check a response that looks perfectly correct.

The same bug, one layer down

Once I knew the shape, I found it again in the AST scanner. Issue #44: resolving an identifier to its string value did this:

sourceFile
  .getDescendantsOfKind(SyntaxKind.VariableDeclaration)
  .find((d) => d.getName() === name);

A file-wide search for a variable name, returning the first declaration found, regardless of which scope the call site was in. Two functions in one file, each with its own const tableName, and every query in the second function got attributed to the first function's table.

The consequences compound in both directions. Edges land on the wrong table node, so an analyzer flags a missing index on a table that does not need one, and misses a full scan on the table that does. A false finding and a suppressed real finding, from one wrong resolution.

The fix was to stop searching by name and ask the type checker instead:

if (Node.isIdentifier(node)) {
  const symbol = node.getSymbol();
  if (symbol) {
    for (const decl of symbol.getDeclarations()) {
      if (Node.isVariableDeclaration(decl)) {
        const init = decl.getInitializer();
        if (init) return resolveStringValue(init, sourceFile);
      }
    }
  }
}

getSymbol() resolves the identifier the way TypeScript itself resolves it, from the call site outward through enclosing scopes. The name-matching search was never resolution. It was a guess that happened to be right most of the time, which is the most dangerous kind of wrong.

Two different layers of the same codebase, written months apart, both reached for "find the thing with this name" and both got it wrong in the same way. That is not carelessness. .find() is what the language hands you when you ask for a lookup, and it produces a value rather than a complaint. The API shape pulls you toward the bug.

What the codebase was already doing right

The uncomfortable part of issue #103 was that two other resolution paths in the same file already handled ambiguity properly. I had solved this problem, twice, and then not applied it in the third place.

Short-name table qualification. SQL text names tables unqualified (orders), while extracted nodes are schema-qualified (public.orders), so code edges have to be resolved against the extracted schema. When a short name maps to more than one qualified table, the map stores an empty string as a poison value:

qualifiedByShortName.set(key, qualifiedByShortName.has(key) ? '' : n.name);

The empty string is falsy, so qualify() falls through to a placeholder schema instead of binding to one of the two real tables. A collision produces a node that is visibly unresolved rather than an edge pointing confidently at a coin flip.

Schema lookup. get_table_schema uses filter, not find. Ask for orders and you get every table matching that short name across every database, and the tool contract says so explicitly. When nothing matches, it returns up to five suggestions instead of an empty result that might be read as "no such table".

The Lambda linkers. Both linkers that connect a deployed Lambda to the source function implementing it contain the same line:

if (matches.length !== 1) continue;

The IaC linker reads handler paths out of Terraform or CDK and links only when exactly one source function matches both the file base and the export name; those links are marked confidence: 'proven'. The heuristic linker normalizes names and links only when exactly one function matches; those are confidence: 'inferred'. Either way, two candidates means no link at all. The graph would rather have a missing edge than a wrong one.

So the pattern was established. analyze_function was the one place that had not adopted it.

Return the fork, do not resolve it

The fix is small, which is usually the case once the shape is named:

const funcNodes = currentGraph.nodes.filter(
  (n) => n.type === 'function' && n.name === functionName,
);

filter instead of find. Then per-file detail moves into a matches array, one entry per source file defining a function with that name, each with its own file, accesses, and missingPermissions, because all three derive from that specific node's edges. When more than one matched, the response carries ambiguous: true, so the caller sees a fork rather than having to notice that an array got longer.

The regression test is deliberately literal about the scenario from the comment:

it('analyze_function returns every same-named function, not just the first', ...)

It builds a graph with getOrder in handler.ts and getOrder in experiments/handler.ts, then asserts ambiguous is true, matches has length 2, and the second match's access resolves to the table only the shadow file touches. If someone reintroduces a .find(), that test fails on the length assertion before anything else.

The same rule applies one level up, where several deployed Lambdas share a handler path. index.handler repeated across a stack is the ordinary case, not the exotic one, and it means several Lambda nodes legitimately link to a single source function. When that happens the tool returns candidateLambdas with each Lambda name and its link confidence, and withholds the triggers entirely, because attaching one Lambda's SQS trigger to code shared by five of them is exactly the confident-and-wrong answer this whole exercise is about. When exactly one Lambda links, you get resolvedLambda: { lambda, confidence } instead, and the triggers come with it.

Notice what is deliberately absent: there is no file input for disambiguating the call. Adding one would move the decision back to the caller before the caller knows the fork exists. Returning the candidates lets whoever asked pick using context the tool does not have, which is usually just "the file I currently have open".

That is the tradeoff I would defend. The response got larger and slightly harder to consume. An assistant now has to read ambiguous and decide, rather than taking a single answer and running. In exchange, there is no configuration of the repo where the tool asserts something it did not prove.

The general rule

If a lookup can match more than one thing, the return type has to be able to say so. A tool that resolves ambiguity internally is not saving its caller work, it is making a decision on the caller's behalf using less information than the caller has, and then hiding that a decision happened at all.

Three shapes are honest: return every candidate, return nothing and say why, or return one with an explicit confidence marker. What is not honest is returning one of several as if it were the only one. Once you look for it, .find() on a name shows up everywhere, and each one is a small silent assertion that names are unique when the code plainly says they are not.

For an AI assistant this matters more than it does for a human reading the same output. A person who gets back experiments/handler.ts when they asked about src/handler.ts notices the path. An assistant folds it into context and moves on, and the wrong file is now a premise for everything it writes next.

Infrawise is on GitHub and npm if you want to see how the graph, the linkers, and the MCP tools fit together. npx infrawise start gets you a live analysis and an .mcp.json without a config file.

Key takeaways

Fresh, successful, and wrong is a distinct failure mode from stale or unread, and neither freshness metadata nor source-status metadata will catch it. It lives in the function signature, not the response body.
.find() on a name is an assertion that names are unique. In a file-scoped graph, in a scoped language, or across the stacks of a monorepo, that assertion is false more often than it looks.
A wrong answer that is well-formed is more expensive than an error, because nothing downstream is built to question it.
If ambiguity is possible, make the return type able to express it: all candidates, or nothing with a reason, or one with a confidence marker. Not one of several, unmarked.
Refusing to link is a valid outcome. if (matches.length !== 1) continue; produces a graph with a missing edge instead of a wrong one, and a missing edge is a thing you can notice.

When a lookup in your codebase matches two things, what does it return today, and would you be able to tell from the output that there was ever a second candidate?

Your retry logic is correct and does nothing

Siddharth Pandey — Mon, 24 Aug 2026 18:12:14 +0000

A comment on one of my posts sat open as an issue for two weeks before I understood how bad the thing it described actually was.

The post was about an AI assistant missing the SQS trigger on a Lambda. Mads Hansen replied with a sentence I have not been able to unthink since: the trigger shape is the first contract, delivery and retry semantics are the second. Getting event.Records[0].body right tells you how to read a message. It tells you nothing about what happens when one of ten messages in a batch throws.

I filed it as issue #87. The first item on that list is a bug no code reviewer can catch by reading the code, because the code is fine.

The handler that is correct and does nothing

Here is a batch consumer. It is the shape you get if you read the AWS docs and follow them.

export const processOrders = async (event: { Records: { messageId: string }[] }) => {
  const batchItemFailures: { itemIdentifier: string }[] = [];
  for (const record of event.Records) {
    try {
      await handleOrder(record);
    } catch {
      batchItemFailures.push({ itemIdentifier: record.messageId });
    }
  }
  return { batchItemFailures };
};

Nine records succeed, one throws, and the handler reports exactly the one that failed. That is the entire point of a partial batch response: the nine that worked are deleted from the queue, the one that failed comes back on its own.

Except this handler does not do that, because whether anyone listens to that return value is not decided in this file. It is decided by the event source mapping. If FunctionResponseTypes on the mapping does not contain ReportBatchItemFailures, Lambda discards the array. The whole batch is marked failed. All ten records are redelivered, including the nine that already ran to completion.

The failure mode is duplicate processing. Nine orders get handled twice, or twenty times, because one poison message keeps replaying its batch until the queue's retry limit. If your handler is not idempotent, that is double-charged customers, not a log line.

Why nobody catches this in review

Read that handler again with a critical eye. There is nothing wrong with it. It builds the array correctly, it uses messageId as the identifier, it catches per record rather than around the loop. A unit test that feeds it ten records and asserts one entry in batchItemFailures passes.

That is what makes this different from an ordinary bug. The code is not wrong. It is inert. The half of the contract that would make it work lives in a Terraform module in a different repository, or in a CDK stack a different team owns, or in a checkbox someone clicked in the console eighteen months ago. Nothing in your editor, your linter, or your test suite has any visibility into it.

And an AI assistant, asked to "add partial batch failure handling to this consumer," writes exactly the handler above and reports the job done. It is not hallucinating. It wrote the only half it can see.

Two ends of the same contract, two different findings

When I built the check into Infrawise, it became clear the mismatch has two directions and they are not equally bad.

The first is the mapping-side gap. MissingPartialBatchResponseAnalyzer looks for an sqs, kinesis, or dynamodb trigger with a batch size above 1 and no ReportBatchItemFailures. A batch of one has nothing to partially fail, so it is skipped. This one is graded medium: it is a missing capability, but the handler may genuinely not need it.

The second is the mismatch. BatchResponseMismatchAnalyzer fires when the code builds a batchItemFailures array and the mapping for that trigger has the setting off. That is graded high, and the description says why:

The code reads as correct and its unit tests pass; only the mapping tells the truth.

A missing setting is an absence. A mismatch is an active false belief — someone wrote the handler on purpose, believing per-record reporting was on. Every downstream decision they made about idempotency rests on that belief.

Detecting the code side is cheap. Both scanners just match the name: ts-morph looks for a property or shorthand property called batchItemFailures, and the Python scanner matches the same dict key. There is no control-flow tracing to a return statement, because building an array by that name has no other purpose in a Lambda handler.

The infrastructure side costs nothing either. FunctionResponseTypes rides on the ListEventSourceMappings response that trigger extraction already pages through, so the whole check is a field carried forward plus two analyzers.

The rule that keeps it honest

One detail mattered more than the analyzers themselves. Both checks fire only on an explicit false:

// Only an explicit false is evidence. undefined means the mapping was
// never read, and this finding would be an accusation without evidence.
if (trigger.reportsBatchItemFailures !== false) continue;

If a lambda:ListEventSourceMappings call was denied by IAM, or the page failed halfway, the field is undefined, not false. Treating that as "the setting is missing" would produce a high-severity finding about a mapping nothing was ever read from.

That failure would be worse than staying silent. A tool that occasionally accuses you of a bug you do not have gets muted, and then it is not there on the day it is right. So the extractor raises a partial-extraction error carrying whatever it did page through: the data survives, the source is recorded as partial, and the tools report it as unread rather than reporting a clean bill of health.

What actually changed in the loop

Two things, both small.

Before writing a batch consumer, analyze_function now returns the trigger with batchSize and reportsBatchItemFailures alongside the event shape, and get_lambda_overview carries the same fields for every function. So the assistant knows, before it writes a line, whether the partial-batch response it is about to build will be read or discarded. If it is going to be discarded, the honest answer is either "set FunctionResponseTypes first" or "make this handler idempotent," and now that answer is available at coding time.

And because the mismatch is graded high, infrawise check fails the build on it at the default --fail-on high. The mapping-side gap at medium does not — it is a suggestion, not a broken promise. A handler that reports failures nobody reads is a broken promise.

Key takeaways

A partial batch response has two ends. The handler returns batchItemFailures; the event source mapping must set FunctionResponseTypes: ["ReportBatchItemFailures"]. One without the other is not half a feature, it is zero.
Correct code can be inert. The bugs that survive review are the ones where the file is right and the thing it depends on lives somewhere your tooling never looks.
Grade the mismatch above the gap. A missing setting is an absence. A handler written to use a setting that is off is a false belief the rest of the design rests on.
Never infer a setting is off from a read that failed. undefined and false are different answers. A tool that conflates them will eventually be wrong loudly, and after that nobody reads it.
Until both ends are in place, the handler must be idempotent. That is not a workaround, it is the only thing standing between a poison message and processing the same order ten times.

Infrawise is open source and exposes this through MCP, so your assistant reads the mapping's real configuration instead of assuming. GitHub · npm

Your monorepo remembers infrastructure you deleted

Siddharth Pandey — Mon, 17 Aug 2026 13:18:05 +0000

A tool told someone to deploy a table from a stack they had deleted

Three bug reports arrived from one person running my analyzer against a CDK monorepo fronted by a single CloudFront distribution. The commit that fixed them describes the worst one in a line: stale cdk.out templates were being reported as live infrastructure.

That sounds mild. Here is what it actually produces. The shape is now a checked-in regression fixture, so I can show it with the fixture's names rather than anyone's real ones:

  1.  MED    IaC drift: DynamoDB table "LegacyInvoicesTable" defined in IaC but not deployed
       "LegacyInvoicesTable" is in cdk.out/LegacyBillingStack.template.json but not found
       in AWS. It may be undeployed or deleted manually.
       → Run `terraform apply` / deploy your stack, or remove the definition from IaC.

That table is not missing. LegacyBillingStack was deleted from the app. The table is correctly absent from AWS, and the tool is recommending its return.

Worse than the wrong answer is the wrong answer's provenance. "It is in your IaC, at this file path" is the kind of statement that ends an argument. An assistant reading that finding has no reason to doubt it, and every reason to write code against a table that does not exist or to helpfully re-add the stack.

How a deleted stack keeps its template

cdk synth writes one CloudFormation template per stack into cdk.out, plus a manifest.json describing the app. Delete a stack from the app, or rename it, and the next synth writes the new set of templates. The template from the deleted stack is still sitting there from the last synth that included it.

Two properties of a monorepo turn that leftover file into a real problem.

cdk.out is a build directory, and the .gitignore that cdk init generates lists it. Nothing in git status, nothing in a code review diff, nothing in CI will ever show you a stale file in there. It exists only on developer machines and build agents, which is exactly where analysis tools run.

And in a monorepo you cannot see it by looking. On a single-stack app, an extra .template.json next to your one real one is noticeable. With a dozen stacks in one repo, and stacks getting split, merged, and renamed as the repo grows, one extra file among thirteen is invisible. The repo with the most stack churn is the repo where leftovers are hardest to spot.

The file itself gives you no help either. An orphaned template is valid CloudFormation. Parse it and you get a table name, a key schema, a billing mode, an SQS queue, an output with an Export.Name, all structurally identical to the live ones. Nothing inside the file says the stack that produced it no longer exists.

Why everything downstream believes it

Follow the orphan forward and every consumer inherits the error.

The drift analyzer compares what is declared in IaC against what was extracted from AWS. Every resource in the dead stack lands on the declared side and nothing on the deployed side, so each one becomes a "defined but not deployed" finding. A deleted stack does not produce one wrong finding, it produces one per resource, all medium severity, all confidently sourced to a real file path on disk.

The graph gets the same resources as nodes, so a question like "which tables exist in this service" is answered with a table that was decommissioned two quarters ago.

Cross-stack exports are the sharpest edge. The orphan's Outputs section still carries Export.Name: demo-legacy-invoices-table-arn, which reads as an export you can Fn::ImportValue against. That import compiles, synths, and fails at deploy time, because the export was removed from CloudFormation along with the stack.

And notice what the naive fix breaks. If you simply drop the orphan's outputs along with its resources, a dead cross-stack export becomes silently missing rather than visibly wrong, and the next person to go looking for demo-legacy-invoices-table-arn gets nothing back with no explanation. Those two cases need opposite treatment.

The file the build rewrites every run

cdk.out/manifest.json is the one artifact that knows what the app looks like today. cdk synth rewrites it every run, and it lists exactly the stacks the app instantiates, as aws:cloudformation:stack artifacts each pointing at their templateFile. That is true whatever language the CDK app is written in, because the manifest is the assembly contract, not a TypeScript detail.

So a *.template.json that no manifest artifact points at is an orphan from a deleted or renamed stack. That gives three grades of confidence, and they get three different treatments:

Not in the manifest. Its resources are excluded entirely: they never reach the graph, so they never reach the drift analyzer, and nothing downstream can act on them. Its outputs are kept and marked stale: true with the reason, so a dead export stays visible instead of vanishing.

In the manifest, but the file's mtime lags the newest template by more than an hour. Flagged, resources kept. Synth rewrites every template each run, so a lagging timestamp is real evidence of something, but a weaker kind, and excluding resources on it would throw away live infrastructure over a clock skew.

No readable manifest. No cross-check is possible, so nothing is flagged and nothing is excluded. Absence of evidence is not evidence.

That last rule is not a nicety. A tool that flags resources on a guess trains you to skim past its findings, and then it does not matter what it detects.

The exclusion that did not hold

Excluding orphans in the CDK parser was not enough, and the bug that followed is the kind you only find by testing the whole pipeline instead of the unit.

There is a second parser for hand-written CloudFormation templates, and it walks the repo recursively. It walked straight into cdk.out and re-admitted the orphaned stacks under a cloudformation source, so the resources the CDK path had just excluded came back in through the side door. The exclusion looked correct in isolation and did nothing in practice.

cdk.out is now on the recursive scan's excluded-directories list, alongside node_modules, .git, and dist, with a comment saying why: that directory belongs to the CDK parser, which cross-checks it. The regression test asserts on both entry points, the CloudFormation extractor and the combined one, because only the combined one catches this class of bug.

The remaining tests are the negative controls: resources from an unlisted template stay out, its outputs stay in with the flag, a lagging mtime raises the flag while keeping the resources, and with no manifest present every template is treated as current.

What changed in the loop

The drift report stopped inventing work. get_stack_outputs returns stale and staleReason per output, and the tool description tells the assistant in as many words not to rely on a stale export without re-synthesizing, so the model does not have to infer what the flag means.

The demo carries the broken shape on purpose as a checked-in fixture: a manifest.json listing one stack, and an orphan template next to it whose table and queue must not appear anywhere while its export must appear flagged. Delete the manifest and both stacks are treated as current again, which is the third rule made visible.

If you run a CDK monorepo, the check you can do right now without any tooling: list cdk.out/*.template.json, list the templateFile values in cdk.out/manifest.json, and diff them. Anything in the first list and not the second is a stack your app no longer builds, still describing infrastructure to anything that reads that directory.

GitHub · npm

Key takeaways

Build output outlives source. A deleted or renamed CDK stack leaves its synthesized template in cdk.out, and because that directory is gitignored, no review or CI step will ever show it to you.
Ground "what exists" in the file the build rewrites every run. cdk.out/manifest.json lists the stacks the app instantiates today. The templates beside it only record what it once did.
Exclude dead resources, keep dead exports, flag them. They are opposite failures: a resource that no longer exists must not be acted on; an export that no longer exists must not disappear silently.
Absence of evidence is not evidence. With no manifest to check against, the honest output is nothing at all, not a guess in either direction.
Test the pipeline, not the unit. A correct exclusion in one parser was undone by a second parser recursing into the same directory. Only an end-to-end assertion caught it.

An empty result is not an all clear

Siddharth Pandey — Thu, 13 Aug 2026 17:04:57 +0000

An infrastructure audit runs across your account and comes back with two findings on S3. You fix both, close the ticket, and move on.

What the report did not tell you is that the role running it lacks s3:GetEncryptionConfiguration. Fourteen buckets returned AccessDenied on that call. The tool caught the rejection, wrote encrypted: false, and moved on to the next bucket. Some of those fourteen are encrypted. Some are not. The report cannot tell you which, because the value it printed was not read from AWS — it was the default that got assigned when the read failed.

This is the bug I spent a release fixing across Infrawise, and it is not really an S3 bug. It is a shape-of-data bug that almost every infrastructure scanner has somewhere: a boolean field with two states being asked to carry three.

`false` is a claim, and a failed call has no claim to make

The S3 extractor issues four calls per bucket — notifications, versioning, encryption, public access block — through Promise.allSettled, so one rejection never takes down the other three:

const [notifResult, versionResult, encryptResult, pabResult] =
  await Promise.allSettled([
    client.send(new GetBucketNotificationConfigurationCommand({ Bucket: name })),
    client.send(new GetBucketVersioningCommand({ Bucket: name })),
    client.send(new GetBucketEncryptionCommand({ Bucket: name })),
    client.send(new GetPublicAccessBlockCommand({ Bucket: name })),
  ]);

allSettled is the right primitive. The mistake was what happened next. Reading a rejected result as false collapses two completely different situations into one byte:

We read the bucket and versioning is off. An observation. Worth a finding.
The call was denied, throttled, or timed out. Not an observation. Worth an error message and nothing else.

Downstream, nothing can separate them again. The analyzer receives versioned: false and emits a medium-severity finding recommending you turn versioning on for a bucket whose versioning state was never read. The finding looks exactly like a real one. It has a bucket name, a severity, a recommendation. It is indistinguishable from evidence, and it is not evidence.

The fix is that the field admits a third state:

const versioned =
  versionResult.status === 'fulfilled'
    ? versionResult.value.Status === 'Enabled'
    : null;

And every analyzer that consumes it tests for the observation, not for falsiness:

if (node.versioned === false) { /* finding */ }

null falls through. No finding, because there is nothing to find — only something unread.

The two exceptions are the interesting part

Not every rejection is an absence of information. GetBucketEncryption answers "this bucket has no encryption configuration" by throwing ServerSideEncryptionConfigurationNotFoundError rather than returning an empty body. GetPublicAccessBlock does the same with NoSuchPublicAccessBlockConfiguration. For those two specific error names, the rejection is the fact:

const encrypted =
  encryptResult.status === 'fulfilled'
    ? (encryptResult.value.ServerSideEncryptionConfiguration?.Rules?.length ?? 0) > 0
    : errorName(encryptResult.reason) === 'ServerSideEncryptionConfigurationNotFoundError'
      ? false
      : null;

This is the part you cannot skip by writing a generic "catch everything, return null" wrapper. Two of the four calls encode a real answer in an exception. Collapse all rejections to null and you stop reporting genuinely unencrypted buckets, which is a false negative traded for the false positive you just removed. The error name has to be inspected. There is no way around reading the API's documented behavior call by call.

Four ways absence gets promoted to fact

Once you start looking for this pattern, it shows up everywhere a scan touches an API it does not fully control:

A capped listing. ListBuckets paginates. The old code took the first page and stopped, so accounts past 200 buckets got a partial inventory rendered as a complete one. Nothing downstream can detect a missing bucket — an absent entry reads as "does not exist" to every consumer.

A synthesized node. When code says QueueUrl: process.env.QUEUE_URL, there is no queue name to resolve. A graph node still gets created so the function's edges have somewhere to point, and it was created with hasDLQ: false. The DLQ analyzer read that default as an observation and produced a high-severity finding: a queue literally named unknown had no dead-letter queue. Those nodes now carry placeholder: true, and every analyzer whose evidence is absent configuration skips them:

if (node.type !== 'queue' || node.placeholder) continue;

A failed service. One extractor throwing should not kill an analysis, so each one is wrapped and its outcome recorded rather than only logged. A warning printed to a terminal nobody read is not a signal. The status is one of four values — ok, failed, partial, disabled — and it rides along with the results.

A partial extraction. Sometimes an extractor gets most of what it needed and loses one piece. Throwing away the whole service costs more than it protects; keeping it silently is the exact false negative all of this exists to prevent. PartialExtractionError carries the usable data and the gap, and the source is marked partial.

Why this got urgent

An infrastructure report with a phantom finding wastes an engineer twenty minutes. They open the console, see versioning is already on, shrug, and move on. Annoying, self-correcting.

That was before the reader stopped being human.

Infrawise serves this data to AI coding assistants over MCP, and a model does not shrug. Ask it "which of my buckets are unencrypted" and it gets a JSON array. If the array is empty because the S3 read failed, the model does not infer a failed read. It answers "all your buckets are encrypted" in exactly the tone it uses for things it verified, and then it writes your bucket policy on that assumption. Empty is the most dangerous possible response, because empty is what "everything is fine" also looks like.

So every tool response carries a dataHealth block, and the part that matters here is the source list:

"sources": [{ "service": "s3", "status": "failed", "error": "AccessDenied" }]

Every key is always present. error is null rather than omitted, so nothing has to be inferred from a missing field. get_graph_summary goes further and stamps each node with its own source and sourceStatus, so a node from a degraded source is distinguishable from a clean one without cross-referencing anything.

The rule this gives an assistant is a single sentence, stated in the description of the first tool it is told to call: a source that is not ok means an empty result is "not read", not "none exist". get_table_schema is the sharpest case — with a database listed as failed, found: false means "not looked for", not "no such table". That is the difference between an assistant writing a query against the wrong schema and an assistant telling you to re-run infrawise analyze.

The general shape

If you build anything that reports on infrastructure you do not own — a scanner, a linter, a dashboard, an MCP server — the check is quick. Take any boolean in your output and ask what it holds when the call that fills it fails. If the answer is false, you are shipping a claim you never verified. If the answer is "the whole field is missing", you are asking every consumer downstream to guess, and at least one of them will guess wrong in the direction of "fine".

Three states, always. Observed true, observed false, not observed. The third one costs a nullable type and a few === false comparisons, and it is the entire difference between a report that is trustworthy and a report that is merely quiet.

Infrawise is MIT-licensed and runs locally against your own account: GitHub · npm.

Key takeaways

A boolean that defaults to false on a failed read is asserting something nobody verified. Make the field nullable and have consumers test === false, not falsiness.
Do not wrap every rejection into null blindly. Some APIs answer "not configured" with an exception — GetBucketEncryption and GetPublicAccessBlock both do — and for those, the error name is the fact.
Unpaginated list calls silently shrink your inventory, and a missing item reads as a non-existent item to everything downstream.
Objects synthesized to hold a reference together (from an env var, an ARN, a code path) must be marked as such, or their default values get audited as if they were read from the provider.
If an LLM consumes your output, ship per-source status alongside the data. An empty array with no health signal will be reported to the user as an all clear.

Stale infrastructure context is worse than none

Siddharth Pandey — Sat, 08 Aug 2026 15:06:55 +0000

The bug that isn't a bug

On Tuesday you attach a dead-letter queue to orders-queue. On Wednesday a batch of messages disappears and you ask Claude Code what happened. It answers immediately: orders-queue has no DLQ configured, so failed messages are dropped after the maximum receive count.

That answer is wrong, and it is also not a hallucination. The assistant read a real snapshot of your AWS account. The snapshot was taken Monday.

This is the failure mode that shows up once you give an AI assistant deterministic infrastructure context instead of letting it guess. Guessing produces answers that feel uncertain, and you treat them accordingly. A stale snapshot produces answers that feel authoritative, with real table names, real queue names, real ARNs. Nothing in the response signals that the underlying facts expired.

Infrawise extracts your DynamoDB tables, Lambda configs, queue settings, database schemas, and code-to-table access patterns into a graph, then serves that graph to AI editors over MCP. Everything below is about the part nobody asks for in a feature list: what happens to that graph when it gets old.

Why the context has to be cached at all

The obvious fix is to never cache. Answer every question from a live account read.

That does not survive contact with an actual session. A full infrawise analyze walks every enabled service, paginating through DynamoDB DescribeTable, Lambda configurations and their event source mappings, SQS queue attributes, SNS subscriptions and filter policies, Secrets Manager rotation state, S3 versioning and public-access configuration, ElastiCache clusters, CloudWatch log groups, plus schema introspection against Postgres, MySQL, or MongoDB, plus a local IaC parse, plus an AST scan of the repository. Every extractor is dispatched through a single Promise.all, so wall-clock time is bounded by the slowest one rather than their sum, but it is still seconds, not milliseconds.

An assistant calls get_infra_overview at the start of a task, analyze_function when it opens a handler, get_table_schema before writing a query. Re-extracting the account on each of those calls would make the tools unusable, and it would hammer AWS APIs with describe calls on every keystroke-adjacent action.

So the graph is cached. Which means the graph goes stale. The only real question is whether the tool bounds that staleness and reports it, or lets it drift silently.

What actually expires, and when

The cache is a directory of JSON files under .infrawise/cache, next to your infrawise.yaml. Each entry stores three things: the data, the timestamp it was written, and a cache version.

Reads are TTL-checked, and the check is deliberately blunt:

export function readCache<T>(key: string, maxAgeMs = 3600000): T | null {
  const entry = readEntry<T>(key);
  if (!entry) return null;
  if (entry.version !== CACHE_VERSION) return null;
  if (Date.now() - entry.timestamp > maxAgeMs) return null;
  return entry.data;
}

An expired entry does not return old data with a warning attached. It returns null, which every caller treats as "no cache" and handles by re-analyzing. There is no code path that serves data past its TTL, because a warning is something a caller can ignore and a null is not.

The graph, the findings, and the raw AWS/DB metadata all use the same 24-hour TTL. That number is not arbitrary, and getting there took one bad bug. The metadata cache originally used the function's 1-hour default while the graph used 24 hours. In a long-running serve session, that mismatch meant every graph rebuilt after the first hour came back with an empty metadata half: no table schemas, no Lambda configs, no queue attributes. Findings that depend on that metadata silently stopped being generated. Not an error, not a warning, just fewer findings than an hour ago. The comment in runCodeRefresh still records why the TTLs are now unified:

// Same 24h TTL as the graph cache — a shorter TTL here silently dropped all
// AWS/DB metadata from refreshed graphs once a serve/stdio session passed 1h.
const cached = readCache<CachedMeta>('meta', 24 * 60 * 60 * 1000);

The general lesson is worth stating plainly: when two caches feed one derived result, different TTLs produce a partially-empty result rather than an error. Partial results are the worst kind, because they look like a correct answer to a smaller question.

Refresh happens at the boundary you already have

Both transports share one bootstrap, and it tries the cache first. Running infrawise serve over HTTP, that looks like:

  ✓ Config loaded  infrawise.yaml
  ✓ Cached analysis loaded  42 nodes · 18 edges · 7 finding(s)

If the entries are missing or older than 24 hours, readCache returns null, the bootstrap warns No cache found — running analysis now..., and it re-analyzes before serving a single tool call. You never run a refresh command. Session start is the refresh trigger, because session start is the moment you were already going to wait a few seconds.

When your editor launches infrawise serve --stdio from .mcp.json instead, the same bootstrap runs with its success channel silenced and warnings routed to stderr with an infrawise: prefix — stdout belongs to MCP JSON-RPC, and a stray status line there corrupts the protocol stream.

Inside a session, file saves take a cheaper path. The watcher debounces for 2 seconds, ignores anything outside .ts, .tsx, .js, .jsx, .mjs, and .cjs, and then calls runCodeRefresh, which re-runs the AST scan and the local IaC parse and rebuilds the graph on top of the cached AWS and database metadata. No AWS calls. This is the right trade: the thing that changed when you hit save is your code, not your account. Add a .scan() call to a handler and the scan edge is in the graph on the next debounce tick, without a single describe call leaving your machine. The infrastructure half of that graph is still whatever was cached, bounded by the same 24 hours.

Making age visible instead of silent

Bounding staleness is half the job. The other half is telling the consumer how old the facts are, so it can decide.

get_infra_overview returns a freshness object alongside the actual data:

{
  "analyzedAt": "2026-08-07T09:14:22.019Z",
  "ageSeconds": 98400,
  "stale": true,
  "hint": "Analysis is stale — run `infrawise analyze` to refresh."
}

analyzedAt comes from readCacheTimestamp, a separate read that deliberately ignores the TTL — its whole job is to report age, so applying an expiry to it would defeat the purpose. The stale flag flips past 24 hours, matching the TTL that drives auto-refresh, and the hint field only appears when stale is true.

This exists because the assistant is the one deciding whether to trust the answer. If it is about to tell you a queue has no DLQ, the difference between a 40-second-old graph and a two-day-old one matters, and only the tool knows which one it is holding. Handing over the timestamp costs one field and removes the entire class of confidently-wrong answers described at the top of this post.

When the server boots with no analysis at all, analyzedAt is null and stale is false. Unknown age is reported as unknown rather than as fresh — a null timestamp defaulting to "current" would be exactly the silent lie the field exists to prevent.

Conclusion

Caching infrastructure context is not optional; extraction is far too expensive to run per question. What is optional is whether the staleness that caching creates stays silent. Every design decision here points the same direction: expired reads return null instead of stale data, the two caches that feed one graph share a TTL so they cannot go half-empty, refresh is attached to session start rather than a command you must remember, and the age of the loaded analysis ships as a field in the response so the consumer can weigh it.

If you want the same behavior in your editor, npx infrawise start --claude writes .mcp.json and hands your assistant the graph — GitHub · npm.

Key Takeaways

A stale cache is more dangerous than an empty one, because it produces specific, confident, wrong answers instead of visibly uncertain ones.
Return null past the TTL rather than stale-with-a-warning. Callers ignore warnings; they cannot ignore a null.
When several caches feed one derived result, give them the same TTL. Mismatched TTLs produce silently partial results, which look like correct answers to smaller questions.
Tie refresh to a boundary the user already pauses at — session start — instead of a command they have to remember to run.
Ship the age of your data as a field in the response. The consumer, not the cache, should decide whether 26 hours old is good enough.

Your 12-Minute Frontend Build Is Now Your AI Agent's Bottleneck

Siddharth Pandey — Wed, 05 Aug 2026 07:30:12 +0000

Your coding agent just opened five PRs in a morning. Each one changes a handful of files in one product area. Each one triggers a twelve-minute build of the entire frontend: search, account, admin, marketing pages, all of it. That is an hour of CI to validate maybe two hundred lines, and the review queue is now the slowest part of a workflow you adopted to go faster.

The same twelve minutes used to be an annoyance you absorbed a few times a day. At agent throughput it is the bottleneck.

It gets worse before it gets better. You ask the agent "where does checkout read the pricing config from?" and it opens forty files across four product areas before answering, because as far as the tooling is concerned there is exactly one application and it is enormous. Then it changes six words of copy in the checkout confirmation screen, and every user on the site redownloads a main bundle whose hash moved for reasons that have nothing to do with them.

One build unit, one bundle graph, one context blob. Micro frontends in a monorepo split all three, and the monorepo part is what keeps it from turning into a distributed systems problem you did not sign up for.

The four taxes you are paying

Build fan-out. Your CI has no idea that checkout and search do not touch each other. Any commit invalidates the whole build. Build time is a function of repo size, not change size.

Bundle coupling. Webpack and Vite chunk splitting help with what gets loaded, but not with what gets invalidated. If checkout and search compile into one build output, a checkout change can shift chunk hashes across the app and evict cached bytes users already had.

Delivery coupling. Two teams shipping to the same artifact means every deploy is a merge queue negotiation. The team that is ready waits on the team that is not.

Context cost. This is the newest one and the least discussed. An AI coding agent working in a repo has a finite attention budget. Give it one 1,200-file application with no enforced internal boundaries and it will read broadly, guess about ownership, and occasionally reach into a module it had no business touching. Give it apps/checkout plus three shared libs and it reads less, guesses less, and produces a diff you can actually review.

Splitting without splitting the repo

The mistake people make is equating micro frontends with repo-per-team. That buys you deploy independence and charges you version drift, six duplicate CI configs, and cross-repo refactors that nobody ever does.

Keep one repo. Split the build.

With Nx, scaffolding the pieces is one command. Nx 23 renamed the generators: the app that loads federated modules is a consumer (previously host), the app that exposes them is a provider (previously remote).

nx g @nx/react:consumer apps/shell --bundler=rspack --providerNames=checkout,search
nx g @nx/react:provider apps/account --consumer=shell

The old @nx/react:host and @nx/react:remote generators still ship, so existing workspaces keep working, but new work should use consumer/provider. With the new generators, providers are registered at runtime from an inline list in the consumer's src/mf.ts rather than being frozen into build config.

Each provider gets its own build target and its own deployable output. Underneath, the Module Federation build plugin config looks like this:

import { createModuleFederationConfig } from '@module-federation/enhanced/rspack';

export default createModuleFederationConfig({
  name: 'shell',
  remotes: {
    checkout: 'checkout@https://cdn.example.com/checkout/mf-manifest.json',
  },
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true },
  },
});

singleton: true on React is not optional. Without it you ship two React copies, hooks break across the boundary, and you spend an afternoon on an error message about invalid hook calls that has nothing to do with your hooks.

For remotes that are not known at build time (a plugin surface, a tenant-specific module, an A/B variant), the runtime API takes over:

import { init, loadRemote } from '@module-federation/runtime';

init({
  name: 'shell',
  remotes: [{ name: 'promo', entry: 'https://cdn.example.com/promo/remoteEntry.js' }],
});

const Promo = await loadRemote('promo/Banner');

The performance case, stated honestly

Cache invalidation gets a boundary. Each remote publishes its own entry and its own chunks. A copy change in checkout produces new checkout bytes. Search bytes keep their hashes and stay in the user's cache. On a large app this is the difference between shipping a small delta and making every user re-download a vendor bundle because one hash cascaded.

Loading follows navigation. A remote is fetched when the route that needs it is entered. Users who never open admin never pay for admin. You can approximate this with route-level lazy imports in a monolith, but you cannot approximate the invalidation boundary, and lazy imports quietly re-couple every time someone adds a top-level import for a type.

Local dev stops rebuilding what you are not editing. nx serve shell starts the whole composed app with the remotes built and served statically. Only the remote you are actively editing needs a real dev server, and since Nx 21 you get that by serving the remote itself:

nx serve checkout

On Angular, or on webpack Module Federation without inferred tasks, the equivalent is nx serve shell --devRemotes=checkout.

Now be honest about the costs, because they are real:

Each remote costs a manifest fetch plus an entry fetch. On a route that pulls three remotes, that is latency you did not have before. Preload the manifests for likely-next routes.
Shared singletons only work if versions are compatible. A remote built against React 18 and a host on React 19 fails at runtime rather than at build time, which is the worst place to find out. This is the single biggest operational hazard of the pattern, and it is exactly the failure a monorepo prevents: one lockfile, one version, enforced by the repo rather than by a wiki page.
Below a certain size this is all overhead. One team, a 90-second build, three routes? Do not do this. The pattern earns its place when multiple teams contend for one pipeline.

Where the AI speedup actually comes from

Two mechanisms, both boring, both effective.

Affected-only work. Nx computes a project graph from real imports, so it knows checkout and search are unrelated:

nx affected -t build
nx affected -t test lint

An agent that opens a PR touching only apps/checkout triggers a build of checkout and its dependents. Not the repo. Those five PRs from the opening now cost five checkout builds instead of an hour of full-frontend CI, and they run in parallel because they no longer contend for the same build. The twelve minutes did not get optimized away, it stopped being charged for work that never changed.

Boundaries the agent cannot argue with. Tag every project and let ESLint enforce who may import whom:

'@nx/enforce-module-boundaries': [
  'error',
  {
    allow: [],
    depConstraints: [
      { sourceTag: 'scope:shared', onlyDependOnLibsWithTags: ['scope:shared'] },
      { sourceTag: 'scope:checkout', onlyDependOnLibsWithTags: ['scope:shared', 'scope:checkout'] },
      { sourceTag: 'scope:search', onlyDependOnLibsWithTags: ['scope:shared', 'scope:search'] },
    ],
  },
],

This is the part that changes how it feels to work with an agent. A prompt that says "do not import from other teams' code" is a suggestion the model may or may not follow. A lint rule that fails CI is a fact. When an agent takes the shortcut of reaching into apps/search/src/internal/pricing.ts from checkout, the build tells it no, and it fixes the mistake in the same session instead of you finding it in review three days later.

The context effect compounds. Scoping an agent to one remote plus the shared libs means the files it reads are the files that matter. Smaller context, fewer distractor files, more of the budget spent on the actual change. The same architecture decision that gave you independent deploys gave you a natural unit of work for an agent, which is not a coincidence: both are asking for the same thing, which is a piece of the system you can reason about without loading the rest.

Migration path that does not stall

Do not carve up the whole app. Pick the boundary that hurts most, usually the one where two teams collide in the merge queue, and extract exactly that one.

Create the consumer, keep the existing app as the first provider. Nothing changes for users.
Extract the contended area into a second provider. Shared code goes to libs/shared, tagged scope:shared.
Turn on enforce-module-boundaries in warn mode, fix the violations it finds, then flip it to error.
Switch CI to nx affected. Measure the build time delta before extracting a third remote.

If step 4 does not show a meaningful improvement, stop. You have a dependency-graph problem, not an architecture problem, and adding remotes will not fix it.

Key takeaways

Agent throughput turns a tolerable build time into a hard bottleneck. Five PRs a day made twelve minutes annoying; five PRs an hour makes it the constraint on everything.
Micro frontends buy independent build, cache, and deploy boundaries. A monorepo keeps the single lockfile and single-commit refactors. You want both, not one or the other.
Mark framework packages singleton: true in shared, or hooks break across the remote boundary at runtime.
nx affected -t build turns build time into a function of change size instead of repo size, which is what makes multi-PR agent work practical rather than theoretical.
@nx/enforce-module-boundaries with tags converts your architecture from a convention into a CI failure, and an AI agent respects a failing build far more reliably than a prompt.
Extract one boundary, measure, then decide. Below a couple of teams and a couple of minutes of build time, this pattern costs more than it returns.

Docs worth reading before you start: Nx Module Federation and Module Federation Core.

Your Cognito Login Code Fails Because the App Client Never Allowed That Auth Flow

Siddharth Pandey — Sun, 02 Aug 2026 20:39:22 +0000

Your login screen works locally. You point it at the staging user pool and every sign-in comes back as an error before it ever reaches a password check.

The code your AI assistant wrote calls InitiateAuth with AuthFlow: 'USER_PASSWORD_AUTH'. Reasonable guess: it is the flow in most Cognito tutorials. But the app client in staging was created by a Terraform module that set explicit_auth_flows = ["ALLOW_USER_SRP_AUTH", "ALLOW_REFRESH_TOKEN_AUTH"], and that client also has a secret. So the call fails twice over: the flow is not enabled for this client, and the request is missing SECRET_HASH.

None of that is visible in your source files. The assistant read your repo, found no answer, and produced the most statistically common Cognito snippet on the internet.

The app client is the config, and it is not in your repo

Cognito's failure modes are almost all per app client settings, not per user pool settings. Four of them break generated code immediately:

Allowed auth flows. ExplicitAuthFlows is a whitelist. If ALLOW_USER_PASSWORD_AUTH is not on it, USER_PASSWORD_AUTH is rejected regardless of whether the username and password are correct. Client A in dev may allow it while client B in prod does not, and the same handler code then works in one environment and not the other.

Client secret. A client with GenerateSecret: true requires every auth call to carry SECRET_HASH, a base64 HMAC-SHA256 of username + clientId keyed with the client secret. An assistant that does not know a secret exists will never emit that field, and the call fails on secret verification rather than on credentials.

MFA. With MFA set to ON, InitiateAuth typically returns a ChallengeName and a session instead of tokens. Code written against the happy path reads response.AuthenticationResult.IdToken, gets undefined, and throws somewhere three functions away from the actual cause.

Token validity units. AccessTokenValidity: 60 means nothing on its own. With TokenValidityUnits.AccessToken = 'minutes' it is one hour. With 'days' it is two months. Refresh logic built on the wrong unit either hammers the token endpoint or lets sessions die.

OAuth settings. If you are using the hosted UI instead of direct auth, the client carries its own AllowedOAuthFlows, AllowedOAuthScopes, and CallbackURLs. Build a redirect against a URL that is not in the callback list, or request a scope the client does not allow, and Cognito refuses the request at the authorize endpoint before your app sees anything. An assistant writing the redirect has no way to know the staging client only registered https://staging.example.com/callback while your local dev URL was never added.

Every one of those lives in AWS, not in your repository. Even when the pool is defined in Terraform, the assistant would have to find the right module, resolve the variables, and know which client the running service actually uses. In practice it does not, so it guesses.

Reading the real client config

Infrawise extracts this and hands it to your assistant over MCP. The Cognito extractor in src/adapters/aws/services.ts walks four read-only calls: ListUserPools for every pool, then per pool DescribeUserPool, then ListUserPoolClients, then DescribeUserPoolClient for each client. Both listings are paginated with NextToken, so a pool with 80 app clients does not get silently truncated at the first page.

For each client it keeps exactly the fields that change how you write the call:

clientName, clientId
authFlows          <- ExplicitAuthFlows
oauthFlows         <- AllowedOAuthFlows
oauthScopes        <- AllowedOAuthScopes
callbackUrls       <- CallbackURLs
generatesSecret    <- !!ClientSecret
accessTokenValidity, idTokenValidity, refreshTokenValidity
tokenValidityUnits <- { accessToken, idToken, refreshToken }

Note generatesSecret. DescribeUserPoolClient does return the secret value, and infrawise converts it to a boolean at the point of extraction. The value is never stored in the graph, never cached, and never returned by any tool. Your assistant learns that a secret exists and that SECRET_HASH is mandatory, without ever seeing the secret. Same for users: infrawise never calls any user API. Sign-in code is what it helps you write, not a directory it reads.

The get_cognito_overview MCP tool returns the whole thing:

{
  "total": 1,
  "note": "Client secret values and user data are never included.",
  "userPools": [
    {
      "name": "app-users-staging",
      "id": "ap-south-1_XXXXXXXXX",
      "mfaConfiguration": "OPTIONAL",
      "clients": [
        {
          "clientName": "web-spa",
          "clientId": "4h1...",
          "authFlows": ["ALLOW_USER_SRP_AUTH", "ALLOW_REFRESH_TOKEN_AUTH"],
          "oauthFlows": ["code"],
          "oauthScopes": ["openid", "email"],
          "callbackUrls": ["https://staging.example.com/callback"],
          "generatesSecret": true,
          "accessTokenValidity": 60,
          "tokenValidityUnits": { "accessToken": "minutes" }
        }
      ]
    }
  ]
}

That is the difference between an assistant guessing USER_PASSWORD_AUTH and an assistant writing SRP with a SECRET_HASH, because the whitelist and the secret flag are sitting right there in its context.

The tool description registered in src/server/index.ts tells the model when to reach for it and when not to: call it before writing any sign-in, sign-up, or token-refresh code; do not call it to look up users or tokens. That last clause matters more than it looks. Tool descriptions are the only thing steering which tool an agent picks, and a tool that sounds like a user directory will get called for the wrong reasons.

Turning it on

Cognito is off by default. infrawise start writes an infrawise.yaml with cognito: { enabled: false }, because most repos have no Cognito and there is no reason to make an API call for them. Auth work means flipping one key:

cognito:
  enabled: true

The IAM policy is four read actions, and nothing else:

cognito-idp:ListUserPools
cognito-idp:DescribeUserPool
cognito-idp:ListUserPoolClients
cognito-idp:DescribeUserPoolClient

Then:

infrawise start --claude

That probes your environment, runs the analysis, writes .mcp.json so your editor reconnects on every future launch, and opens Claude Code with all 21 tools available. From then on you just run claude. Results are cached for 24 hours, and get_infra_overview reports a freshness object with the analysis age and a stale flag so the assistant can tell when it is looking at yesterday's picture.

Ask "write me a sign-in handler for the staging pool" and the flow is no longer a guess. The assistant calls get_cognito_overview, sees ALLOW_USER_SRP_AUTH and generatesSecret: true, and writes SRP with a secret hash the first time.

What this actually buys you

The bug class here is boring, which is why it eats so much time. Nothing crashes at build time. Types are fine. Tests that mock the Cognito client pass. The failure only shows up against a real user pool, as an exception whose message is about a flow name rather than about the app client that disallowed it, and the fix is a config value you have to go read in a console tab.

Cognito is one instance of the general pattern. The information needed to write correct code is split between your repo and your cloud account, and the assistant only has half. Infrawise closes that gap deterministically: no LLM in the extraction path, just SDK calls, AST parsing, and rule-based analyzers producing a graph that MCP tools read from.

Try it: GitHub or npm.

Key takeaways

Cognito failures are per app client, not per user pool. The same code succeeds against one client and fails against another in the same pool.
Check callbackUrls and oauthScopes before building a hosted UI redirect. A URL that is not registered is rejected at the authorize endpoint.
If generatesSecret is true, every auth call needs SECRET_HASH. An assistant that does not know a secret exists will never emit it.
AccessTokenValidity is meaningless without TokenValidityUnits. 60 is an hour or two months depending on the unit.
Set cognito: enabled: true in infrawise.yaml (it defaults to false) and grant the four cognito-idp read actions.
Call get_cognito_overview before writing sign-in, sign-up, or refresh code. It never returns client secret values or user data.

Your Lambda Passes Tests Then Throws AccessDeniedException in Production

Siddharth Pandey — Mon, 27 Jul 2026 06:12:56 +0000

You asked Claude Code to add a step to your order handler: pull the Stripe key out of Secrets Manager, then publish an order.settled event to SNS. It wrote clean code. Your unit tests mock both SDK clients, so they pass. CI is green. You deploy.

Then the first real invocation logs this:

AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/order-processor-role/order-processor
is not authorized to perform: sns:Publish on resource: arn:aws:sns:us-east-1:123456789012:order-events

Nothing was wrong with the code. The execution role was written months ago, when the function only touched DynamoDB. The code grew a new dependency and the policy did not follow.

This is one of the most annoying classes of AWS bug because it is invisible to every tool in the loop. The type checker sees a valid PublishCommand. The linter sees valid TypeScript. The AI assistant reads your handler and has no idea what order-processor-role allows, because the policy lives in AWS (or in a Terraform file three directories away), not in the file it is editing.

Infrawise closes that gap by comparing the two directly. GitHub · npm

Why the assistant cannot see this on its own

An AI coding assistant works from the files you give it. When it writes a Lambda handler, it can see:

the handler source
imports, so it knows which AWS SDK clients you use
maybe a nearby test file

What it cannot see is the runtime identity that code will execute as. The link between "this handler" and "this IAM role" is a Role property on the deployed function, resolved through an ARN, and the policy behind that ARN is a set of JSON documents attached to a role name. Three lookups away from anything in your repo.

So the assistant does the only thing it can: it assumes the permissions exist. Ninety percent of the time they do, which is exactly what makes the other ten percent expensive. The failure surfaces at runtime, in an environment where you are reading CloudWatch instead of your editor.

What infrawise actually compares

Infrawise already builds a graph of your infrastructure and your code. The AST scan produces typed edges from functions to the things they touch: a query or scan edge to a DynamoDB table, a reads_secret edge to a Secrets Manager secret, a reads_parameter edge to an SSM parameter, a publishes_to edge to an SQS queue or an SNS topic.

Separately, the Lambda extractor pulls roleArn off every function, then fetches what that role permits. It batches the fetch per unique role ARN, so ten functions sharing one role cost one IAM round trip, not ten. For each role it walks both attached managed policies and inline policies, decodes the policy documents, and reduces every Allow statement to the service prefix of its actions. sns:Publish becomes sns. dynamodb:GetItem becomes dynamodb. A bare "*" action becomes *.

The result is allowedServices, a flat list like ["logs", "dynamodb"].

Now the comparison is trivial. Walk the function's outgoing edges, map each to the service prefix it requires, and subtract allowedServices. What is left is what the code needs and the role does not grant.

The mapping is deliberately narrow. Five edge types map to five services:

Edge	Required service
`query` or `scan` on a DynamoDB table	`dynamodb`
`reads_secret`	`secretsmanager`
`reads_parameter`	`ssm`
`publishes_to` a queue	`sqs`
`publishes_to` a topic	`sns`

Two cases produce no finding at all, on purpose:

No IAM data. If the IAM read fails (missing permission, SCP, whatever), allowedServices comes back undefined and the analyzer skips the function entirely. Infrawise will not tell you a permission is missing when it could not read the policy. Silence beats a false alarm you learn to ignore.

Wildcard. If the role has "Action": "*" anywhere, the service list contains * and the function is skipped. AdministratorAccess is its own problem, but it is not a missing-permission problem.

Where you see it

Two places, and they cover the two moments where it matters.

While you are writing the handler. analyze_function returns missingPermissions alongside everything else it knows about the function:

{
  "function": "order-processor",
  "found": true,
  "file": "src/handlers/order-processor.ts",
  "triggers": [
    { "type": "sqs", "source": "orders", "eventShape": "event.Records[0].body" }
  ],
  "accesses": [
    { "targetId": "table:dynamo:Orders", "edgeType": "query", "targetName": "Orders", "targetType": "table" },
    { "targetId": "secret:aws:stripe/live", "edgeType": "reads_secret", "targetName": "stripe/live", "targetType": "secret" },
    { "targetId": "topic:aws:order-events", "edgeType": "publishes_to", "targetName": "order-events", "targetType": "topic" }
  ],
  "missingPermissions": ["secretsmanager", "sns"],
  "issues": [ ... ],
  "recommendations": [ ... ]
}

That is the whole point. The assistant asked one question before writing code and got back the trigger event shape and the fact that two of the three services this function talks to are not in its role. It can tell you to fix the policy in the same breath as it writes the handler.

Note the field is omitted entirely when IAM data was unavailable, rather than returned as an empty array. An empty missingPermissions means "checked, nothing missing." An absent one means "not checked." Those are different answers and conflating them is how you get misplaced confidence.

Before you deploy. The same comparison runs as a high-severity analyzer in infrawise analyze and infrawise check:

  1.  HIGH   Lambda "order-processor" accesses sns but execution role has no sns permissions
       "order-processor" calls sns in code but its IAM execution role (arn:aws:iam::123456789012:role/order-processor-role) has no sns:* permissions. This will cause AccessDeniedException at runtime — code passes tests but fails in AWS.
       → Add sns permissions to the execution role for "order-processor". Minimum required: sns:Publish.

The recommendation names actual actions, not sns:*. Each service has a minimal action set baked in: secretsmanager:GetSecretValue for secrets, ssm:GetParameter, ssm:GetParameters, ssm:GetParametersByPath for parameters, sqs:SendMessage, sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes for queues, and the CRUD-plus-query set for DynamoDB. You can paste the list into the policy without thinking about whether you just granted dynamodb:DeleteTable.

Because it is a high-severity finding, infrawise check fails the build on it by default. That is the whole CI story: check runs a fresh analysis (never a cached graph, since CI gating on stale data is worse than no gating) and exits non-zero when anything at or above --fail-on shows up. Default threshold is high.

infrawise check

Two things to know before you trust it

Names have to line up. The check joins a code function node to a Lambda node by exact name match. If your handler is exported as handler in src/orders.ts but deployed as order-processor, infrawise finds no code node for that Lambda and produces no finding. It fails closed, which is the right direction, but it means the check is only as good as your naming discipline. If you use a framework that derives function names from the deployed name, you get this for free.

Granularity stops at the service prefix. Infrawise compares sns against sns, not arn:aws:sns:us-east-1:123456789012:order-events against the resource in your PublishCommand. A role scoped to one topic passes the check even if your code publishes to a different topic. So this catches "the policy has no SNS at all," which is the common case, not "the policy has the wrong SNS resource." Resource-level checking is a different problem and pretending otherwise would make the finding untrustworthy.

It needs read access to IAM. Five actions: iam:ListAttachedRolePolicies, iam:ListRolePolicies, iam:GetRolePolicy, iam:GetPolicy, iam:GetPolicyVersion. They are optional in the infrawise IAM policy. Drop them and everything else still works, you just lose this check. Infrawise is read-only across the board, so nothing here writes to your account.

Try it

cd your-project
npx infrawise start --claude

That probes your environment, writes infrawise.yaml and .mcp.json, and opens Claude Code with all 21 tools connected. Ask it to write a Lambda that reads a secret, and watch it check the role before it writes the code.

GitHub · npm

Key takeaways

AccessDeniedException in a Lambda is almost never a code bug. It is a drift bug: the code grew a dependency, the execution role did not follow.
Your AI assistant cannot catch this from source files alone, because the role that code runs as is three lookups away from anything in your repo.
Infrawise compares the function's actual outgoing edges (DynamoDB query, secret read, SSM read, SQS send, SNS publish) against the service prefixes its IAM role permits, then reports the difference.
Call analyze_function before writing a handler to get missingPermissions alongside the trigger event shape. An absent field means IAM was not readable; an empty array means it was checked and clean.
Run infrawise check in CI. Missing permissions are high severity, so the default --fail-on high blocks the deploy.
The check is service-level, not resource-level, and joins code to Lambda by exact function name. Know both limits so you know what a clean result actually proves.

How I Solved Claude Code Silently Missing the SQS Trigger on My Lambda

Siddharth Pandey — Wed, 22 Jul 2026 19:50:35 +0000

I asked Claude Code to add a handler for processOrders, a Lambda wired up to consume from orders-queue and read the matching row out of the Orders DynamoDB table. It wrote one immediately — confidently, in one shot, the way it writes most things.

It also parsed the event body wrong.

The problem: Claude Code didn't know the Lambda had an SQS trigger

processOrders is invoked by orders-queue through an event source mapping — that's not in processOrders's source file, it's in the AWS account. Claude Code, reading only the handler's code, had no way to see that mapping. So it guessed at the event shape instead of knowing it, and reached for event.body — the shape you'd expect from an API Gateway proxy integration, not from SQS. The actual shape for an SQS-triggered Lambda is event.Records[0].body. First message in, first field access, and the handler throws.

That wasn't the only thing invisible from source alone:

orders-queue has no dead-letter queue. If the handler throws, SQS retries up to maxReceiveCount times and then discards the message — no alert, no queue-depth spike, nothing in the logs pointing at what happened. A failed order just vanishes.
The Orders table has one partition key (orderId) and zero GSIs. Any lookup by anything else becomes a full table scan the moment the handler ships.

None of that is visible from reading processOrders's current code. It's the state of the AWS account, and an AI assistant reading only source files fills the gap with a plausible guess instead of a fact — starting with which trigger the function even has.

The fix: infrawise's MCP tools in the loop, in order

Here's what the same session looked like once I wired infrawise into Claude Code as an MCP server and asked it to redo the handler.

Start wide: get_infra_overview. No arguments, just a snapshot — table names, queue names, lambda count, high-severity findings. It comes back showing the Orders table, orders-queue, and processOrders already in the graph, plus a high-severity finding already attached to that Lambda. That finding surfaces before the handler is written, not after the deploy.

Narrow to the function: analyze_function. Called with function: "processOrders", this is the tool built for "I'm about to write or review this handler," and it returns four things Claude Code would otherwise guess at:

The trigger event shape. processOrders is triggered by SQS, so the correct shape is event.Records[0].body — not event.body. Infrawise keeps a fixed map per trigger type (SNS is event.Records[0].Sns.Message, S3 is event.Records[0].s3.object.key, DynamoDB Streams is event.Records[0].dynamodb.NewImage), so the entry point is right on the first draft.
The DLQ finding, made concrete. Infrawise's LambdaMissingTriggerDLQAnalyzer walks every Lambda's SQS/Kinesis/DynamoDB-stream triggers, checks whether the source queue has a DLQ, and raises high severity when it doesn't: "processOrders is triggered by orders-queue which has no DLQ — if the Lambda handler fails, messages will be retried and eventually discarded with no failure record." Same problem named in the previous section, now attached to the exact function and queue instead of being a fact nobody checked.
Missing IAM permissions. When execution-role data is available, analyze_function diffs what the function's code actually calls against what its role allows, and returns the gap — catching an AccessDeniedException before it happens in prod instead of after.
Deduplicated recommendations, collapsed into one list instead of several warnings to reconcile by hand.

Confirm the queue directly: get_queue_details. The handler's retry behavior depends on more than DLQ presence, so Claude Code checks the queue itself: hasDLQ: false confirmed, plus visibility timeout, encryption, and isFifo. That last field matters more than it looks — if the queue were FIFO, every SendMessage call in the handler would need a MessageGroupId, and skipping it isn't a lint warning, it's a runtime error the first time the handler publishes.

Get the schema right: get_table_schema. Called with tables: ["Orders"], this returns the partition key (orderId), billing mode (PAY_PER_REQUEST), and the fact that there are no GSIs. If the handler needs to look up an order by anything other than orderId, that's a Scan, and infrawise's scan analyzer flags it the moment it lands in the code graph — so Claude Code reaches for suggest_gsi up front instead of shipping the scan and fixing it in the next PR. Row data is never included — column names, types, keys, and index definitions only, and only for the tables this handler actually touches, not the whole account's schema dumped into the prompt.

What shipped instead

With all four calls back, the rewritten handler:

Parses event.Records[0].body — the correct shape for this trigger, not a guess
Queries Orders by orderId — no scan, because the schema call already ruled that out
Ships with an explicit callout that orders-queue needs a DLQ before this goes to production
Doesn't publish anywhere without checking isFifo first

Every one of those four things was either wrong or invisible in the first version — the one Claude Code wrote from source files alone. None of it required me to open the AWS console mid-task or remember which table has which GSI.

Why this is a repeatable pattern, not a one-off

The four tools compose in a fixed order because each answers a narrower question than the last: get_infra_overview says what exists, analyze_function says what's wrong with the one thing being touched, get_queue_details and get_table_schema fill in the operational and schema detail neither of the first two carries at full resolution. That's the same shape as infrawise's own "reviewing an entire service" and "before writing a query" patterns — it holds for any handler, not just this one.

None of this runs an LLM against the infrastructure. Extraction and analysis are deterministic — AST parsing, live AWS reads, rule-based analyzers, graph correlation. Claude Code only consumes that graph through MCP, the same way it consumes source files. The difference is the graph doesn't guess.

Try it in your own project — npx infrawise start --claude writes the .mcp.json and opens Claude Code with all 21 tools wired in, no server to babysit. GitHub · npm

Key takeaways

Call analyze_function before writing or reviewing any Lambda handler — it returns the correct trigger event shape, missing IAM permissions, and any DLQ/trigger findings in one call.
A queue with a live SQS trigger and no DLQ is a high-severity finding for a reason: failed messages are retried up to maxReceiveCount times, then discarded with no record.
Check isFifo on any queue before writing SendMessage calls — a missing MessageGroupId on a FIFO queue is a runtime error, not a style issue.
Use get_table_schema with just the tables a handler touches instead of dumping the whole schema into the prompt — it also tells you whether the GSI your query needs already exists.
None of this requires an LLM to analyze your infrastructure — the graph is deterministic; Claude Code only reads it.

Your Lambda List Was Silently Truncated at 200 — And Your AI Assistant Never Knew

Siddharth Pandey — Mon, 20 Jul 2026 15:01:08 +0000

Hook

An AWS account with 240 Lambda functions runs infrawise analyze. The tool prints a clean summary: services detected, findings generated, no errors. A developer asks their AI assistant, wired up through MCP, "does this function have a dead-letter queue?" for a function that happens to be function #217 in the account. The assistant calls get_lambda_overview, gets back a list, doesn't find the function, and confidently tells the developer it doesn't exist — or worse, silently skips it and reasons about a different function with a similar name. No error. No warning. Just a wrong answer delivered with total confidence, because 40 functions never made it into the graph in the first place.

That was Infrawise issue #40, and it's a useful case study in how a tool whose entire pitch is "stop AI assistants from guessing" can quietly start guessing itself.

The 200-function wall

Infrawise builds an in-memory graph of a project's infrastructure — tables, functions, queues, indexes — and exposes it to AI coding assistants through 21 MCP tools. extractLambdaMetadata in src/adapters/aws/services.ts is the function responsible for pulling every Lambda function into that graph. It calls AWS's ListFunctionsCommand in pages of 50 and loops until AWS says there's nothing left:

do {
  const res = await client.send(new ListFunctionsCommand({ Marker: marker, MaxItems: 50 }));
  // ...push each function into the array...
  marker = res.NextMarker;
} while (marker && functions.length < 200);

That trailing && functions.length < 200 is the whole bug. Once the running total hit 200 — four pages in — the loop stopped, even though AWS was still handing back a NextMarker and had more functions to give. There was no error, no thrown exception, no log line. The function just returned early with a partial list and reported success.

For a small project this never surfaces. Most side projects don't have 200 Lambda functions. But "common in larger orgs," as the issue itself puts it, is exactly the audience infrawise is trying to win — teams with enough infrastructure that pasting schemas into a prompt every session actually hurts. Those are the accounts most likely to hit the cap, and the ones with the least tolerance for a tool that quietly drops data.

Why silent is worse than wrong

Infrawise's own docs describe two pillars: Context — give the AI assistant your real schema instead of making the developer paste it — and Guard — catch expensive infrastructure mistakes before they ship. The 200-function cap broke both, and it broke them without telling anyone.

Every function past the cap disappeared from the graph entirely — no node, no edges, nothing for the graph engine to attach event-source mappings, IAM roles, or trigger metadata to. Three consumer paths inherited that gap directly:

LambdaMissingTriggerDLQAnalyzer — the analyzer that flags Lambda triggers with no dead-letter queue — silently produced zero findings for those functions. Not "skipped, see warning." Zero findings, same as a function that's perfectly configured.
analyze_function, the MCP tool an AI assistant calls before writing or reviewing a handler, would report no issues for a function it never saw, rather than saying it didn't have data.
get_lambda_overview, the tool that lists every function's runtime, memory, timeout, and triggers, just wouldn't include the function in the list at all.

None of these paths distinguish "checked and found nothing wrong" from "never checked." That distinction is the entire value proposition of a deterministic tool. Infrawise's pitch, explicit in its own docs, is that it doesn't use an LLM to analyze infrastructure — everything is AST parsing, schema introspection, and rule-based analyzers, specifically so an AI assistant gets ground truth instead of a guess. A silent truncation at 200 functions turns that ground truth into a guess anyway, just one dressed up as certainty.

A pattern, not a one-off

The 200-function cap wasn't an isolated mistake — it's one of several bugs in Infrawise's own issue tracker that share the same shape: a limit or a stale value fails quietly instead of loudly.

Issue #45 found that CACHE_DIR was computed from process.cwd() at module load time, so running infrawise analyze from one directory and the MCP server from another meant the second command silently read a cache built for a different invocation path — no mismatch warning, just answers that looked current and weren't. Issue #38 found that --no-cache was accepted by the CLI parser but never actually read by runAnalyze, so a developer explicitly asking for a fresh scan got a cached one anyway, with no indication the flag had been ignored. And issue #39 found that LambdaMissingTriggerDLQAnalyzer was wired into the one-time infrawise analyze path but missing from runCodeRefresh, the path the file watcher calls on every save — so DLQ findings that showed up on the first run quietly vanished after the first edit, with the developer none the wiser.

Different subsystems, same failure mode: nothing crashed, nothing logged, the tool just answered with less than it should have and gave no sign of it. For a tool that stakes its value on being more trustworthy than an LLM's guess, "wrong but confident" is the one failure mode it can't afford — and it's the one that shipped three separate times before anyone caught it.

The fix

The fix for #40 was a one-line diff:

- } while (marker && functions.length < 200);
+ } while (marker);

Pagination now runs until AWS says there's nothing left, full stop. The fix direction noted in the issue also called for a warning log if pagination ever gets cut short for another reason — worth keeping in mind if you're building a similar extraction loop: an arbitrary safety cap on a paginated API call is rarely wrong to have, but silence when it triggers always is. A logger.warn costs one line and turns a silent data gap into a debuggable one.

If you're pointing an AI assistant at your own AWS account and it has more than 200 Lambda functions, this fix landed in the same release cycle as the other three — worth confirming you're on a current version.

GitHub · npm

Key Takeaways

A pagination cap with no warning is a silent data-loss bug waiting for an account large enough to trigger it — 200 felt generous until "larger orgs" turned out to be the target audience.
Distinguish "checked and found nothing" from "never checked" in any analyzer or query result — collapsing them into the same empty response is the failure mode that erodes trust fastest.
Audit every loop bounded by both a natural termination condition (a pagination marker) and an arbitrary one (a hardcoded count) — the arbitrary one is usually the one that fails silently.
Cache keys derived from process.cwd() or other invocation-time state can go stale in ways a static cache TTL never catches — tie cache identity to something stable, not to where the process happened to start.
If a CLI flag exists, verify the code path actually reads it. --no-cache sitting in the parser but unused is exactly the kind of gap that only turns up when someone reads the issue tracker, not the tests.

The Right Way to Start Claude Code on an AWS Project

Siddharth Pandey — Tue, 14 Jul 2026 09:40:36 +0000

You know the drill for adding an MCP server to a project: dig the exact command string out of the docs, hand-write a .mcp.json with an absolute path you'll typo once, restart the editor, and discover no tools showed up because the server expected a config file you haven't created yet. Plenty of MCP servers lose their would-be users somewhere inside that loop.

Infrawise collapses the whole loop into one command. It's an open-source tool (npm) that statically analyzes your codebase, AWS infrastructure, and database schemas, then exposes that context to AI coding assistants over MCP — so Claude Code knows your actual partition keys, GSIs, and indexes instead of guessing from source files. This post is about the part that usually kills tools like this before they deliver any value: setup.

Section 1: One command, four steps

npm install -g infrawise   # or skip install and use npx
cd your-project
infrawise start --claude

start does four things, in order:

1. Probes your environment. If there's no infrawise.yaml in the project, it generates one. It reads AWS_PROFILE if set; otherwise it looks at your configured AWS profiles — one profile means zero questions, several means one prompt asking which to use. That's the entire interview. (If you want the full guided wizard instead, infrawise start --interactive runs it.)

2. Runs the analysis. It scans your AWS services, database schemas, and codebase, builds a graph of services, tables, indexes, and query patterns, and runs rule-based analyzers over it. No LLM is involved in this step — extraction and analysis are deterministic, so the same infrastructure always produces the same graph.

3. Writes .mcp.json to your project root. This is the file you'd otherwise write by hand:

{
  "mcpServers": {
    "infrawise": {
      "command": "infrawise",
      "args": [
        "serve",
        "--stdio",
        "--config",
        "/absolute/path/to/infrawise.yaml"
      ]
    }
  }
}

4. Opens Claude Code. Claude Code reads .mcp.json automatically and starts the session with all 21 infrawise tools available — schema lookups, per-function analysis, GSI suggestions, queue and topic details, the lot.

If the claude CLI isn't installed, start tells you exactly that and where to get it, instead of failing silently.

Section 2: Day two — you never type `infrawise` again

This is the part that matters more than the first run. .mcp.json doesn't point at a long-running server you have to remember to start. It tells the editor how to spawn one: every time you launch Claude Code in that project, the editor itself runs infrawise serve --stdio as a child process. There is no port to keep free, no background daemon to babysit, no "is the server running?" debugging session.

So the second-day workflow is:

claude

That's it. No infrawise command anywhere.

Two mechanisms keep the context from going stale underneath you:

A 24-hour analysis cache. The analysis from start is cached. When the editor spawns the server and the cache is fresh, the session begins instantly with the existing graph. Once the cache is older than 24 hours, the next session start refreshes it. The freshness is also visible to the assistant itself: get_infra_overview returns an analyzedAt timestamp, an ageSeconds value, and a stale flag, so Claude can tell you — or decide on its own — when the picture it has is old. (This came out of a reader question on an earlier post about deterministic analysis; it shipped as a proper feature.)

A file watcher inside the session. While the server is running, it watches the repository for file changes and re-runs code analysis on save. Write a new function that calls DynamoDB.scan() mid-session, and the code graph reflects it — you don't need to restart anything for the assistant to see what you just wrote.

Infrastructure changes are the one thing that won't propagate automatically mid-session — if you just added a table or changed a GSI in AWS, run infrawise analyze to force a full re-scan rather than waiting out the cache. And if the config itself has drifted from reality (new AWS account, different profile), infrawise start --rediscover deletes infrawise.yaml and the .infrawise/ cache directory and rebuilds both from scratch.

Section 3: Not a Claude Code shop? Same command, different flag

The --claude flag is one of three editor targets, and none of them changes what gets analyzed — only where the MCP config lands:

infrawise start --cursor writes .cursor/mcp.json and opens Cursor.
infrawise start --vscode writes into .vscode/mcp.json and opens VS Code. This one merges rather than overwrites: if you already have other MCP servers registered in that file, they survive. Infrawise adds its own entry alongside them.
infrawise start with no flag writes .mcp.json, prints the launch command for each editor, and exits — for any other MCP-capable editor, point it at infrawise serve --stdio --config /path/to/infrawise.yaml.

And for the teammates who don't use an AI editor at all, the same analysis runs as a CI gate:

infrawise check --fail-on high

check runs a fresh analysis and exits non-zero when any finding reaches the threshold severity (high is the default; medium and low tighten it). A full-table scan on a production DynamoDB table fails the build whether or not anyone on the team has ever opened Claude Code.

Section 4: What the assistant actually does with it

The payoff for the setup being this short is that the context is there before you need it. Without it, an AI assistant reading only your source files will happily suggest a .scan() on a table with 50 million rows, or recommend adding a GSI you already have. With the MCP tools connected, it can call get_table_schema for the exact columns and keys, analyze_function for a Lambda's real trigger event shape, or suggest_gsi for a ready-to-use index definition matched to your table's billing mode — before writing the query, not after you've reviewed it.

I've written about those analysis capabilities in earlier posts; the point of this one is narrower. A context tool only works if it's actually connected, and "actually connected" has to cost less than the problem it solves. Pasting a schema into a prompt costs thirty seconds, every session, forever. infrawise start --claude costs one command, once.

Conclusion

The gap between "this MCP server exists" and "this MCP server is running in my editor" is where most infrastructure context tools die. Infrawise's answer is to make the editor own the server lifecycle: one start command probes, analyzes, writes the editor config, and launches; from then on the editor spawns infrawise serve --stdio itself, a 24-hour cache keeps session starts instant, and a file watcher keeps the code graph current while you work.

Try it on a real project — the first start on an actual AWS account is where it gets interesting: GitHub · npm

Key Takeaways

infrawise start --claude is the entire setup: probe environment, generate infrawise.yaml, analyze, write .mcp.json, open Claude Code with 21 MCP tools.
After the first run, just launch your editor — it spawns infrawise serve --stdio from .mcp.json on its own. No daemon, no port, no second command.
Analysis is cached for 24 hours and refreshed at session start when stale; the assistant can check freshness itself via get_infra_overview.
File changes are picked up mid-session by a watcher; infrastructure changes need infrawise analyze, and --rediscover rebuilds config from scratch.
--cursor and --vscode target other editors (the VS Code writer merges with existing MCP servers), and infrawise check --fail-on high gates CI with the same analysis.

DEV Community: Siddharth Pandey

Your AI context gets worse the longer you work

A context layer is a process, not a fetch

Why nobody catches these

What to actually check

The uncomfortable conclusion

Key takeaways

Your agent trusts the first match. Should it?

The failure mode that has no error to report

Why the wrong answer is the confident one

The same bug, one layer down

What the codebase was already doing right

Return the fork, do not resolve it

The general rule

Key takeaways

Your retry logic is correct and does nothing

The handler that is correct and does nothing

Why nobody catches this in review

Two ends of the same contract, two different findings

The rule that keeps it honest

What actually changed in the loop

Key takeaways

Your monorepo remembers infrastructure you deleted

A tool told someone to deploy a table from a stack they had deleted

How a deleted stack keeps its template

Why everything downstream believes it

The file the build rewrites every run

The exclusion that did not hold

What changed in the loop

Key takeaways

An empty result is not an all clear

false is a claim, and a failed call has no claim to make

The two exceptions are the interesting part

Four ways absence gets promoted to fact

Why this got urgent

The general shape

Key takeaways

Stale infrastructure context is worse than none

The bug that isn't a bug

Why the context has to be cached at all

What actually expires, and when

Refresh happens at the boundary you already have

Making age visible instead of silent

Conclusion

Key Takeaways

Your 12-Minute Frontend Build Is Now Your AI Agent's Bottleneck

The four taxes you are paying

Splitting without splitting the repo

The performance case, stated honestly

Where the AI speedup actually comes from

Migration path that does not stall

Key takeaways

Your Cognito Login Code Fails Because the App Client Never Allowed That Auth Flow

The app client is the config, and it is not in your repo

Reading the real client config

Turning it on

What this actually buys you

Key takeaways

Your Lambda Passes Tests Then Throws AccessDeniedException in Production

Why the assistant cannot see this on its own

What infrawise actually compares

Where you see it

Two things to know before you trust it

Try it

Key takeaways

How I Solved Claude Code Silently Missing the SQS Trigger on My Lambda

The problem: Claude Code didn't know the Lambda had an SQS trigger

The fix: infrawise's MCP tools in the loop, in order

What shipped instead

Why this is a repeatable pattern, not a one-off

Key takeaways

Your Lambda List Was Silently Truncated at 200 — And Your AI Assistant Never Knew

Hook

The 200-function wall

Why silent is worse than wrong

A pattern, not a one-off

The fix

Key Takeaways

The Right Way to Start Claude Code on an AWS Project

Section 1: One command, four steps

`false` is a claim, and a failed call has no claim to make

Section 2: Day two — you never type `infrawise` again