AI Writes Code But Misses the Point: Why Unwritten Rules Make or Break AI Assistance

1. AI Has No Thought: Code Like a Construction Site, Habitable But Uncomfortable

An engineer in a technical management group chat shared a story: a developer used AI to create a pull request, AI reviewed it and approved, but a senior architect immediately spotted a flaw—"Your bugfix approach destroys the original architectural intent." The code ran, tests passed, AI said OK, yet the architect saw the problem instantly.

"AI can solve problems, but it has no thought. Reading good code used to be like reading a poem. Now it's like looking at a construction site... you can't say it's uninhabitable, but it's just not comfortable."

AI-generated code is logically correct, functionally complete, and passes tests. But something feels off—not syntax, not logic, but the "flavor" (锅气). It's like instant noodles versus a carefully crafted bowl of noodles: both fill you up, but the latter has "wok hei"—the chef's anticipation of future needs: will this module be split in six months? Will this function be reused? Does this design leave room for evolution? AI only sees the immediate requirement, not tomorrow's evolution.

A group member offered a vivid analogy: AI is a top-tier Tsinghua graduate—brilliant, zero experience. It outperforms other inexperienced people, but only becomes reliable under a competent lead. In the hands of a solid architect, AI is a powerful assistant; in a novice's hands, it produces construction-site code.

2. The Rule Debate: Not That Rules Are Wrong, But That They're Unclear

An architect posed three challenges:

Even with rules defined, AI ignores them—useless.

Requirements keep changing; AI gets confused about which rule applies.

The boss doesn't know which requirements are reasonable, only vague ideas.

His conclusion: "So it's best to use waterfall—freeze requirements first." Immediately countered: "It's not a rule problem, it's a rule clarity problem."

How many team rules are actually written down? How many are unwritable? Take code layering: the standard says "business logic in Service layer." But in a real project, what counts as business logic vs. a utility method? The boundary is never black-and-white. Veterans judge by experience, juniors guess, AI doesn't even know the boundary exists.

Worse, rules are context-dependent . Same project, different phases—code freeze prioritizes stability; feature development prioritizes speed. AI cannot distinguish these contexts. It follows the current prompt, ignoring history, team tacit knowledge, and situational nuance.

3. AI Doesn't Get Unwritten Rules: A High-Scoring Student With No EQ

The discussion introduced the term "unwritten rules" (潜规则) . An engineer illustrated: "Like the layering rule—it's not documented, it's a mutable default among people. Current AI doesn't get unwritten rules: you must toast the leader at the head seat first; the fish head must point toward the leader."

Though a banquet metaphor, it maps perfectly to code. Every project has its own unwritten rules:

This module's coding style isn't in the style guide, but everyone writes it this way.

That interface's documented usage differs from how everyone actually calls it.

Certain legacy code looks ugly but nobody dares touch it—touch it and things explode.

Senior engineers sense these through tacit understanding (默契) —one glance and they know "this is how it's done here." AI has no tacit understanding. AI has no EQ. It follows explicit rules; where rules are vague, it defaults to the most generic approach—which is rarely the best fit for your specific project.

4. Whack-a-Mole: It's Still the Human Driver's Problem

An architect complained: "Tell AI to fix something, it's whack-a-mole. You correct it, it complies, next time it repeats the error. You store the fix in memory, that error stops, but a new weird issue appears."

The author relates: every time you painstakingly prompt "don't do this," it complies once, then forgets. Memory helps for that specific error, but a new angle brings new mischief.

Then a striking insight from a group member:

"Honestly, most people I've mentored are worse than AI ."

And the metaphor worth rereading:

" AI is like the Red Hare horse: in the hands of Guan Yu or Lü Bu, it's a legendary steed; in a foot soldier's hands, it's horse meat in a few days."

It's not that AI fails—it's that the human driving AI fails . The more standardized your project management, the more comprehensive your data accumulation, the more reliable AI becomes in your team. Conversely, if your team's data is chaotic and standards are nominal, AI just helps you manufacture chaos faster.

The group's final verdict:

"Every issue I've encountered is a people problem. 100%."

5. Summary

The core message: AI can write code and fix bugs, but it doesn't know your project, your team, or your unwritten rules. This isn't AI's fault, nor yours—it's a new collaboration challenge.

We used to onboard juniors by teaching them project unwritten rules, team tacit knowledge, and code "flavor." Onboarding AI requires the same. The difference: a junior learns in three months; AI may never fully learn after three months. But AI's output efficiency dwarfs any junior's.

So the real question isn't "Can AI do it?" but "Can you?":

Are your project standards clear enough?

Is your data accumulation comprehensive enough?

Has your team turned unwritten rules into explicit rules?

Can you mentor AI like you'd mentor a high-potential new hire?

If you've done all of the above, AI is your Red Hare horse. If not, you may need to level up yourself first.