TRAE Writes 90% of Its Code With AI. ByteDance's VP Revealed Why That's a Problem

When ByteDance's VP of Technology Hong Dingkun took the stage at the Volcano Engine FORCE Conference in late June, he disclosed a number that most AI vendors would have buried. ByteDance's TRAE team now generates more than 90% of its code with AI. Per-capita throughput improved by 60%.

Read those two figures together and the story inverts. Ten times the AI-written code. Roughly half a unit of additional output per engineer. The gap between them is the most honest description of the enterprise AI coding market in 2026 — and almost nobody selling into that market wants to talk about it.

This is not a contrarian take on whether AI coding works. It does. The question that actually matters for any company spending real money on this transition is narrower and harder: when the code volume goes up tenfold and the delivered output barely moves, where did the value go? The answer determines whether an AI investment compounds or quietly becomes a liability.

The Measurement That Everyone Is Getting Wrong

The instinct in most organizations is to measure AI adoption by the things that are easy to count: lines of code generated, percentage of commits AI-assisted, tokens consumed, and seats deployed. These numbers are satisfying to put in a board deck and almost entirely disconnected from whether work is getting done faster.

The most rigorous evidence on this point comes from METR, a research nonprofit that ran a randomized controlled trial — the same methodology used in drug trials — on experienced open-source developers working in repositories they knew intimately. The developers predicted AI would make them roughly 24% faster. After the study, they believed they had been about 20% faster. When developers were allowed to use AI tools, they actually took 19% longer to complete their tasks.

The striking part is not the slowdown itself, which is sensitive to context. It is the 39-point gap between perceived and actual productivity. The people doing the work could not tell that the tool was slowing them down. They were confident it was helping.

Developer AI tool adoption reached 84% in 2025 even as positive sentiment fell from 70% to 60% and trust in output accuracy dropped from 43% to 33%. An industry is scaling its dependence on a class of tools it increasingly distrusts, guided by a productivity signal that the most careful available study suggests is unreliable.

For a CTO, this is the first uncomfortable implication: if your engineers feel dramatically more productive, that feeling is not evidence. It may be the opposite of evidence.

Correctness Is Not Deliverability

ByteDance's second disclosure cut closer to the mechanism. The TRAE team ran the same requirement through three mainstream coding models paired with three frameworks, 900 times. Functional correctness consistently cleared 80%.

But when they scored the output on maintainability, performance, and compatibility — the dimensions that decide whether code can actually ship — the scores roughly halved.

This is the distinction that gets lost in every demo. “It runs” and “it can go to production” are different claims separated by an enormous amount of unglamorous work. A model that produces functionally correct code 80% of the time is genuinely impressive and still nowhere near deployable in a system with real quality standards.

The longitudinal data backs this up. A large-scale empirical study of AI-generated code published on arXiv tracked what happens after AI-written code is merged, not just whether it passes initial review. The cumulative number of surviving AI-introduced issues continued to rise over time, exceeding 100,000 by February 2026 and accumulating into a substantial maintenance burden.

A separate 2026 study of 700 engineering practitioners by Harness found that 69% of teams using AI coding tools frequently face deployment problems involving AI-generated code.

The pattern is consistent across independent sources: AI lowers the marginal cost of producing code while doing little to guarantee its integration, architecture, or long-term maintainability. The speed you feel at the moment of generation is borrowed against a maintenance bill that arrives later, on someone else's sprint.

What ByteDance Did About It, and Why It Matters

Here is the part of Hong's talk that should interest any operator more than the headline numbers. After identifying the gap, the TRAE team added what they called a “Harness” — context engineering, architectural constraints, and the consolidation of team knowledge into something the AI could actually use.

Deliverability scores moved from the 40–50 range to 80.

The model did not change. The infrastructure around it did. And that single intervention is where the real productivity lived all along.

This reframes the entire conversation. The bottleneck for enterprise AI coding was never the model's raw capability. It was whether the organization had built the surrounding system — the context, the constraints, and the accumulated knowledge — that lets a capable model produce something deployable.

Most companies skip this step entirely. They deploy the tool, watch the code volume spike, and conclude that AI works because the dashboard is green. The deliverability gap shows up two quarters later as technical debt nobody can trace.

The Same Story, Written Across the Whole Enterprise

What is true of code is true of AI deployment generally, and the macro data is brutal. MIT's NANDA initiative, in its widely cited study of enterprise generative AI, found that about 5% of AI pilot programs achieve rapid revenue acceleration while the vast majority stall, delivering little to no measurable impact on the P&L.

The researchers were explicit about the cause. The core issue is not the quality of the AI models, but the learning gap for both tools and organizations. Generic tools stall in enterprise use because they do not learn from or adapt to specific workflows.

The financial reckoning is already underway. By mid-2026, reporting described a wave of enterprise “AI sticker shock” as token bills ballooned without corresponding returns. Microsoft reportedly canceled most of its Claude Code licenses partly over cost, and one company reportedly spent $500 million in a single month after failing to cap usage.

When public companies' productivity claims are traced to their own financial filings, the gap reappears. JPMorgan Chase claimed roughly 10% developer productivity savings while actual 2025 compensation expense grew approximately 6% and headcount rose. Morgan Stanley reported around 20% productivity improvement while compensation expense grew 12%.

The productivity exists in the press release. It has not yet shown up in the income statement.

But the most important number in the MIT data is the one that points to a solution rather than a problem. External partnerships achieve 66% deployment success compared to just 33% for internally developed tools.

Across the research, the consistent finding is that roughly 80% of the work required to move from pilot to production is data engineering, governance, workflow integration, and measurement infrastructure — not model selection.

What Actually Compounds

Put the evidence in one place and the conclusion is hard to avoid. The companies pulling ahead are not the ones with access to the best model. By 2026, frontier model access is close to a commodity.

They are the ones who built the layer underneath: the context engineering that lets a model understand how their organization actually works, the architectural constraints that keep generated code shippable, the governance that makes output auditable, and the measurement that proves whether any of it is working.

This is unglamorous infrastructure. It does not fit on a launch slide. It is exactly the work ByteDance's Harness represents, exactly the work the successful 5% in MIT's data invested in, and exactly the work most enterprises skip in the rush to report adoption metrics.

The 90/60 problem is not an argument against AI in software. It is an argument against treating AI as something you install rather than something you design around.

The organizations that internalize this in 2026 will quietly own the productivity gains that everyone else is still measuring in tokens.

The gap between 90% and 60% is not a failure of the technology. It is the precise size of the engineering and organizational work that still has to be done — and the precise location of the value for anyone willing to do it.

The data referenced in this piece draws on disclosures from ByteDance's Volcano Engine FORCE Conference (June 2026), METR's randomized controlled trial on developer productivity, MIT's NANDA initiative report on enterprise generative AI, the Harness 2026 engineering practitioner survey, and longitudinal studies of AI-generated code published on arXiv.