跪拜 Guibai
← Back to the summary

The Five Layers of Engineering Judgment AI Can't Replace

In the previous article, I gave a product manager's solution to the problem that was making them very anxious—If AI is already writing the code, why are some people even more panicked?.

Honestly, this isn't just a PM's dilemma.

A lot of programmers around me are stuck in the same spot: AI writes code incredibly fast, the code runs, but the moment they need to deliver a system that can go live, iterate, and withstand real users, they start to panic.

So where exactly is the bottleneck? I've thought about it for a long time, and in this article, I'll talk about the solution to the programmer's deep anxiety.

A while back I saw some data that made my heart sink. Sonar's 2026 developer survey: 42% of code is already AI-assisted, 96% of developers don't fully trust AI's output, but only 48% seriously review AI code every time. Half the code is written by AI, half isn't seriously reviewed—the industry has given this gap a name: Verification Debt.

There's an even harsher number. Veracode's 2025 security report: 45% of AI-generated code introduces security vulnerabilities. Almost half.

Anthropic itself ran a randomized controlled experiment with 52 people: the group using AI assistance scored 17% lower on code comprehension tests than the control group that didn't use AI. Note, it's not that the code was written poorly, it's that understanding was poor. Google's Addy Osmani coined a term for this phenomenon—Comprehension Debt: the speed at which AI helps you write code, and the speed at which you truly understand that code, are rapidly diverging.

After seeing this data, one sentence was stuck in my chest—what most people lack is not "how to make AI write more code," but a set of engineering judgment systems for collaborating with AI. The traditional path of "learn syntax first, then frameworks, then do projects" is already somewhat outdated in the era of human-machine collaboration. Memorizing syntax, handwriting complete code, piling up framework knowledge points—it's time-consuming, low cost-effectiveness, and completely unadaptable to the current R&D pace.

Based on my experience of over a year implementing AI projects, I've broken down programming learning into five layers of capability. These five layers are not a parallel list of skills; they are progressive—if you don't pass the previous layer, the next one is a castle in the air.

Let me first lay out the five layers of capability alongside the traditional learning approach:

Capability Layer Traditional Learning Focus What to Really Practice in the AI Era Consequence of Failing
Explicit Error Acceptance Looking at console errors Spotting pitfalls in AI code at a glance Approving features just because they run, then they explode after going live
Requirement Structuring & Restoration Writing code according to PRD Translating vague descriptions into specs AI can understand AI gives you something completely different from what you wanted
Technical Solution Trade-offs Memorizing the entire tech stack family bucket Doing subtraction based on project scale Small projects piled with heavy architecture, maintenance costs explode
Engineering Standards & Architecture Memorizing code standard documents Controlling table structures, interface contracts, exception chains One person writes happily, the team takes over and immediately curses
Production Delivery Learning ops and deployment Building permission, encryption, monitoring, and disaster recovery systems Demo runs smoothly, crashes on the first day of going live

Just looking at the table might be a bit abstract. Let me use a real case I personally led—the complete process of an internal operations backend from requirement to launch. Once you walk through this chain, it's clear at a glance where each layer gets stuck.

Case Background

First, let's set the scene; I'll return to this case for every layer later:

This example is very common, just an ordinary internal backend, the kind everyone probably did during internships or early in their careers.

Layer 1: Can You See What's Wrong with AI's Code?

Back to the case above. This frontend developer had AI generate the first version of the backend code. Pages opened, buttons were clickable, data displayed. He looked at it and thought it was almost done, ready to submit.

I asked him to do three things:

  1. Open the browser console and check for red errors.
  2. Click every button in three states—normal, loading, error.
  3. Drag the window narrow and see how the tables and forms look on a narrow screen.

The result—4 warnings in the console, the delete button could be clicked repeatedly in the loading state (sending 3 requests), and the table overflowed at 1366 resolution.

Code written by AI has a large gray area between "the feature runs" and "the engineering is usable." Missing interface exception handling, uncovered edge states, a bunch of compatibility issues—these problems are completely invisible during a demo, but the moment they reach a real user, they are exposed instantly.

The security company Ox Security gave AI code a name—"Army of Juniors." Think about it, code written by AI is like hiring a thousand interns; each one can write, features all run, but none can take responsibility for the architecture. Functional correctness is extremely high, engineering judgment is basically zero. What's the scariest part? It's Silent Behavioral Drift. AI changes the code, tests pass, the diff looks clean, but on some path you didn't test, the behavior has already changed, and you simply can't discover it.

