Posts

Everyone on the team writes code several times faster, but delivery cycles haven’t gotten any shorter. The surge of newly generated code simply overwhelmed the downstream review queue and integration pipeline. The bottleneck didn’t vanish; it moved from the text editor to code review and release verification. Coding Got Faster, Delivery Didn’t # AI has not made software delivery faster overall, and empirical industry data still fails to back that claim.

When writing automation scripts or working in the terminal, developers assume a simple rule: as long as git add <file> exits with code 0, the change is staged. Today, while updating author metadata on the blog, I hit an elusive silent failure: real file modifications on disk, git diff clearly printing the hunk, git add returning 0, yet git status stubbornly insisting the file was untracked, with git diff --cached remaining completely empty.

By the time I was maintaining the fifteenth or so skill in dev-skills, I realized I had no reliable way to tell whether any of them actually worked. Every demo produced clean output. But the output had no control group, no causal grounding — I knew what happened with the skill mounted, not what would have happened without it. How I Was Judging at the Start # The original method was simple: write a skill, load it into Claude Code, run a task, check whether the output looked right. The first version of grill passed this way — I fed it a service design with a concurrency bug, the agent flagged a lock contention issue, I marked it valid.

When designing runtime architectures for modern coding agents, the traditional single-step tool-calling loop hits a hard engineering ceiling. In multi-file refactoring and cross-module codebase exploration, discrete JSON RPC turn-taking leads to interactive round-trip explosions and runaway context bloating. It also fails to express asynchronous dependencies between tool invocations. To overcome this scheduling bottleneck, Pi Coding Agent’s CodeMode and DeepSeek Harness’s (CLI: dsh) Programmatic Tool Calling (PTC) mode represent two divergent code-execution paradigms.

In any enterprise tech team that claims to be “fully AI-powered,” the bill nobody wants to look at closely is usually not production inference — it’s the evaluation pipelines we run to deceive ourselves. Over the past three years, the biggest, most sacred, and least defensible totem in the enterprise stack has been the “private enterprise knowledge base” — first repackaged as RAG, then upgraded again as GraphRAG with a knowledge-graph label. Every architect, when drawing the final architecture diagram for the CTO, dutifully adds the last box: “Closed-loop evaluation and continuous alignment.”

An email popped up in my inbox today: “You can just build things, enjoy 6 months on us.” Sender: the Codex team at OpenAI. The first line, in big letters: “You’re in.” Then: “Thanks for maintaining open source projects.” I stared at that line three times and couldn’t help laughing out loud. Free ride: secured A while back I filled out their Codex for Open Source application on a whim. Didn’t expect much — I just listed the PRs I’d submitted to context-mode, plus my own byf and dev-skills.

The direct links below always point to the latest local build: Windows # Version Link x64 (user installer) https://api2.cursor.sh/updates/download/golden/win32-x64-user/cursor-local/latestWindows ARM64 https://api2.cursor.sh/updates/download/golden/win32-arm64-user/cursor-local/latestWindows macOS # Version Link Apple Silicon (M-series, recommended) https://api2.cursor.sh/updates/download/golden/darwin-arm64-user/cursor-local/latestMac Intel chips https://api2.cursor.sh/updates/download/golden/darwin-x64-user/cursor-local/latestMac Universal https://api2.cursor.sh/updates/download/golden/darwin-universal-user/cursor-local/latestMac Linux (Ubuntu/Debian) # Version Link x64 AppImage https://api2.cursor.sh/updates/download/golden/linux-x64-user/cursor-local/latestLinux ARM64 AppImage https://api2.cursor.sh/updates/download/golden/linux-arm64-user/cursor-local/latestLinux

Conclusion first: the value of multi-agent doesn’t come from more models; it comes from the right structure. Multi-agent without structure is just more expensive concurrency — burn 2 to 3 times the tokens to watch a group of models nod at each other. Multi-agent with structure is an execution system that can delegate, parallelize, and verify. Why a Single Agent Fails at Long Tasks # Diagnosis first. A single agent executing complex tasks has five structural defects — blame the execution structure, not the model’s intelligence:

Let me start with something that actually happened. In early 2025, I added a feature to an internal system: export to Excel. Small requirement — I didn’t even write it up, just typed “add an export button to the list page” into the chat box. The AI delivered in ten minutes. Frontend changes, new endpoint, SQL — all in one pass. I was pleased when I opened the PR, right up until review revealed: the export columns didn’t match the list page, a hundred thousand rows would hang the service outright, there was no permission check, and the tests only covered the happy path.

The conclusion first, so you don’t waste your read We used to split teams by craft: frontend, backend, product design. Now we split teams by stage: Prototyper — grabs the first idea and fails fast Builder — turns the prototype into a product you can take to market Maintainer — holds the fort once the software reaches scale Scaler — takes a proven product and scales it 10x, 100x Finisher — polishes the product and the code, sands off the burrs As for why we’re only splitting this way now — the answer involves AI. Read on.