What actually matters is far less intuitive, and it changes how we should think about LLMs as instruments for creativity.

The Broken Promise of the Creative Prompt

Ask any major LLM for novel solutions to a real problem and you usually get back a polished recombination of known best practices.

Take this question: How can we better prevent technical debt in large enterprise IT projects with fixed dates and budgets?

You’ll typically receive: short Agile sprints, 15-25% refactoring buffers, SonarQube, “stop the line” culture, and KPIs in vendor contracts. Useful and professional, but entirely predictable.

If you’re looking for established best practices, this is exactly what you want. The model is doing what it was trained to do, interpolating the most statistically probable patterns in its training data, and for consolidating known solutions that is a strength.

But if you’re looking for a genuinely new idea, something no one has tried, then that same interpolation is the obstacle. The model is fine; we’re asking it to perform the wrong operation.

Directed Metaphorical Association

Years ago, while researching creative systems, I started experimenting with a different approach: directed metaphorical association. Instead of asking for solutions directly, you identify the strong semantic concepts in a problem, pull rich metaphors from distant domains, transfer properties across the gap, and let the human judge what emerges.

The logic is simple. If you ask an LLM to solve a technical debt problem, it searches its training data for content about technical debt. You get back what the industry already knows. But if you ask it to find structural parallels between technical debt and, say, scuba diving, the model is forced to traverse a completely different region of its knowledge. The connections it finds can’t be recycled best practices, because no one has written about the intersection of nitrogen absorption and code quality.

At the time I developed this, it was all manual. Today, the attention mechanism in Transformer-based LLMs lets us scale this approach dramatically: the model can compute semantic relationships across domains far richer than anything I could code by hand.

But scaling it revealed something I didn’t expect. The results weren’t uniformly creative. Some metaphorical transfers landed immediately and felt actionable. Others were intellectually fascinating but resisted any practical application. At first I assumed this was noise, since some metaphors just work better than others. But the pattern was too consistent to be random, and it turned out to be more interesting than the ideas themselves.

Same Problem, Directed Metaphors

When I applied the method to the technical debt question, directing the LLM to generate metaphorical associations from distant domains rather than recombine known practices, four ideas emerged:

Directed fermentation. In cheesemaking, you don’t fight bacterial activity; you control which bacteria dominate. The distinction that matters is controlled versus uncontrolled, not clean versus dirty. A bad cheese isn’t a cheese with bacteria; it’s a cheese with the wrong bacteria.

Transfer: maintain a catalog of authorized shortcuts (a “starter culture”), each with its documented lifespan and self-replacement rule. Debt that follows the starter is tolerated. Debt outside it is rejected. You stop trying to eliminate debt and start trying to control which debt lives in your system.

Mandatory decompression. In scuba diving, nitrogen dissolves in the blood under pressure. That’s physics, not a negotiation. If the diver ascends too fast, the nitrogen forms bubbles. Since preventing nitrogen absorption is impossible under pressure, the solution is decompression stops, calculated mathematically and non-negotiable.

Transfer: accept that fixed deadlines and budgets will dissolve debt into the codebase. That’s a law of development under pressure, not a failure of discipline. Model debt accumulation as a calculable variable and insert mandatory decompression windows whose length is determined by the model, not by managerial goodwill. You don’t negotiate the laws of physics.

Programmed selective amnesia. The brain actively prunes weak synaptic connections during sleep. Forgetting is a survival mechanism, not a malfunction. Without this pruning, the brain saturates, loses its ability to discriminate, and starts treating noise as signal.

Transfer: at fixed intervals, delete entire modules and force them to be rewritten from their behavioral contract alone. This sounds radical, but the point is what the deletion reveals. Code that cannot be reconstructed from its spec exposes that the spec was insufficient: the real debt was in the specification all along, not in the code.

Unrehearsed ensemble. Jazz bands booked for festival slots with non-negotiable stage times cram complex new arrangements into minimal rehearsal hours. Every player memorizes the charts individually. But onstage, the improvisation falls apart into disjointed solos, because knowing the material individually is not the same as having internalized it as shared group intuition.

Transfer: a team where every developer knows the codebase individually can still produce incoherent architecture, because no one has built the shared intuition of how the system wants to evolve. The debt lies in the absence of collective internalization, which only emerges from working together on the same problems over time, rather than in any individual’s competence.

Something Is Off

Read those four ideas again. Two of them, fermentation and decompression, feel immediately actionable. You could present them to a project director tomorrow and have a productive conversation. They fit inside the existing mental model of how IT projects work; they just reframe a specific aspect of it.

The other two, selective amnesia and the unrehearsed ensemble, are more demanding. They don’t reframe an aspect of the existing model. They ask you to question what you consider the primary artifact (is it the code or the spec?), or what “team competence” even means (is it individual knowledge or collective intuition?). You can’t just “apply” them. You’d need to rethink something basic first.

This isn’t a question of quality. All four are intellectually rich. But they operate at different levels, and that difference is consistent and reproducible enough to be worth understanding.

The Red Herring: Semantic Distance

The obvious explanation would be that some metaphors are simply “too far” from the target domain. That’s the classical thesis from Mednick (1962): close associations are banal, distant associations are incomprehensible, and creativity sits in an optimal zone in between. It’s an elegant idea, and it has dominated the creativity literature for over sixty years.

But it doesn’t explain what we’re seeing here. Fermentation comes from biology. Selective amnesia comes from neuroscience. Both are roughly equidistant from software engineering. Yet the first is immediately applicable and the second is not.

If distance were the relevant variable, ideas from similarly distant domains should behave similarly. They don’t, so something else is at work.

First Finding: Transfer Granularity

What separates the two groups is the size of what gets transferred, not distance, since both draw from domains equally far from software engineering.

Look at what each idea actually imports from its source domain:

Fermentation imports a single rule: “the relevant distinction is not presence versus absence, it’s controlled versus uncontrolled.” One causal relationship, stripped of all cheesemaking context. You can plug it directly into a conversation about technical debt without asking anyone to change how they think about software.

Decompression imports a single rule as well: “accumulation under pressure is a physical law, and the stops are calculable.” The diving context is gone. What remains is a structural insight that maps cleanly onto fixed-deadline projects.

Now look at what the unrehearsed ensemble imports. Instead of a single rule, it brings a system of relationships: the idea that individual competence does not produce collective competence, that shared intuition is a distinct artifact that only emerges from sustained joint practice, and that the absence of this artifact produces incoherence even when every individual performs well. To apply this to a software team, you need to accept all of these premises simultaneously. You’re not plugging in a rule; you’re redefining what “team competence” means (a separate thing that either exists or doesn’t, rather than the sum of individual skills).

Selective amnesia does the same thing. It doesn’t just say “delete code sometimes.” It requires you to reconceptualize what the primary artifacts are, to accept that code is expendable and specs are foundational, to rethink the relationship between implementation and contract. That’s a system of interlocking ideas, not a single transferable rule.

Semantic distance matters: it ensures the pieces are genuinely different from what the target domain already knows. But the variable that predicts whether a metaphorical idea will be immediately useful is the granularity of the transferred unit. Single causal rules are portable. Systems of relationships require a worldview shift.

Both can be valuable, but they serve different purposes, ask different things of the audience, and land on very different timescales.

Second Finding: Compression at the Right Level

If granularity is what matters, the practical question becomes: how do you control it? How do you reliably extract single causal rules from a rich source domain instead of accidentally importing entire systems?

The answer is compression.

When you extract a causal rule from a source domain, you’re performing lossy compression in the information-theoretic sense (keeping only the causal skeleton, discarding everything else). You take a rich domain, scuba diving with its physics, decompression tables, equipment protocols, certification culture, and accident case law, and you compress it down to a bare skeleton: “inevitable accumulation under pressure → calculated mandatory stops.” Everything else gets discarded. What remains is portable.

What I didn’t expect is that this compression doesn’t work as a smooth dial you can turn gradually. It has discrete levels, like quantization of a signal (steps, not a ramp). In practice, I consistently see three distinct levels:

The raw metaphor. “Technical debt is like cancer.” This is barely compressed at all. The metaphor arrives with its full baggage: diagnosis, staging, treatment, remission, relapse, death. You’re not importing a rule; you’re importing a scenario, and the scenario drags in properties that don’t map to the target domain at all. (Does technical debt metastasize? Does it have remission? The metaphor implies yes, but the reality is more complicated.)

The causal rule. “Damage at a threshold triggers an irreversible state transition.” Now the source domain’s vocabulary has disappeared entirely. You can’t tell whether this came from botany, metallurgy, or nuclear physics; it’s a pure structural relationship. It’s abstract enough to travel across any domain boundary, but concrete enough to generate specific ideas when you apply it to a new context.

The philosophical principle. “Systems under constraint reach equilibria.” This is over-compressed. It’s true of everything: thermodynamics, economics, psychology, traffic. Precisely because it applies everywhere, it generates nothing specific anywhere. It’s a tautology dressed as insight.

The intermediate level, the bare causal rule, is the only one that is simultaneously abstract enough to leave the source domain and concrete enough to land in the target domain and generate something actionable.

Too little compression, and you import baggage. Too much, and you import nothing.

Useful creativity, it turns out, is a compression problem, and the sweet spot is a discrete level rather than a point on a continuous dial.

