跪拜 Guibai
← Back to the summary

AI Code Generation's Final Bottleneck Is Human Judgment, Not Compute

Why AI Code Writing Ultimately Comes Down to People: The Essential Difference Between Compute Bottlenecks and Domain-Expert Prompts

Author: ENCI Tags: Algorithms, Architecture

In 2026, large model capabilities are still improving, but one thing never changes: compute power can never keep up with demand. More importantly, whether AI code writing works well and produces correct code depends not on how powerful the model is, but on how much you understand. Many people assume that using AI to write code means they can "win by lying back," only to hit the worst case: hitting a bug and not knowing how to fix it, not even seeing where the problem is.

This article skips the empty talk and answers three things directly: why compute can't keep up (current state), why domain experts can spot problems at a glance (professional ability), and how to turn expert experience into prompts AI can understand (methodology), plus a runnable comparison code.

📦 Companion resources: this is an opinion/analysis piece; there is no source package, configuration list, or chart source files. The companion resource slot is empty; skip the opening resource position.

Table of Contents

  1. The Human Factor: A Counterintuitive Conclusion
  2. Compute Can Never Keep Up: The Underlying Logic of the Bottleneck
  3. The Worst Case: Non-Technical People Using AI to Write Code
  4. Expert's Eye: Why Domain Experts Spot Problems at a Glance
  5. Professional Prompts: Injecting Expert Experience into AI
  6. Symptom-Cause-Solution Reference Table
  7. Runnable Comparison Code: Novice Prompt vs Expert Prompt
  8. When to Use It and When Not to (Judgment)

1. The Human Factor: A Counterintuitive Conclusion

Let's state the conclusion first: when AI writes code, the final contest is still between people. Not models, not compute, but people's professional competence.

Over the past year, large model capabilities have kept improving, but one point never changes: "compute can never keep up." You'll find a blunt reality: when model capability rises, hardware becomes the constraint; when hardware barely catches up, people's skill level becomes the constraint. No matter how strong AI tools are, they are only a magnifying glass. The more professional you are, the more professionalism they magnify; if you're not professional, they magnify your blind spots.

The most typical case is the illusion brought by "vibe coding." Many people can "write" an app in minutes with it, which looks great, but that satisfaction has a cost. After security researchers scanned more than 5,600 vibe coding applications, they found over 2,000 security vulnerabilities, more than 400 exposed keys, and 175 cases of personal private data leakage. It runs, but that doesn't mean it can ship; it works, but that doesn't mean you understand it. That is the most direct footnote to the phrase "it comes down to people."

Why this conclusion? Because the essence of AI writing code is: you ask, it gives. If you can't ask high-quality questions (prompts), it gives mediocre answers; if you can't tell whether its answer is right, you can only accept it wholesale and get buried in the pits it dug. After the low-hanging fruit is picked, every inch of remaining progress depends on people.

This theme finds echoes in earlier articles in this column. In the piece on why agents need self-evolution, we discussed that agents relying only on parameter accumulation "go static after training" and must rely on experience mechanisms to keep getting stronger — and experience comes precisely from how knowledgeable people set up reflection and consolidate strategies. Model bottlenecks need mechanisms to compensate, and mechanism bottlenecks need people to design.

2. Compute Can Never Keep Up: The Underlying Logic of the Bottleneck

Why say "compute can never keep up"? This is not pessimism; it's a structural fact.

Demand is expanding exponentially. According to data from the China Academy of Information and Communications Technology (CAICT), by June 2026, China's daily token call volume had exceeded 500 trillion, a large increase from 100 trillion at the end of 2025. The stronger models become and the more widespread agents become, the larger the call volume and the more unlimited the thirst for compute.

Supply is stuck behind multiple bottlenecks. Zhang Linshan, a researcher at the Macroeconomic Research Institute of the National Development and Reform Commission, points out that the explosive growth of generative AI applications has spawned massive compute demand; tech giants and startups have thrown themselves into the "battle of a hundred models," driving demand for high-performance GPUs sharply upward. Supply is constrained by production capacity, advanced process nodes, and import restrictions on high-end cards, so the gap keeps widening. "The fundamental reason for rising compute prices is supply-demand imbalance," says Li Mingyan, director of the Intelligent Economy Research Institute at Sai Zhi Industrial Research Institute, bluntly.

Architecture itself is also becoming a bottleneck. CAICT's "AI Compute Node Development Research Report (2026)" notes that to meet the extreme communication performance demands of training hundred-billion and trillion-parameter models, the traditional architecture that treats servers as units and relies on stacking external networks has become the main bottleneck restricting the release of compute efficiency. The current evolution of AI compute nodes is shifting from "CPU-connection-centric" to "GPU-interconnect-centric," squeezing efficiency through architectural restructuring.

