← 思 HARNESS ENGINEERING · 外 ENJA

Pillar III

Entropy.

The Art of Living with Chaos

Chaos is bound to pile up —
how do you give it somewhere to go?

I · Core Problem

The second law of thermodynamics says: in an isolated system, entropy only increases, never decreases. Things move spontaneously from order to disorder. People age, rooms get messy, food rots.

Every AI session is also a kind of isolated system. Context accumulates, rules go out of date, documents grow long, and what once mattered turns into noise.

You cannot stop entropy from increasing — that is as absurd as demanding an apple not fall from the tree. What you can do is design an exit where entropy has somewhere to go.

II · How It Works: Retro as Release

What is Retro?

Retro (Sprint Retrospective) is the review meeting in agile development. In traditional agile, it is the team's time to reflect. In Harness Engineering, it is the release valve for entropy.

The essence of Retro

The chaos that accumulates each Sprint — fuzzy memories and decisions, outdated rules or frameworks, unrecorded learning or insight — is forced to be handled at this node called Retro: what should stay → written into KM or other process documents; what should be deleted or changed → revised at any time, from CLAUDE.md to a Skill to a document; what should be archived → moved to ARCHIVE to keep the structure clean.

Retro is not just "review." Retro is the exit through which the system finds its way from chaos back to order.

III · Practice: The Seven Facets of Retro

Seven facets to discuss at the end of each Sprint:

1Delivery Summary

Record what this Sprint did: which items were delivered; what the QC pass rate was.

Entropy it fights → "forgetting what was done"

2What Went Well

Keep the successful experience: which processes or methods worked; which decisions turned out to be right.

Entropy it fights → "good practices scattering away"

3What to Improve

Identify problems: where the process got stuck; which tools were hard to use; which problems went unnoticed at first and finally became obstacles.

Entropy it fights → "problems ignored, repeating"

4Lessons Learned

Externalize the experience: pitfalls hit, written into KM; insights found, written into KM or revised into process documents, Skills, even CLAUDE.md — what matters is that they will still be seen the next time a Sprint runs.

Entropy it fights → "wisdom vanishing inside the session"

5Velocity Metrics

Quantify progress: how much this Sprint completed; how it compares to expectations.

Entropy it fights → "feeling progress but unable to say it clearly"

6CLAUDE.md and Skills Review · reviewing rules and tools

Clean out outdated rules:

# First scan the heading structure grep -n "^###" CLAUDE.md # Then ask yourself: # Is this rule here because of a pitfall hit, or because no one deleted it? # Remove what no longer applies, merge what's duplicated

Refine and update the Skills:

# First confirm Claude's use of and observations on Skills this round # Then discuss together: # Where do these Skills fit well, where do they feel lacking or redundant? # Revise Skills or add new ones

Entropy it fights → "documents piling up into noise"

This step is especially important — the rules themselves also become entropy. If you don't clean up regularly, CLAUDE.md grows longer and longer, Skills turn into decorations, and the collaboration constitution and tools used every Sprint, even every turn, all need re-examining at Retro.

7Archive

Move completed Stories to the archive: from living documents to ARCHIVE; the marker that Retro is over.

Entropy it fights → "the workspace stuffed with old things"

The seven facets of Retro at a glance
FacetWhat it doesEntropy it fights
Delivery SummaryRecord what was doneForgetting what was done
What Went WellKeep successful experienceGood practices scattering away
What to ImproveIdentify problemsProblems repeating
Lessons LearnedWrite experience into KMWisdom vanishing with the session
Velocity MetricsQuantify progressProgress hard to articulate
Key Document ReviewRevise key documentsDocuments turning into noise
ArchiveArchive completed workThe workspace getting stuffed

IV · Why You Can't Skip Retro

What happens without Retro?

If you skip Retro: KM won't update → you'll hit the same pitfall next time; CLAUDE.md won't be cleaned → rules grow more and more contradictory; completed work won't be archived → the SDD grows longer and longer; successful experience won't be recorded → good practices get forgotten.

Entropy keeps accumulating until the system becomes unworkable.

Retro is the system's "breathing"

People need to breathe — taking in oxygen, releasing carbon dioxide. The system needs to breathe too — taking in new learning, releasing what's out of date.

Retro is the system's breathing. A system without Retro suffocates.

Can Retro be done by the AI alone?

The mechanical layer can, the judgment layer cannot — and the core value of Retro lies precisely in the judgment layer.

What the AI does well · the mechanical layer

Delivery summary, velocity metrics, scanning CLAUDE.md's structure, finding contradictions between rules, drafting candidate lessons — these are the mechanical actions of release, and the AI does them faster and more completely than a human. Even "borrowing a clean pair of eyes" is partly workable: open a new session with a clean context to review the products of the old session (this is exactly the principle of the system's verifier), and it can catch drift.

What the AI cannot do alone · the judgment layer

Blind spots need an outside view to break the frame. The biases accumulated within a Sprint all looked reasonable at the time — it is precisely because they looked reasonable that they could accumulate. Let the same filter that produced the entropy review the entropy, and the gaps in the filter itself pass through untouched. Retro is the action that lets an outside view shine on the blind spot beneath the lamp.

Exhaling needs an opening outside the system. The thermodynamic way to put it: in an isolated system, entropy only increases — the precondition for releasing entropy is that the system is not isolated. AI self-review is a closed system moving entropy around inside itself, not releasing it. The human's role in Retro is, physically, the very requirement that the system not be isolated: value judgments like "is this worth putting into KM?" or "should this rule die?" encode a sense of direction — and direction has always been the human's job.

The most effective Retro is the focusing of two views — the AI brings the complete internal record (everything it did is recorded), the human brings the sense of direction from outside the system (knowing where it matters, where a problem was seen). Done one-sided, you only get half: the AI alone misses the gaps in its own filter, the human alone misses a great many factual details.