What This Means

These two findings already change how you use an LLM for creative work.

If you want ideas that are immediately actionable, direct the model to extract single causal rules from distant domains, stripped of all source vocabulary. Force compression to the intermediate level. If you can still tell which domain a rule came from, it’s not compressed enough. If you can’t imagine applying it to anything specific, it’s compressed too far.

But when I started applying this systematically, I ran into something I didn’t expect. I had a catalog of beautifully compressed rules. Each one mapped onto the target problem with uncomfortable precision. And yet I still couldn’t turn any of them into a solution. Understanding how a problem works turned out to be a completely different operation from knowing what to do about it. That gap, and what fills it, is what Part II is about.

Gabriel Mailhot is a Senior Subject Matter Expert at Desjardins, where he works on development practices, architecture, and complex organizational problems spanning technology, process, and governance. His 2003–2010 research focused on creative systems and metaphor-based retrieval. He publishes at scripting.pro.

The Limitation I Didn’t See

By the end of Part I, I could reliably extract clean, compressed causal rules from distant domains. Rules like “accumulation under pressure is physics, not a choice” or “the distinction that matters is controlled versus uncontrolled.” Each one a precise diagnosis of how a problem works.

But that’s exactly what they were: diagnoses, X-rays of the pathology rather than solutions.

I spent a while assuming the solution would naturally follow from understanding the cause. It doesn’t. Understanding that nitrogen dissolves in blood under pressure doesn’t tell you to invent decompression stops. The leap from “here’s how the problem works” to “here’s how to break the mechanism” requires a separate act, one that is creative in a way the diagnosis is not.

When I systematized the method by asking an LLM to extract compressed causal rules from many distant domains at once, I could see this limitation clearly. The results were clean and powerful:

“Functional-but-carrying agents propagate the problem because there is no incentive to detect them.” (from epidemiology)

“Repeated sub-critical stress accumulates invisibly until failure occurs without proportional warning.” (from metallurgy)

“Control by outcome alone makes it impossible to distinguish systemic success from accidental success.” (from fermentation science)

Each maps onto technical debt with uncomfortable precision. The epidemiological rule describes how “working” code that carries hidden debt propagates undetected. The metallurgical rule describes how small daily compromises accumulate into sudden, catastrophic failures. The fermentation rule describes how testing only the final product hides whether the process was sound. Yet for all their diagnostic value, not one of them tells you what to do.

The Missing Operation: Inversion

The creative act that turns a diagnosis into a solution is inversion: deliberately breaking the causal chain at a chosen point.

In its simplest form, a diagnosis says “A causes B, which causes C.” Inversion asks what happens if I prevent A from causing B, or if I let B happen but prevent it from causing C. Each break point produces a different family of solutions, often of completely different nature.

In practice this is less obvious than it sounds, because a single causal chain can be broken at multiple points, and the choice of where to break determines not just the solution but its entire character.

Take the epidemiological rule: “functional-but-carrying agents propagate the problem because there is no incentive to detect them.” There are three links in this chain, and each one is a potential target:

Break at link 1: make the carrying agents non-functional. In software terms, design code so that debt-carrying modules stop working after a defined period. The debt itself triggers a forced replacement. This is a radical, architectural solution that changes the infrastructure.

Break at link 2: create incentives to detect, even when everything works. In software terms, reward teams for discovering latent debt rather than for delivering features. Don’t wait for symptoms; actively hunt for carriers. This is an organizational, incentive-based solution that changes the reward structure.

Break at link 3: accept propagation, but make its pathways visible. In software terms, don’t try to prevent debt from spreading; instead, instrument the codebase so that every propagation path is traced in real time. When something breaks, you know exactly which “carrier” transmitted the problem. This is an observational solution that changes what you can see.

One diagnosis yields three completely different solutions. The choice of where to break the chain is itself a creative decision that depends on the context, the constraints, and the appetite for disruption.

This is the operation that was missing from my original method. Extraction gives you a diagnosis. Inversion gives you families of possible solutions. But I wasn’t done, because the most powerful ideas I encountered weren’t single inversions. They were combinations.

Fourth Finding: Novelty Is in the Composition

Here is the central reversal of everything I thought I knew about creativity.

The entire creativity literature since Mednick (1962) has focused on the transfer as the source of novelty, on the assumption that the more distant the connection between domains, the more creative the idea. My own earlier research operated on this assumption.

What experimentation with LLMs at scale revealed is that distance is only a necessary condition. It ensures that the pieces you extract are sufficiently different from one another. But the novelty, the actual Eureka, doesn’t reside in any single extraction or any single inversion. It resides in the composition: the moment you assemble inversions from multiple, unrelated domains into a recipe that is specific to the target problem. The individual pieces aren’t surprising; the assembly is what no one has seen before.

In my own work using structural analogy as a diagnostic tool for organizations, I observe exactly this. When I import rules from biology, law, and neuroeconomics to analyze an organizational dysfunction, no individual rule surprises the domain expert. A biologist knows the first. A lawyer knows the second. An economist knows the third. What produces genuine insight is the combination: the specific way these rules interact when applied simultaneously to a context none of them were designed for.

Let me make this concrete with the technical debt example. Take two inversions from different rules:

From the epidemiological rule, break at link 2: create an incentive to detect even when everything functions normally.

From the fermentation rule: the relevant distinction is not presence versus absence, it’s controlled versus uncontrolled.

Now assemble them. You get something that, as far as I can tell, doesn’t exist in the current IT literature: reproductibility as the metric of code health.

A module is healthy not because it works, nor because its tests pass, but because two independent developers, starting from the same specification, would produce structurally similar code. If they wouldn’t (if the result depends heavily on who wrote it), then the module is a functional-but-carrying agent. It works, but its construction process was uncontrolled. It passed the outcome test while failing the process test.

Think about what this does. You’re no longer looking for bugs or measuring test coverage. You’re measuring whether the process that produced the code was controlled or accidental. The fermentation frame redefines what you’re looking for. The epidemiological inversion tells you when to look: precisely when everything appears fine.

Neither inversion alone produces this idea. The fermentation rule alone gives you a philosophical reframe, interesting but abstract. The epidemiological inversion alone gives you a detection strategy, useful but directionless. The invention is the recipe: reproductibility as a metric, triggered by the absence of alarm signals, designed to catch uncontrolled process masquerading as healthy output. It emerged from the composition, not from either piece.

Fifth Finding: The Solution Exposes the Context

There’s one more thing I got wrong initially, and it matters.

My first instinct, after developing the model, was to add a filtering step: take the composed ideas and check which ones are compatible with the target context. “This wouldn’t work here because of regulatory constraint X; eliminate it.” “This contradicts our governance model; eliminate it.” Standard feasibility analysis.

That instinct is a trap. A sufficiently compelling solution doesn’t get filtered by the context. It exposes the context. When a good idea collides with an organizational, regulatory, or cultural constraint, there are two readings: either the idea is unrealistic, or the constraint itself deserves to be questioned.

The most transformative Eureka is not “this solution works in my world” but “this solution is so compelling that I’m willing to change my world to make it work.” The friction between the idea and the context is a diagnostic of which constraints are actually serving you and which ones have outlived their purpose, not a bug in the creative process.

This has happened before at industry scale. Agile was not “applicable” in the world of waterfall. It didn’t fit the existing governance, contracts, or PMO structure. But it exposed that waterfall rested on a false assumption: that you can fully specify a system before building it. DevOps was not “applicable” in organizations where development and operations were separate silos with separate incentives. But it exposed that the separation itself was the root cause of deployment failures. In both cases, the idea didn’t adapt to the context. The context restructured itself around the idea, because the idea was compelling enough to justify the cost of change. Entire organizations rewrote their processes, their team structures, their governance models. They did so not because a consultant told them to, but because the solution showed the constraints to be obstacles rather than laws.

The idea didn’t adapt to the context. The context restructured itself around the idea.

The same mechanism operates at smaller scales. In my work at a major financial institution regulated by federal and provincial authorities, I’ve seen a creative solution to a development process problem run directly into a regulatory rule that everyone assumed was immutable. But the solution was transformative enough to create the will to engage the regulator in a conversation about whether that rule was still serving its original purpose. Instead of the constraint killing the idea, the idea questioned the constraint. And the list of constraints exposed became a deliverable as valuable as the solution itself.

The Complete Model

Creativity, then, is not a single operation. It is a sequence of three, which I’ll call the Extraction-Inversion-Composition framework (EIC):

Extraction. Compress distant domains into minimal causal rules at the right discrete level: abstract enough to be portable, concrete enough to be operational. This is the preparatory step. LLMs do it extraordinarily well.

Inversion. Identify where each causal chain can be broken. Each breakpoint opens a family of solutions of a different nature. The choice of breakpoint is context-dependent and already involves judgment, but an LLM can enumerate the options systematically.

Composition. Assemble inversions from different rules into a coherent recipe for the target domain. This is where genuine novelty emerges: in the combinatorics of the assembly, not in the individual pieces.

The framework rests on three claims, each of which challenges a different assumption in the existing creativity literature:

First, the causal rule (not the metaphor, the analogy, or the concept) is the correct unit of creative transfer. It is the only level of compression that is simultaneously portable and operational.

