A Frontend Loop Needs a Real App

I built an AI VRAM calculator because I needed a sample app for TypeScript frontend loops. That turned out to be the right kind of mistake: calculators force generated frontends to deal with real state, real math, real copy, and real edge cases.

The app is live at vram.rxdt.dev. You give it a model size, precision, workload, and deployment mode, and it gives you a VRAM estimate, a hardware tier, a rough speed, and the assumptions it used to get there. Everything runs in the browser. There is no backend.

This post is about why that app, and not a todo list, is the right target for an agent loop that writes frontend code.

Why this appThe domain supplies the rigor

VRAM estimation is a real question people ask before spending real money. “Will a 70B model fit on the GPU I’m about to buy?” has a checkable answer, and getting it wrong is embarrassing in a way a mislabeled todo item never is.

More importantly for a loop benchmark, the domain has naturally interacting inputs: model size, precision, quantization overhead, context window, batch size, KV-cache precision, execution mode (inference vs LoRA vs QLoRA vs full training), MoE routing, memory sharding. These aren’t invented complexity. They’re the actual variables of the actual problem, and they interact. QLoRA pins you to 4-bit. Training modes hide inference-only fields. MoE changes speed but not resident memory. A Local/Edge profile that outgrows every consumer card needs to say so instead of cheerfully recommending a datacenter accelerator.

A loop can fake its way through a todo app. It cannot fake its way through this.

Why it beats a todo appThe failures are visible

• Incorrect math is visible. 70B at fp16 is 140 GB of weights. AdamW mixed precision is ~16 bytes per parameter. Anyone in the field can eyeball the output, and so does the parity suite, which drives four canonical scenarios through real browser controls.
• The UI complexity is natural. The uncheck path of a checkbox whose default is true was a real bug: HTML forms omit unchecked boxes, normalization fell back to the default, and Gradient Checkpointing could never be turned off. Tests passed, the gate was green, and the bug shipped, because nobody wrote the uncheck test.
• Tests matter because money does. People may buy hardware based on this output. That reframes 100% branch coverage from vanity metric to floor.
• Accessibility is the product. The suite runs six browser projects, phone to 2560px. That matrix caught a WebKit bug: Safari never restyles a sibling when a <meter> attribute changes, so the fit meter stayed wrong for every real Safari user while Chrome looked perfect.

What the loop taughtSpecs, gates, and copy

• Specs beat vibes. Every behavior worth having was written down before it was generated. The ones that weren’t are the ones that churned.
• Gates catch boring, real issues. Eighteen checks: prettier, eslint, stylelint, typecheck, semgrep, 100%-coverage units, the full Playwright matrix, Lighthouse budgets. Almost nothing it rejected was interesting. All of it was real.
• Copy is product logic when numbers are uncertain. “Fits on one 24 GB card: 19.0 GB uses 93% of its 20.4 GB usable VRAM” took more revisions than the math. An estimate without its assumptions is indistinguishable from a wrong one.
• Quality drifts upward when checks are strict. The gate refuses lint bypass comments, unstages forbidden paths at commit, runs the whole matrix on every push. “Demo app” stopped being accurate without anyone deciding it should.

The takeawayPick a product-shaped target

Good frontend agent loops need a product-shaped target: something with state that interacts, math that can be checked, copy that carries meaning, and users who would notice. A calculator is a cheat code. The domain supplies the rigor, and the loop either meets it or fails visibly.

This one ended up as both: a tool I actually use before recommending hardware, and the proving ground that shaped LoopGate’s checks. The todo app never stood a chance.