Technical Practice

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.