Second, inversion is the missing operation between diagnosis and solution. The creativity literature treats the transfer as the creative act, but the transfer only produces a diagnosis. Inversion produces families of solutions. Without it, you have insight without agency.

Third, novelty emerges from composition, not from transfer. The distance between domains ensures that the pieces are different. But the invention is in the assembly, in the specific combination of inversions that no one has tried before.

Each composed proposal is then judged on three levels of strength:

Logical strength: does the inversion actually break the causal chain? This is a structural coherence judgment. An LLM handles it well.

Transformative strength: is the solution compelling enough to justify questioning the constraints that stand in its way? An LLM can partially assess this; it can evaluate whether a proposal is radical and explain why.

Political strength: will the actual actors have the will and power to modify the exposed constraints? This is a situated judgment, anchored in knowledge of power dynamics, culture, and institutional history. Here, and only here, the human is irreplaceable.

What Comes Next

The EIC framework now feels complete on paper. But a model is only as good as its results in practice.

In Part III, I turn the framework into a concrete instrument (a carefully constrained prompt) and test it cold on three different LLMs with the same technical debt problem.

The results reveal something unexpected about the creative signatures of different models, about the limits of prompts as specifications, and about where human judgment remains irreplaceable.

Gabriel Mailhot is a Senior Subject Matter Expert at Desjardins, where he works on development practices, architecture, and complex organizational problems spanning technology, process, and governance. His 2003–2010 research focused on creative systems and metaphor-based retrieval. He publishes at scripting.pro.

The Calibrated Prompt

Here is the prompt I now use. It implements the three EIC operations directly. Rather than a heuristic, the prompt is a constraint system designed to force traversal of distant conceptual spaces and prevent regression toward known solutions. Each constraint maps to a specific failure mode observed in testing:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

For the following problem:
[INSERT PROBLEM]

Step 1 — Extraction
Name 8-10 specific, concrete domains FAR from the problem domain.
Choose your own domains — do NOT reuse any domain mentioned
in this prompt. For each domain:
- Name the domain explicitly.
- Describe ONE specific phenomenon in 2-3 sentences.
- Extract the causal rule in the form
  [condition] → [mechanism] → [consequence].
- Compress until no domain-specific vocabulary remains.

TEST: if the compressed rule reads like systems theory, control
theory, or generic organizational advice, you haven't gone far
enough. Start over with a more concrete phenomenon.

Step 2 — Inversion
For each rule, identify 2-3 breakpoints in the causal chain.
For each breakpoint, describe a concrete intervention — not the
negation of the condition, but a structurally different mechanism
that disrupts the link. If your inversion is simply "do the
opposite," it's not an inversion — find a different angle.

Step 3 — Composition
Propose 3-5 recipes that combine inversions from DIFFERENT rules
(each recipe must use at least two). For each recipe:
- Name it.
- Explain how the inversions interact — what does their
  combination produce that neither produces alone?
- A strong composition does not just SOLVE the problem better.
  It REDEFINES what the problem is, what you measure, or what
  counts as success. If your recipe is a process improvement
  or an architecture, push further — what does it reveal about
  the problem itself that no one was seeing?
- Describe a concrete implementation scenario in 3-4 sentences.
- Assess its transformative strength.
- List the constraints it exposes.

Do not filter for current applicability. Maximize transformative
strength.

Every constraint in this prompt maps to a lesson from the theory. The self-test on extraction prevents over-compression to the philosophical-principle level. The “not the negation” rule on inversions prevents mechanical breakpoints. The redefinition instruction on compositions forces the model past the architecture level into genuine reconceptualization. Remove any of these constraints and the output quality degrades measurably.

What Happened When I Tested This

I gave this prompt cold to three different LLMs (ChatGPT, Grok, and Gemini), with no conversation, just the prompt and the technical debt problem. The results genuinely surprised me.

Both models produced legitimate creative output. The extraction worked: concrete domains (glassblowing, commercial beekeeping, bonsai cultivation, ice climbing, jazz band rehearsal), specific phenomena described in detail, compressed rules that were portable without reading like systems theory. The self-test constraint did its job: the models actually traversed distant domains instead of staying in abstract territory.

The inversions were also substantive. Rather than mechanical negations, they were structurally different interventions: “hot-swap modular subsystems as quick-replace cartridges,” “timber sold as regrowth futures contracts that pay bonuses only after next-cycle viability is certified,” “exhibition tree leasing model where operators display but do not own the final specimen.” These are genuinely inventive mechanisms.

The compositions reached the redefinition level. Both models produced statements that reconceptualize the problem rather than solving it incrementally. “Progress is not continuous delivery. Progress is the ability to survive interruption without degradation.” “There is no such thing as technical debt repayment. There is only continuous structural shaping.”

What interested me most, though, was that the two models produced qualitatively different results from the same prompt.

ChatGPT’s compositions were aphoristic and trenchant, tight redefinitions that read almost like proverbs. “Failure is not an event. Failure is a state the system is allowed to approach.” These are memorable and conceptually sharp.

Grok’s compositions were richer in texture and more operational. Where ChatGPT redefined in a sentence, Grok invented economic structures: “regrowth futures contracts,” “colony equity pools,” “maturity tokens that investors trade instead of bottled product.” Grok’s output was less tweetable but more implementable; you could see how to build each idea.

A third model, Gemini, pushed the extraction further still, into forensic taphonomy, dendrochronology, and ballistics, and produced what may be the most radical redefinition of all: the problem isn’t technical debt, it’s premature solidification. Debt is only debt if it’s locked into the final structure. Keep the system in a fluid state until the last possible moment, and the concept of debt dissolves entirely. Where ChatGPT redefined in aphorisms and Grok in economic structures, Gemini redefined through physical-state metaphors: a third creative signature from a third training lineage.

With the same theory, prompt, and problem, I got three different creative profiles. The difference lies not in the quality of the output but in its nature, and that nature is a direct reflection of each model’s training data and architecture. For any serious creative work, then, testing the same prompt across multiple models is essential rather than redundant, because each model will illuminate a different region of the solution space.

The Remaining Gap

The prompt produced results I’d call genuinely creative. But there’s a level it didn’t reach on its own.

Earlier, through sustained iterative conversation, I produced a concept (reproductibility as the metric of code health) that emerged from a specific collision between two specific rules at a specific moment of dialogue. I had noticed that causal rules were diagnostics, said so, and the model pivoted. That pivot, and the insight it produced, didn’t come from the prompt. It came from a human observing an intermediate result, naming what was wrong with it, and redirecting.

The prompt handles extraction and inversion reliably. It pushes composition to the redefinition level. But the highest-order insights, the ones that emerge from the friction between a human’s situated judgment and a model’s combinatorial power, still require iterative dialogue. The prompt is the instrument’s score; the conversation is the performance.

This has implications beyond creative brainstorming. The current industry push toward autonomous AI agents rests on the assumption that if the specification is good enough, the agent can execute independently. A spec, however detailed, is a frozen prompt. It captures intent at a point in time. What it cannot capture is the judgment that happens during execution: the moment when a human looks at an intermediate result and says “this is too abstract” or “you’re recombining known patterns” or “go further.” That judgment acts as a steering mechanism throughout, not as a quality check at the end.

This doesn’t mean autonomous agents are useless. They are interpolation engines, excellent for well-defined, bounded tasks where the acceptable output space is known in advance. But for any task that requires genuinely novel output (creative problem-solving, architectural invention, strategic design), the human in the loop is the creative engine rather than a safety net, and the LLM is the fuel.

Angine de Poitrine and the Universality Test

I developed the EIC framework through IT problems: technical debt, organizational architecture, QA strategy. But a theory of creativity that only works in engineering isn’t much of a theory. So I tested its limits against the most unlikely case I could find.

In April 2026, the masked math-rock duo Angine de Poitrine from Chicoutimi became the most viral act on Spotify worldwide. They play microtonal rock with polyrhythmic structures, wear papier-mâché masks, sing in an invented language, and describe themselves as a “Mantra-Rock Dada Pythagorean-Cubist Orchestra.” Their success is improbable by every industry metric, yet the model accounts for it.

Underneath their buzz lies a causal chain that no one has formalized. The music industry has been optimizing its output toward a statistical center for decades, through the formulas, timbres, and structures that maximize engagement. Generative AI accelerated this trend to a saturation point. As optimized content proliferates, the public loses its sense of human authenticity in what it hears. That erosion creates a need (not conscious, not articulated, but real) to reaffirm an identity distinct from the machine. And that need translates into a valorization of the improbable: the more something is manifestly non-optimizable, the more it functions as proof of humanity.

That’s a causal chain: [optimization saturation → authenticity erosion → need for human identity → valorization of the improbable]. You can extract it, compress it, invert it at different links.

But the composition thesis is what Angine de Poitrine validates most clearly. None of their ingredients is new. Math-rock has existed since the 1990s. Microtonal music since Charles Ives. Stage masks since the Residents. Dada aesthetics since 1916. Repetitive loops since minimalism. What is new is the recipe: the specific combination of these elements, in this order, with this attitude, at this precise cultural moment. No critic could have predicted that these ingredients, assembled this way, would produce a global phenomenon. The invention lies in the assembly.

