Skeram is not a chatbot with opinions about your architecture. It’s a measured pipeline: an LLM reads your code exactly once, under strict rules — and every number you see is computed by deterministic, unit-tested TypeScript. Here is the whole machine, end to end, no hand-waving.
Five stages. One of them uses an LLM; the other four are plain code that produces the same output for the same input, every time.
Plain TypeScript walks the tree and catalogs what’s architecturally real: routes and API handlers, background jobs, queues, database schema and clients, external SDKs. No LLM involved — the same repo always yields the same inventory.
From the inventory, the pipeline selects the files that define the architecture — entry points, data access, job definitions — capped at 200KB total and 200 lines per file. Deterministic, and deliberately small enough to be read closely rather than skimmed.
Claude reads the selection and fills a strict schema — the AppModel: routes, data stores, queues, external calls, and their traffic shape. The rules: every claim must cite evidence, the file and lines it came from. The output is validated twice — against the schema, then for referential integrity. A failed validation earns exactly one retry, fed the validator’s errors; truncated output fails immediately instead of being patched up. And if the model can’t be validated, the run fails and the credit is refunded — Skeram never guesses a page into existence.
Pure TypeScript sweeps the model from 100 to 100,000 users: a curated AWS pricing table, sizing formulas for the things that actually break — connection pools, NAT throughput, queue depth, instance classes — and a failure-pattern rule catalog. All of it unit-tested. Click any number on any page and it shows you its formula. The LLM never writes a number.
The result is a living page: the interactive diagram, the scale slider, findings with file-and-line evidence. Same repo at the same commit, same numbers — that’s a testable claim, not a slogan.
The pipeline is deterministic; the world isn’t. What keeps Skeram honest is not better prompts — it’s a human feedback loop with teeth.
Before a teardown goes public, a human with seven years of AWS experience writes an expectations file — what a correct analysis of that codebase must find — and the pipeline’s output is scored against it. The publishing bar: at most two material discrepancies. The current bench: six repos, six passes.
When the pipeline gets something wrong, the fix lands in the deterministic layers — inventory rules, selection heuristics, schema constraints — and the miss becomes a permanent regression check. The prompt is the least interesting part of this system.
If a maintainer or a reader shows a finding is wrong, it gets corrected fast and credited. A tool that sells trust doesn’t get to bury its mistakes — a visible correction is worth more than a quiet one.
Samples of real analyses go through the same human review as the public bench, so the pipeline keeps learning from repos in the wild — not just the six it was graded on.
Credibility is mostly a list of things you won’t let the system do.
LLMs are unreliable at arithmetic across pricing SKUs, and worse at sizing. Every dollar figure, every saturation point, every threshold comes from the engine — code you could unit-test, because we do.
The pipeline speaks the JS/TS ecosystem — Next.js first-class; Express, Fastify, and Hono best-effort. Anything else is politely declined rather than improvised. A confident wrong answer is the one thing we can’t afford to ship.
The output is a modeled estimate with stated assumptions, not a replay of your AWS invoice. The point is that every assumption is visible and arguable — audit it, disagree with it, and if you’re right, we’ll correct it.
Every public teardown is the full pipeline’s real output — drag the slider, click the numbers, check the formulas against the evidence. If the methodology holds up, point it at your own repo: five analyses for $10.
Prepaid credits, no subscription · failed runs are refunded automatically