DEV Community: Siddharth Pandey

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 infrawise dev 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.

Why SNS Silently Drops Your Messages and How to Catch It Before You Ship

Siddharth Pandey — Sat, 11 Jul 2026 08:53:46 +0000

Your checkout service publishes an OrderRefunded event to an SNS topic. The publish call returns a MessageId. No exception, no retry, nothing in the dead-letter queue. Three days later a customer emails asking where their refund is, and you discover the refund Lambda was never invoked.

The message wasn't lost. It was filtered. One of the topic's subscriptions has a filter policy that requires an eventType message attribute, and your publish call didn't include it. SNS did exactly what it was configured to do: it evaluated the filter, found no match, and skipped delivery for that subscription. From the publisher's side, everything looks like success.

This is one of the nastiest failure modes in event-driven AWS architectures, because every tool you'd normally reach for reports green. This post walks through why it happens, why neither your code review nor your AI coding assistant can catch it from source code alone, and how to make the contract visible at coding time instead of incident time.

The contract nobody wrote down

SNS filter policies live on the subscription, not the topic. A subscriber says "only deliver messages where the eventType attribute is one of these values":

{
  "eventType": ["order.refunded", "order.cancelled"]
}

For that subscription to ever receive anything, the publisher must include the attribute:

await sns.send(
  new PublishCommand({
    TopicArn: process.env.ORDER_EVENTS_TOPIC,
    Message: JSON.stringify(refund),
    MessageAttributes: {
      eventType: { DataType: 'String', StringValue: 'order.refunded' },
    },
  }),
);

Omit MessageAttributes and the publish still succeeds — SNS accepts the message and returns a MessageId regardless of whether any subscription matches. The message simply isn't delivered to the filtered subscription.

Three things make this failure quiet:

No error surface. A filter mismatch is not a delivery failure. The subscription's redrive policy never kicks in, so the message never lands in a DLQ. There is nothing to retry and nothing to alert on by default.
The only trace is a metric. SNS increments a NumberOfNotificationsFilteredOut CloudWatch metric, but unless you already suspect filtering, nobody looks at it — and by the time you do, you're debugging in production.
Tests pass. Unit tests mock the SNS client and assert that PublishCommand was called. The mock has no filter policy. The gap between your code and the subscription's configuration is exactly the part the test can't see.

There is a second variant of the same trap: filter policies can also match against the message body (FilterPolicyScope: MessageBody) instead of message attributes. Then the required keys must appear in your JSON payload itself. Same silence, different location.

Why your AI assistant writes the broken version

Ask an AI coding assistant to "publish an order refunded event to the order-events topic" and it will produce a perfectly reasonable PublishCommand call — topic ARN from an environment variable, JSON.stringify on the payload, maybe a comment. What it will almost never produce is the MessageAttributes block with exactly the keys your subscriptions filter on.

It can't. The filter policy is not in your repository. It's a JSON document attached to a subscription in your AWS account, set by whoever wired up the consumer — possibly you, six months ago. The assistant reads your source files, sees other publish calls (which may themselves be missing attributes), and generates code that matches the pattern it found. If the pattern is wrong, the wrongness propagates.

The manual fix is miserable: open the AWS console, navigate to the topic, open each subscription one by one, read each filter policy, and paste the required attribute names into your prompt. Every session. For every topic. This is the copy-paste loop that breaks flow — and if you skip it once, you ship the silent drop.

Pulling the contract into the coding session

This is the problem infrawise is built for: it extracts your live infrastructure into a graph and serves it to your AI assistant over MCP, so the assistant queries facts instead of guessing.

cd your-project
npx infrawise start --claude

That analyzes your AWS account and codebase, writes .mcp.json, and opens Claude Code with 21 MCP tools connected. For SNS specifically, the extraction is read-only and direct: infrawise lists your topics, then for every confirmed subscription fetches its attributes, parses the FilterPolicy JSON, and records which attribute keys the policy requires and whether the policy scope is MessageAttributes or MessageBody.

The result is exposed through a tool called get_topic_details. For each topic it returns the subscription count, encryption status, and a filterPolicies array:

{
  "name": "order-events",
  "provider": "aws",
  "subscriptionCount": 3,
  "encrypted": true,
  "filterPolicies": [
    {
      "subscriptionArn": "arn:aws:sns:...:order-events:a1b2...",
      "protocol": "sqs",
      "requiredAttributes": ["eventType"],
      "scope": "MessageAttributes"
    }
  ]
}

Now the workflow changes. When you ask your assistant to write a publish call, it calls get_topic_details first, sees that a subscription on order-events filters on eventType, and writes the MessageAttributes block into the code on the first attempt. The contract that used to live invisibly in a subscription's configuration is now part of the context every generated publish call is checked against.

