The Fastest AI Toolchain Still Needs a Slow Human Judgment Loop

A big shot in the group joked that in the current AI era, as long as you learn slowly, you don't need to learn at all.

Yes, AI is developing too fast. Looking back at this time last year, the way we wrote code was different, and the way we asked questions was different.

I'm not anxious about efficiency, nor am I nostalgic for the idea that "old-school programming has soul." What I'm thinking about is: as the cost of generation continues to drop, an engineer's most scarce ability is rapidly shifting from "producing content" to "making judgments." Judging whether an interface should be split, whether technical debt should be repaid, how much of a "must" the stakeholder's demand really is, which of the ten solutions the model offers can go into production, and which one looks elegant but will blow up upon deployment.

AI hasn't done these things for us. On the contrary, it has amplified the problem.

Because the biggest problem now is no longer "not knowing how to do it," but "it's too easy to do it." When you don't know how, people naturally slow down a bit—they look up information, ask one more question about dependency boundaries, and think through the why. When it's too easy to do, the most common path for a team is: generate first, understand later; launch first, govern later; piece things together first, and assume there will be time to clean up later.

However, "later" usually never comes.

I increasingly feel that in the AI era, we should reserve a zone of slow thinking for ourselves. This "slowness" is not procrastination, not inefficiency, and not feigned profundity. It is a deliberately established cognitive damping: when the system is already fast enough, adding necessary friction to the judgment process to prevent people from being swept away by the tool's velocity.

So where should we be slow?

The first category: decisions involving irreversible costs. Architecture selection, data models, permission boundaries, organizational responsibility division, vendor lock-in, long-term agreements, core link transformations—once these things are decided wrongly, the cost of fixing them later does not increase linearly but spills over exponentially. An extra two days spent here can often save half a year.

The second category: problems involving complex causality. Online incidents, quality degradation, organizational dysfunction, collaboration conflicts, project delays—these problems are all annoying because the symptoms are clear but the causality is messy. You think it's a people problem, but actually the process incentives are wrong; you think the system is unstable, but actually the change strategy is too aggressive; you think the model's performance is poor, but actually the evaluation dataset is contaminated. If you pursue speed here, you usually just arrive at wrong attributions faster.

The third category: problems involving the accumulation of personal capability. Writing, reviewing, solitude, long-duration exercise—I see all of these as part of engineering capability. They appear to produce no code and don't directly improve QPS, but they train something more fundamental: abstraction ability, causal judgment, attention stability, and noise resistance.

"Slowness" is not opposing efficiency; it is assigning different clock frequencies to different problems. The assembly line can run at high frequency, but the human brain cannot stay at high frequency all the time. A CPU that runs at full load for too long will throttle; so will a person.

If someone asks how to make themselves slow down, I think they can try "writing, running, solitude."

If I were to keep only one method of slow-thinking training, I would most likely choose writing.

Writing has several benefits. First, low cost. You don't need equipment, you don't need a venue, and you don't need cooperation from others. Second, direct feedback. By the time you write the third paragraph, you will discover whether you have really thought things through. Third, it leaves traces. Many vague feelings, when you look back months later, allow you to see your blind spots and inertia at that time.

What can a technical person write about? Personally, I think the following three categories:

One is solution memos. Not the kind of complete document meant for others to read, but judgment drafts for yourself. What is the problem, what are the known facts, what are the unknown variables, which solution do I currently lean toward and why, what is the biggest risk, what evidence would make me change my mind. Not many words are needed; the key is to force yourself to lay out your judgment.

Another is incident post-mortems. Not standard review templates, but writing about your own cognitive process at the time. When the alert appeared, what was my first reaction; why did I rule out a certain clue; at what point in time did I start being led astray; which past experiences helped me, and which past experiences harmed me. Writing this kind of thing often will gradually form a personal fault-judgment archive.

And another category is long-term thematic writing. For example, we continuously observe the impact of AI on R&D organizations, or continuously observe the friction of a certain architectural paradigm landing in a company. This process is very much like running a long-term experiment. Each time you write, you are updating your own cognitive model. Its return is not immediately visible, but after a year, you and most people who just watch the spectacle will have a clear gap.

The greatest value of writing is that it forces you to turn borrowed opinions into your own structure. Many people usually listen to podcasts, read articles, scroll through posts—lots of input, but their minds are always filled with scaffolding built by others. Only by writing yourself do you know which beams are hollow.

The current information environment is extremely dense. WeChat, DingTalk, Feishu, email, group messages, monitoring alerts, PR comments, AI dialog boxes—a person's attention is sliced into many pieces. More troublingly, AI is constantly providing an illusion: whenever you are stuck, you can ask immediately, get a response immediately, and get an answer that is roughly usable immediately.

Over time, people lose the ability to stay with a difficult problem for a long time.

And many truly important problems are not suitable for immediate answers. Why does an organization's decision quality decline after expansion, why does a platform become heavier and heavier, why does a team start obsessing over quick wins, why is a technical leader clearly very busy but producing less and less key output. These problems all require time without input interference. You need to let the problem ferment in your mind, and allow some uncomfortable blank spaces to exist.

In the AI era, people increasingly tend to live only in symbol systems: documents, messages, code, tables, metrics, prompts. The value of something like running lies in letting you temporarily escape the torrent of symbols and return to a lower-bandwidth but more continuous state. This state is very important for the quality of thinking.

Of course, it doesn't have to be running. Long-distance walking, swimming, cycling, or even doing housework quietly alone can all potentially enter a similar state. The key is not the form of exercise, but continuity, low interference, and rhythm.

All the actions above ultimately aim to give yourself better judgment.

So how do you build judgment?

People often say, "See more of the world and you'll have judgment." Saying it this way is a bit hollow. Judgment is certainly related to experience, but it depends on what kind of experience. A person who has done projects for ten years might just have repeated one year of experience ten times.

So for judgment to grow, I think at least four things are needed.

First, the ability to distinguish facts, interpretations, and decisions. On a shallow level, it's like what I often tell my kid: is this an opinion or a fact?

Second, think a few steps ahead.

Third, the ability to place bets and make decisions under incomplete information.

Fourth, the ability to review your own misjudgments.

Personally, what I have consistently persisted in is writing:

Writing. Not for publishing anything, not for building a content account, not for cultivating a persona—just to put the judgments in my mind onto paper. Many chaotic feelings become clear once they land on paper. At the same time, it's also to have a fixed time alone with AI.

My understanding of "in the AI era, let yourself slow down" is roughly this meaning: go all out fast where you should be fast, and hold the line firmly where you should be slow. Don't train your brain into a relay station that only takes prompts and spits out results. As tools become stronger, people must not give up that part of capability that is slow, heavy, but determines the upper limit.

Many years later, looking back, an engineer's or a technical leader's capability will most likely not be judged by how much content they can generate in an hour, but by whether they can stay steady when facing complex situations, whether they can see one layer deeper, and whether they can, among a pile of seemingly correct answers, pick out the decision that truly should be made.

This capability cannot be rushed.

Postscript:

Actually, this article was also an idea that suddenly popped into my head while cycling slowly in the morning. On Saturday, I was still thinking about what to write this week.

A little slower is fine, too.

That's all.