Posts

What Is a Coding Harness? Agent = Model + Harness. The model is the reasoning engine. The harness is everything else — the guides that steer it before it acts, the sensors that catch it after it does. (Harness Engineering). In practice a coding harness has several moving parts: Context injection — what the agent knows before it writes a line. CLAUDE.md files, system prompts, project conventions. Codebase indexing — a queryable map of the repo. Symbols, call graphs, semantic embeddings. Tool layer — what the agent can do. Read files, run tests, call linters, search the index. Feedback loop — sensors that observe output quality. Type errors, failing tests, lint violations, architecture drift. Memory / sync — persistence across sessions. Hooks that re-index on session start, sync on file write. graph TD A[Developer Intent] --> B[Context InjectionCLAUDE.md · system prompt · conventions] B --> C[Model] C --> D[Tool Layerread · write · run tests · search index] D --> E[Codebase Indexsymbols · embeddings · call graph] E -->|semantic search results| C D --> F[Feedback Looptype errors · lint · test failures] F -->|sensor output| C C --> G[Output] G --> H[Memory / SyncPostToolUse hook · incremental re-index] H --> E The vocabulary here is not new. Russell & Norvig’s AI: A Modern Approach (1995) defined an agent as anything that perceives its environment through sensors and acts upon it through actuators. Chip Huyen applies this directly to modern LLM agents in Agents (2025): the model is the brain, tools are the actuators, observations are the sensors. Böckeler maps the same structure onto coding harnesses — guides are actuators (steer behavior forward), sensors are feedback mechanisms (observe what came out). ...

It’s 2026, and everyone is claiming to run parallel agents through one harness or another: Claude Code, Cursor, Aider, and whatnot. Still, I think we need to understand how these tools work underneath, and even use the same primitives ourselves in the old and boring way: manually. That was my experience with Git worktrees. I knew about them for more than 10 years, but only started using them seriously last year. ...

Kubernetes storage is one of those areas that looks simple from the outside — you create a PersistentVolumeClaim, a pod mounts it, done. But the moment you need to integrate your own storage backend, you’re staring at the Container Storage Interface spec, sidecar containers you’ve never heard of, and gRPC services that have to be wired together just right. I had the pleasure of writing and contributing to a production-grade CSI driver end-to-end. This post covers everything I wish I had in one place: what CSI actually is, how Kubernetes orchestrates it, and how to implement all three services in Go. ...

Go 1.25 just dropped with expected changes to GOMAXPROCS, which significantly change how Go applications behave in containerized environments. The runtime now automatically detects and respects container CPU limits when setting GOMAXPROCS. This isn’t just a minor improvement—it’s a shift that may dramatically improve performance for millions of containerized Go applications. And this isn’t the only amazing change, but this is the one I’ll focus on in this post. The Problem That Plagued Go for Years Before Go 1.25, there was a fundamental mismatch between Go’s runtime and containerized environments: ...