The tool description itself tells the assistant when to use it — before writing any SNS publish code — so you don't have to remember to prompt for it. And because infrawise also scans your application code (an AST pass that recognizes PublishCommand, PublishBatchCommand, and SDK publish calls and resolves their target topic ARNs), the graph knows which of your functions publish to which topics. Reviewing an existing publisher works the same way: the assistant can cross-reference what the function sends against what the topic's subscriptions require.

A few boundaries worth stating, because tools that read your AWS account should be explicit about them. Infrawise is read-only — the SNS extraction uses GetTopicAttributes, ListSubscriptionsByTopic, and GetSubscriptionAttributes, nothing that writes. It never reads message contents, secret values, or parameter values. And the analysis is deterministic: AST parsing and API introspection, no LLM deciding what your infrastructure looks like. The LLM is only a consumer of the extracted context.

Conclusion

Silent message drops are a configuration-versus-code mismatch, and those never show up in the layer you're staring at. The filter policy is correct. The publish code is correct. Only the combination is broken, and the combination exists nowhere in your repository — until you put it there.

You can do that manually every session by reading subscriptions in the console, or you can have it extracted once and served to your assistant automatically. If you're on the second option: GitHub · npm — npx infrawise start --claude and ask your assistant what the order-events topic requires.

Key Takeaways

An SNS publish that misses a subscription's filter policy succeeds silently: MessageId returned, no DLQ entry, no error. The redrive policy only covers delivery failures, and a filter mismatch isn't one.
The publisher's contract lives on the subscription, in AWS, not in your code — so tests with mocked SNS clients and AI assistants reading source files both miss it.
Check FilterPolicyScope: policies can require message attributes or keys in the message body. The fix is different for each.
Before writing any publish call, enumerate the target topic's filter policies and include every required attribute. With infrawise, get_topic_details gives your AI assistant that list automatically.
The NumberOfNotificationsFilteredOut CloudWatch metric is your post-hoc signal, but the goal is to never need it — catch the missing attribute at coding time.

Stop Sending Your AI Assistant 40 Tables When It Only Needs 3

Siddharth Pandey — Tue, 07 Jul 2026 08:35:15 +0000

Say your service has 40 tables. You ask Claude Code to fix a bug in checkout — a function that touches exactly three of them: orders, payments, inventory_reservations. If your MCP server hands the model your whole schema graph on every call just to answer that, you've spent a few thousand tokens of context on 37 tables nobody asked about, before the model has written a single line of code.

Multiply that by every tool call, every session, every developer on the team, and "just give it the schema" turns into a real line item — slower responses, a noisier context window, and a model more likely to get distracted by a campaigns table that has nothing to do with the bug you're fixing.

Infrawise's MCP tools are built around a specific answer to this: never send more schema than the task needs, and give the agent an explicit way to ask for exactly what it's missing.

The two bad defaults

Without something like this, an AI coding assistant reading your codebase has two options, and both are wrong in a different direction.

Option one: no schema at all. The model reads your source files, sees a DocumentClient.scan() call, and has no way to know that table has 50 million rows and a GSI it isn't using. It writes code that compiles and looks reasonable and is wrong the moment it touches production data — because "wrong" here isn't a syntax problem, it's a missing fact about your infrastructure that isn't in any file it can read.

Option two: dump everything, every time. Paste the full schema — every table, every column, every foreign key, every DynamoDB GSI — into the prompt so the model definitely has what it needs. This works, in the sense that the model now has the fact it's missing. It also means every single request pays for the full graph whether the task touches one table or fifteen. Context windows aren't free, and neither is the model's attention: the more irrelevant schema it has to read past, the more likely it latches onto the wrong table or a stale column name from a service you don't even own.

Infrawise's MCP server is designed around a third option: give the agent a cheap way to see what exists, then let it ask for detail only on the things it's actually going to touch.

How the lookup actually works

The server exposes 21 tools, but three of them define the whole pattern.

get_infra_overview is the entry point. It returns a compact snapshot — every table and collection by name and database type, queue and topic names, secret names, Lambda names, high-severity findings — no columns, no foreign keys, no indexes. It's meant to answer "what exists here" in a few hundred tokens, not "give me everything about it."

get_table_schema is where the actual detail lives, and it's scoped on purpose: it takes a list of 1 to 20 table or collection names and returns, per name, the columns with data types and nullability, primary keys, foreign keys (so an agent building a join knows the path without guessing), indexes, DynamoDB partition/sort keys, or a MongoDB estimated document count. Row data is never included — this is schema, not a data dump. Names are matched case-insensitively and by suffix, so asking for orders matches public.orders without the agent needing to know your schema prefix in advance. Ask for a table that doesn't exist and instead of a bare failure, you get up to five closest name matches back — useful when the agent guessed order instead of orders.

