Development¶

Multi-agent engineering with Claude Code: the dev loop, demonstrated

The previous post walked through a single Claude Code session — one engineer, one context window, 14 turns. That's the right shape for most work. But some tasks don't fit in one brain. A migration across 12 services, a security audit of 200 endpoints, a refactor that touches every file in the repo — these want a small team, not one engineer working 14-hour days.

Claude Code has a Task tool that spawns sub-agents with isolated context windows. The main session is the lead engineer; sub-agents are specialists. Each specialist runs to completion, returns a summary, and the lead stitches the work together. That's the multi-agent loop, in Claude Code.

This post is a full session that uses it. I'll do a real task — port a Python CLI from one config library to another across 8 files — by having Claude Code delegate parts to sub-agents. You'll see the prompts, the sub-agent invocations, where handoffs went well, and where they didn't.

The session is reconstructed from real Claude Code runs. The patterns work; the exact transcripts are illustrative.

The full Claude Code dev loop, demonstrated end-to-end

Most posts about Claude Code show a single claude command and a single impressive output. That's not how you actually use it. A real session is 30+ turns: plan, write, run, fail, read the error, fix, test, commit, repeat. The interesting parts are the failures and the recovery.

This post is one full session, reconstructed from real Claude Code sessions. Every command is one you'd actually run, every code block is code you'd actually see, every bug is the kind of bug that does appear. The wall time and the exact bug-discovery sequence are approximate — the patterns are real.

The session took 14 minutes of wall time. The transcript below is annotated.

The backend-for-frontend pattern for AI apps: thin client, fat API, one job

Most AI apps in 2026 still ship as "browser → OpenAI" with an API key in the frontend bundle. This is broken in every dimension that matters: security, cost, observability, provider lock-in, and rate limiting. The fix is a Backend-for-Frontend (BFF) — a thin server between the browser and the LLM provider that owns auth, cost, streaming, and provider abstraction. The browser does UI. The BFF does everything else.

This is the pattern every serious AI product has converged on by 2026. Here's what it looks like, why each piece exists, and how to build it without over-engineering.

Streaming responses in 2026: SSE vs WebSockets vs gRPC for AI apps

Every AI app needs to stream. Most teams pick the wrong transport and spend a week debugging why the first token takes 8 seconds. The LLM is fast — the network in front of it isn't. This post compares the three transports that actually work in production (SSE, WebSockets, gRPC streaming), shows the buffering traps that kill streaming, and gives you the decision framework to pick the right one in 30 seconds.

If you've ever shipped a "ChatGPT-style" streaming endpoint and watched it work in dev, then break in staging behind nginx, this is the post for you.