Put this logic in plain terms: compute is like cars on a road; demand is traffic, supply is lanes. Traffic doubles every year, but the lanes are blocked by various roadblocks (capacity, process nodes, purchase limits). So don't expect compute to suddenly become abundant; that's neither realistic nor the key to solving the problem. The lever that truly moves efficiency is not hardware; it's "how you use it."

Compute bottleneck references:

3. The Worst Case: Non-Technical People Using AI to Write Code

If the compute bottleneck is a "hard constraint," then "writing anyway without understanding the technology" is the easily overlooked soft disaster. What's the worst case for using AI to write code? You don't understand the technology at all, you can't tell the AI how to write it, and after it's written you can't read it either. Once it plants a bug, all you can do is stare — you can spend an entire afternoon trying to fix it and still not know where to start.

This is vibe coding's cruelest side. It has lowered the threshold for "writing code" to an unprecedented low, but the threshold for debugging hasn't dropped at all. You can have AI "write" an app in five minutes, but when it exhibits strange behavior, you lack the ability to judge whether it's a hallucinated dependency, an unreset state, or fundamentally misplaced logic.

The security data from Chapter 1 already makes the point: more than 5,600 vibe coding applications, with 2,000+ vulnerabilities and 400+ exposed keys. Most creators of these apps lack security knowledge. They aren't deliberately planting landmines; they simply can't see them.

The pitfalls people who don't know the field step into tend to cluster in a few categories:

First, "hallucinated dependencies (slopsquatting)." AI fabricates package and method names that look very real. A knowledgeable person's first reaction is "check the lockfile to verify whether this import actually exists"; someone who doesn't know simply runs pip install, and installs a malicious package with the same name that attackers pre-registered.

Second, "getting the structure right but the intent wrong." A typical example: in a try...catch block AI writes, catch only does console.log(error) and then nothing — no fallback, no user notification, no retry. The code doesn't crash; it just "fails quietly." An outsider sees everything as normal; only someone who understands the intent knows the feature is already broken.

Third, "reverse tracing" is impossible. A true debugging expert traces backwards from the symptom: "the second upload bypassed the modal" → starting from the upload execution point, ask "what condition let it run" → find the flag that was never reset. This reverse reasoning presupposes that you have a model in your head of "what the correct system looks like." Without that model, no matter how smart the AI is, it can't save you.

Looking at these three types of pitfalls together yields a blunt conclusion: AI has lowered the threshold for "writing code" but hasn't lowered the threshold for "reading and debugging code" in the slightest. So those who enjoyed only the first half's dividends will take a hard fall in the second half. The threshold hasn't disappeared; it has just moved from "writing" to "judgment."

Worst case references:

4. Expert's Eye: Why Domain Experts Spot Problems at a Glance

The previous section covered how badly off the ignorant are; this section covers the other side — why knowledgeable people can spot problems at a glance. This is exactly the core argument for "it ultimately comes down to people."

There's a vivid real case: a young engineer using AI to write code reacts to a bug by "throwing the error message at AI for analysis"; a veteran engineer who only knows "ancient-style programming" instead reacts by "first guessing what's bothering the machine." He knows a seemingly random crash might be because a certain bit in a certain register wasn't set; a communication failure might be signal attenuation from an overlong cable; corrupted data might be stack overflow from too-deep interrupt nesting. He carries a complete model of "what the machine is thinking," so he can reason from clues back to the true cause — something neither the AI nor the error text can give you.

Why can't AI tools do this? Because AI excels at "pattern recognition," not "intent-level understanding." Real-world tests of various AI code review tools point to the same conclusion: they reliably catch errors that fit known patterns (unused variables, unreachable code, potential null pointers, language-specific anti-patterns), but they can't catch errors with no pattern to follow — misplaced business logic, hallucinated authentication flows, cross-service privilege escalation, and race conditions under high concurrency.

In other words, AI is a "scanner" that can only see the surface; the expert is a "doctor" who can infer what's happening inside from symptoms. The disease the scanner can't find is the truly dangerous one. This is also why nearly all advice about AI code review adds: automated tools cannot detect intent-level errors, and expert human review of AI-generated code is non-negotiable.

Senior engineers haven't been eliminated in the AI era; they've just changed roles. After AI takes over mechanical checks (style violations, null pointers, missing documentation), senior developers shift their energy to higher-value work: architecture review (does this fit our system design), security analysis (what are the domain-specific threats), performance evaluation (can it handle scale), and mentoring (explaining to juniors why this particular AI suggestion matters). These four things are precisely what AI is worst at right now.