get_graph_summary is still there, and it still returns everything — every node, every edge, every finding, no filtering. It's the tool description that makes the intent explicit: it exists as the tool to reach for when you genuinely need the full picture across services, not the one an agent should reach for to answer "what does the orders table look like." The default path is get_infra_overview for orientation, get_table_schema for the two or three tables actually in scope, and get_graph_summary only when the task is broad enough to need it — reviewing an entire service, tracing relationships across five different tables and functions at once.

What this looks like on a real task

Take the checkout bug from the top. An agent working through it calls get_infra_overview once and learns there are 40 tables across Postgres and DynamoDB, plus a queue and a couple of Lambdas — cheap, one call, no column data yet. It's now looking at orders.ts, sees a query joining on payment_id, and calls get_table_schema with ["orders", "payments"]. Back comes exactly two schemas: column types, the foreign key from orders.payment_id to payments.id, and the indexes on both tables. That's the entire fetched context for the task — two tables, not forty.

If the bug turns out to touch inventory_reservations too, the agent just adds it to the next get_table_schema call. It never had to have asked for it upfront, and it never had to eat the cost of the other 37 tables it was never going to look at.

Compare that to the alternative most teams reach for without a tool like this: pasting the schema export once, keeping it in context, and hoping it doesn't drift as the schema changes. Infrawise's tables come from a fresh analysis (get_infra_overview even reports a freshness field with an age and a stale flag once the cached analysis passes 24 hours), so the agent knows when to ask for a re-run instead of working off of something that quietly went out of date three deploys ago.

Why this matters beyond the token count

The token savings are the visible part, but the more important effect is on accuracy. A model given forty tables' worth of columns has to do implicit filtering — figure out which of them are relevant, hold the rest as noise. Give it three tables that are actually in scope, and there's no filtering step: everything in context is something it's going to use. That's a smaller, sharper problem than "here's a schema, find what you need," and models are measurably better at smaller, sharper problems.

It also composes with what AGENTS.md calls out directly for large-database use cases — a text-to-SQL or query-writing agent should call get_infra_overview once per session for the table inventory, then get_table_schema only for the tables the current query touches, and treat get_graph_summary as the tool of last resort, not the default. That's the same pattern the checkout example walks through, just named as the recommended path for exactly the case where dumping everything hurts most — a database with hundreds of tables where "just paste the schema" was never realistic in the first place.

None of this requires the developer to think about it. You don't decide when to call get_table_schema versus get_graph_summary — the agent does, because the tool descriptions say when to reach for each one. The developer experience is just: ask Claude Code to fix the bug, and it already knows which two tables matter.

Key Takeaways

Two bad defaults exist for schema context: give an AI assistant nothing (it guesses and gets it wrong) or give it everything (it pays for and gets distracted by tables it will never touch).
get_infra_overview is a compact, column-free snapshot meant for orientation — names and types, not detail.
get_table_schema fetches full column, key, and index detail for up to 20 named tables at a time, matched case-insensitively by short name, with fuzzy suggestions on a miss.
get_graph_summary still returns the full graph — it's the explicit escape hatch for cross-service work, not the tool an agent should reach for to answer a question about two tables.
The pattern scales down naturally to large databases: fetch the inventory once per session, then pull schemas only for the tables the current task actually touches.

GitHub · npm

Stop Pasting Your Database Schema Into Every AI Prompt

Siddharth Pandey — Mon, 06 Jul 2026 06:04:42 +0000

Your team builds an internal agent that answers questions like "revenue by product category last quarter." It generates SQL against a Postgres database with 240 tables. The first version does the obvious thing: dump the entire schema into the system prompt. It mostly works, and it is quietly terrible — every single question pays the token cost of 240 table definitions, the agent confuses users.name with the actual column full_name because the real signal is buried in noise, and the schema snapshot in the prompt drifts out of date the moment someone runs a migration.

The fix is not a bigger context window. It is giving the agent the same thing a human analyst has: a way to look up the tables it needs, when it needs them.

This is a use case I did not originally design Infrawise for — it started as infrastructure context for AI coding assistants — but as of v0.15.0 it handles this pattern end to end, for SQL and NoSQL databases. (GitHub · npm)

The schema dump is the problem, not the model

When a query-writing agent gets the whole schema up front, three things go wrong:

Token cost scales with your database, not your question. A 240-table schema rendered as DDL is tens of thousands of tokens. You pay that on every request, forever, even when the question touches two tables.

Irrelevant schema actively hurts accuracy. Models pick columns from tables that merely look plausible. The more near-duplicate tables in context (orders, orders_archive, orders_v2), the more confidently wrong the generated SQL gets.

The dump goes stale. Someone pastes the schema into the prompt template in March. In May a column is renamed. The agent keeps generating SQL against the March schema, and the failures look like model errors instead of what they are: stale context.

The alternative is progressive disclosure — a small inventory up front, full detail on demand. Infrawise exposes exactly that over MCP, the protocol most agent SDKs can already speak.

Inventory first, schema on demand

