Tencent's QQ Speed engineering team burns roughly 30 billion model tokens a month, and the speaker's agent concurrency moved from about five workspaces in March to 10 to 20 by July and August, according to an edited InfoQ transcript of a talk by Ren Leida, a Tencent senior backend engineer and agent implementation lead for the QQ Speed project team.
"Are we trying to build an agent, or to use one well?" Leida asked at AICon 2026 in Shenzhen, and the answer shaped the team's practice: prompting fixes one problem at a time, while writing a loop asks the agent to spot the same class of problem on its own next time, so the same mistake is made only once. The team frames the payoff as it frames autonomous driving: a loop takes repetitive cognitive load off the engineer and raises output quality, which is why ROI, not token consumption, became the metric optimised.
The practice evolved in stages. The team discussed harness engineering in March, when concurrency was roughly five workspaces; it encountered the term "loop engineering" in June; by July and August concurrency had reached 10 to 20 workspaces, gained by making the work structure clear enough to trust rather than by adding models. Before that the project moved from SVN to Git, because SVN's treatment of agent input and output left no stage for human participation.
On Git, a feature-branch push creates a merge request through a CI hook, parallel lint and review pipelines run, and a failing lint stage hands its diagnostics back to the agent, which repairs and re-triggers the pipeline until it turns green. The team also built an LLM-based custom linter, first for log formatting, that checks the incremental file diff after each agent edit, returns diagnostics for self-repair, and runs again as a git pre-commit hook with a stricter variant at commit time. Rule-based auto-approval covers a narrow set of cases, review comments trigger further agent loops through a comment hook, and a scheduled loop clears stale issues and merge conflicts.
The workflow is split into preparation, execution and post-hoc review, with review findings written back into the team's skills, rules and memory, which shows up as falling MR comment counts, a falling share of repeated comments, and shorter clarification time before work starts. Within a requirement the team separates checking from doing, so agents write the test strategy rather than their own tests, keeping verification risk-driven. Context for one requirement grew to 200k tokens and stopped fitting, so the team rebuilt it as a skill entry point with second- and third-level routing, bringing it from roughly 600k tokens down to about 100k.
Adding a sub-agent fork to every skill backfired as well: hallucinated recursive forks burned 500 million to a billion tokens on some days without shipping anything, and a simple data-conversion request grew into 40,000 lines of code, 200 review comments and 27 rounds of review before being closed. Leida's conclusion is to decide in advance whether a loop is bounded or open, since a bounded loop lifts ROI sharply; for next steps he points to structured loop implementations such as OpenClaw and Hermes, and to a scheduled task that reviews the day's agent logs and fixes repeated mistakes.