Tencent QQ Speed Team Shares Loop Engineering Practices in Agentic R&D Transformation

This talk started from a very concrete confusion. Ren Leida said that when harness engineering first came up in March, the concept sounded very abstract to him, and at the time he understood it as having two possible goals: maximize concurrency during working hours, so five to ten agents can be operated simultaneously; and let agents keep working outside working hours. He says he consumed roughly 30 billion tokens in the past month, and at that scale it is mainly the increase in concurrency during working hours that is having an effect—the out-of-hours part has not really looped yet and needs further exploration.

From this he draws the dividing line between loop and prompt: a prompt agent focuses more on solving a specific problem, such as asking the agent to streamline a piece of code; whereas writing loop requires the agent to proactively discover and raise problems—why didn't you notice this code is too long, next time you should proactively discover it. In this way experience is sedimented into the loop through iteration, pursuing the goal that the same problem is only ever made once.

It should be noted that the above token consumption scale and concurrency goals all come from the speaker's own account, sourced from a single conference talk, and lack first-party data corroboration. The shared content is a talk transcript, edited and organized by InfoQ without changing the original meaning, and is not independently verified by a third party.

From an engineering practice perspective, Ren Leida divides the loop into four layers: the first layer is hook level, the second is CI level, and these two layers resemble the three-layer division proposed by Andrew Ng; the third layer is structured decomposition of work structure; the fourth layer is organizational team efficiency. He emphasizes that if it is merely meaningless, thoughtless, experience-less repetition, it cannot bring value, so in his definition loop is an iteration.

He also draws boundaries around this framework. He mentions that the agents and skills the team uses have already reached the level of over a hundred, and at this scale, if you want to loop these things and think about the effect of evaluation in real R&D scenarios, it is very difficult to put additional things in order.

The fourth layer is explicitly marked by him as uncertain: he believes that an individual loop being deployed by other team members is just copying practice, not an engineering product, and that team efficiency improvement needs more graph engineering orchestration, and he says this topic is very new and what he says may not be right.