AI Coding Is Not Enough

I recently re-read MotherDuck’s Perf Is Not Enough, and one idea stayed with me: engineers are very good at optimizing the part of a system that is easiest to measure.

In databases, we obsess over query latency. But users do not really care about query → result. What they care about is question → answer.

I think AI coding is falling into the same trap.

Today, AI can read a large codebase, implement a feature, write tests, create commits, and open a pull request. A task that once took days may now take hours.

That is impressive.

But if coding became 10x faster, why doesn’t software delivery feel 10x faster?

Because coding was never the whole system.

A real software pipeline looks more like this:

Customer signal → Strategic decision → Product definition → Code → Review → Test → Release → Production → Support → Feedback

AI is making one stage dramatically faster. Every distributed systems engineer knows what happens when you optimize one stage of a pipeline without fixing the rest: you usually just move the queue somewhere else.

If coding becomes 10x faster but review and testing stay the same, congratulations—we increased QPS on the producer and forgot to scale the consumer.

Before Coding, Someone Has to Decide What to Build

This may be the most important part.

Before asking AI to implement a feature, someone must decide that the feature is worth building at all.

Of course, we can ask AI to research the market, summarize competitors, analyze support tickets, and generate a beautiful roadmap with five strategic themes and perhaps a 2×2 matrix.

I still would not run TiDB’s product strategy that way.

For infrastructure software, deciding what to build requires spending time with customers, understanding how their businesses are changing, seeing patterns across industries, and distinguishing between a one-off request and the beginning of a major trend.

Sometimes we deliberately decide that we want to win in a particular industry or workload. Sometimes a strategic customer is growing so quickly that supporting them forces the product into a new territory.

That decision determines where engineering capacity goes.

And engineering capacity is always finite.

So deciding what not to build may be just as important as deciding what to build.

AI can provide information and options. But someone still has to choose the hill—and decide which hills not to climb.

Review Is Really About Responsibility

Once we know what to build, AI becomes extremely powerful.

But after AI creates the PR, can it merge it?

For a typo, probably. For a small type change, maybe.

For a change affecting transaction semantics, replication, scheduling, or data correctness in TiDB? That becomes much harder.

The problem is not only whether AI is smart enough.

It is responsibility.

If an AI approves a bad change and a customer’s production database goes down, we cannot tell the customer:

“Please contact the model. It approved the PR.”

Someone still owns that decision. Someone joins the incident call. Someone writes the postmortem. Someone is accountable.

So I suspect human review will not disappear. Instead, it will move up one abstraction layer.

Today, humans review code. Tomorrow, humans may review evidence: what requirement is being implemented, what tests prove it, what workloads were replayed, what the blast radius is, and whether the change can be safely rolled back.

AI does more of the mechanical work. Humans own the risk boundary.

Testing and Release Are Context Problems

Testing has a similar problem.

AI is already very good at generating unit tests. But the hardest database bugs rarely come from a simple function returning the wrong value.

They come from combinations of workload, schema, concurrency, topology, upgrades, failures, and behavior that nobody predicted five years ago.

And many of the best test cases live inside customers.

A bank has its own transaction patterns. A SaaS company has its own multi-tenant architecture. An AI company may suddenly create one million tables or connections in a way that previously looked absurd—until it becomes an important production workload.

These are not just test cases. They are business context.

AI can help us preserve and transform that context, but first we need to acquire it. That still requires talking to customers, understanding their systems, debugging real incidents, and turning tacit knowledge into something executable.

And even after all tests pass, we still have not delivered anything.

For a cloud database, releasing software means changing an engine while the aircraft is flying. You need canaries, rolling upgrades, compatibility checks, monitoring, automatic abort, and rollback.

This is where AI becomes much more interesting.

A truly useful engineering agent should not stop at “PR created.”

It should be able to implement a change, validate it, replay representative workloads, deploy it gradually, observe production signals, detect regressions, roll back, analyze the problem, and try again.

At that point, we are no longer talking about an AI coding agent.

We are talking about an AI-native software delivery system.

Production Still Has Humans

Even after a successful release, customers will have questions, incidents, and concerns.

AI can help enormously. It can analyze logs, correlate incidents, search historical tickets, generate runbooks, and prepare engineers before a customer call.

But enterprise software has one dependency that rarely appears in architecture diagrams:

trust.

When a mission-critical system has a serious problem, customers do not only want the technically correct answer. They want someone they trust on the other side of the call.

Sometimes that trust comes from years of solving problems together.

Apparently, enterprise software still has a few APIs implemented in coffee, dinner, and human relationships.

AI can make those humans dramatically more effective.

But replacing the relationship itself is much harder.

The Real Metric

This is why I think AI coding is not enough.

The industry is currently optimizing:

Prompt → Code → PR

That is useful, but it is a local optimization.

The real metric should be closer to:

Customer Need → Trusted Production Value

That includes deciding what to build, writing the code, reviewing it, testing it, shipping it safely, operating it, and learning from customers afterward.

If one stage becomes 10x faster while the rest remain unchanged, the system simply finds a new bottleneck.

Every distributed systems engineer has seen this movie before.

The only difference is that this time, the distributed system is the engineering organization itself.

So I don’t think the ultimate goal is a 10x coding agent.

We need a 10x software delivery loop.

AI coding is part of that loop—but code was never the final product.

Trusted customer value is.

---

Note: This article was originally dictated by me and then organized, edited, and polished with the help of AI. The ideas, opinions, and final judgment are mine; AI helped turn my spoken thoughts into a more structured article.