@xiaogaifun: ByteDance's reflections on AI Coding in big companies are so real. I watched the sharing by Hong Dingkun, ByteDance's VP of Technology, several times and found it very inspiring. ByteDance's practices in AI Coding are quite representative; I recommend all R&D peers to take a look. You'll probably relate. After watching, I filled a whole page with notes, and...

ByteDance's reflections on AI Coding in big companies are so real. I watched the sharing by ByteDance's VP of Technology Hong Dingkun several times and found it very inspiring. ByteDance's practices in AI Coding are quite representative; I recommend all R&D colleagues to take a look. You'll probably relate. After watching, I filled a whole page with notes, and I'm sharing them with everyone. I even think this sharing can be understood as some true reflections from ByteDance on AI Coding. Based on my understanding, I'll expand on a few insights from the sharing that inspired me. I'll mix in a lot of my own thoughts. If you want the original text, you can look up the full speech. Reflection 1: AI code contribution rate should not be a KPI AI Coding has gradually entered the production workflows of many companies. Many people claim that 90% of their business code is AI-generated, which sounds shocking at first. But in reality, the efficiency improvement from AI for R&D is not as high as outsiders imagine. Hong Dingkun cited the example of the TRAE team. TRAE itself builds AI tools, so this team is very aggressive in adopting AI Coding. Over the past six months, 94% of their code was contributed by AI. However, per-capita request throughput only increased by 60%, i.e., 1.6 times the previous level. This raises a question: AI writes code at least 10 times faster than humans. If over 90% of the code is AI-generated, shouldn't efficiency improve by at least 5 or 10 times? Why only 1.6 times? ByteDance's conclusion is that a single metric, like AI code percentage, simply cannot represent true productivity. If AI code contribution rate is used as a KPI, everyone will optimize for AI generation volume rather than delivery capability. It looks like a lot of AI is being used, but system efficiency doesn't truly improve. So why does 90% AI code only lead to a 1.6x improvement in human efficiency? An important reason is that writing code is just one part of the entire R&D workflow. Before writing, you need to understand requirements and write specs; after writing, you need to verify functionality and submit for release. If these other steps remain traditional, simply accelerating code writing won't boost overall efficiency much. Hong Dingkun described ByteDance's attempt in this area as systematic AI Development. The core idea is that AI shouldn't just handle code writing—it needs to be integrated into more stages of the R&D process, with the entire chain running smoothly, for efficiency to truly improve. I was actually debating this with someone recently. Many companies still track how many tokens employees use. In other words, they're tracking the process. What should be focused on is whether delivery has become faster and more reliable from an outcome perspective after using the tool. If a team boasts about using AI tools proficiently and consuming a lot of tokens but has little effective output, is that good or bad? I think this is a new question worth thinking about for every manager. Reflection 2: Functional correctness ≠ Engineering readiness The ideal state of Vibe Coding is like chatting—expressing your needs in natural language and eventually producing the desired product. If something is wrong, you communicate with AI in natural language to make changes. This has been the popular approach over the past year. For less complex applications, this approach works perfectly. Some of my own projects have followed this flow. But for production-grade software, regardless of company size, the process is definitely not like this. Because companies inevitably have legacy code and a set of constraints. How to reuse existing components, handle security and permissions, ensure performance, compatibility, and maintainability. Anyone who has seriously written engineering code knows that the state described by Vibe Coding is quite idealistic, better suited for small projects and validating ideas. Real programmers may also be Vibe Coding, but the flow is different from the ideal state. ByteDance did an internal experiment to test this: three models, three agent frameworks, combined into nine schemes. For the same requirement, each group ran 100 times, totaling 900 runs. The result: AI performed reasonably well on functional correctness—all combinations exceeded 80%, meaning AI's ability to write correct functionality has passed the passing line. But regardless of the combination, the engineering quality of the generated code was poor. For example, UI mismatches, no component reuse, performance issues, structure not following standards. These problems are likely familiar to anyone using AI to write code. All the Coding models now on the table have passed the critical threshold of Opus 4.6, meaning models can write code autonomously. At this point, the success of AI Coding is definitely not determined by the bare model alone, but by the bare model plus the Harness capability. This judgment itself isn't new. But what struck me most was ByteDance's understanding of Harness. They reflected that the industry still seems to equate Harness with agent frameworks, such as single agent vs. multi-agent, which roles are included, and how they collaborate. These are important, but ByteDance found in practice that what really determines whether AI Coding can land is actually more fundamental and engineering-oriented. Hong Dingkun called it infrastructure. For example, whether context engineering is done well, whether architectural constraints are clear enough, whether team knowledge can be effectively accumulated, and whether past technical debt has been sorted out. These less glamorous tasks directly impact the effectiveness of AI Coding. Experimental data also confirmed this. With the same model and framework combinations, after incorporating this infrastructure, functional correctness directly improved from 80% to nearly 90%, and engineering quality scores rose from a failing level of 40-60 to around 80 points. If infrastructure is not well built, the potential consequence is that Vibe Coding feels faster, but overall it may actually be slower. Engineering debt will eventually have to be repaid. Reflection 3: After the coding bar lowers, how does the team collaborate? One example from Hong Dingkun's sharing left a deep impression on me. A product manager had a requirement but found it would have to wait for R&D scheduling. So he said, "I'll do it myself," and used AI to quickly implement the feature. Indeed, the feature was not complex. After finishing, the product manager gave the code to R&D and said, "I've written the code; now you just need to help get it online." R&D looked at it and said, "No. Your code runs, but it doesn't meet online standards. There are permission issues and security problems." The product manager felt aggrieved: you don't have time to work on this requirement, and now that I've done it, you won't let it go live. But what R&D saw was code quality issues. So here's something everyone needs to face: although the bar for generating code has lowered, the complexity of the system hasn't. In real business systems, code must be placed into existing architectures, cooperate with existing modules, and consider various issues. It's definitely not something anyone can write and immediately put online. Otherwise, problems will surely occur. How to enable people in different roles to use the same set of tools and standards to produce compliant code is something that needs to be addressed going forward. ByteDance's approach is to toolify this internally. For example, productizing internal practices directly into TRAE and making them available to everyone. In short, it's about toolification. I saw many big names sharing this article on WeChat Moments; it seems to resonate broadly. I feel this sharing is somewhat of a correction, because over the past period there have been many outrageous statements—some people wildly boast about how many tokens they've used, thinking that makes them AI Native... I strongly recommend everyone read the original article. It's on ByteDance's official WeChat account.