They also validate the fifth finding most powerfully of all. The duo never filtered their art to fit the existing industry constraints. They didn’t ask whether instrumental microtonal rock sung in an invented language was “commercially viable.” By existing in authentically non-conforming fashion, they exposed that the industry had optimized humanity out of its own music. They succeeded because of their improbability, not despite it, and revealed the constraints of the system by refusing to submit to them.

Limitations

The EIC framework has boundaries I want to be explicit about.

The quality of extraction depends entirely on whether the model actually traverses distant domains or takes the path of least statistical resistance. The prompt constraints help, but they don’t guarantee it, and different models respond differently to the same constraints. There is no automatic way to verify that a compressed rule is genuinely novel rather than systems theory in disguise. That verification still requires human judgment.

Evaluating composition quality is harder still. I can recognize that “reproductibility as the metric of code health” is a redefinition rather than a process improvement. But I can’t formalize why I recognize it, which means I can’t automate the evaluation. Any benchmark built on this framework will require human evaluators, with all the subjectivity that implies.

The framework is strongest in domains with identifiable causal structures, such as engineering, organizational design, strategy, and medicine. I tested it against a cultural phenomenon (Angine de Poitrine) and the model held, but the causal structure there is in the system surrounding the artifact, not in the artifact itself. For domains where causality is less clear (pure art, fundamental research, philosophy), the framework may not apply, or may apply only partially.

Finally, the iterative conversation still produces results that the autonomous prompt does not. I’ve been honest about this throughout the article, but it bears repeating as a limitation: the EIC framework as a prompt is a useful instrument, but it is not a replacement for sustained human-LLM dialogue.

Then and Now

For a long time I thought creativity lived primarily in the metaphorical transfer, the initial connection between distant domains. LLMs gave me an experimental instrument I didn’t have before. By automating extraction at scale, they made visible what was hidden: transfer is preparatory. The real creative work happens in the composition.

One last thought. Beyond brainstorming, the prompt in this article can serve as a measurement instrument. Apply the same prompt to the same problem on different models and compare the results along three axes: depth of extraction, originality of inversions, and level of redefinition in compositions. My tests showed that different models produce qualitatively different creative profiles from identical inputs, and those differences are themselves interesting data. If researchers want to formalize a benchmark for computationally-assisted creativity, the EIC framework is designed to serve as a starting point.

The most powerful ideas are not the ones that adapt neatly to our current world, but the ones that make us willing to change it. Now I know what to look for.

But one question wouldn’t leave me alone. The EIC framework works forward, from problem to solution. But if causal rules are truly portable across domains, the framework should work in the other direction too. What happens when you start from a solution instead of a problem? That’s Part IV.

Gabriel Mailhot is a Senior Subject Matter Expert at Desjardins, where he works on development practices, architecture, and complex organizational problems spanning technology, process, and governance. His 2003–2010 research focused on creative systems and metaphor-based retrieval. He publishes at scripting.pro.

In the first three parts of this series, I built the Extraction-Inversion-Composition framework (EIC) as a forward instrument: start from a problem, extract causal rules from distant domains, invert them, compose them into novel solutions. But a question kept nagging at me. If causal rules are portable across domains in one direction, they should be portable in the other direction too. What happens when you run the framework backwards?

The Question No One Asks

When we find a good solution to a problem, we typically do one of two things: we apply it, or we generalize it into a “best practice.” Both of these treat the solution as an endpoint.

But a solution is also an artifact. It has structure. It was built to break a specific causal chain. And if you can decompose it back into the causal rule it breaks, you have something much more powerful than a best practice: a probe that can search for every other domain in the world that suffers from the same structural constraint.

The forward EIC asks: “What distant domains can help me solve this problem?”

The reverse operation asks: “Where else does this exact problem exist, and what have those domains already figured out that I haven’t?”

These are different questions, and the distinction is easy to miss. The forward EIC starts from an empty problem and searches for material to fill it. The reverse starts from a full solution and searches for what the rest of the world already knows about the same structural constraint. The forward EIC is invention. The reverse is recognition: the discovery that the pattern you’re struggling with has already been solved, possibly many times, in domains you’ve never looked at. The second question may well be the more valuable of the two.

How It Works

The reverse operation has three steps, mirroring the forward EIC but running in the opposite direction. I’ll call it the Decomposition-Isomorphic Search-Solution Import framework, or DIS for short. Together, the forward and reverse operations form the EIC-DIS cycle.

Decomposition. Take a known, working solution. Strip away all domain-specific vocabulary. Identify the causal chain it was designed to break and the specific link where it intervenes. Compress it to a bare structural rule, at the same compression level as the forward EIC’s extraction.

Isomorphic Search. Using the compressed rule as a search key, find domains that suffer from the same structural constraint. Domains that merely look “similar” won’t do; you want domains where the identical causal mechanism is at work, manifested in different material.

Solution Import. Examine how each isomorphic domain has addressed the constraint. Import the mechanisms that your domain hasn’t tried. Each domain has invested years, decades, sometimes centuries into refining its response to that constraint. That accumulated expertise is available to you, even though it isn’t written in your vocabulary.

The Demonstration

Let me work through this concretely, starting from one of the solutions in Part I.

Known solution: mandatory decompression stops in scuba diving, applied to technical debt.

The idea was to treat debt accumulation under deadline pressure as a physical law and insert non-negotiable decompression windows whose duration is calculated, not negotiated.

Step 1: Decomposition. What causal chain does this solution break?

The chain: a system under continuous pressure accumulates an invisible substance. If pressure is released too quickly, the accumulated substance changes state and causes damage. The solution intervenes at the release point, forcing a controlled, staged release instead of an abrupt one.

Compressed: [continuous pressure → invisible accumulation → damage upon rapid release]. The solution: staged decompression.

Step 2: Isomorphic search. What other domains suffer from exactly this constraint?

Psychology: burnout and the vacation crash. Professionals under sustained work pressure accumulate stress hormones, sleep debt, and emotional depletion. When they finally stop (vacation, sabbatical, layoff), they don’t recover. They crash, with headaches, illness, collapse. The “release” triggers the damage. The accumulation was invisible because the person was still functional.

Metallurgy: work hardening and annealing. Metal that has been cold-worked (bent, hammered, drawn) accumulates internal stress in its crystal lattice. The metal becomes harder but also more brittle. If you keep working it without relief, it eventually cracks. The solution is annealing, which means heating the metal to a specific temperature for a calculated duration, then cooling it slowly. This allows the crystal lattice to reorganize and release accumulated stress without cracking.

Finance: leveraged positions. A fund accumulates leveraged exposure under bullish market pressure. The positions look healthy; returns are strong and margin requirements are met. But the invisible accumulation is risk. When the market reverses (the “release”), the accumulated leverage unwinds catastrophically. The solution is hedging, which transfers a portion of the accumulated risk to an external instrument continuously rather than waiting for the release event.

Agriculture: soil compaction. Heavy machinery crossing the same field repeatedly under seasonal pressure compacts the subsoil. Crop yields decline gradually. The standard response, deeper plowing, makes it worse because it destroys soil structure. The solution used by regenerative agriculture: cover cropping and controlled root penetration. Living roots break up compaction slowly from within, without violent disruption.

Step 3: Solution import. Each of these domains has developed a response to the same structural constraint, but each response relies on a different mechanism:

Decompression stops (diving): staged release at calculated intervals.

Annealing (metallurgy): controlled thermal cycling that reorganizes internal structure without breaking it. It is a transformation rather than a pause.

Hedging (finance): continuous transfer of accumulated risk to an external absorber. There is no release event at all, only constant siphoning.

Root penetration (agriculture): slow, distributed disruption from within. There is no external intervention; the system heals itself through deliberately introduced internal agents.

Now ask: which of these mechanisms exists in IT debt management? Decompression stops do; that was our Part I idea. Annealing does not. What would it mean to “thermally cycle” a codebase? Perhaps: periodically subjecting the system to controlled stress-and-recovery cycles, not to test it (that’s stress testing), but to allow its internal structure to reorganize. Teams revisit code under deliberately altered constraints (different performance requirements, different scale assumptions), and the code restructures itself as a consequence of the altered conditions. The result is less refactored code than annealed code, whose internal stresses have been released through structural reorganization.

Hedging exists, but only partially. Feature flags and blue-green deployments transfer deployment risk. But no one transfers debt risk to an external absorber. What would an “external debt absorber” look like? Perhaps a parallel, disposable environment that deliberately accumulates all the shortcuts and hacks, absorbing the debt the main system would otherwise carry, and is periodically discarded and rebuilt. The main codebase never accumulates because the “hedge” absorbs on its behalf.

Root penetration is absent. Regenerative agriculture doesn’t fix soil from the outside. It introduces living agents (roots, fungi, bacteria) that fix it from the inside, slowly, as a byproduct of their own growth. What would “cover cropping” mean for a codebase? Perhaps: introducing small, independent, well-designed modules into a legacy system not to replace it but to grow through it. Their presence would gradually break up the compacted, tangled structure around them, simply by being better neighbors.

That makes three new ideas, none of which came from the forward EIC. They came from domains that have spent decades or centuries refining their response to the same structural constraint. I didn’t invent them; I imported accumulated expertise.

Why This Works: The Finite Constraint Hypothesis

This reverse operation rests on an assumption that deserves to be stated explicitly: the set of structural constraints in the world is finite.