How to practice? Most people's habit is—after changing code, run through the normal flow; if the page opens and buttons are clickable, they default to no problem, ready for testing or launch. But with AI-written code, the normal flow often doesn't reveal problems. The places that really explode are at the boundaries: how to handle interface failures, how to handle concurrency conflicts, whether the page will white-screen if abnormal data comes in. AI won't proactively cover these for you.

So this layer practices just one thing: shift your testing focus from the happy path to the exception path. Every time AI produces code, don't test the normal flow first; first think of 3 "what ifs"—what if the interface times out? What if the data is empty? What if the user is fast and double-clicks? Test these first, then look at the normal flow.

Layer 2: Can You Translate Vague Requirements into Specs AI Understands?

After passing the first layer, the frontend developer in the case encountered a second problem: the page AI gave wasn't what operations wanted.

Operations said "the activity list should be clear," and AI gave a card layout with three columns per row. Operations said "configuring prizes should be convenient," and AI gave a long, fully expanded form.

The problem is never with AI. AI doesn't know what "clear" means, or what "convenient" means. You feed it vague words, it gives you sloppy work.

I asked him to switch methods. Don't tell AI "be clear," instead say:

Same AI tool, same person, just changing the requirement description method from "adjectives" to "structured specs," and the code quality immediately jumped a level.

It boils down to one thing: break subjective terms like "good-looking," "easy to use," "smooth" into page structure, component states (normal/empty/loading/error/no permission), interaction flows, data boundaries. Try it; when requirements are written like this before being thrown to AI, the output will be an order of magnitude different from before.

Layer 3: Can You Judge if the Technical Solution AI Recommends Is a Trap?

This layer is the watershed. Master the above two layers, and you're still an "AI operator"; pass this layer, and you start to control AI.

In the case, this frontend developer asked AI to set up the backend tech stack, and the solution AI gave was: React + TypeScript + Node.js + PostgreSQL + Redis + Docker + K8s.

Looks very professional, right? Each item alone seems fine.

But this backend is used by an average of 10 people daily, data volume doesn't exceed tens of thousands of records, no high concurrency scenarios, no elastic scaling needs. Why use Redis caching? What's the point of K8s? A monolithic Node app + SQLite or a lightweight ORM could handle it, yet it was forcibly piled into a microservices architecture posture.

I've stepped into this pit more than once. AI especially loves piling up tech terms—its training data is full of blog posts and tech solutions from major companies; it doesn't know your project is maintained by only 3 people, doesn't know your server is just one 2C4G machine.

A study from Florida International University specifically documented this phenomenon—they called it Translation Tax: senior developers become slower using AI because they spend a lot of time correcting AI's naive suggestions. The more experience you have, the more time AI wastes for you. What does this mean? You save time writing code using AI, but lose it all correcting its over-engineering.

How to pass this level? I set three soul-searching questions for myself, asked every time before AI pushes a solution:

The ability to do subtraction is a hundred times more valuable than the ability to do addition.

Layer 4: Can Someone Else Take Over the Code You Write?

After the first version of the backend in the case went live, another problem arose—operations raised a new requirement, the frontend developer tried to change it for two days but couldn't, and asked a colleague for help. The colleague pulled the code and was instantly baffled:

One person using AI to write code, it's truly satisfying. But code isn't written for just you to see. In multi-person collaboration scenarios, chaotic technical debt accumulates faster than in the pure handwriting era—because AI writes fast, your non-standard code is produced fast too.

This layer doesn't require you to deeply drill into code details, but a few hard rules at the architectural level must be strictly guarded:

  1. Database Table Design: Think through relationships before creating tables, unify field naming, add proper indexes.
  2. Interface Contract: Define success and failure return formats upfront; don't let each interface do its own thing.
  3. Exception Handling: Don't let AI just try-catch and then console.log and call it a day.
  4. Logging: Key operational nodes must have logs; otherwise, you won't even have clues when online issues occur.

My experience is that once these rules are set, AI-produced code can reduce standardization problems by over 60%.

Layer 5: Can Your System Withstand the Real World?

This is the last layer, and the true chasm between a Demo and a commercial product.

