Experience · Domain priors · Process priors

Experience Is Compressed Priors — and You Can Now Record Both Kinds

“Have you done this before?” is really asking whether you carry compressed domain priors and process priors. AI-era co-design produces both streams on every serious project — and for the first time you can record them as replayable artefacts that make each other faster.

Scott Farrell · LeverageAI · Sharpens the experience leg of the AI Learning Flywheel

I was designing a personal news radar — the kind of system that watches sources, holds unresolved attention in a queue, and tries not to spam you — and I noticed something stranger than the product itself. I was getting domain learning and process learning at the same time. What is true about systems like this. And how you find that out when you cannot fully specify the design up front. And I guess this is what people call experience.

Not the résumé line. The real thing underneath it.

Here is the funny thing about that hiring question — “Have you implemented that before?” — once you look at it while co-designing with AI. They are not only asking whether you have touched the stack. They are asking whether you carry compressed priors that change what you notice and what you do next. Hidden failure shapes. Distinctions that matter early. Paths that look reasonable and become traps. A method for discovering the unknowns you cannot name yet.

Experience is not merely having done something before. It is carrying forward compressed domain priors and process priors that change what you notice and what you do next.

The new fact is not that experience exists. The new fact is that AI-era practice lets you record both kinds — as files, traces, rejected designs, architecture decisions and frameworks — so the next project starts higher than this one ended. Most of that used to stay tacit. Industry reporting on professional services still puts the bulk of firm expertise in people’s heads, rarely written down.¹ Polanyi’s old line still holds: we know more than we can tell — until we perform it, and even then we often do not write the performance down.²

This piece is the cross-project claim. The per-project design loop that turns usage into design evidence lives in a sibling; I will point you there and not re-teach it.³ The general learning flywheel — engagement upgrades your thinking — is already published; this sharpens what the “experience” upgrade is made of.⁴

Two assets fall out of one conversation

Midway through the radar work I said something I had been feeling for a while: I am designing a new project, but I am also watching the co-authoring of the design process with AI. Out of the same conversation falls a system and a method. Two assets. The second may be more general than the first.

That is not a branding slogan. It is a description of what the work was doing.

I could not completely explain what I wanted at the start. I had the shape of it. Outside influences — other products, prior wiki thinking, real multi-source stories — forced redraws. The advances were perturbation, not pure decomposition. If you only look at the repo afterwards, you miss half of what was produced: the method for getting to a design when neither party can fully specify the answer up front.

That is the second asset. Treat it as optional meta-work and it evaporates into chat history. Treat it as experience and it compounds.

Domain priors and process priors

Every serious project produces two learning streams. They look similar in the heat of the work. They are not the same object when you file them.

Domain learning — what is true about systems like this

For the radar, domain priors looked like this:

• Signal cases beat raw posts as the unit of attention.
• Queues need serial state — developing episodes, not a firehose of items.
• Canonical anchors can change as evidence arrives.
• The broad concept belongs in durable memory; the queue holds the narrower developing episode.

Those are claims about the problem world. Once you have them, you notice different things. You stop treating every tweet as a ticket. You stop treating every repository as a new story. You start asking what would make two observations the same case — and when one case becomes two.

That grain is the domain of the signal-case queue. I will not rebuild the queue here. I need only the shape of a domain prior: a distinction that, once compressed, changes the next design move.

Process learning — how you discover what you do not know

The other stream is about method:

• Begin with a strong shape, not a complete specification.
• Perturb with external examples and prior experience.
• Build enough to encounter reality — early enough to learn, not late enough to pretend you knew.
• Inspect behaviour and traces.
• Promote surprises back into the design.
• Regenerate rather than nurse a pile of local patches when the design has moved.

Those are claims about discovery under AI co-design. They change how you run the next unknown. They are closer to what organisational theorists called double-loop learning: not only correcting errors under fixed rules, but questioning the governing variables — the goals and decision rules themselves — when experience shows the frame is wrong.⁵

Chris Argyris’s thermostat still works as a picture. Single-loop turns the heat on when the room drops below the set point. Double-loop asks why the set point is what it is.⁵ Process priors are how you get better at asking that second question with an AI that can supply historical structure, while you supply direction, taste, and the recognition of what is still wrong.

The double flywheel

The streams do not sit side by side. They accelerate each other.

A sharper domain model lets you design better probes. Better probes produce cleaner surprises. Cleaner surprises improve the process you use next time. The improved process discovers the next domain distinction faster. That is more than “learning while doing.” It is why recording both streams is not bureaucracy — it is how the pair compounds.