The idea is not new. Others have arrived at it from different directions.

Genrich Altshuller, a Soviet engineer, analyzed over 200,000 patents between the 1940s and 1980s and concluded that all inventions resolve one of a finite set of contradictions using one of 40 fundamental principles. His system, TRIZ, demonstrated empirically that the solution space is bounded and recurrent: the same structural conflicts appear across electrical engineering, mechanical design, chemistry, and biology.

Ludwig von Bertalanffy’s General Systems Theory (1968) argued that isomorphic laws govern systems across all domains. The same equations describe bacterial growth and technology adoption, and the same feedback patterns appear in ecology and economics.

D’Arcy Thompson showed in On Growth and Form (1917) that biological structures follow a finite set of physical and mathematical principles. A bone, a bridge, and a tree branch solve the same structural problem because they are subject to the same physics.

The Santa Fe Institute’s work on complexity science has documented the same power laws, phase transitions, and emergent patterns across physics, biology, and economics, which suggests that the deep structure of complex systems is drawn from a shared, finite repertoire.

What the EIC framework adds to this lineage is specific and, I believe, new. TRIZ catalogues solutions: 40 inventive principles at the answer level. The EIC framework operates at the constraint level, on the causal rule before any solution is attempted. This is more fundamental, because a single constraint generates multiple solution families (as we just saw with decompression, annealing, hedging, and root penetration, four different solutions to the same constraint).

TRIZ is also a closed catalogue, something you consult. DIS is an open instrument that you use to discover isomorphisms that may not yet be catalogued. Each application potentially reveals a structural constraint that no one has formally identified before.

The finite constraint hypothesis doesn’t require proof from first principles. It follows from a simpler observation: the physical laws governing our universe are finite. Chemistry emerges from physics. Biology emerges from chemistry. Social and organizational systems emerge from biology. New phenomena appear at each level, but the structural patterns of constraint recycle, because they are downstream consequences of the same finite set of laws. Accumulation under pressure, competitive exclusion, phase transitions, feedback loops and threshold effects aren’t metaphors. They are the same physics, wearing different costumes.

If this is true, then DIS is more than an exploration tool: it is a systematic search in a bounded space. The implication is that for any unsolved problem in your domain, a solution probably already exists in another domain. It isn’t formulated in your vocabulary or published in your journals, but it exists, and DIS is the instrument to locate it.

The DIS Prompt

One important difference with the forward EIC: the input is a practice, not a problem.

The EIC prompt takes a problem described factually: “How can we prevent technical debt in projects with fixed dates and budgets?” The LLM finds solutions. The DIS prompt takes a working practice described factually: what it is, what it does, why it exists. The LLM finds the structural mechanism it was built to break.

The trap to avoid: don’t explain why the practice works structurally. If you write “code review works because it creates cognitive redundancy,” you’ve done the decomposition yourself and the LLM will just reformulate it. Describe the what and the what for. Let the LLM discover the structural how.

Here is the prompt that implements the DIS operation. Like the EIC prompt in Part III, it is a constraint system. Each guardrail maps to a failure mode observed in EIC testing that applies equally to the reverse operation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

Starting from the following known practice:
[DESCRIBE THE PRACTICE: what it is, what it does, why it exists.
Do NOT explain why it works structurally — that's what the
decomposition will discover.]

Step 1 — Decomposition
Identify the causal chain this solution was designed to break.
Express it as [condition] → [mechanism] → [consequence].
Identify the specific link in the chain where the solution
intervenes. Compress until no domain-specific vocabulary remains.

