AI Technology

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.

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.”

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:

Thoughts on Dynamic Intervention in AI Agent Runtimes # A few weeks ago, late at night, I stared at the agent logs scrolling through my terminal, frustrated enough to want to smash the keyboard. It was dutifully generating a requirements analysis report — it had been running for a dozen-plus minutes, pulling loads of data and drawing charts, clearly on the verge of wrapping up — when I suddenly realized the requirements were missing a key dimension: “Don’t split by region, split by user age group.” If I interrupted it now, all the context, intermediate results, and tool call state would be thrown away and it would start over. If I didn’t, it would soon produce a wrong report that would cost me just as long to fix by hand.

Conclusion first: plenty of tools out there can be installed, but most of them sit there gathering dust after installation. Below is what I filtered out of the things I actually use, sorted into five scenario categories, with a few genuinely used picks in each. First, One All-Rounder Recommendation # If you want a single install that covers most scenarios, take a look at this one:

Attachment download: Agent Interview Questions.pdf — handy for printing or offline reading Why Would You Need Multiple Agents # An opening question to separate people who have “read the articles” from people who have “actually built one”. The bad answer: “Multi-agent enables parallel processing, which improves system throughput and robustness.” Every word of that is correct, but if you follow up with “so after splitting into two agents, did throughput actually double?”, they stall. The reality: inter-agent communication has overhead, coordination has complexity, and after the split total throughput may well drop. Adding agents is not like adding CPU cores.

A 67 MB DMG installer, 164 MB unpacked, hiding Anthropic’s Claude Science (internal codename Operon). After reverse engineering it, I found 54 SQLite tables, a 9-layer security model, 30+ bioinformatics skills, and a complete AI agent platform for computational biology. On the other side is TCMSP, an AI-native Traditional Chinese Medicine systems pharmacology platform under active development. Looking at the two projects side by side, some design ideas are worth cross-referencing.

Why AI Agents Need a Memory System # If you’ve spent serious time with AI agents, these scenarios will feel familiar: Re-explaining the project background, coding conventions, and output format preferences in every new session Halfway through a long task, the context fills up with tool logs and the agent starts “forgetting” earlier instructions Wanting the agent to learn your working habits, but having no way to do it except hand-writing a system prompt every time Memory isn’t about making the AI store everything — it’s about making sure humans never have to repeat themselves. That’s the core idea behind TencentDB Agent Memory.