Infrawise runs a read-only analysis of your infrastructure — Postgres, MySQL, and MongoDB via schema introspection, DynamoDB via the AWS API — and serves the result through an MCP server. It never reads row data, only metadata.

The agent flow is two calls.

Call 1, once per session: get_infra_overview. This returns a compact inventory — every table name with its database type, plus counts and high-severity findings. For a 240-table database this is a fraction of the tokens of a full dump, because it is names, not definitions. The response also carries a freshness object with analyzedAt, ageSeconds, and a stale flag that flips after 24 hours, so the agent knows whether the analysis is current or should be refreshed with infrawise analyze. That freshness contract means you can cache the inventory for the session and trust the server to tell you when it has gone stale.

Call 2, per question: get_table_schema. When the agent decides the question needs orders and payments, it asks for exactly those (up to 20 names per call):

{
  "name": "get_table_schema",
  "arguments": { "tables": ["orders", "payments"] }
}

Names are matched case-insensitively, and short names work — orders matches public.orders, so the agent does not need to know your schema-qualification convention. The response is the full picture for just those tables:

{
  "note": "Row data is never included.",
  "tables": [
    {
      "requested": "orders",
      "found": true,
      "matches": [
        {
          "name": "public.orders",
          "databaseType": "postgres",
          "columns": [
            { "name": "id", "dataType": "integer", "nullable": false },
            { "name": "user_id", "dataType": "integer", "nullable": false },
            { "name": "status", "dataType": "character varying", "nullable": false },
            { "name": "total", "dataType": "numeric", "nullable": false }
          ],
          "primaryKeys": ["id"],
          "indexes": ["orders_pkey"]
        }
      ]
    }
  ]
}

Column names, data types, nullability, primary keys, indexes. If the agent asks for a table that does not exist — a hallucinated name, a typo — it gets found: false, and when near matches exist, up to five suggestions from the real inventory. That turns a silent wrong-table failure into a correctable one.

The prompt for any given question now contains the inventory plus two or three real schemas instead of 240 speculative ones. Costs drop, and the model stops choosing columns from tables that were never relevant.

Foreign keys are the context your agent actually needed

Column lists get you valid syntax. Join paths get you correct queries — and join paths are exactly what schema dumps usually omit, because people paste \d output or ORM models without constraint details.

Infrawise extracts foreign keys directly from information_schema (Postgres and MySQL) during analysis, and get_table_schema returns them per table:

"foreignKeys": [
  {
    "column": "order_id",
    "referencesTable": "public.orders",
    "referencesColumn": "id"
  }
]

When the agent fetches payments and sees order_id → public.orders.id, the join is no longer a guess. Chains compose the same way: fetch the tables the question mentions, follow the referencesTable values one hop out, and the agent has the join graph for the query without ever seeing the other 230 tables.

The same flow works for NoSQL

The tool is polymorphic across database types, because "what does my agent need to know before writing this query" differs by engine:

DynamoDB — the response carries partitionKey and sortKey, which decide whether the access pattern is a cheap Query or an expensive Scan. Index names cover the GSIs.
MongoDB — collections return their indexes and an estimated document count, so the agent can tell a 100-row lookup table from a 50M-document collection before choosing a filter strategy.

One inventory call, one schema tool, four database engines.

Wiring it into an agent

Setup is one command in the project that has your infrawise.yaml (or lets start generate one):

npx infrawise start    # analyze + write .mcp.json for stdio-based editors/agents

For agents that speak HTTP instead of stdio:

infrawise serve        # MCP server at http://localhost:3000/mcp

Any MCP-capable agent framework can then list the tools and call them. The system prompt shrinks to a policy instead of a schema:

Call get_infra_overview once to learn what tables exist. Before writing a query, call get_table_schema with only the tables the question needs. Use the returned foreign keys for joins. Never guess column names.

Two cautions from building this. First, the server has no authentication — it is designed to run locally or inside a private network, next to the agent. Keep it off the public internet; it exposes schema metadata (never data, never secrets, but your table names are your business). Second, the analysis is a snapshot: honor the stale flag rather than assuming the graph is live.

Conclusion

"Text-to-SQL accuracy" problems are very often context problems wearing a trench coat. An agent that receives 240 table definitions is being asked to find a needle in a haystack it paid for by the token. An agent that can look up exactly the three tables a question touches — with types, primary keys, and foreign-key join paths — is doing what a competent analyst does with a schema browser open.

Infrawise was built to stop AI coding assistants from guessing about infrastructure. It turns out the same deterministic extraction, served over MCP, is a schema context provider for any query-writing agent. That flow shipped in v0.15.0: GitHub · npm.

Key Takeaways