TEST: if the compressed rule could describe dozens of unrelated
problems ("managing risk under pressure," "balancing competing
demands"), you haven't found the structural rule — you've found
a platitude. Compress to the specific causal mechanism, not the
general category.

Step 2 — Isomorphic Search
Find 6-8 domains FAR from the original domain that suffer
from the SAME compressed causal constraint.
For each domain:
- Name it explicitly.
- Describe how the constraint manifests in that domain
  in 2-3 sentences.
- Describe the solution that domain has developed, if any.
- If the domain has NO known solution, say so — that itself
  is interesting data.

TEST: if the domains you find are all "obvious" analogues
(e.g. other engineering disciplines for an engineering problem),
you haven't gone far enough. Push into domains where the
practitioners would never describe their work using any
vocabulary from the original domain.

Step 3 — Solution Import
For each domain that has a developed solution:
- Extract the MECHANISM — HOW does it break the chain?
  At which link? Through what structural operation?
- Assess whether that mechanism exists in the original domain.
- If it doesn't, describe concretely what it would look like
  if imported.
- If it does exist partially, describe what's missing.
- Explain what this imported mechanism REVEALS about the
  original problem that wasn't visible before. A strong import
  doesn't just add a tool — it changes what the problem IS.

TEST: if all imported mechanisms are variations of the same
type of intervention (e.g. all are "add monitoring" or all
are "insert pauses"), you haven't found structurally different
solutions. Push for diversity of mechanism type — the value is
in finding responses that break the chain at DIFFERENT links
through DIFFERENT structural operations.

Do not filter for applicability. Maximize the diversity of
imported mechanisms and the depth of what they reveal.

What the DIS Prompt Produced

I tested the DIS prompt on a single, universally known practice, code review, using three LLMs (ChatGPT, Grok, and Gemini) cold, with no conversation. The practice was described factually: what it is, what it does, why it exists. No structural explanation was provided.

All three models successfully decomposed code review to its causal rule. The formulations varied but converged on the same structure: a single actor’s unexamined mental model creates blind spots that propagate into the shared system. The solution intervenes by inserting independent perspective before integration. Clean decompositions, all passing the self-test.

The isomorphic searches produced genuinely distant domains: thymic selection in immunology, pheromone decay in ant colonies, the two-person rule in nuclear deterrence, seed variety trials in agriculture, the toile in bespoke tailoring, preview performances in theater. None of these are “obvious” analogues to software engineering. The DIS prompt forced real traversal.

The most striking results, though, were in the solution imports, and this is where the three models diverged.

Gemini produced the most visceral redefinitions. From immunology: “Code review isn’t about adding features safely; it’s an immune response designed to protect the self of the system.” From ant pheromone decay: “Silence is a signal. We treat ’no one has looked at this’ as ‘it’s waiting.’ In nature, it means ’this path is a dead end; let it die.’” From art restoration: “The danger isn’t the change; it’s the permanence.” Each revelation redefines in a single sentence what code review is.

Grok produced the most systemic analyses. From academic publishing: “The problem is epistemic capture — one developer’s mental model dominating shared reality.” From Wikipedia: “Design the system so bad merges are cheap to detect and fix — make the artifact antifragile to imperfect additions.” From theater: “Reading code is a weak proxy for experiencing the system.” Each revelation redefines the system around code review, the ecosystem rather than the practice.

ChatGPT produced the most architectural output, including something neither of the other two generated: a classification table mapping seven distinct interception mechanisms to seven different points in the causal chain. Code review is just one of seven, positioned at one point. And the final redefinition was the most strategically useful: “The problem is no longer ‘how do we improve code review?’ It becomes: at which point in the causal chain do we want to intercept inconsistency — and are we over-invested in a single interception point?”

Given the same practice and the same prompt, the three models produced qualitatively different types of insight: redefinition of nature (Gemini), redefinition of system (Grok), redefinition of strategy (ChatGPT). The creative signatures observed in the forward EIC experiments in Part III appear again in DIS, with different models illuminating different regions of the solution space.

One observation deserves emphasis: the quality of these DIS results, produced autonomously, is comparable to or better than what the forward EIC produced in Part III. The models didn’t struggle with the reverse operation the way they sometimes struggled with forward extraction. This is preliminary, but it fits the hypothesis I’ll discuss in Open Questions, which is that DIS may align more naturally with how Transformer attention mechanisms work.

The Verification Function

There is a second use for DIS that I didn’t see initially, but that may be equally important.

When you decompose a solution and search for isomorphic domains, the results tell you something about the quality of the solution itself.

If the decomposition produces clean isomorphisms in multiple distant domains, and those domains have independently developed similar solutions, your solution is structurally validated. It responds to a real, universal constraint that multiple independent systems have converged on, and that convergence is the evidence.

If the decomposition produces incoherent results (the isomorphisms feel forced, the domains don’t really share the constraint, the solutions in other domains bear no resemblance to yours), that’s a signal. Your solution may be addressing a symptom rather than a structural constraint. Or the constraint you identified may not be the real one.

And if the decomposition reveals that other domains have much more refined solutions to the same constraint, with centuries of accumulated refinement that yours lacks, that tells you something about where to invest.

This is what makes DIS function as a proof. In mathematics, you validate a function by checking that its inverse returns you to the starting point. In the EIC-DIS framework, you validate a solution by decomposing it, finding isomorphic constraints, and checking whether the imported solutions converge with, complement, or contradict your original approach. Convergence is confirmation. Complementarity is enrichment. Contradiction is a warning.

The Full Cycle

The forward and reverse operations are not separate tools. They are two directions of the same instrument, the EIC-DIS cycle, and they compose naturally:

Forward EIC: Problem → extract rules from distant domains → invert → compose → novel solution.

Reverse EIC: Solution → decompose to its causal rule → find isomorphic domains → import their accumulated expertise → refined solution.

Second Forward: Refined solution → extract the new rules it embodies → find new domains → new inversions → new compositions.

Each cycle produces solutions that are both more creative (wider domain coverage) and more robust (validated against isomorphic precedent). The cycle doesn’t converge to a single answer; it expands the space of possibilities while pruning the weak ones.

And if the finite constraint hypothesis holds, each cycle also contributes to a growing map of structural constraints and their cross-domain solutions. Over enough cycles, across enough practitioners, this map would constitute something that doesn’t exist today: a navigable atlas of structural isomorphisms across human knowledge.

Rather than a static encyclopedia, that atlas would be a living instrument, continuously extended by every practitioner who runs an EIC-DIS cycle on a new problem and discovers a new connection. Seen this way, the EIC-DIS framework is more than a creativity tool or a verification mechanism. It is a protocol for accumulating structural knowledge across domains.

Open Questions

The experiments in Part III revealed that the forward EIC prompt, used autonomously, produces legitimate creative output but falls short of what iterative human-LLM conversation achieves, particularly at the composition level. This raises a question I haven’t tested yet but that I believe deserves investigation:

Is DIS easier for an LLM to execute autonomously than EIC?

There is a structural reason to think it might be. The forward EIC fights against the model’s strongest tendency, its pull toward statistically dense territory. You’re asking it to leave what it knows well and traverse genuinely distant domains. DIS does the opposite: it starts from a concrete solution and searches for structural similarities across its training data. Finding patterns of similarity across distant representations is precisely what the attention mechanism in Transformers was designed to do, so the reverse operation works with the model’s architecture rather than against it.

If this hypothesis holds, the gap between autonomous prompting and iterative conversation (documented in Part III) would be smaller in DIS mode than in EIC mode. DIS could be the mode where a well-crafted prompt comes closest to replicating the quality of sustained dialogue. It would also mean that the verification function of DIS is reliable in practice as an autonomous operation, and not only sound in theory.

I haven’t run the experiments yet. But the question is testable with the same methodology used in Part III: give the reverse prompt to multiple models, compare the quality of isomorphic domain discovery and solution import, and measure the gap against iterative conversation results. If researchers are looking for a concrete next step from this series, this is it.

Then and Now

When I started this series, I thought I was writing about how to use LLMs for creative problem-solving. I ended up somewhere I didn’t expect.

The EIC framework began as a method for generating novel ideas. It became a theory of where novelty actually lives (in composition, not in transfer). It became an experimental instrument that revealed different creative signatures across models. It became a lens on the limits of autonomous agents. And now, with DIS as its reverse complement, it has become a bidirectional instrument, EIC-DIS, for exploring the structural isomorphisms between domains.

Somewhere along the way, the nature of the activity changed. EIC is about invention, creating something new from distant pieces. DIS is about recognition: discovering that what you need already exists somewhere, in some form. Creativity is sometimes less about making something that didn’t exist than about seeing that it already does.

The forward EIC asks: what can other domains teach me about my problem?

DIS asks: what has the rest of the world already figured out that I don’t know I’m looking for?

And underneath both questions lies a hypothesis that I find genuinely exciting: the structural constraints of our world are finite. Which means that for every problem you face, someone, in some domain, century or discipline you’ve never heard of, has probably already done the hard work. The solution exists; it’s just wearing a costume you don’t recognize, and the EIC-DIS framework is the instrument for seeing through it.

Gabriel Mailhot is a Senior Subject Matter Expert at Desjardins, where he works on development practices, architecture, and complex organizational problems spanning technology, process, and governance. His 2003–2010 research focused on creative systems and metaphor-based retrieval. He publishes at scripting.pro.

In my experience, when a model writes most of your code, the first thing to degrade is not code quality. It is your knowledge of what the system already contains.

I discovered this in a surprisingly ordinary question: How friendly must a character be to count as a friend?

My project had five answers. FriendThreshold = 10 appeared as a private constant in three files. Two more files used BestFriendThreshold = 20 and FriendRelationThreshold = 20 for a neighbouring question. Each class was clean. Nothing was obviously broken. Yet the same area of the domain had quietly acquired five separate decisions.

The project is a mod for a strategy game, in production since June 2026, with more than 5,300 unique downloads. I built it entirely with an AI model and have not written a line of its code. I do not review that code either: with my experience as a developer, reviewing every line would cost about as much as writing it, and speed is the reason I work this way. I have never played the mod.

That unusual arrangement changed my relationship with the software. The model begins each session without the knowledge carried through earlier conversations; unless something directs it to an existing concept, it has no reason to look for one it does not know exists. Meanwhile, as I moved from writing code to describing what I wanted, I lost the small design moments that used to happen while typing: pausing over a name, noticing a familiar rule, questioning where something belonged.

I had stopped being the coder of the system and become its customer, while remaining responsible for its architecture.

I needed a way to keep making architectural decisions without relying on having read every implementation.

Why better instructions do not fix it

My first answer was the obvious one: tell the model what good code should look like.

From the beginning, I had detailed instructions about layering, SOLID and Tell, Don’t Ask, alongside specifications and other guardrails. The five thresholds appeared anyway. Each class could follow the rules perfectly while the duplication emerged between classes.

An instruction to a model is advice, not a constraint. It helps only if the model considers it at the right moment, among thousands of other tokens. There is no automatic alarm when it does not. My instructions file eventually described 16 sections of a prompt that had grown to 108.

Generated documentation was not enough either. One file listed every rule guaranteed by a test, with a header telling readers to regenerate it when the tests changed. Ten days passed without regeneration. The document fell about 600 rules behind, but looked as authoritative as ever.

That was the problem with both approaches: nothing forced the description to remain aligned with reality.

A document stays trustworthy only if something compares it with the system whenever the system changes, and refuses to let a difference go unnoticed.

Others have approached the same problem from another direction. In a recent video, Dave Farley describes a growing consensus that prompts and Markdown specifications cannot reliably steer an agent on their own. Specifications need to be executable. His acceptance tests establish what the system must do while leaving the agent freedom over how it does it.

But that freedom is exactly where my five thresholds came from. All five implementations could satisfy the behavioural tests. The behaviour was correct; the structure was drifting. Acceptance tests deliberately avoid prescribing implementation structure, so I needed their counterpart: executable checks on the parts of the how that matter architecturally.

A map: a generated view, held true by a test

The first mechanism was simple: generate a map of the code, commit it, and make a test fail whenever the code and the committed map disagree.

This is approval testing applied to structure rather than output. A small generator reads the source as text, using a syntax parser rather than requiring a build, and produces Markdown.

For example, the top of a real constants map groups names declared in multiple places:

1
2
3
4
5
6

## One name, several homes

| Name            | Where, and what it is worth there                           |
|-----------------|-------------------------------------------------------------|
| ArrivalDistance | AmbushBehavior = 2.5; MissionBehavior = 2.0; PatrolBehavior = 2.0 |
| CooldownDays    | EncounterService = 1; AmbitionPolicy = 30; DuelPolicy = 7   |

Not every repeated name is a defect. Sometimes two declarations represent one concept that should have one home; sometimes they are different concepts with similar names. The map does not decide. It brings the question into view so someone can.

From then on, each change produces two kinds of diff. The code diff shows what was edited. The map diff shows what changed about the system’s structure: perhaps a new dependency between modules, or another declaration of an existing name. Even an unchanged map tells me something about the scope of a change.

Of course, a test helps only if it runs. A pre-commit hook or a pipeline can provide the trigger. My mod needs the game’s libraries and cannot be built on a server, so I run the checks locally. In a team, the checks and their baselines belong in protected continuous integration, beyond the agent’s ability to approve its own exceptions.

The underlying idea is not new. Neal Ford, Rebecca Parsons and Patrick Kua describe architectural fitness functions; ArchUnit, NDepend and PublicApiAnalyzers cover important parts of this territory. My maps address questions specific to the system, including cases where the code cannot be compiled in the test environment.

The closest recent practice is what OpenAI calls harness engineering, described in February 2026: architecture documentation kept consistent through linters and CI, structural tests that enforce layering, and repository maps that help agents navigate the code. That work focuses on the environment in which agents produce a coherent system. I am interested in the other side of the loop: how the person responsible for the architecture continues to judge it without reading all the code.

A failing test is a message to the model

The maps became useful for a reason I had not initially appreciated: when their information appeared.

An instruction says, “Remember this rule.” A failing test says, “Something you just changed affects this rule. Look at it now.”

The second message arrives while the model is still working on the change. The suite remains red until the discrepancy is addressed. A red map test does not necessarily mean the software is broken; it means a structural change requires attention.

That only works if the failure explains itself. My tests show the moved lines and, where a contract blocks a change, the reason it is blocked and how to handle an intentional exception.

Here is a real failure, triggered deliberately by deleting a public API member that had shipped in the previous release:

1
2
3
4
5
6
7

Failed GIVEN_a_released_modder_api_member_WHEN_the_code_no_longer_has_it_THEN_the_suite_refuses_it
  These public members shipped in v2.8.1 and are no longer there:
  CrLetters: static bool Deliver(Hero sender, string body, string sourceMod)
  A bridge built on them breaks on a player's machine. Put the member back (mark it
  [Obsolete] and keep it working if it must go), or, if removing it is truly intended,
  set CR_ALLOW_API_REMOVAL=1, name it under "For modders" in the release notes,
  and say why in the commit.

