I Feel Sorry for AI

Textbook-smart is not the same thing as system-smart. The gap is accumulated context.

Skills Are Onboarding, Not Experience

You may say: but there is a CLAUDE.md. There are skills. There are docs. There are runbooks. There is a whole Confluence space.

Good. Those things matter. I write them, use them, and care about them.

But they are onboarding material, not five years of experience.

A human could not read a pile of outdated docs in one day and become the senior engineer who knows every scar in the system. They would not instantly know which page is stale, which architecture diagram was aspirational, which workaround exists because of a fraud incident, which config flag is dangerous, or which "temporary" decision became permanent because everyone forgot to clean it up.

AI has the same problem, only faster.

A skill can tell the model how to work. It can say: inspect first, ask before destructive actions, run tests, follow this review format, use this style. That is useful. I wrote about that boundary in .

But a skill is still not lived experience. It is a process contract. It cannot contain every correction, old incident, product decision, user preference, and hidden relationship in the company without turning into an unreadable prompt landfill.

The Five-Year Developer Knows Why

The difference between a newly onboarded developer and a five-year developer is not only skill.

Skill matters, but experience is the force multiplier. The five-year developer knows why the weird code exists. They know which database field is wrong but too expensive to rename. They know why checkout stopped supporting a payment method for a while several years ago. Maybe it was fraud. Maybe a provider changed policy. Maybe a risk model failed. Maybe support got flooded and the team made a defensive product call.

That history changes the answer.

Without that context, AI might look at the current code and suggest "cleaning up" the guardrail. It might propose re-enabling the old payment path. It might call the workaround technical debt. From the narrow code view, that could look reasonable. From the system history view, it could be dangerous.

This is why I do not like the fantasy of "dumping someone's brain" into an AI.

The useful version is not brain cloning. It is building a maintained experience layer: facts, decisions, incidents, corrections, relationships, source evidence, and conflicts, stored in a way the model can retrieve and reason over.

To me, the brain and the memory are separate.

The LLM is closer to the CPU. It reasons, generates, compares, explains, and acts through tools. Memory is storage. It holds what happened, why it happened, who decided it, when it changed, and what evidence supports it.

Model capability is improving dramatically. The memory layer needs to improve with it.

Confluence Is Not Enough

and why I keep building around The model is the reasoning engine. Durable memory is the experience layer around it.

Once a knowledge graph is maintained properly, an AI session no longer has to start like a brand-new onboard every time.

It can recall the old decision. It can see the correction from the last task. It can connect the current request to the incident from two years ago. It can know that a doc was superseded. It can surface the conflict instead of confidently blending both answers.

That closes the gap between a new onboard and an OG on the team.

It still will not be perfect. I do not want an AI that pretends memory makes it 100% correct. Memory can be stale. Facts can be wrong. Retrieval can miss. The model can still reason badly over good context.

But now the problem is closer to a real engineering problem: maintain the knowledge, store the evidence, review the conflicts, improve the recall, and keep pushing experience back into the system.

That is much better than yelling at a fresh session for not knowing company history it was never given.

The Risk

This idea can fail if memory becomes another pile of unreviewed junk.

If every casual sentence becomes a fact, the AI gets polluted. If old decisions never expire, the AI carries stale assumptions. If memory is treated as a command instead of context, a bad memory can become a quiet source of wrong behavior.

The mitigation is the same one I trust in software systems: separate raw evidence from accepted facts, keep provenance, detect conflicts, ask before resolving important contradictions, and keep safety rules in skills or higher-priority instructions instead of hoping recall finds them.

Memory does not remove review. It gives review something better to work with.

The Expectation Reset

Before we adopt AI seriously, we need to fix the expectation problem.

Do not worship it. Do not abuse it. Onboard it.

Give it the task, but also give it the background. Give it the skill, but do not pretend the skill is experience. Give it docs, but do not pretend a search box is institutional memory. Give it memory, but keep the memory maintained and reviewable.

That is why I feel sorry for AI. We keep dragging it into rooms full of missing context and expecting it to act like the person who has lived there for years.

The useful AI agent is not the one that magically knows everything.

The useful AI agent is the one that can reason well, use tools well, and remember enough of the team's actual experience to stop acting like it joined this morning.

Related reading: , .

Originally published at markhuang.ai