Full-schema prompts scale cost with database size, not question size — and the irrelevant 95% of the schema makes column hallucination worse, not better.
Use progressive disclosure: get_infra_overview once per session for the table inventory, get_table_schema for only the tables each question needs.
Foreign keys are the highest-value schema context for SQL generation — they turn joins from guesses into lookups. Infrawise extracts them from information_schema automatically.
Unknown table names return suggestions instead of silent failure, catching hallucinated tables before they become broken SQL.
Respect the built-in freshness contract: the overview reports analysis age and flips a stale flag at 24 hours, so agents know when to trigger a re-analysis instead of trusting old schema.

Your SQS Queue Is Redelivering Messages Your Lambda Is Still Processing

Siddharth Pandey — Sun, 05 Jul 2026 09:41:35 +0000

Your order-processing Lambda starts sending duplicate confirmation emails. Not always — maybe one order in twenty. CloudWatch shows more invocations than messages published. The function code hasn't changed in weeks. What changed is that someone added a fraud check that pushed processing time from 25 seconds to around 45, and your SQS queue is still running the default 30-second visibility timeout.

That combination is the whole bug. When a Lambda pulls a message from SQS, the message isn't deleted — it's hidden for the duration of the visibility timeout. If the function is still working when that window closes, SQS assumes the consumer died and hands the same message to another invocation. Now two Lambdas are processing the same order, both will "succeed," and both will send the email. Nothing errors. Nothing retries. There is no log line that says "this message was delivered twice because your timeouts are misconfigured."

Infrawise (npm) flags this exact mismatch as a high-severity finding before it costs you an afternoon of staring at idempotency-free handler code. This post walks through why the bug is so hard to see, how the detection works, and how to keep an AI assistant from reintroducing it.

Why you never catch this one yourself

Three things make this misconfiguration nearly invisible:

It passes every test. In local tests and staging, your handler processes a synthetic message in two seconds. The 30-second visibility window never comes close to expiring. The bug only exists under production conditions — real payload sizes, real downstream latency, cold starts stacking on top of slow dependencies.

The defaults set the trap. SQS queues default to a 30-second visibility timeout. Lambda functions routinely get their timeout bumped to 60, 120, or 900 seconds as they grow. Nobody bumps the queue at the same time, because the two settings live in different consoles, different IaC resources, and usually different pull requests.

The failure signature points elsewhere. Duplicate processing looks like an application bug. You'll audit your handler for accidental double-sends, check whether the producer published twice, and read DynamoDB conditional-write docs before anyone thinks to compare two timeout values across two services.

The fix is one line of IaC. Finding out you need it is the expensive part.

How infrawise detects the mismatch

Infrawise builds a graph of your actual AWS account and runs rule-based analyzers over it — no LLM involved in the analysis, so a finding either fires or it doesn't (deterministic by design).

For this check, two extractions matter:

Queue attributes. For every queue returned by ListQueues, infrawise calls GetQueueAttributes and records VisibilityTimeout alongside the redrive policy, encryption status, and approximate message counts. A queue node in the graph carries its visibilityTimeoutSec.

Event source mappings. Infrawise paginates through ListEventSourceMappings and attaches each mapping to its Lambda. Every SQS-type mapping becomes a triggers edge in the graph: queue:aws:order-events → lambda:aws:process-order. Disabled mappings are skipped — a queue that used to feed a Lambda doesn't generate noise.

Then the VisibilityTimeoutMismatchAnalyzer walks the graph: for each queue that actually triggers a Lambda, it compares the queue's visibility timeout against that function's configured timeout. If the visibility timeout is smaller, you get a high-severity finding.

Two details keep this precise rather than noisy:

Only wired-up queues are checked. A queue with no active event source mapping is ignored. The analyzer isn't pattern-matching on names or guessing at architecture — it follows the same edge SQS itself uses to deliver messages.
The comparison uses real values from both sides. The Lambda timeout comes from the function configuration; the visibility timeout comes from the live queue attributes. If your Terraform says one thing and someone changed the queue in the console, infrawise reports what's actually deployed.

Running infrawise analyze against the scenario above prints:

  1.  HIGH   Queue "order-events" visibility timeout (30s) is less than Lambda "process-order" timeout (120s)
       If the Lambda takes longer than the visibility timeout, SQS will re-deliver the message to another consumer while the original invocation is still running, causing duplicate processing.
       → Set the visibility timeout for "order-events" to at least 720s (6× the Lambda timeout of 120s), per AWS best practice.

The 6× multiplier follows AWS's own guidance for Lambda event source mappings: the extra headroom covers batch processing and retries within the polling window, not just a single invocation.

The fix — and keeping it fixed when AI writes your infra

The immediate fix is mechanical. In CDK:

const orderEvents = new sqs.Queue(this, 'OrderEvents', {
  visibilityTimeout: cdk.Duration.seconds(720), // 6× the consumer's 120s timeout
});

The longer-term problem is that this class of bug gets reintroduced constantly — and increasingly by AI assistants. Ask an assistant to "add an SQS queue that triggers the order processor" and it will happily emit a queue with default settings wired to a 120-second function. The code is syntactically perfect. It deploys. It has the bug from paragraph one built in.