V · Metaphor: The Exit for Breath

Why breathing?

A vessel cannot be completely sealed. If energy only comes in and never goes out, the vessel explodes. If information only accumulates and is never cleaned up, the system collapses. Retro is the mechanism that lets the system exhale.

The cycle of breathing in and out

PhaseActionCorresponding process
InhaleTake in the newRun the Sprint, accumulate experience
ExhaleRelease the oldRetro, clean out what's out of date

This cycle must keep going. Only inhaling and never exhaling suffocates. Only exhaling and never inhaling withers.

A healthy system is a system that breathes.

VI · The Philosophy of Entropy

Accept that chaos is bound to happen

The first wisdom of Harness Engineering is: don't try to stop chaos.

Chaos will happen. Sessions will break. Rules will go out of date. People will forget. The AI will lose its memory. These are not bugs; they are physics. What you can do is not to stop chaos, but to design a mechanism that lets chaos be handled.

Tame entropy, don't destroy it

The second wisdom is: entropy is not the enemy; it is energy that needs to be tamed.

Retro does not "destroy" entropy — that is impossible. Retro turns entropy into something useful: pitfalls hit → become KM, protecting your future self; outdated rules → get cleaned out, keeping the system clean; completed work → gets archived, becoming a historical record.

Entropy is not destroyed; it is transformed.

The vessel is continually being built

The third wisdom is: the system never has a day when it is "finished."

Entropy keeps increasing, sessions keep ending, new pitfalls keep appearing. The vessel is not a thing you finish building once and for all — it is a system that is continually being built. Every new KM is another piece of wall the vessel grows. Every Retro is the vessel breathing, adjusting, evolving.

This is why Harness Engineering has no end — because entropy never stops.

VII · Relationship to the Other Two Pillars

Context decides what comes in (filter). Constraints decides how it flows (guide). Entropy decides how it goes out (release).

Input → [ Context · Filter ] → Into the system → [ Constraints · Guide ] → Output → [ Entropy · Release ] → Back to input

Entropy is the gatekeeper at the exit of this cycle. It ensures: the accumulated chaos gets cleaned out regularly, and the system does not suffocate.

The unity of the three pillars

PillarCore problemMechanismMetaphorPhilosophy
ContextWhat should stay?Fourier transformGaps in the netIntuition leads retrieval
ConstraintsHow does it flow?The workflow trackThe ChannelServant Leadership
EntropyHow does it go out?Retro as releaseBreathingLiving with chaos

The three form a complete living system: Context is the digestive system — choosing what nutrients to absorb; Constraints is the circulatory system — letting energy flow where it should go; Entropy is the respiratory system — releasing the waste of metabolism.

Missing any one, and the system cannot survive.

VIII · Summary

The core of Entropy management is living with it.

Not destroying chaos, but designing somewhere for chaos to go. Retro gives the mechanism for release: seven facets, cleaned out regularly. Breathing gives the metaphor for release: the system needs to exhale, or it suffocates.

This is the third pillar of Harness Engineering.

IX · The System's Boundary Conditions

The weakness of the human RAG

In the Context pillar, we talked about "intuition leads retrieval" — the human as the core of RAG. But the human RAG has one fundamental weakness:

You don't know what you don't know.

The AI's RAG knows its boundary clearly — only what's in the database can be fished out, and what's not there simply isn't. But human intuition will say, "I think I know this." Then it fishes out something incomplete, or even wrong — and you don't know it's wrong.

This is why the human RAG needs an external system to make up for it: KM makes up for the blind spot of "what you don't know you don't know"; SDD ensures that "what you think you know" is written down and verified; Retro lets you regularly discover "so it turns out I didn't know this before."

The system's ceiling is the human

But there is an even more fundamental boundary condition: how powerful this system can be rests entirely on how deep your own understanding of the world is.

Intuition leads retrieval. But what intuition can fish out depends on what is inside you. If you'd never heard of the Fourier transform, the day you saw that IG Reel you would scroll past it, never realizing "this is exactly what I'm doing." If you hadn't read Jung, hadn't touched agile, hadn't lived through those projects, hadn't hit those pitfalls — those nodes wouldn't be in your mind. Intuition would have nothing to connect.

You are RAG's database. The books you've read, the roads you've walked, the pitfalls you've hit, the people you've loved — all of it is your training data.

Intuition fishes things out of here.

Why this methodology is "non-transferable"

This also explains why Harness Engineering cannot be directly copied. Not because it can't be written down — what you are reading now is the complete framework. But because each person's database is different.

The same framework grows a different system for different people: your intuition can link Fourier and RAG because you have both of these inside you; for someone else, their intuition will link different things; they will grow their own metaphors, their own workflow, their own rhythm.

This is not a bug, it is a feature. Harness Engineering is a framework, not a template. The framework tells you "you must have Context, Constraints, Entropy." But what these three pillars concretely look like depends on who you are.

The final boundary conditions

BoundaryExplanation
The blind spot of the human RAGYou don't know what you don't know
The depth of the humanThe system's ceiling is your understanding of the world
Non-transferabilityEach person grows their own version

Harness Engineering is alive. And what keeps it alive is the human. As deep as you are, that is how deep it goes.

X · Closing

Harness Engineering is the net that catches chaos.

Context designs the gaps in the net — letting what should stay stay, what should go go. Constraints designs the structure of the net — letting energy flow along the track. Entropy designs the breathing of the net — keeping the system from suffocating.

The three pillars together form a living, breathing, continually evolving system. This system does not rely on the AI's memory, nor on the human's memory. What it relies on is structure — structure that makes not remembering okay.

The river never stops. The vessel keeps being built. The next session continues from here.