How AI Coding Triggers a Forced Cognitive Cleanup of Tacit Knowledge

1. Our Most Valuable Experience Sleeps in Our Heads

Michael Polanyi’s famous claim "We know more than we can tell" resonates strongly in software engineering, where many decisions are based on undocumented intuition.

Examples include why a module must be written a certain way, why an interface should never change, or why a seemingly ugly architecture is trusted because of historical stability.

A Real Scenario

A colleague fixed a bug using the fastest AI‑suggested solution, which later broke another feature due to an implicit business constraint that was never documented.

The root cause: the constraint was never written down.

2. AI Becomes the "Dumbest Reader" – It Misses Your Implicit Meaning

Traditional documentation captures what we already understand. When AI is asked to work, we must document what we have never fully clarified.

Why?

AI does not understand subtext or vague instructions. It only sees the literal text.

# You think you said "clear enough"
"Optimize this function"
# AI sees
"Change anything as long as it runs"
# What you actually want
"Optimize this function while ensuring:
 1. No backward‑compatibility break (V2 API still in use)
 2. Latency increase ≤ 50 ms (SLA)
 3. Preserve existing retry logic (business requirement)"

Those unspoken assumptions are invisible to AI.

3. Three Types of Knowledge and Their Explicitness Difficulty

Not all knowledge is equally hard to write down. The author classifies it into three categories:

Explicit Knowledge (Easiest)

Facts that can be textbook material, such as "Redis is an in‑memory database", "Git uses commits", or "RESTful APIs use GET/POST/PUT/DELETE". AI already knows these, but knowing "what" and "why" are different.

Implicit Knowledge (Medium Difficulty)

Procedural know‑how that requires demonstration, e.g., using gdb to debug segmentation faults, locating performance bottlenecks in logs, or politely rejecting a proposal during code review. AI can now capture these steps.

Example: the author asked AI to observe how they troubleshoot a failing kubectl Pod start‑up; AI produced a seven‑step checklist that newcomers can follow directly.

Tacit Knowledge (Hardest)

The "cannot be expressed" insights Polanyi described, such as feeling a requirement is off, sensing code looks wrong, or preferring solution A over B for historical reasons.

To surface this, the author creates a TASTE.md file that records preferences rather than strict rules, e.g.:

# Our "Taste"
1. Prefer copy‑paste over speculative abstractions
2. Ugly but runnable code beats over‑engineered elegance
3. Trust a readable 50‑line implementation over a clever 10‑line one
4. Explicit error handling beats elegant exception chains

These are not formal rules but valuable shadows of judgment.

4. Pitfall: Turning "Taste" into a KPI

A team quantified "code taste" into dozens of rules and let AI enforce them. The code became compliant, but developers stopped making changes for fear of breaking a rule, and new requirements were filtered through the rule set instead of user needs.

This illustrates Goodhart’s Law: when a measure becomes a target, it gets distorted.

Advice: Preserve Unmeasurable Space

The author deliberately leaves four areas undocumented: strategic direction, core values, muscle‑memory taboos, and aesthetic debates, because forcing them into rules would stifle flexibility.

5. From Today, Make Knowledge Explicit – AI as a Mirror, Not a Leash

Three‑step approach:

Write the "why" instead of the "how". Example markdown explains why a module is ugly: micro‑service attempts added 30 ms latency, exponential debugging complexity, and onboarding time grew from 1 week to 1 month, making the cost too high.

Document the "no". Create NO.md or AVOID.md listing prohibitions, e.g., no inheritance deeper than two levels, no caching user sessions, no Friday‑afternoon releases, no V2/V3 naming.

Regularly review your taste. Spend half an hour each month discussing recent code that felt "off", AI suggestions that missed the mark, and potential improvements, then update TASTE.md accordingly.

These practices turn personal, undocumented engineering judgment into reusable, AI‑understandable assets.

The eight‑year veteran engineer spent two hours writing a "Project Taste" document not for AI, but for himself; AI merely forced him to confront the tacit knowledge he thought he already knew.

This is not an efficiency tool; it is a forced cognitive cleanup that is just beginning.