This is where infrawise's MCP server changes the workflow. Run once:

infrawise start --claude

It scans your account, writes .mcp.json to the project root, and opens Claude Code with the analysis available as tools. From then on the assistant can call get_queue_details, which returns every queue with its visibilityTimeoutSec, DLQ presence, encryption, FIFO flag, and message counts — plus any findings attached to that queue. The tool description explicitly tells the model to verify visibility timeout against Lambda timeout when reviewing messaging architecture, so an assistant asked to touch queue infrastructure checks the real numbers instead of emitting defaults.

Concretely, the before/after looks like this:

Before: "add a queue for order events" → assistant generates new sqs.Queue(...) with no visibility timeout → default 30s ships → duplicates appear weeks later when processing slows down.
After: the assistant calls get_queue_details and get_lambda_overview, sees the consumer's 120s timeout, and generates the queue with visibilityTimeout: Duration.seconds(720) — citing the existing high-severity finding if one is already live.

Two adjacent findings tend to show up in the same report, and they compound. If the mismatched queue also has no dead-letter queue — another high-severity check — your duplicate-processing problem coexists with silent message loss after retries are exhausted. And note the fix's flip side: a properly long visibility timeout means a genuinely failed message stays hidden for that full window before retry, which is exactly why the DLQ check matters alongside this one. Duplicate delivery can still happen in rare cases even with correct timeouts (SQS standard queues are at-least-once), so idempotent handlers remain good practice — but there's a difference between designing for a rare edge case and misconfiguring your way into hitting it on every slow invocation.

Analysis results are cached for 24 hours, and the MCP server refreshes stale analysis at session start, so the numbers your assistant reads track what's actually deployed.

Key takeaways

A Lambda timeout longer than its queue's visibility timeout guarantees duplicate processing under load. SQS redelivers any message whose consumer is still running when the visibility window closes.
The defaults create the bug: queues start at 30 seconds, Lambda timeouts grow over time, and the two values live in different resources that rarely change in the same PR.
Set visibility timeout to 6× the consumer Lambda's timeout, per AWS guidance — and pair every triggered queue with a dead-letter queue so retries can't silently discard messages.
Check deployed values, not IaC intent. Infrawise compares the live queue attribute against the live function configuration, so console drift gets caught too.
Give your AI assistant the real numbers. With infrawise's MCP tools connected, an assistant generating queue infrastructure reads actual timeouts instead of shipping defaults.

Try it against your own account — or against a free LocalStack sandbox if you want to see the findings without touching real AWS: GitHub · npm.

Block AI-Generated Infrastructure Mistakes in CI Before They Hit Production

Siddharth Pandey — Sun, 28 Jun 2026 17:57:30 +0000

Last Tuesday your team merged a PR with 40 lines of clean TypeScript. Code review passed — the function was readable, typed correctly, and had a unit test. Twenty minutes after deploy, CloudWatch alerted: your Orders table was being fully scanned on every request. The merged function called .scan() without a partition key filter. Claude Code wrote it; nobody caught it because nobody — not the reviewer, not the tests, not the linter — had any way to know that Orders has 8 million items.

This is the gap infrawise check fills. It's a CI step that reads your actual DynamoDB schemas, PostgreSQL indexes, and query patterns, then fails the build when AI-generated code introduces anti-patterns against your real infrastructure.

The Gap Between Code Review and Infrastructure Reality

Static analysis tools like ESLint, TypeScript, and Semgrep analyze the code. They can't tell you that listAllOrders() is doing a full table scan, or that your PostgreSQL users table has no indexes and the new query will degrade from milliseconds to seconds as data grows.

AI assistants compound this. They write syntactically correct code that compiles and passes tests — but they're working from source files, not live infrastructure. They don't know your table's partition key distribution. They don't know you already have a GSI on status. They generate code against an imagined infrastructure and get it wrong in ways that only surface at scale.

The consequence isn't just performance. A DynamoDB full scan in a high-traffic Lambda reads capacity units proportional to table size on every invocation. A missing index causes query times to grow linearly with rows. Unit tests won't catch either of these; they show up in production.

infrawise check — a Build Step That Knows Your Tables

infrawise check runs a fresh analysis of your codebase and cloud infrastructure, then sets exit code 1 when blocking findings exist. That exit code is all a CI pipeline needs.

infrawise check

Actual output on violations:

  Blocking findings  2 at or above high

  1.  HIGH   Full table scan detected on DynamoDB table "Orders"
             The table "Orders" is being scanned without any filter, which reads every item.
             → Replace Scan with a Query operation using a partition key or GSI.

  2.  HIGH   Full table scan detected on DynamoDB table "Sessions"
             The table "Sessions" is being scanned without any filter. Called from: cleanupExpiredSessions
             → Replace Scan with a Query operation using a partition key or GSI.

  ✗ Check failed
    2 high+ finding(s) must be resolved before deploy