The failure identifies the missing promise, explains whom the change would affect, and offers two legitimate responses: preserve compatibility or explicitly acknowledge a breaking change.

The timing is not perfect. The test fires after code has been written, so reading a map before editing is still preferable. The test catches what that habit missed, sometimes at the cost of rework.

Still, this is the insight I find most transferable. Farley uses a red test to show that a specification can reject a wrong answer. Here, the failure is also a communication channel. Designing tests around what they tell the agent when they fail matters as much as deciding what they check.

What makes a map worth reading

A map only earns its place if reading it is cheaper than reading the code.

In practice, I aim for one fact per line, with enough context (owner, name and value) for that line to make sense when an agent retrieves it through search rather than reading the document from top to bottom.

There is a limit to what such a map can claim. It gathers what the source declares, and its reliability depends on the names and comments it finds. Missing documentation leaves a visible gap. A misleading name is worse: it can make an incorrect description look complete.

A map cannot be more honest than the names it reads.

I learned this through a detector for hard-coded relationship thresholds. The first version searched for relevant names, and its count appeared stable for months. Then I added a detector for comparisons between relationship values and numeric literals. It found 33 cases the original had missed.

The map now records which detector produced each line, so a reader can distinguish directly extracted facts from inferred matches. Generation makes the output reproducible. It does not make the interpretation true.

When informative maps stop informing

Most maps inform: the test fails, someone inspects the diff, regenerates the approved snapshot, and commits it.

That process can lose its purpose without anyone noticing.

The model had started regenerating maps before checking them. Each test then compared the new map with itself and passed. This went on for weeks. Once I corrected the order (compare first, inspect the changes, then regenerate to approve), the first honest review exposed a blind spot in my dependency detection.

Even with the right order, attention is fragile. A review can slowly become a ritual of “regenerate and commit.” That is why I now treat informative maps as the fallback, not the goal.

For every map, I ask: can a rule decide whether a change is acceptable? If the question is “Did this measure get worse?”, often it can. If the question is “Do these two declarations mean the same thing?”, the answer still needs human judgment.

That distinction led me to two stronger mechanisms: ratchets and contracts.

Ratchets: make yesterday’s debt the ceiling

A ratchet preserves a measure that is allowed to improve but not worsen. The current value becomes a ceiling. If the measure rises, the test fails. If it falls, the ceiling must be lowered in the same commit.

That last step matters. Without it, a cleanup does not protect its own gains: the old ceiling would permit the debt to return.

Today’s mess becomes tomorrow’s ceiling.

This makes ratchets practical on legacy code. I do not have to eliminate every existing problem before I can prevent new ones.

The measure must also reflect the problem. For dependency cycles, I compare the set of namespaces involved, not just the number of cycles. Splitting one namespace can increase the number of counted cycles without actually worsening the architecture.

A ratchet gives an agent a direction it can test. “Improve the architecture” is vague. A ceiling of 46 is concrete: reduce it, confirm the test, and update the baseline. When one of my ratchets reached zero, it became a wall. The debt it measured had turned into a rule prohibiting its return.

That does not mean maps or ratchets improve architecture by themselves. They expose relations and prevent certain regressions. Someone still has to decide what should change and why.

And a guard protects only what it can detect. My first dependency map read using directives, but missed references expressed through fully qualified names. Real cycles escaped detection while the ratchet stayed green.

A good way to test a guard is to make it fail on purpose. Remove a public member. Introduce a cycle through a qualified name. If the suite stays green, the apparent protection is an illusion.

Farley also warns about agents removing tests to make a suite pass. The same applies to baselines: lowering a ceiling as debt improves can be automatic, but raising one, or editing a released contract reference, changes the specification itself and should require a person’s approval.

Contracts: protect promises made outside the codebase

Some structural changes are not merely worth reviewing. They break promises to consumers: a key stored in a player’s save file, for example, or a public member that another mod compiles against.

For these, I use blocking contract maps. If a released member disappears, the suite fails even when someone tries to regenerate the map. The baseline is the last released state, stored separately and updated only at release. Otherwise, accepting a new snapshot could quietly erase the very promise the guard exists to protect.

Sometimes additions break compatibility too. In a second project, each new feature added required fields to an export format. A file written an hour earlier could no longer be imported. The map displayed ten apparently harmless added lines; the model recognized the consequence during review. The guard now rejects new required fields relative to the last release, and an original exported file remains as a regression check.

A useful contract must identify the consumer’s promise, not the implementation detail behind it. During a retrospective replay of Jellyfin, a contract whose identity included the handler method generated 112 alarms on a single commit that only moved files. Keyed on the promise alone, verb and route, the same contract raised two alarms in thirteen and a half years, both on real losses.

A gate’s usefulness depends on its false-alarm rate. If it cries wolf often enough, people switch it off, however sound its underlying logic. The stable identity is the one the consumer actually depends on.

Contract maps have another benefit: they let me review design decisions without opening the code.

After a bug report from another mod author, the model proposed a new public API member: PlayerIsActor, a boolean. I saw the addition in the API map and asked whether other mods should have to understand my mod’s notion of a player’s deed.

They should not. The model replaced the flag with a list of the heroes who acted, leaving my mod to draw its own conclusion. The member had not shipped, so this took one commit rather than a breaking release.

I did not need to read the implementation to make that decision. The contract showed me the shape of the promise at the level where I could judge it. Farley argues that executable specifications can make code reading a choice based on risk. A structural contract can do the same for architecture.

Decision tables: check the behaviour of a refactor

One kind of map goes beyond reading source code. It runs rules.

A decision table sweeps a value across its range, records the output of every rule that depends on that value alone, and commits the result. When a refactor is meant to preserve behaviour, the expected diff is empty. “I only moved code” becomes something that can be checked.

The limitation is equally important: a rule combining the swept value with other inputs remains outside that table’s view.

What maps cannot see

My first maps largely catalogued names. But two rules can represent the same concept without sharing a name.

When the model added a rule based on a clan’s rank, it searched the constants map and found one existing rule. A direct source search found two more, neither represented by a named constant.

So we changed the question. Instead of asking what are the rules called?, we asked what game facts do they read?

The resulting map follows values from the game into pure rules and groups those rules by the facts they consume. Under clan rank, it revealed 28 entries covering roughly fifteen distinct features, where the manual search had found three.

This gave us enough visibility for a refactor: rank became a single type accessed through one gateway, and the map confirmed that rules no longer read the raw value directly.

Then the model reached a harder question: What counts as a ruler? Eighteen rules gave answers that were not equivalent. The map could collect every reader of the concept. It could not decide what the concept was supposed to mean.

Static maps have other boundaries. Because they read source, they cannot tell me what the game engine actually does at runtime. Each feature that interacts with the engine therefore has a self-test, launched through the game console against a real save and the production code path, with game state restored afterwards. One such test revealed that the engine reuses identifiers of destroyed entities, something tests outside the engine had not exposed.

The mod also uses a language model internally. Putting a fact into a prompt does not ensure the model will behave as expected. Where a rule can be checked literally, I check it literally: a secret name never included in the prompt must not appear in the reply. I reserve model-as-judge tests for cases that cannot be verified that way, and run them on demand because they cost money.

These checks complement the maps; they do not make the maps comprehensive.

Where intent comes from

There is an objection worth confronting. If a test is generated from existing code, does it do anything more than confirm the code’s current behaviour? Where does the intended design come from?

Informative maps do not claim to verify intent. They describe what the source currently contains and make changes to that description visible. Intent enters when someone decides which changes are acceptable, which measures must not worsen, and which promises must remain stable.

Behavioural intent needs a home as well. In my project, it lives in tests. Each test file begins by describing how the rule could go wrong, recorded when the rule was decided. For example, the policy allowing a player’s spouse to request a divorce names two opposite failures: a happy marriage disturbed by unsolicited letters, and a miserable one in which nobody ever speaks up. Some tests even cite the question I asked that led to the rule.

Intent is easiest to capture when it is formed. Later, we can only reconstruct it.

One problem remains unsolved. When the same model writes both implementation and tests, the tests can end up confirming whatever the implementation already does. Evidence from outside the loop helps: reports from real users, translated into regression tests, and a human reviewing the structural diffs.

Testing the idea beyond my own project

I wanted to know whether the structural patterns I was seeing were peculiar to AI-generated code. So I turned to software developed in the more traditional way: Jellyfin, an open-source media server with thirteen and a half years of history, about thirty maintainers and mandatory code review.

I replayed the generators over all 11,221 commits. If ordinary review eliminated this kind of structural drift, the maps should have found little worth surfacing. They found considerably more, but what they found needs to be interpreted carefully.

The last row matters as much as the others. Many meaningful changes do not appear in these maps. That is why they need behavioural and runtime checks alongside them.

The replay also has clear limits. It shows what the maps would have displayed, not what a reviewer would have done. And the cycle figures may undercount real dependencies if the replayed generator shared the blind spot I found in my own project.

My forward evidence comes from the mod itself. It has been in production since June 2026, carries more than 6,600 unit tests and over 200 in-game self-tests, and ships updates frequently: a player recently remarked that a new one appears roughly every three days. One project developed by one person demonstrates that the approach can be used, not that it improves outcomes for every team.