The sources of expert capability can be split into three layers:

  1. Mental model: a complete picture in the head of "how the system should operate," so one can judge the boundary between "normal" and "abnormal."
  2. Pattern of failure: having stepped in enough pits to know "what this kind of problem usually looks like and where it hides."
  3. Root-causing: can reason from appearance back to root cause rather than being led by the appearance. All three layers rely on long-term human accumulation that model parameters cannot replace.

Expert's eye references:

5. Professional Prompts: Injecting Expert Experience into AI

We've said experts have sharp eyes; how do you "lend" those eyes to AI? The answer: write the expert's experience, constraints, and acceptance criteria into the prompt. The prompt is the task specification you hand to AI; the more professional the spec, the more professional the output.

Look at a blunt quantitative fact first. Data shows 84% of developers already use AI tools, but fewer than 30% can reliably get production-usable code. The reason isn't bad models; it's that vague prompts only produce mediocre code — most developers treat AI like Google, dropping a line like "write a function to sort an array," then complain the result looks like a 2010 StackOverflow answer.

There's an even more intuitive comparison: code generated from a vague description may need 80% rework, while structured prompts can push first-pass success above 80%. Same model, same requirement — whether the prompt is clear can make several times the difference in efficiency. This isn't mysticism; it's the engineering of "saying things clearly."

So what does a "professional prompt" actually look like? It's not some secret incantation; it's a structured task specification with six elements:

Element Purpose Counterexample (vague) Positive example (professional)
Role Makes the model answer from a specific identity/perspective "Write a sorting function" "You are a senior Python backend engineer"
Context Provides background the model cannot infer Not provided "This is a REST API handling millions of orders"
Task A clear deliverable "Optimize it" "Reduce API response time to P95 < 200ms"
Constraints Limits scope and prohibitions Not limited "Python 3.12, no new dependencies, don't change the function signature"
Output format Specifies the return structure Whatever "Return JSON with fields code/message/data"
Acceptance criteria Defines what counts as 'done right' Missing "pytest all green + 30% latency reduction"

The essence of this table is translating the "self-evident" tacit knowledge in experts' heads into a unified language AI can understand. Experts write prompts fast not because their typing is fast, but because they know what to trade off, what to forbid, which approach to use, and what counts as "correct." These judgments are exactly what novices lack most and what is most valuable.

Injecting expert experience into prompts can be summarized into three reusable moves:

  1. Give specific goals, not directives. Don't just say "optimize it"; say "reduce API response time to P95 < 200ms." Measurable acceptance criteria force AI to produce results you can judge.
  2. Give constraints, especially "what not to do." Specifying "no new dependencies," "don't change signatures," "don't delete fields" stops AI from overreaching and prevents it from inflating things you don't want.
  3. Give environment and examples. Tell it "Linux + reproduction logs available," or provide a few-shot example, so AI aligns with your business context instead of applying generic templates.

One sentence sums up this chapter: prompts aren't mysticism; they're the engineering of "speaking clearly." The clearer you can state the requirement, the better AI can do the work — and "speaking clearly" relies on professional knowledge, not typing speed.

Professional prompt references:

6. Symptom-Cause-Solution Reference Table

The previous five chapters unpacked the compute bottleneck, the pitfalls of ignorance, the expert's eye, and the method of prompts. This chapter organizes the pitfalls you'll hit when using AI to write code and how to fix them into a table you can check against. If you're using AI to write code, just match your symptom to the row.

Symptom Cause Solution
Spent an afternoon on a bug after AI wrote the code, no idea where to start Don't understand the technology; no mental model of the "correct system" Build domain knowledge first before rushing to AI; have an expert review or read the code through yourself
AI-generated code runs, but security problems surface at launch (key leaks, vulnerabilities) No security knowledge; can't see the mines AI planted Review critical areas + scan with tools; forbid direct promotion to production
AI suggests package/method names that look real; install turns out to be a malicious package Hallucinated dependency (slopsquatting); didn't check the lockfile Verify each import exists and matches versions; don't blindly trust AI suggestions
Logic looks "right" but isn't what the business wants; fails quietly AI got the structure right but the intent wrong (e.g., catch only logs and does nothing) Define acceptance criteria; have an expert judge whether it matches business intent
The simpler the prompt, the more generic the code, the less like your project Missing context and constraints; model can only apply generic templates Write structured prompts with role + context + constraints + output format + acceptance criteria
Compute insufficient; responses slow and stuttering Supply-demand imbalance + architecture bottleneck; no short-term fix Don't count on hardware; shift to optimizing "how you use it" (prompts, caching, routing)
"AI is so strong, I can use it casually and win by lying back" Misunderstanding the difference between the "writing threshold" and the "judgment threshold" Focus on improving professional skill and judgment, not piling up tools