Findings reference the exact table name and caller function. The recommendation isn't generic — it points to the specific operation to replace.

Add it to GitHub Actions in one step:

- name: Infrastructure check
  run: infrawise check --fail-on high

--fail-on high means only HIGH findings block the build. Medium and low appear in the log but don't fail the step. Use --fail-on medium for stricter enforcement.

Available options for --fail-on: high (default), medium, low.

Writing infrawise.yaml for CI

In local development, infrawise start --claude generates the config and connects your editor. In CI, commit the config and pass credentials through environment variables:

project: payments-service

aws:
  profile: default
  region: us-east-1

dynamodb:
  enabled: true
  includeTables:
    - Orders
    - Users

postgres:
  enabled: true
  connectionString: postgresql://infrawise_ro:${DB_PASSWORD}@host:5432/mydb

lambda:
  enabled: true

The ${DB_PASSWORD} substitution keeps credentials out of the committed config — infrawise expands environment variables at runtime. Set DB_PASSWORD as a CI secret.

For AWS access, infrawise is read-only. The minimum IAM policy it needs for DynamoDB is dynamodb:ListTables and dynamodb:DescribeTable. Create an IAM role for CI with just these permissions and configure OIDC trust for your GitHub Actions runner.

What Blocks, What Warns, What Can Wait

Not every finding warrants a hard block. A starting policy:

Block on HIGH: Full table scans, hotspot patterns where multiple functions hammer the same partition key. These have immediate cost and availability impact.

Warn on MEDIUM: Tables with no GSIs queried by multiple functions, missing indexes on filterable columns in PostgreSQL. These degrade as data grows — log them and schedule remediation.

Log only for LOW: Non-critical index suggestions, rarely-queried pattern gaps. Useful signal for the next sprint.

Start with --fail-on high. Once the team has cleared existing HIGH findings, tighten to --fail-on medium. The goal is catching regressions — new findings introduced by merged code — not blocking work on pre-existing debt.

The includeTables field in infrawise.yaml lets you scope analysis to specific tables. Roll out the gate incrementally: start with the tables your AI assistant touches most.

Conclusion

The table scan that paged your on-call engineer wasn't wrong code. It was a gap in tooling — your pipeline understood TypeScript but not DynamoDB. infrawise check closes that gap by giving CI the same infrastructure context your AI assistant should have had when it wrote the query.

One step in the pipeline. One committed config file. The build fails when generated code would fail in production.

GitHub · npm

Key Takeaways

AI-generated code passes code review and unit tests but can introduce DynamoDB full scans and missing index queries that only appear at scale
infrawise check runs deterministic infrastructure analysis and exits non-zero on blocking findings — drop-in CI gate
--fail-on high|medium|low controls what severity blocks the build; high is the default
infrawise.yaml uses ${ENV_VAR} substitution so database passwords never need to be committed
infrawise is read-only — minimum IAM for DynamoDB is dynamodb:ListTables and dynamodb:DescribeTable

Your DB Is Still Red After Adding a Cache — Here's Why

Siddharth Pandey — Tue, 23 Jun 2026 12:21:17 +0000

You deployed a cache in front of your database three weeks ago. The DB is still running at 90% utilization. Traffic doubled last month and you're wondering if the cache is doing anything at all.

It is — just not as much as you expected, because cache hit rate is not something you configure. It emerges from two things: how much of your working set fits in memory, and how skewed your access patterns are.

Paperstack is a free system design simulator that makes this visible. Sketch an architecture, press play, watch utilization numbers and node colors update live. The demo below walks through the cache problem using it.

Hit Rate Isn't a Setting

A cache absorbs reads by serving them from memory instead of forwarding them to the database. The fraction it absorbs — hit rate — depends on one thing: whether the data a request needs is in memory.

Two variables determine that:

Working-set vs memory. If your active data is 100,000 keys and your cache holds 50,000, only half the requests can possibly hit — the rest miss and forward to the DB. Your cache isn't broken. It's undersized for the working set.

Access skew. If 80% of requests hit 10% of keys (common in social or content workloads), a much smaller cache can achieve a high hit rate because the hot keys stay warm and rarely get evicted. Paperstack models this directly via the skew parameter on the Cache node: with an LFU eviction policy, higher skew boosts hit rate beyond raw memory coverage. With LRU, skew gives no benefit — the eviction algorithm doesn't take access frequency into account, so cold pages get evicted as readily as hot ones.

This is why you can't just set hitRate: 0.9 in the config panel — Paperstack doesn't expose hit rate as a field. You set memory and workingSet; hit rate is computed. If the simulation let you enter a hit rate directly, it would be lying to you about what your architecture actually does.

The Comparative in Action

Here's the experiment worth running in Paperstack: sketch Traffic → App → Cache → Database. Run the simulation. Watch which nodes go red.

