QCon 2026: When AI Became the Developer, Not Just the Assistant

Late Wednesday night, I saw a WeChat post that made me stop scrolling.

Huang Dongxu, CTO of TiDB, casually mentioned he’d consumed “tens of billions of tokens” over the past few months working with AI employee systems. The attached screenshot showed a terminal with a counter still climbing. My first instinct was to calculate the API bill. My second was: what does that actually look like in practice?

The answer came from QCon 2026 Beijing, held April 16-18. Over 2000 developers showed up, and the dominant theme wasn’t subtle—AI is structurally rewriting how software gets built.

This Isn’t Incremental. This Is Structural.

Huang’s talk was titled “The Rise of AI Employee.” The key data point he shared: at TiDB, AI code generation tools now cover more than 78% of daily active developers, and about 35% of all code commits are directly AI-generated, then human-reviewed. Not suggestions. Commits.

That’s a fundamentally different workflow. It means the starting point has shifted—from “I need to write a function” to “I need to tell the AI what kind of function I want, and in what context.”

OpenClaw was the other name that kept coming up. Teams are now using it to run the entire development cycle, from requirement analysis to deployed code. One live demo at the conference showed a PRD going from document to deployed code in under two hours.

So What Exactly Is a Programmer For Now?

The most memorable comment under Huang’s WeChat post was blunt: “So what’s the point of programmers anymore?”

Honestly, I’ve asked myself the same thing. But the vibe at QCon was weirdly calming—actual engineers weren’t panicking. Why? Because they’ve discovered that AI handles the standardized parts well—CRUD, unit tests, simple bug fixes—but stumbles badly on architecture decisions, cross-system tradeoffs, and negotiating requirements with product managers.

Huang himself was candid: “AI writes fast, but the quality is uneven, and sometimes it introduces subtle bugs that are really hard to catch.” His prescription: every team needs at least one person who actually understands the code deeply enough to review AI output quickly. That’s not a “code writer” anymore—that’s more like an “AI code quality gatekeeper.”

This reminds me of every tool revolution in programming history. Assembly replaced hand-coded machine instructions. C replaced assembly. High-level languages replaced C. Every single time, people said programming was dying. Every single time, the profession got bigger. The difference is the layer of abstraction you need to work at.

Same thing now. AI writes code. But you still need to know what problem you’re solving, what that problem looks like in the context of your system, and why this approach beats alternatives. That’s not going away anytime soon.

The Real Hidden Signal from the Exhibition Floor

One corner of the exhibition floor was consistently packed—companies building code search and code understanding tools. Their core pitch was basically: when your codebase gets large, how do you get AI to actually understand your code structure instead of just pattern-matching?

This is the unglamorous bottleneck nobody talks about. Everyone’s racing on “generation,” but “understanding existing codebases” is way harder than it looks. I talked to a few engineers on the floor—AI is great for new code, painful for maintaining old code. Legacy systems have this fun property where nobody remembers why certain decisions were made, and AI really, really struggles with that.

We’re still in phase one of this transformation: efficiency gains in generation. The real frontier is getting AI to understand context deeply enough to modify old code as well as it writes new code. That’s still a hard unsolved problem.

One thing’s for certain though: programmers who learn to work with AI are going to replace programmers who don’t. That trend is clearer than any benchmark score.