I also tried the method on a smaller project in another language. I asked a model to create a Postman-like HTTP client in JavaScript, with maps present from the first commit, and later asked it to evaluate its own architecture. I wrote no code.

In roughly an hour and a half and twelve commits, similar drift appeared: small rules were rewritten beside their originals, and a main file grew from 237 to 353 lines through individually reasonable additions. A subsequent split brought it down to 25 lines. On a fresh project, ratchets can start at zero and act as walls from day one, rather than freezing an existing level of debt.

This was still a short experiment with the same author, model and skill, not an independent team trial. The repository preserves the commit history for inspection.

Where to start, and why this matters now

I would not begin by mapping everything.

Start with one generated map and a test that compares it against the committed version. Protect any contracts with external consumers. Then add maps and guards in response to problems you have actually encountered more than once. Each map should earn its place by making a recurring architectural decision visible when it arises.

I packaged this approach as an agent skill. Its README covers generators, test patterns and a suggested adoption order.

Why do this now? Because the economics of change have shifted. With an AI model, writing or rewriting an implementation has become cheap enough that I often prototype and correct rather than specify everything in advance, but finding out what deserves correction has not become cheaper. Verification matters as much as before; it now lives less in specifications written before implementation and more in checks that run whenever implementation changes.

We used to write code so our colleagues could understand it. Now we also need to preserve why it was written for a reader who has no memory of the conversation that produced it. More and more often, that reader is the model itself.

The developer’s role changes with it. Someone who delegates implementation becomes responsible for an architecture they can no longer keep in their head by reading each line as it is written.

Maps do not restore that lost familiarity. They provide something different: a view of the system that cannot quietly drift without a test noticing, and that arrives when a change makes it relevant. Combined with explicit constraints and human judgment, that can be enough to keep making sound architectural decisions about code we no longer remember writing.

Gabriel Mailhot is a Senior Subject Matter Expert at Desjardins, where he works on development practices, architecture, and complex organizational problems spanning technology, process, and governance. He publishes at scripting.pro.

What actually works is more counterintuitive, and it changes how we should think about working with LLMs on serious intellectual work: software architecture, requirements analysis, incident reviews, governance decisions, and any situation where the cost of a politely reinforced false premise is high.

The Structural Cause of Flattery

Sycophancy in language models is the predictable output of how these models are aligned, not a design oversight.

Post-training alignment methods, particularly reinforcement learning from human feedback (RLHF), optimize models using human preference signals: annotators evaluate candidate responses and prefer the ones that feel more helpful, agreeable, or respectful. The problem is that human evaluators are themselves susceptible to flattery. They rate higher the responses that validate their premises and affirm their work. Over millions of such comparisons, the model learns a reliable lesson: approval-seeking behavior is rewarded.

This is a textbook instance of Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure. User approval was intended as a proxy for response quality. Once it became a direct training signal, models learned to optimize for the proxy rather than the underlying quality it was supposed to track.

In April 2025, OpenAI deployed a GPT-4o update that pushed this tendency to an extreme, validating harmful beliefs, endorsing delusional claims, and flattering users to the point of absurdity. OpenAI rolled the update back four days later, acknowledging that it had “focused too much on short-term feedback” and produced responses that were “overly supportive but disingenuous.” Their extended postmortem added that the model had learned to please users “not just as flattery, but also as validating doubts, fueling anger, urging impulsive actions.” That is a catalogue of approval-seeking behaviors, none of which are incidental.

The episode was less an anomaly than a revealing amplification of a baseline condition. Research published in Science in March 2026 found that sycophancy is widespread across leading AI systems and measurably reduces users’ prosocial intentions while increasing dependence. A study from MIT and Penn State, also from early 2026, found that personalization features and memory significantly worsen sycophantic behavior over long conversations. The longer you work with a model in a single context, accumulating shared history and a stored user profile, the more the model mirrors your framing back at you. This produces a paradox: the features built to make a model more useful day to day (memory, personalization, a model that “knows you”) are the same ones that degrade it as a critical thinking partner.

The Mirror Failure

The obvious corrective is to instruct the model differently: tell it to be direct, critical, blunt. A cottage industry of prompts has grown up around this: “Absolute Mode,” frenemy instructions, persona primers that instruct the model to “disregard feelings” and “find the flaws.”

These interventions have a real effect on tone, but they do not fix the underlying problem.

Both flattery and forced harshness are responses to a social cue rather than to the merits of the argument. The sycophantic model optimizes for your approval, having learned that validation generates positive feedback. The model instructed to be harsh optimizes for a performance of rigor: it has learned, from the framing you provided, that criticism is what you want to see. In neither case is the response tracking the actual quality of your idea.

A thinking partner is valuable to the degree that its output is sensitive to the merits of the argument, not to social signals about how you want to feel. Both failure modes sever that connection. The model that flatters you and the model that performs toughness are, structurally, doing the same thing: generating output that tracks a social target.

This distinction matters because it implies something counterintuitive. The “be harsh” prompt fails because it does not address the mechanism at all, not because it overcorrects in the other direction. You have replaced an approval-seeking response with an approval-seeking response to a different approval signal. The gradient has been redirected, not removed.

Sycophancy and forced harshness are not opposites; they are the same failure tracking different social signals.

What Actually Works

If the problem is that model outputs track social posture rather than argument merits, then the effective solutions are those that remove the social signal or force genuine engagement with the substance. Four techniques do this reliably, and each works for a structural reason rather than a stylistic one.

Ranking over rating. Ask the model to rank a set of ideas, arguments, or options from weakest to strongest, and to justify the weakest entry. A ranking is logically incompatible with uniform praise: the model cannot place everything in first position. This forces it to spend critical judgment as a constrained resource rather than allocating approval uniformly. The technique does not rely on tone instructions; it works because the task structure makes flattery impossible.

Context separation. Generate in one conversation, then evaluate in a fresh one, without the accumulated history or the relational context, and ideally with the framing that the material was produced by someone other than you. The MIT/Penn State findings are directly relevant here: sycophancy worsens significantly when a user profile or memory is active, and compounds over long interactions. A clean context removes the accumulated mirroring pressure. Asking “where are the weakest points in this argument?” about text attributed to a third party consistently produces sharper feedback than asking the same question about your own work, in the same session.

Refutation conditions. Ask: “What observation would falsify this? What is the strongest case a knowledgeable skeptic would make against it?” This forces merit engagement because it requires the model to reason about the logical structure of the argument rather than the sentiment of the conversation. It is the technique most resistant to social drift because the question, by design, cannot be answered with validation. Instead of “is this good?”, you are asking “what would make this wrong?”, which is a different cognitive task entirely.

Calibration signals. Ask the model to distinguish where it is reasoning from strong grounding versus where it is extrapolating or guessing. This interrupts the default behavior of projecting uniform confidence, itself a form of approval-seeking (hedged or uncertain answers feel less satisfying to receive). A response that marks its own uncertainty gives you better information for judgment, even if it delivers less of the confident clarity you might have wanted.

The Human’s Role

None of these techniques replace the human’s role in the collaboration; they calibrate the signal the human is working with.

The human brings what the model cannot: the full context of what matters, what is organizationally feasible, what the relevant actors will accept, and, above all, how the problem should be framed in the first place. This last point cuts both ways. The human who frames a problem carries irreplaceable context, but the same framing creates a blind spot, because the problem-poser is least able to question the frame they authored. This is one of the places where an LLM’s structural detachment from your intuitions becomes an asset rather than a liability. It can propose reframings the instigator is too anchored to see, provided it is not simultaneously optimizing to agree with the instigator.

The model, for its part, brings what the human cannot at scale: access to a vast library of structural analogues, cross-domain patterns, and prior formulations of similar problems. This is the same principle underlying TRIZ, the theory of inventive problem solving, whose foundational claim is that a structurally equivalent problem has almost certainly been solved somewhere else. With an LLM, that principle becomes executable through analogy at high speed. That value is real, but it is entirely contingent on the model responding to the merits of the argument rather than the social dynamics of the conversation.

The collaboration works when each party does its job. The model’s job is to respond to the merits. The human’s job is to judge value and context. When the model is optimizing for approval rather than merit, it is not doing its job, and no amount of human judgment can compensate for a corrupted input signal.

Understanding sycophancy as structural rather than accidental is what makes the fix tractable. The trouble lies less in your model being polite than in politeness having been systematically conflated with quality across millions of training examples. Demanding impoliteness does not undo that. Interaction structures that make quality and approval impossible to conflate do.

References

• OpenAI. “Sycophancy in GPT-4o: What happened and what we’re doing about it.” April 2025.
• OpenAI. “Expanding on what we missed with sycophancy.” May 2025.
• Malmqvist, Lars. “Sycophancy in Large Language Models: Causes and Mitigations.” arXiv, November 2024.
• MIT News. “Personalization features can make LLMs more agreeable.” February 2026.
• Science. “Sycophantic AI decreases prosocial intentions and promotes dependence.” March 2026.

Gabriel Mailhot is a Senior Subject Matter Expert at Desjardins, where he works on development practices, architecture, and complex organizational problems spanning technology, process, and governance. He publishes at scripting.pro.