The criterion this table conveys: the root of most "AI code writing failures" lies in "insufficient human judgment," not "the model isn't strong enough" or "compute is insufficient." So the priority of solutions is always "improve people first, then optimize tools."

Reference table sources:

7. Runnable Comparison Code: Novice Prompt vs Expert Prompt

Everything above is theory. This section gives code you can run directly, demonstrating the difference when a "novice prompt" and an "expert prompt" make the same AI output the same function. It uses a minimal CodeGenerator to simulate the "prompt → generate code → quality check (rework judgment)" flow.

# -*- coding: utf-8 -*-
"""
Minimal comparison demo of AI code writing with 'novice prompt vs expert prompt':
same model, same requirement, only prompt quality differs; output and first-pass rate differ wildly.
This demo uses only the standard library; no extra dependencies needed.
"""


def generate_code(prompt):
    """Simulate AI-generated code based on prompt quality (prompt quality score approximates rework rate)."""
    # Simulate: vague prompt → generated code needs heavy rework; structured prompt → passes on first attempt
    if "验收标准" in prompt and "约束" in prompt and "输出格式" in prompt:
        return "Passes on first attempt; code can go straight to production", 0.0    # rework rate 0%
    return "Code runs but needs rework; has security risks", 0.8        # rework rate 80%


def novice_prompt():
    """Novice prompt: vague instruction, missing context and constraints."""
    return "Help me write a sorting function"


def expert_prompt():
    """Expert prompt: structured task spec with all six elements."""
    return (
        "You are a senior Python backend engineer. "
        "Task: implement a stable sorting function for a REST API handling millions of orders. "
        "Constraints: Python 3.12, no new dependencies, don't change the function signature. "
        "Output format: return JSON with fields code/message/data. "
        "Acceptance criteria: pytest all green + API latency reduced by 30%."
    )


if __name__ == "__main__":
    # Simulate the same model receiving the two types of prompts
    print("===== Novice prompt =====")
    novice_result, novice_rework = generate_code(novice_prompt())
    print(f"AI output: {novice_result}, rework rate: {novice_rework * 100:.0f}%")

    print("\n===== Expert prompt =====")
    expert_result, expert_rework = generate_code(expert_prompt())
    print(f"AI output: {expert_result}, rework rate: {expert_rework * 100:.0f}%")

    print("\nConclusion: same model; whether the prompt is clear drops the rework rate from 80% to 0%.")

What does the code show? The core is that one judgment line in generate_code: whether the three phrases "acceptance criteria," "constraints," and "output format" appear in the prompt directly decides between a first-pass success and 80% rework. In production, you'd replace this function with a real model call + test suite + expert review; the principle is identical: professional prompts front-load the expert's tacit knowledge into the prompt.

Code references:

8. When to Use It and When Not to (Judgment)

Which situations should rely on the "professional competence + prompt" path? When you use AI to write code in a domain you genuinely understand — you know the boundaries, know what to forbid, and can judge right from wrong. Here, professional prompts can greatly amplify your efficiency; AI is your super-amplifier. Likewise, when facing reusable, verifiable tasks, structured prompts can significantly reduce rework.

Which situations should not rush into AI code writing, or should not rely only on AI? When you completely don't understand a domain, don't fantasize that AI can "skip learning" for you. You can have AI build the skeleton and make demos, but core logic, security plans, and business intent must be checked by people who understand. Also, in high-risk, strongly audited scenarios (critical financial paths, backends with real user data), expert human review is irreplaceable; AI-generated code must pass an expert review before shipping.

One-sentence criterion: "Well-versed + verifiable" is worth amplifying with AI; "ignorant + high-risk" don't touch it first — AI can't save you. "It ultimately comes down to people" is not a slogan; it's your real situation every time you type a prompt in front of the keyboard — first look at whether you understand, then look at how high the task risk is, then decide how to use AI.

Column introduction: This column, LLM Large Model Technology Column, runs from the Transformer attention mechanism all the way to LangChain, RAG, and MoE implementation, with runnable code in every piece, updated weekly. To read in order, subscribe on the column page.

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

ENCI

The pitfall I stepped in wasn't that my prompts weren't good enough — it was that I didn't understand the business at all. When AI ran logic that looked reasonable, I believed it, and only during debugging did I realize the direction was wrong. A: Are you more often blocked by insufficient compute/model? B: Are you more often blocked by not understanding enough? Let's discuss in the comments — I guess most people would pick B.