From June 23 to 24, 2026, Volcano Engine held its FORCE conference. In previous years, this kind of industry conference was usually dominated by multimodality, large-model call volume, and the MaaS business. This time, however, Volcano devoted a large share of the agenda to AI coding. The Economic Observer used a fitting headline in its coverage: ByteDance is filling in its AI coding gap.
At the conference, ByteDance released Doubao 2.1 Pro, with a focus on stronger coding and agent capabilities. The original TRAE SOLO was also upgraded into TRAE Work, split into two modes: Work for everyday office work, and Code for software development.
For developers and engineering managers, though, the real signal from this conference was not the product-name change. It was the internal engineering data ByteDance made public.
Hong Dingkun, ByteDance’s vice president of technology and head of the TRAE business, said that over the past year, the share of code produced by AI inside ByteDance increased sixfold, and the TRAE team exceeded 90%. TRAE’s average daily Token consumption reached 5.6 trillion, 50 times higher than a year earlier. Volcano Engine president Tan Dai gave the broader context: as of June this year, the Doubao large model’s average daily Token call volume had exceeded 180 trillion. China Entrepreneur recorded this set of numbers and noted that Volcano had taken close to half of China’s domestic MaaS market.
This creates a contrast: AI can write code more than 10 times faster than humans, and more than 90% of the TRAE team’s code comes from AI. Does that mean the team’s engineering efficiency also multiplied several times?
The answer is no. Hong Dingkun’s number was that per-capita requirement throughput increased by about 60%.
This data point matters because it gives both the input side and the output side. The input side is how much code AI wrote. The output side is how many requirements the team ultimately delivered. Once both sides are measured, the loss in the middle becomes visible: code generation volume grew extremely fast, but real delivery did not grow at the same rate.
Hong Dingkun gave several concrete examples at the conference. An engineer might only want to change one parameter, but AI copies out and rewrites a large block of related logic, leaving redundant code behind. AI can generate a piece of code quickly, but putting it back into the existing architecture, aligning interfaces, integrating it, and testing it still leaves a long distance to cover. There is also a more typical organizational problem: inside ByteDance, some product managers used AI to build feature-complete pages and hoped to ship them directly, but the engineering team stopped them because the code needed refactoring for extensibility, security, and performance.
These problems point to the same bottleneck: AI has made code generation cheaper, but the downstream process of turning code into shippable software has not become cheaper at the same pace.
Remio relayed another set of experimental data in its reporting. According to Remio, ByteDance ran more than 900 tests. Mainstream models could achieve code correctness above 80%, but without surrounding tool support, code deliverability was only around 40 to 60 points. After adding a harness, meaning validation and support tools such as testing, dependency checks, and staging, deliverability could rise to around 80 points. For now, this set of numbers mainly comes from media reporting. We have not yet seen an official white paper or full transcript, so attribution should be handled cautiously. But it points in the same direction as the fact that a 90% AI code share only translated into a 60% throughput gain.
What the FORCE conference really exposed was not whether ByteDance is building AI coding tools, nor how TRAE Work is positioned. It looked more like a pressure test after large-scale practice: in the AI era, the act of writing code is becoming extremely fast, but the bottleneck in software engineering is moving downstream.
A 60% increase in per-capita requirement throughput would be a major gain for any mature engineering team. So this data should not be read as a failure of AI coding. What it really shows is something else: code generation speed and software delivery speed have become visibly disconnected.
You can think of AI-written code as semi-finished goods in a factory. When AI keeps producing code like an assembly line, downstream steps such as review, compilation, test execution, dependency management, deployment to staging environments, and security audits do not automatically accelerate. New code queues up in front of these checkpoints and turns into inventory. It has been produced, but it does not yet count as delivered.
Software engineering has seen a similar bottleneck shift before.
Around 2010, agile development became more widespread. The frequency with which teams wrote code and submitted changes compressed from once every few months to once every few weeks, days, or even less. But for many teams at the time, merging code into main, testing it, and deploying it to servers still depended on manual compilation, manually run tests, email-based operations scheduling, and handoffs to infrastructure teams. Development finished the change, but integration and deployment became a nightmare. The same pattern appears repeatedly in security: the real problem is often not the code snippet itself, but deployment, permissions, and environment boundaries. In earlier analysis of vibe coding leak cases, the same structure appeared: the issue was not whether the code could run, but whether the deployment layer blocked the risk.
DevOps did not emerge because everyone suddenly developed a taste for CI/CD or YAML. It was forced into existence by high-frequency change. Once deployment frequency increased, the old delivery process could no longer keep up, and the industry had to automate testing, integration, and release. The point of a CI/CD pipeline is to let high-frequency changes enter production reliably and safely.
AI coding today is in a similar position. The difference is that this time, the part that suddenly became faster is not deployment, but code generation farther upstream. Token costs have fallen, model capabilities have improved, and code generation has become a low-cost supply. But downstream review, testing, dependency management, staging, architectural constraints, and security audits have not automatically become cheaper.
This explains why a 90% AI code share only turns into a 60% throughput increase. Code generation has become faster, but teams still lack a delivery pipeline that can match that speed. The role of the harness here is similar to the role CI/CD played back then: automatically run tests, check dependencies, enforce architectural constraints, spin up staging, and send high-frequency generated code through a repeatable validation process.
In other words, harness is the CI/CD of the AI code era.
When discussing harness engineering, we usually look at several dimensions: how long a single agent can run, how multiple agents run in parallel, and how humans interact with agents. Volcano’s data adds another dimension: the team’s absorption bandwidth for AI code.
Tokens can be bought with money, and the throughput of AI-generated code can be scaled with compute. But a team’s ability to absorb that code does not automatically double. When a product manager uses AI to finish a page, engineers still need to check how network requests are sent, whether components can be reused, whether there is any privilege-escalation risk, and whether performance will drag down the page. AI amplifies code production, but review, architecture governance, and integration validation remain scarce.