The backend in the case ran smoothly for two months, then an incident occurred—operations accidentally deleted an activity. No soft delete, the data was directly gone. No operation logs, no one knew who deleted it, when it was deleted, what was deleted. Backups? Not done.

This has nothing to do with AI. AI's goal is to "make the feature work"; it won't proactively consider: permission levels (who can delete?), operation audit trails (who deleted what?), data recovery (what if deletion is a mistake?). These things must exist in a human's mind first, then be explicitly written into the requirements for AI to execute.

I'll list the checklist for this layer; every item was bought with blood and tears:

This layer, AI cannot help you; it won't even remind you to do it. These capabilities can only be accumulated through engineering experience, so they are your true moat as a technical professional.

If I put "someone who only knows how to use AI to write code" and "someone with five-layer capabilities" in front of the same requirement, the gap looks like this:

Dimension Someone Who Only Uses AI Someone with Five-Layer Capabilities
Receiving Requirements Directly throws vague requirements at AI First breaks down requirements into structured specs, then lets AI execute
After Code Output Passes if the normal flow runs First tests exception paths, edge states, then looks back at the normal flow
AI Recommended Solutions Accepts everything, thinking "it knows better than me" Does subtraction based on project scale and team capability
Code Standards Scattered, writes wherever thoughts go Table structures, interface contracts, logging standards defined first, then written
Before Launch Launches if features are fine Confirms permissions, auditing, backups, alerts item by item
After Problems Occur Can't find the cause, guesses Locates via logs, has a rollback plan as a fallback

Summarizing the "Debts" and "Taxes" Mentioned Earlier

This article mentioned several terms coined by the industry—Comprehension Debt, Verification Debt, Translation Tax, Army of Juniors, Silent Behavioral Drift. None of these terms were made up casually; there's research and data behind them. Looking at them together feels more impactful than scattered across paragraphs:

Concept Source What It Means
Comprehension Debt Google / Anthropic The speed AI writes code and the speed you understand that code are diverging. You think you're in control, but actually the codebase is already piled with logic you don't recognize.
Verification Debt Sonar / Veracode Half the code is AI-written, half isn't seriously reviewed. 45% of AI code has security vulnerabilities, but only 48% of people review it every time.
Translation Tax Florida International University Seniors become slower using AI—the coding time saved is entirely lost correcting AI's over-engineering and naive suggestions.
Army of Juniors Ox Security AI is like a thousand interns: functional correctness is extremely high, engineering judgment is basically zero. Not one can take responsibility for the architecture.
Silent Behavioral Drift CodeGeeks Solutions The most dangerous bug—tests all pass, diff is clean, features are normal, but on some path you didn't test, the behavior has already quietly changed.

These five concepts actually point to the same thing: AI's output speed has far outpaced human understanding and verification capabilities. The stronger the models get, the bigger this gap becomes.

Conversely, these five concepts also correspond exactly to the five layers of capability. Army of Juniors + Silent Behavioral Drift, if you can't handle the first layer, you're dead. Comprehension Debt corresponds to the second and fourth layers—if requirements aren't clear and code isn't standardized, the debt of understanding rolls bigger and bigger. Translation Tax, the third layer is stuck right here. Verification Debt, the fifth layer—if you don't confirm permissions, auditing, backups before launch, the verification pitfalls are all left for production. The five layers of capability are not just icing on the cake; they are rigid demands forced by these "debts."

In the End

What I want to say in writing this article is really just one sentence: AI rewrites the learning method, not the value of programming. What it eats up is the physical labor of mechanical coding; what it amplifies is precisely the "brain work" of judgment, trade-offs, architecture, and risk control.

In the past, we competed on hand speed; now we compete on judgment.

Many people are now frantically tinkering with various AI coding tools and plugins, yet ignore the core engineering judgment. Tools are just means of acceleration; what truly determines whether you can build a stable, deployable system is always the human.

You don't need to pursue handwriting all your code, but you must possess the ability to provide a safety net, verify, and make trade-offs. The five layers of capability progress step by step; solidly practicing the first layer of code verification first is far more important than blindly chasing new tools. People who can discover risks and control systems will never be replaced by AI. People who can see problems are always more valuable than people who can only write code!

After reading this article, which layer do you think you're on? Feel free to reply with any thoughts in the comments.

Everyone is welcome to follow my public account: 深入浅出AI

55663d977f57f6cc6e888942ff5a99bb.jpg