Organisational research keeps rediscovering a related point at firm scale: tools and talent are not enough; benefits show up when humans and machines learn from each other over time.⁶ Firms that couple organisational learning with AI — so-called Augmented Learners in one MIT SMR / BCG line of work — are reported as substantially more effective at handling external uncertainty than limited learners.⁷ I am not importing their survey into a solo design project. I am pointing at the same structural fact: learning infrastructure is not a nice-to-have wrapper around AI. It is the layer where experience stops evaporating.

The model will not remember your project for you. Session context is not organisational learning. If the priors are going to survive, they have to land in files the next loop can load.

Proof from one project: an ADR and a process rule

Abstracts are cheap. The brief’s minimum proof is one project yielding both streams with a concrete artefact for each. The radar conversation did that in the open.

Domain artefact — ADR-class decision

Decision: A queue case is an open hypothesis about a bounded developing episode — not a timeless concept and not an individual source object.

That is an architecture decision record in plain language. It is domain learning compressed into a rule you can defend, replay, and violate on purpose later if evidence demands it.

Supporting distinctions that fell out of the same work:

Those may not need three storage engines. They need three ideas. Without them the queue becomes either too broad to resolve or too narrow to accumulate meaning. With them, future design moves start from a sharper prior: you already know the grain of the thing you are building.

That is the kind of thing a résumé “experience” claim is actually pointing at — whether you have already paid for that distinction.

Process artefact — a rule for discovery

Rule: When the design is still open-ended, the next move is collision with reality and outside perturbation — not another abstract decomposition of fields you have not earned yet.

In the radar conversation that looked like: take real multi-source stories, feed observations serially, force the system (or the design) to choose attach / create / merge / split / resolve — and ask, at each step, what the case is claiming and what would make it a separate case. The point of the exercise was not a database schema. It was a Case Boundary and Lifecycle Contract discovered through serial contact, not invented in a vacuum.

A second process prior, tightly related: build early enough to learn, but never let the code become the only place where the learning lives. Patches that only exist in the implementation are experience you rented once. Promotions into design, ADRs, rejected alternatives and process rules are experience you own.

The full workshop that operationalises serial design replay is Replay-Driven Design Evolution. This article only needs the process prior as an artefact — a rule you can hand to your future self, or to an AI, at the start of the next unknown.

What “have you done this before?” is really auditing

Read the interview question as a priors audit:

Years still matter. Contact still matters. The claim is not that files replace scars. The claim is that AI projects produce scar-density so fast that scars without capture become expensive amnesia. You are turning normally tacit advantages into objects that can be replayed — by you, by a teammate, by an agent that needs better priors than the base model’s average.

That is the AI-era twist on second-hand time travel: frameworks and compressed decisions let later work start further along the path someone already walked.⁸

A two-column capture checklist

You do not need a knowledge-management programme. You need a habit at project phase boundaries — end of a design probe, end of a week, end of a release candidate. Five minutes. Two columns. Route answers into something durable (wiki page, ADR folder, team canon — pick one place and keep using it).

If you only fill the left column, you get smarter product facts and the same chaotic discovery next time. If you only fill the right column, you get methodology without domain teeth. The double flywheel needs both deposits.

This is a lighter, dual-stream version of a learning extraction ritual: sticking points, surprises, never-agains — sorted so domain and process do not collapse into one vague “lessons learned” paragraph.

The compounding test

At the end of a project, ask one question:

Did we leave merely another codebase — or a sharper dual-stream corpus that makes the next project easier and better?

A loop that piles findings into chat history is linear activity. A loop whose outputs become structured substrate the next loop reads as priors is compounding — the difference between an activity and an asset.⁹

Code is still important. Under AI, it is also regenerable. The durable intellectual capital is the architecture and the learning from which fitting code can be generated again — including the process learning that tells you how to run the generation when you do not yet know the answer.

The same radar work, viewed from another angle, is about a private corpus that gets more discriminating over time.¹⁰ This piece is not that defensibility argument. It is the prior layer underneath: what experience is, when both streams are named, and how a builder records them before the conversation ends.

What to do on the next project

1. Name the two streams early. Mid-project, say out loud: we are learning domain X and process Y. If you cannot name both, one is still invisible.
2. Write one ADR-class domain decision before you “feel done.” Not a novel — a decision, context, consequences.
3. Write one process rule that would change how you start the next unknown. Put it where your future self (or agent) will load it.
4. Keep rejected designs. The path not taken is domain and process evidence, not clutter.
5. Run the two-column checklist at phase ends. Empty cells are a smell.
6. Pass the compounding test before you call the project finished.

I will not pretend this is glamorous. It is the opposite of glamorous. It is how experience stops being a story you tell about yourself and becomes a corpus that compounds.

Have you done this before? Good. Show me the priors — both kinds.