We may assume that a creative idea is a distant analogy, connecting two things no one had connected before. That assumption is wrong. The distance between domains explains almost nothing about whether an idea will be novel, useful, or transformative.
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.