Forem: CallmeMiho

Stop Paying OpenAI to Read Garbage: The Two-Stage Agent Pipeline

CallmeMiho — Wed, 22 Apr 2026 02:43:21 +0000

Hey DEV community, CallmeMiho here. I spent my Monday morning watching a junior dev ship a Rube Goldberg machine powered by a credit card. Let's talk about why your AI agents are bankrupting you.

The task was simple: extract a specific itemUuid and a scimId from a massive dump of raw Activity Log data. Instead of engineering a solution, the dev just pipe-lined the raw, unformatted JSON slop—full of broken quotes, escaped characters, and mixed HTML tags—directly into a prompt and told the model to "find the ID."

The result was a textbook case of probabilistic vibration. Because the log was a disaster of escaped quotes (\") and malformed HTML, the agent hit an escaped character, hallucinated an end-of-file bracket that didn't exist, and entered an infinite recursion loop trying to re-parse the "rest" of the string.

It wasn't "reasoning"; it was a neural network tripping over its own feet because it was forced to be a parser. By the time I killed the process, the agent had burned through 50,000 tokens of high-tier compute just to find a single scimId.

That is not "AI Engineering"—it is technical debt with a monthly subscription.

The Hard Data: Measuring the Waste

If you aren't looking at the telemetry of your prompts, you aren't an architect; you’re a philanthropist for cloud providers. We call the delta between these two rows the Hype Tax.

Metric	Raw Activity Log Data	Cleaned/Extracted JSON
Input Volume	45,000 tokens	150 tokens
Cost Per Call	$0.68	$0.002
Latency	15s	2s
Success Rate	70%	99.9%

Paying a model to navigate 45,000 tokens of "garbage" formatting is a total failure of basic engineering discipline. When you feed an LLM unextracted noise, you aren't just wasting money—you are intentionally introducing non-determinism into a process that should be binary.

The Philosophy: LLMs Are Not Parsers

If a local Regex script or a JSON formatter can extract the signal for free, paying a model to do it is architectural waste.

High-performance engineering is grounded in a Secure by Design approach. Just as modern zero-knowledge architectures perform cryptographic operations locally to eliminate server-side risk, a professional AI integration must perform data extraction locally to eliminate token overhead. You should not trust a cloud LLM with raw data extraction; that belongs in the deterministic layer.

In a professional stack, we distinguish between Deterministic Logic (Regex, Zod) and Probabilistic Logic (LLMs). You don't use a billion-dollar neural network to find a DeviceKey in a text string; you use a parser. The LLM should only see the specific, non-sensitive identifiers required for the task after the local environment has done the heavy lifting.

The Fix: The Stage 1 Deterministic Pipeline

The only professional way to build AI integrations is a Two-Stage Agent Pipeline. Stage 1 is a local, deterministic cleanup phase. Before a single token is sent to a cloud provider, the data must pass through a local pipeline that strips the noise.

If you don't have a local pipeline, use offline utilities to build one:

Regex Tester: Your first line of defense. Use a local script to pull the itemUuid from a URL before the LLM ever sees the log entry. If the model is reading <div> tags to find a UUID, you have already failed. Build your regex patterns here.
JSON Formatter: Standardize and minify. This prevents the model from "vibrating" on broken quotes or escaped characters. A minified schema ensures the model focuses on the values rather than the syntax of the log. Format and minify your JSON here.
Zod Schema Generator: Use this to enforce strict data contracts. Based on the Least Privilege principle, your Zod schema should programmatically strip fields before the prompt is assembled. If the model doesn't need to see it, Zod shouldn't pass it. Generate your Zod schemas here.

Conclusion: Engineering Discipline vs. Hype

High-performance engineering isn't about how much AI you use, but how little you need to use to get the job done. If you are sending unformatted log slop to a cloud model, you aren't building an agent; you are building a technical debt generator.

Stop subsidizing Sam Altman’s compute with your company’s technical debt. Clean your data or get out of the kitchen.

P.S. If you want to audit your token payloads before they bankrupt you, I built a suite of 100% offline, zero-server-log developer tools atFmtDev.dev.

Next.js 15 & AI Agents: 4 Engineering Hacks to Save Your Production in 2026

CallmeMiho — Tue, 21 Apr 2026 23:32:41 +0000

Hey DEV community, CallmeMiho here. Following up on my 0ms latency build, I’ve spent the last few weeks post-morteming production wrecks in the new AI-native stack. 2026 isn't just about shipping fast anymore; it's about not being the person who leaks the database or burns the entire API budget in one night. I’ve put together four 60-second deep dives into the most critical engineering shifts you need to make right now.

1. I Stole Your Next.js Admin Token in 2 Seconds

If you are still storing JWTs in localStorage, you aren't building a security model; you're building a honeypot. One malicious NPM package or a single XSS vulnerability, and your user's session is gone.

The 2026 Standard: Use HttpOnly cookies. If JavaScript can't touch it, hackers can't exfiltrate it.
👉 Read the full guide on the Death of LocalStorage

2. How AI Agents Destroy Your Bank Account

Autonomous agents are prone to "Reasoning Loops." With 1M token context windows, an agent stuck in a loop sends the entire history back to the server every step. This isn't a linear cost; it's exponential. One logic error can cost you $1,000 overnight.

The Fix: Implement hard "Token Budgets" and iteration limits. Stop letting your agents go rogue.
👉 Calculate your AI Token Costs here

3. The "JWT Kidney Surgery" Hack

Think your RSA-signed tokens are safe? Hackers are performing "Kidney Surgery" by swapping your RSA keys for HMAC (HS256) and using your own Public Key as the secret. If your backend doesn't enforce strict algorithm checking, you're open.

The Fix: Move to deterministic standards like PASETO v4.
👉 Audit your tokens locally here

4. How I Force AI to Write Perfect Code

Relying on prompt engineering to get JSON from an LLM is a fatal mistake. They hallucinate Markdown backticks and conversational fluff that crashes your JSON.parse(). You need the "Validation Sandwich."

The Fix: Use strict JSON Schema to constrain the LLM, and Zod to validate the runtime output.
👉 Generate Zod Schemas from JSON instantly

Conclusion: Stop Guessing, Start Architecting

The era of "Copy-Paste Engineering" is over. Whether it's math-based RAG retrieval or protocol-level JSON-RPC, the machines you're building for require absolute precision.

Be honest in the comments: Which one of these has actually bitten you in production? 💀

If you need to debug these without leaking production secrets to a third-party server, I built a suite of local-only tools at FmtDev.dev.

The Death of LocalStorage: Why Enterprise Apps Use Cookies

CallmeMiho — Tue, 21 Apr 2026 02:01:26 +0000

Hey DEV community, CallmeMiho here. I recently built a 140-page, 0ms latency web-app without a single database query. But speed is irrelevant if your architecture is a security liability. I keep seeing 2026 tutorials teaching junior devs to store JWTs in localStorage. Let me be brutally honest: if you are doing this in production, you aren't building a security model; you're building a honeypot. Here is why enterprise stacks have abandoned it.

A single malicious NPM package can scan window.localStorage and exfiltrate every identity token in your application in less than 10 milliseconds. If you are still persisting JWTs in client-accessible storage, you are practicing hope-based architecture.

In an era where AI agents are expected to intermediate $15 trillion in B2B spend by 2028, structural integrity is the only currency. Persisting credentials in localStorage is no longer a "developer trade-off"—it is architectural negligence.

Why is localStorage vulnerable to XSS?

The fundamental flaw of window.localStorage is the total absence of isolation. It is a shared bucket, fully accessible to any JavaScript executing within the same origin.

When a Cross-Site Scripting (XSS) vulnerability occurs—via a compromised third-party dependency—the attacker gains the same programmatic access to your tokens as your own code. There are no "gates" to check authorization; localStorage.getItem() is a wide-open door.

The rise of agentic workflows has introduced sophisticated semantic injections. Accidental logic flaws in AI-produced code can create "silent" XSS vulnerabilities that traditional scanners miss, leading to mass exfiltration events.

The Architecture of Isolation: HttpOnly Cookies vs LocalStorage

Moving to HttpOnly cookies provides hardware-level isolation that localStorage cannot match.

Criteria	localStorage	HttpOnly Cookies
Access Method	Programmatic (JavaScript)	Browser-Managed (Headers)
XSS Vulnerability	High (Tokens are exfiltratable)	Low (Inaccessible to JS)
CSRF Risk	None (Manual transmission)	High (Requires SameSite mitigation)
Transmission	Manual Authorization Header	Automatic via Browser

By using the HttpOnly flag, you ensure that JavaScript—malicious or otherwise—cannot touch the token. Pair this with SameSite=Strict as your primary defense against CSRF.

Securing JWTs in Next.js

Hardened environments require harder patterns. For Next.js auth security, the shift involves moving token handling out of the client-side lifecycle and into Server Actions.

Warning: The Token to Shell Attack
Never trust a decoded JWT or Base64 payload without rigorous validation. In a Token to Shell exploit, a hacker modifies a decoded payload to include command injection patterns (e.g., ; rm -rf /). Always treat decoded data as "untrusted input."

Utilize an offline JWT Decoder to audit your token claims safely within your browser, ensuring no sensitive data leaks into server logs or AI training sets.

Hardening Patterns

Validate with Zod: Treat every server action as a public API. Use a Zod Schema Generator to define strict schemas for all payloads.
Explicit Auth Checks: The "use server" directive is an export, not a security guard. Implement explicit session validation inside every Action.
UUID v7 for Sessions: Abandon random UUID v4 for primary keys. Randomness forces B-Tree fragmentation. Use aUUID v7 Generator to ensure IDs are sequential and strictly time-sortable.

Conclusion: Stop Being the Breach

The death of localStorage is a prerequisite for a trusted digital presence. Security is not a configuration; it is code you either write or forget to write.

Harden your architecture, isolate your credentials in HttpOnly cookies, and build a presence that both humans and agents can trust.

P.S. If you want to audit your tokens locally without sending them to a server, you can use theFmtDev Developer Suite.

The 2026 Developer Manifesto: Mastering the AI-Native and RSC Stack

CallmeMiho — Fri, 17 Apr 2026 11:47:47 +0000

A few weeks ago, I shared how I built my 0ms latency developer workbench, FmtDev, using pure Next.js 15 SSG (without a single database query). But as I started building the next wave of tools for 2026, I realized the game has completely changed. We aren't just dealing with JSON and Base64 anymore; we are dealing with the intersection of Agentic LLMs and React Server Components. Here is my manifesto on surviving the new high-complexity stack.

The Great Architectural Shift of 2026

The era of simple Client-Side Rendering (CSR) and basic REST APIs is officially over. As we navigate 2026, the industry has converged on two massive, complex shifts: the rise of React Server Components (RSC) in the frontend and the integration of Agentic LLMs in the backend. For developers, this means the "simple" stack has become a high-complexity orchestration problem.

This is not a trend article. This is an engineering reckoning. The tools, patterns, and mental models that defined web development from 2020 to 2024 are now legacy. If your workflow does not account for RSC wire formats, deterministic AI outputs, and token-based cost economics, you are building on a foundation that is already depreciating.

Challenge 1: The Black Box of React Server Components

While RSCs offer unparalleled performance by moving rendering logic to the server, they introduce a new debugging nightmare: the wire format. The serialized payload sent from the server to the client — a stream of hexadecimal-prefixed rows containing $L lazy references, I import chunks, and E error boundaries — is no longer an opaque implementation detail. Understanding it is a non-negotiable requirement for performance tuning in production.

When an RSC hydration mismatch occurs or a payload looks bloated, you cannot just "check the network tab" and move on. The raw response is a dense, concatenated stream of React Flight protocol data. You need to parse it: decode the hex IDs, resolve the $L lazy references, trace emitModelChunk output back to specific component trees, and verify that sensitive server-only data is not leaking across the client boundary.

Using an RSC Payload Decoder is now a standard part of the debugging workflow. Paste the raw text/x-component response from DevTools, and the decoder will parse every row — imports, models, errors, hints — into a structured, color-coded view. This transforms a wall of serialized text into an inspectable tree, enabling you to answer critical questions: Which components are being lazy-loaded? Where is the Suspense boundary? Is my server leaking database records into the client payload?

The RSC Mental Model Shift

The key insight engineers must internalize is that RSC does not send HTML. It sends a lightweight, typed instruction stream that React's client-side runtime interprets to construct and update the DOM. This is fundamentally different from traditional Server-Side Rendering (SSR), which sends a fully-rendered HTML document. The RSC model allows for fine-grained partial updates — the server can stream a single component's updated data without the client losing any local state, scroll position, or focus.

Challenge 2: The Determinism Gap in AI Integration

As we move from "Chatbots" to "AI Agents," the biggest engineering hurdle is determinism. An agent is only useful if its output is predictable. If an LLM returns a conversational sentence when your code expects a valid JSON object conforming to a strict interface, the entire application pipeline crashes — silently, in production, at 3 AM.

This is where Structured Outputs become the backbone of AI engineering. We can no longer rely on "prompt engineering" alone; we must enforce strict JSON Schema constraints at the model inference layer. The contract between your application and the LLM must be as rigorous as a typed API contract.

Tools like the OpenAI Structured Output Generator allow developers to bridge the gap between natural language and strict programmatic interfaces. You define the shape of the data you need, the tool generates the response_format JSON Schema, and the model is constrained — not "asked nicely" — to produce conforming output.

To ensure these outputs are type-safe within a TypeScript ecosystem, developers are increasingly using the Zod Schema Generator to instantly convert raw JSON requirements into robust z.object() validation logic. The workflow becomes: define your types → generate the schema → enforce it on the model → validate the response. End-to-end type safety, from the LLM's inference layer to your database insert.

Challenge 3: The Economics of Intelligence

In 2026, Token Spend is a first-class engineering metric, right next to Latency and Memory Usage. With models like GPT-5.4 and Claude 4 pushing context windows to millions of tokens, an unoptimized prompt is not just a slow request — it is a massive financial liability.

Architects must now perform Prompt Cost Audits. This means calculating the input token count, the expected output token count, and the per-model pricing before a feature ships. Utilizing an LLM Prompt Cost Calculator is essential during the CI/CD phase to predict the operational expenditure of new agentic features before they hit production. If a prompt refactor reduces token count by 30%, that is not just an optimization — it is a direct reduction in your cloud bill.

Comparison: Legacy vs. 2026 Workflow

Feature	Legacy Workflow (2020–2024)	Modern Workflow (2026+)
Frontend Focus	Client-side State Management	RSC & Server-side Orchestration
Data Integrity	Manual Type Casting / `PropTypes`	Zod & Strict JSON Schema
AI Integration	String-based Prompting	Structured, Deterministic Outputs
Cost Management	Fixed Server / API Costs	Dynamic Token-based Economics
Debugging	Browser DevTools, `console.log`	RSC Payload Inspection & Schema Validation

Conclusion: Embracing the Complexity

The complexity of the 2026 stack is not a bug; it is a feature of a more powerful, more distributed web. By mastering RSC payloads, enforcing strict schema determinism, and managing the economics of LLMs, we move from being "coders" to being Systems Architects.

Build with precision. Audit with rigor. Ship with confidence.

FAQ: Navigating the New Stack

How do RSCs differ from traditional SSR?

Traditional SSR sends a fully-rendered HTML document. React Server Components send a specialized, serialized React Flight format that allows for fine-grained updates to the DOM without losing client-side state, making the transition between server and client seamless.

Why is JSON Schema important for LLMs?

LLMs are probabilistic. JSON Schema provides a mathematical constraint that forces the model to adhere to a specific structure, transforming a "suggestion" into a "contract" and eliminating malformed responses in production.

How do I prevent "Token Bloat" in my AI agents?

Token bloat occurs when unnecessary context is passed to the model. Use structured data (JSON, not prose), implement strict system prompt versioning, and use token-counting tools to monitor consumption patterns before they hit your billing alert thresholds.

CORS is Not a Security Feature: Mastering Access-Control Headers in 2026

CallmeMiho — Fri, 17 Apr 2026 11:46:48 +0000

A few weeks ago, I showed you how I built a 140-page, 0ms latency web-app without a single database query. But speed is useless if your API is leaking data due to a "CORS Panic" configuration. If you’re still copy-pasting headers from 2018 StackOverflow threads to fix console errors, you aren't fixing a bug—you’re opening a back door. Here is how you actually handle Access-Control in 2026.

If you are treating Cross-Origin Resource Sharing (CORS) as a firewall for your API, you are fundamentally misunderstanding the modern web's security model. Most developers view CORS as a barrier they have to "get past," usually by throwing wildcards at the problem until the red console errors stop.

Let’s be clear: CORS is an insecurity feature. By default, the browser’s Same-Origin Policy (SOP) blocks everything. CORS exists solely to relax those restrictions. If you configure it incorrectly, you aren't just "fixing a bug"; you are intentionally opening a door that was meant to stay locked.

1. The Fundamental Misconception: CORS vs. CSRF

A common mistake among even senior developers is conflating CORS with Cross-Site Request Forgery (CSRF) protection. Based on architectural standards, these two serve entirely different purposes.

Mechanism	Primary Goal	Implementation Level
CORS	Read Protection: Controls which origins can read the response of a request.	Browser-level enforcement of server-sent headers.
CSRF Protection	Write Protection: Prevents unauthorized actions (writes) from being performed on behalf of a user.	Application-level (Server-side) via tokens or custom headers.

The root of this confusion often lies in the "Confused Deputy" problem. Browsers automatically include cookies in requests to the same origin domain. An attacker on evil.com can trick a user's browser into sending a request to bank.com. Because the browser attaches the user's session cookies automatically, the server thinks the request is legitimate.

CSRF protection is about write protection; CORS is about read protection. If your API is strictly JSON-based, you have a natural defense: application/json triggers a CORS preflight. Since the attacker’s origin won't be allowed, the browser kills the request before the 'write' even happens. If you're still using standard form-enclosure types for sensitive actions, you're living in 2005. Move on.

2. The 'CORS Panic' and the Wildcard Disaster

When production deadlines loom and a frontend dev screams about a blocked request, the common reflex is to set Access-Control-Allow-Origin: *. In 2026, this is a catastrophic architectural failure.

The Credentials Restriction

Per MDN technical specifications, the wildcard * is strictly invalid when Access-Control-Allow-Credentials is set to true. The browser refuses to expose responses containing sensitive credentials (cookies or Authorization headers) to an anonymous global audience.

The Authorization Gotcha

Even if you aren't using credentials, there is a major technical trap in Access-Control-Allow-Headers. The Authorization header is a special case. According to MDN, it cannot be represented by a wildcard and always needs to be listed explicitly in the response.

Impact: The 'Reflecting Origin' Sin

As seen in the infamous Acronis HackerOne report #958459, the most dangerous "Senior" mistake is reflecting the Origin header. If your server reads the Origin from the request and echoes it back into Access-Control-Allow-Origin while setting Credentials: true, you have effectively neutralized the SOP.

A malicious site can now carry out privileged requests—retrieving user settings or payment data—because your server "authorized" the attacker's specific domain on the fly.

Whitelisting a wildcard prefix like `.yoursite.com` is better than reflecting the Origin header, but it's still lazy. It lacks the critical 'need-to-know' security control. If I see an API reflecting headers in production, I don't see a 'dynamic' solution; I see a complete surrender of the security boundary.*

3. Optimizing API Latency: Mastering the Preflight (OPTIONS)

CORS is often the "silent killer" of mobile performance because of the Preflight Request. This is an OPTIONS request automatically issued by the browser before any non-simple request (e.g., those with JSON payloads or custom headers).

Performance is a Feature:
Every preflight adds an extra round-trip of latency. To mitigate this, use the Access-Control-Max-Age header to cache the preflight response.

Listen carefully: The preflight cache is separate from the general HTTP cache. If you think your standard Cache-Control headers are handling your CORS latency, you're wrong. You're wasting user battery and server CPU on redundant OPTIONS handshakes.

4. Implementation Showdown: Next.js vs. Express vs. Nginx

Where you handle CORS logic defines your application's resilience.

Next.js (next.config.js): Ideal for edge-readiness. Handling headers at the framework level ensures they are applied before the request hits your heavy serverless functions.
Express Middleware: The highest risk for "silent failures." If your middleware order is wrong, or if an error handler strips headers during a 500-error, the browser will block the error response, leaving your frontend team debugging a "CORS error" instead of the actual backend crash.
Nginx: The superior choice for microservices. Offloading CORS to the reverse proxy prevents your application runtime from wasting cycles on OPTIONS requests and ensures a unified security policy across your entire cluster.

Architectural Best Practices:

Favor Infrastructure over Code: Move CORS handling to Nginx or your API Gateway.
Validate, Don't Guess: I got tired of the manual header math, so I built a visual CORS Configuration Builder that generates exact configurations for Next.js, Express, and Nginx. Stop guessing your headers. Use tools like the DevFormat YAML ↔ JSON Converter to validate your infrastructure-as-code manifests before deployment. A ghost space in a YAML config is not an excuse for a production outage.

5. The Next Frontier: Security Beyond the Header

Professional standards in 2026 demand a "Local-First" and "Privacy-First" approach. localStorage is a massive liability. It is accessible by any script on the page—meaning one XSS vulnerability leads to a total session takeover.

Mandatory Refresh Token Rotation:
In the frontend, refresh tokens have no client authentication; they are effectively bearer tokens. 2026 standards mandate Refresh Token Rotation. When a refresh token is used, the Security Token Service (STS) must issue a new pair. If an attacker steals a refresh token and tries to use it, the STS will detect the reuse and revoke the entire token chain.

The "Local-First" Mandate:
Why does this philosophy matter to an architect? Because sending your production secrets, JWTs, or SQL queries to a third-party "formatter" server is a breach of duty.

If I catch you pasting a production JWT into a SaaS decoder, we're having a performance review. 100% client-side processing is the only way to ensure your secrets don't end up in someone else's server logs.

Conclusion: Reclaiming Your Toolchain

Modern engineering requires moving away from the "copy-paste" security of the last decade and toward deterministic, architectural safeguards.

Stop guessing. Validate your headers, cache your preflights, and for heaven's sake, stop treating the browser like it's your only line of defense. Data should never leave the client unless you have explicitly, and securely, authorized it at the infrastructure level.

How I built a 140-page, 0ms latency web-app in Next.js 15 (Without a single database query)

CallmeMiho — Sun, 08 Mar 2026 04:50:48 +0000

Everyone seems to be obsessed with heavy Server Actions, complex ORMs, and edge databases right now. But I wanted to see how far I could push the absolute raw performance of Next.js 15 using only functional programming and pure Static Site Generation (SSG).

My goal was to build a massive suite of developer utilities (formatters, converters, regex testers) that loaded instantly and respected user privacy by never sending data to a backend.

Here is how I architected DevFormat to generate over 140 localized, high-performance routes without a single database call.

1. The Programmatic SEO "Factory" Pattern

Instead of writing 100 individual page components for things like "JSON to Go" or "cURL to Python", I built a centralized routing engine using the [locale]/[slug]/page.tsx convention.

I defined a strict TypeScript configuration map of target languages and regex patterns. At build time, generateStaticParams iterates over this map, cross-references my i18n locales (English and French), and statically pre-renders every single combination.

The result? The server does the heavy lifting once during the Vercel build, and the user gets a pure HTML/JS file delivered from the Edge CDN in under 50ms.

2. Offloading Compute to the Client (Privacy by Design)

The biggest issue with existing dev tools is data leakage. Pasting a production JWT or a proprietary JSON schema into a server-rendered tool is a massive security risk.

To solve this, I completely disabled SSR for the actual tool logic using next/dynamic with ssr: false.

All parsing—whether it's quicktype-core for generating Rust structs or crypto-js for SHA-256 hashing—runs strictly inside the browser memory.

The UX benefit: Zero network latency when a user clicks "Format".
The Security benefit: You can literally turn off your Wi-Fi, and the tools still work perfectly.

3. The "Suspense" Gotcha in Next 15

One massive headache I ran into was implementing analytics. In Next 15, reading useSearchParams() for my PostHog proxy caused the static build to throw a Missing Suspense with CSR Bailout error.

If you are building SSG pages in Next 15, you must wrap any component reading search params in a <Suspense> boundary, or the compiler panics and bails out of static generation.

The Final Result

The platform is live, totally free, and currently houses 25+ tools (from UUID v7 generation to Regex debugging).

If you want to poke around and test the 0ms routing speed, or if you just need a secure place to format some JSON without leaking your API keys, you can check it out here:

👉 fmtdev: The Local-Only Developer Workbench

(I highly recommend checking out the JSON to Rust Converter to see the client-side parsing in action).

I’d love to hear your thoughts on this architecture. Are you guys still leveraging heavy SSG, or has everyone moved to SSR/PPR for side projects?