With cache memory smaller than workingSet, most reads miss and forward to the DB. The DB stays red. The cache stays green — it has throughput headroom, it's just not absorbing much.

Now increase the cache memory past the working-set size. The hit rate climbs. Fewer reads reach the DB. At some threshold the DB color shifts from red to orange to green — and a different node becomes the bottleneck. Maybe the App Server. Maybe the cache's own throughput cap.

This is what Paperstack calls the comparative: when you change one variable, the bottleneck doesn't disappear — it moves. That relocation is the lesson. Scaling the cache fixed your DB problem and revealed your next one.

The inverse is just as instructive. Remove the Cache node and rerun. Watch the DB immediately redline. This is how you build intuition for what a cache is actually doing — not by reading about hit rates, but by watching the utilization delta before and after.

When Write Policy Matters

Paperstack exposes three write patterns on the Cache node: Cache-aside, Write-through, and Write-behind. The choice affects both latency and what happens when you kill the cache node.

Cache-aside (the default) separates reads from writes entirely. Reads check the cache first; misses go to the DB. Writes bypass the cache and go directly to the DB. The cache is populated on read-miss, not on write. Kill the cache: reads start missing entirely, DB load spikes, but the write path was already going to DB — no disruption there.

Write-through keeps the cache and DB in sync on every write. Writes pay the cache's latency and the DB's latency on the write path, making writes more expensive than cache-aside. Kill the cache: reads fall through to DB, but every write was already reaching the DB, so nothing is lost.

Write-behind is where the kill scenario gets interesting. In this mode, the cache absorbs writes entirely — they never reach the DB during normal operation. Only read-misses reach the DB. The DB is effectively shielded from the write load.

Kill the cache node in write-behind mode: Paperstack's passThroughOnKill behavior makes the cache transparent — all traffic falls straight through. The DB suddenly receives the write workload that was never reaching it before. If the DB was sized assuming writes were handled by the cache, it may not have the writeCap headroom to absorb the sudden change. The simulation shows this directly as DB utilization spiking and requests dropping.

This failure mode is invisible on a static architecture diagram. The diagram shows cache → DB regardless of write policy. The simulation shows what breaks.

Conclusion

The cache-doesn't-help problem is usually a mismatch between memory and working set, not a configuration error. Once hit rate is computed from real inputs rather than typed in, the DB utilization behavior makes sense.

Paperstack makes the relationship between working-set size, cache memory, write policy, and DB utilization visible without deploying anything. Sketch the architecture, tune the numbers, kill nodes, and watch the bottleneck move. When the DB finally turns green, you know exactly why.

Try it at Paperstack — it runs in the browser, no account needed.

Key Takeaways

Cache hit rate emerges from memory vs workingSet and access skew — it's computed, not configured. Undersizing cache memory caps hit rate regardless of traffic volume.
The comparative (change one variable, watch the bottleneck move) is how you build cache intuition: adding cache makes the DB green, revealing the next bottleneck.
LFU eviction benefits high-skew workloads (popular keys stay warm); LRU does not — skew only matters with the right eviction policy.
Write-behind shields the DB from writes during normal operation; kill the cache and the DB suddenly receives the write load it was never sized for.
Write-through and Cache-aside are safe to kill (writes were already reaching DB); write-behind changes the DB's workload profile on failure.

DEV Community: Siddharth Pandey

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

Section 2: Day two — you never type infrawise again

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

Section 4: What the assistant actually does with it

Conclusion

Key Takeaways

Why SNS Silently Drops Your Messages and How to Catch It Before You Ship

The contract nobody wrote down

Why your AI assistant writes the broken version

Pulling the contract into the coding session

Conclusion

Key Takeaways

Stop Sending Your AI Assistant 40 Tables When It Only Needs 3

The two bad defaults

How the lookup actually works

What this looks like on a real task

Why this matters beyond the token count

Key Takeaways

Stop Pasting Your Database Schema Into Every AI Prompt

The schema dump is the problem, not the model

Inventory first, schema on demand

Foreign keys are the context your agent actually needed

The same flow works for NoSQL

Wiring it into an agent

Conclusion

Key Takeaways

Your SQS Queue Is Redelivering Messages Your Lambda Is Still Processing

Why you never catch this one yourself

How infrawise detects the mismatch

The fix — and keeping it fixed when AI writes your infra

Key takeaways

Block AI-Generated Infrastructure Mistakes in CI Before They Hit Production

The Gap Between Code Review and Infrastructure Reality

infrawise check — a Build Step That Knows Your Tables

Writing infrawise.yaml for CI

What Blocks, What Warns, What Can Wait

Conclusion

Key Takeaways

Your DB Is Still Red After Adding a Cache — Here's Why

Hit Rate Isn't a Setting

The Comparative in Action

When Write Policy Matters

Conclusion

Key Takeaways

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