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.

I have watched a pattern repeat itself across organizations too many times to believe it is accidental. A technically competent person does careful work, raises legitimate concerns about architectural shortcuts, pushes back on timelines that will generate problems downstream. They are right. Their concerns are documented. And they are quietly sidelined while the project proceeds, delivers on schedule, and the manager who overrode their concerns is promoted.

The promoted manager is not incompetent. In many cases, they are genuinely skilled at something. But skilled at what, exactly? And why does that skill, rather than technical judgment, determine who advances?

This article is an attempt to answer that question rigorously. The answer implicates organizational dynamics, but also the educational institutions that train managers, the governance models that structure IT investment, and the reform movements, Agile among them, that have tried and failed to change the outcome. The system is not broken; it is working exactly as its underlying structure dictates. In 2007, Robert Schaefer, writing in ACM SIGSOFT Software Engineering Notes, asked the same question in more general terms: why do large complex systems so often work against their declared goals? His answer pointed directly at organizational governance, specifically at what he termed the Authoritarian Hierarchy of Control. What follows builds on that diagnosis and extends it into the specific dynamics of IT investment, selection, and reform.

Technical debt is not a failure of discipline. It is a system of incentives working exactly as designed.

The Incentive Structure That Generates Technical Debt

Large organizations govern IT investment through annual budget cycles and delivery metrics. A project is funded for a year, expected to deliver defined functionality by a defined date, and evaluated on whether it did. This structure imposes a specific temporal resolution on decision-making: what matters is what is visible within twelve months.

Architectural quality does not operate on a twelve-month horizon. The decisions that determine whether a system can be evolved cheaply in three years (modularity, decoupling, reversibility, testability) produce no visible output in the current budget cycle. By the logic of the measurement instrument, they are invisible.

Every technical role in a delivery team, whether developer, tech lead, or architect, is in the business of reducing the cost of being wrong. Good design does not predict the future; it ensures that when the system must evolve in ways no one anticipated, the cost of that evolution is bounded rather than catastrophic. But this value cannot be captured by a metric that closes at year end. It has no line in the budget and generates no deliverable.

The project manager who allocates time and money to architectural quality is making an investment whose return will appear in someone else’s budget cycle, under someone else’s name. The project manager who defers that investment delivers on time and on budget, and receives the recognition that comes with it. That is a sensible response to the incentive structure rather than a failure of individual judgment.

Schaefer named this mechanism risk shifting: when direct action to reduce a risk is judged too costly, the less costly tactic is to transfer that risk burden to others. If this transfer can proceed without immediate observation, the conflict it generates will simply be deferred. Annual budget cycles are, structurally, a machine for making risk shifting invisible. The cost lands in a future cycle, under a different manager, attributed to different causes.

Game theory offers a complementary framing. In a prisoner’s dilemma, two actors each face a choice between cooperation, which produces the best collective outcome, and defection, which protects individual interest at collective cost. When both actors reason independently and arrive at the locally coherent choice, both defect. The problem is not irrationality but the fact that individually sensible behavior produces collectively irrational outcomes. The parallel with IT governance runs deep enough to carry predictive weight. Every project manager, every budget cycle, every delivery team faces the same calculus. When every actor optimizes for their own position, the collective result is a technology estate that grows progressively more rigid, more expensive to evolve, and less capable of supporting the business it was built to serve. Nobody made a bad decision; everyone made a good one, given the game they were playing.

The Cascade: From Deferral to Dissimulation to Manipulation

Technical debt is the first and most visible symptom of this structure. But the same logic operates at every level of the organizational hierarchy, producing a cascade of increasingly consequential behaviors.

At the project level, the actor defers architectural quality. This is risk shifting in its most direct form: a cost that is real but diffuse, transferred to a future that belongs to someone else.

As the project encounters difficulty (deferred costs begin to materialize, timelines slip, complexity compounds), the actor at the next level faces a different version of the same calculus. Delivering bad news upward is costly. It damages reputation, invites scrutiny, and moves the problem from the future into the present. Filtering that information, presenting progress in the most favorable available framing, managing perception rather than reality: this is individually sensible for exactly the same reason that deferring architectural debt is individually sensible. The cost is real but diffuse, while the benefit is immediate and personal.

Schaefer formalized this in what he called the Liars’ Axioms. A liar, his term for any actor who strategically manages information to protect their position, suppresses, manufactures, or denies evidence to align observers’ judgments with their own goals. The intent of the lie, he observed, may simply be to stall for time. If the delay runs long enough, the consequences will have had greater impact on the world than the uncovering of the lie. Those who discover it afterward (auditors, commissions of inquiry, historians) matter only to a small audience. The actor has long since moved on.

The calculus that defers architectural quality also defers information. Technical debt accumulates at the bottom of the hierarchy; informational debt accumulates at the top. The mechanism is identical, and the consequences, when they finally surface, are proportional to how long the deferral has continued.

This is a structural observation, not a cynical one about human nature: it describes what happens when the same incentive pattern operates at multiple levels of a hierarchy simultaneously. Each level protects its position by deferring its costs to the next. The progression from deferral to dissimulation is continuous, not discrete. There is no moment at which a sensible actor becomes a dishonest one, only a gradual drift toward behaviors that the structure rewards and away from behaviors that it penalizes.

What Gets Selected

Organizations do not select randomly among the people available to them. Over time, through promotion decisions made by individuals operating within the incentive structure described above, they exercise a form of natural selection. The behaviors that advance are the behaviors that the structure rewards. The behaviors that are penalized (transparency, technical rigor, willingness to deliver unwelcome news) become associated with career stagnation.

Schaefer described this dynamic in terms of the Authoritarian Hierarchy of Control: organizations structured around command and control systematically suppress independent judgment in favor of loyalty and conformance, rewarding those who display alignment with authority over those who bring accurate but unwelcome observations. The result, he noted, is that the quality of products and services tends to be driven to the lowest level of mediocrity the market will bear, and that responsibility for poor performance will be attributed to individual contributors, never to the structure that produced it.

This selection process has a name for each of its outcomes. HEC Montréal, one of Quebec’s leading business schools, administers a political skill assessment that classifies managers into five profiles: Machiavellian, Strategist, Survivor, Good Soldier, and Sacrificial Lamb. The Machiavellian profile, described as driven by a strong thirst for power, politically motivated behavior, and the belief that ends justify means, is listed as having two strengths: highly effective, and achieves objectives. Ethical risks appear as a limitation, alongside friction and mistrust. The profile is presented not as a pathology but as a high-performance option with known trade-offs.

At the other end of the scale, the Sacrificial Lamb, described as believing that merit is sufficient, unable to decode political dynamics, potentially becoming a victim of the system, is listed as having three strengths: integrity, authenticity, and focus on work well done. Its risks include marginalization and incomprehension of real organizational dynamics.

What Gets Trained

HEC is not inventing the reality it describes. It is documenting what it observes in organizations, and then teaching it. HEC is not alone in this. The framing of political skill as a legitimate and measurable managerial competency has been widely adopted across business schools. What was once informal knowledge (how to handle power, manage perception, read the room) has been systematized into curriculum. By naming these profiles, measuring them, and transmitting them to the next generation of managers as legitimate knowledge about how organizations actually work, business education completes a feedback loop that Schaefer identified: the selection pressure that organizations exert is validated, codified, and taught as professional competence.

The Machiavellian who advances in a large organization is not a deviation from the system. They are its product: shaped by the incentive structure, selected by promotion decisions, and trained by the curriculum.

There is an irony here. Schaefer’s 2007 paper received only three citations in the seventeen years following its publication, not because it was wrong, but because the professional and academic structures of software engineering had no established category for an argument that located the root cause of system failure in governance, power, and the suppression of independent judgment. The diagnosis arrived before the vocabulary existed to receive it. That, too, is the system working as designed.

There is a question this article does not pretend to resolve: does the organization produce this selection pressure, which the educational institution then documents? Or does the educational institution legitimate and amplify a pressure that would otherwise remain informal? The honest answer is that causality runs in both directions. The organization and its educational infrastructure have co-evolved into a system that is now very difficult to disturb from within.

Why Agile Was Structurally Condemned

The Agile movement emerged in the early 2000s as a direct response to the dysfunctions described above. Its founding documents, particularly the Agile Manifesto, called for transparency over performance theater, genuine collaboration over contract negotiation, and working software over comprehensive documentation. It identified, correctly, that waterfall project dynamics generated exactly the kind of rigidity and deferral that technical debt represents.

The adoption of Agile in large organizations over the following two decades produced a result that is by now well documented: the vocabulary was adopted; the underlying dynamics were not changed. Sprints became fixed-scope, fixed-date delivery commitments. Velocity became a production output target. Retrospectives became compliance rituals. The Agile transformation was managed by the same people operating within the same incentive structure, producing the same behaviors under a new name.

Agile did not transform governance. Governance transformed Agile.

The standard explanation for this failure centers on the frozen middle: middle managers whose positional authority depends on the existing governance model, who absorbed the pressure for change without transmitting it upward. This explanation is correct but incomplete.

The deeper explanation is that Agile, authentically practiced, requires a specific type of organizational actor. It requires transparency about progress and problems, the willingness to deliver unwelcome news early, and collaboration that is genuine rather than performed. These are the behaviors associated with the Good Soldier and the Sacrificial Lamb in the HEC taxonomy, the profiles described as loyal, competent, and appreciated for their work, but also naive, vulnerable, and easily marginalized in competitive environments.

The Strategist and the Machiavellian, the profiles that large organizations have systematically selected and elevated, are precisely those for whom authentic Agile practice is not a viable strategy. Transparency exposes their deferral. Early bad news undermines their narrative management. Genuine collaboration limits their control of information flows. For these actors, adopting the vocabulary of Agile while hollowing out its content is political competence applied to organizational survival, not resistance to change.

Schaefer anticipated this failure with what he called the Process Paradox: the more a process is commanded, the less independent judgment is permitted, and when something goes wrong (as it inevitably will), the worse the consequences. Agile, commanded from above within an authoritarian hierarchy, does not produce agility. It produces a rigid process that eliminates independent judgment while preserving the appearance of flexibility. The name changes; the structure does not.

Agile did not fail because it was poorly designed or poorly implemented. It failed because it was introduced into organizations that had spent decades selecting against the human dispositions it required. The frozen middle did not block Agile. The selection process that produced the frozen middle made authentic Agile adoption structurally improbable before the first sprint planning meeting.

The Agile coach role, now a standard position in many large organizations, crystallizes this contradiction with particular clarity. It is an officially sanctioned mandate to transform a culture that the incentive structure actively reproduces. The role signals commitment to change without requiring it. In Schaefer’s terms, it is a display directed outward: the organization can point to its coaches as evidence of transformation while the governance model remains untouched. And it produces a specific collateral damage that rarely appears in any measurement. Developers who glimpse a different way of working, who are shown what genuine collaboration and technical quality could look like, find themselves unable to practice any of it within the real constraints of the system. The choices available to them are narrow: exit the organization, remain with a chronic frustration that compounds over time, or disengage quietly and accept the distance between what they know is possible and what the system will permit. The organization does not notice this damage, because what it measures is sprint velocity.

The Normalization of Failure

One final mechanism completes the loop and explains why the system persists without generating the corrective pressure one might expect.

Large IT project failure is not an occasional anomaly. The Standish Group has tracked IT project outcomes for decades; their data consistently show that only around 30% of IT projects are considered fully successful, a figure that drops further for large-scale initiatives, with roughly half of all projects challenged and nearly one in five outright cancelled or abandoned. The pattern is stable across years and geographies. Yet when a specific project fails (costs overrun, the system delivered is less capable than the system it replaced, timelines stretch beyond any defensible estimate), the failure is almost never attributed to the incentive structure that generated it. It is attributed to poor management, to vendor problems, to scope creep, to technical complexity. The postmortem identifies individuals and decisions. It does not identify the game those individuals were playing or the rules that made their decisions predictable.

Schaefer identified this as a structural property of hierarchical governance: the source of all faults will ultimately be whatever legitimate authority claims it is, whether or not such claims are true. Accountability flows downward to individual contributors. The structure that produced the conditions for failure is never the finding. To make it the finding would require those conducting the examination to indict what elevated them.

This misattribution operates at two scales simultaneously, and the two reinforce each other. At the organizational level, the postmortem blames individuals and decisions, protecting the incentive structure. But the same dynamic operates earlier, at the level of the project itself. When timelines slip, as they inevitably do when architectural shortcuts accumulate and deferred complexity begins to surface, the reading is almost always that the technical team is slow, that estimates were poor, that execution was lacking. This interpretation is structurally necessary. If the delay were attributed to its actual cause, the decisions that sacrificed quality to meet an earlier date, accountability would travel upward, toward the people who made those decisions. Attributing it to technical competence severs that causal chain cleanly. The practitioners who lived through the accumulation carry the reputational cost of a problem they did not create. They raised concerns that were overridden and worked inside constraints they did not choose. Some internalize the blame, wondering whether they could have done better, whether they should have pushed back harder, whether they lack something. The structure produces this doubt as a feature, not a side effect.

The system then produces a second deferral: the failed system is declared legacy (too old, too rigid, too expensive to maintain) and replaced. The replacement project is governed by the same annual budget cycle, managed by the same profiles, and evaluated by the same metrics. The cycle restarts. The debt that accumulated in the previous system is not examined as evidence of a structural problem but treated as the natural aging of technology, as entropy rather than design.

Software does not age. The observation is Schaefer’s, made in passing but worth dwelling on: software stays fixed in time. What changes is the context around it: the business it serves, the expectations placed on it, the people who maintain it. When an organization declares a system legacy, it is not describing a property of the technology. It is describing the accumulated consequences of decisions that were never attributed to their real cause.

A system whose failures are consistently misattributed, whose lessons are never learned, and whose replacements reproduce its conditions is not a system that is trying and failing to improve. It is a system that is successfully maintaining itself.

A Final Observation

This analysis is not offered as a counsel of despair to the practitioners who have spent years pushing against these dynamics, advocating for better design, raising concerns that were overridden, watching careful work be undone by delivery pressure. The frustration those practitioners feel does not mean they misunderstood something. It means they understood something correctly and found themselves playing a game whose rules made their understanding a competitive disadvantage.

Schaefer ended his 2007 paper with a question that remains unanswered: what are the limits of the will? He was asking whether individuals operating within deeply coercive systems retain any meaningful capacity for independent judgment. The question is not rhetorical. History suggests that the levers which have actually changed systems of this kind are rarely internal. They tend to be external: competitive pressure severe enough to punish rigidity, regulatory constraint that removes certain decisions from the negotiating table, or the cumulative weight of people who refuse to play the game and vote with their feet. Departures concentrate in exactly the profiles the system needs most, the Good Soldiers and Sacrificial Lambs who carry the technical judgment the Machiavellians cannot replace. Whistleblowing, when it occurs, is almost always punished before it produces change. Smaller organizations built deliberately outside the AHoC model sometimes succeed precisely because they have not yet had time to reproduce its conditions. None of these are solutions. They are the terrain on which change, when it happens, actually occurs.

The technical argument for architectural quality (modularity, decoupling, reversibility) remains correct. The problem is that it is a technical argument being made in an environment where the selection pressure runs in the opposite direction, and technical correctness has never overridden incentive structure.

What this analysis suggests is that the relevant question is not how to make the case for better architecture more persuasively. It is a prior question: in an organization that has systematically selected for political behavior, trained its managers in its legitimacy, and structured its governance to make individual rationality and collective interest incompatible, from what position, and with what leverage, is change actually possible?

That question does not have a technical answer.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Researcher (2005–2010): Image Processing & Creative AI
Business Expert / Domain Expert (2010–2026): Software Architecture, Software Development and Quality Practices

Reference

Schaefer, R. (2007). The Grand Theory of Everything: What Man-Made Systems Are, and Why They Fail. ACM SIGSOFT Software Engineering Notes, 32(4).

What AI Cannot Replace in Software Development, Part 3

In a previous article in this series, I proposed a redefinition of legacy: legacy is not a property of the code itself, but a state of the relationship between the code and those expected to maintain it. A system becomes legacy the moment no one in the organization mentally inhabits what they are nonetheless expected to evolve. The problem lies less in the age of the technology than in the developer’s lack of deep cognitive engagement with their own code.

This definition raises an urgent question: if generative AI produces code in place of developers, and if those developers only supervise the output without having genuinely thought through the underlying reasoning, are we creating the conditions for legacy at scale from the very first generated line?

The purpose of this article is to examine this question and its organizational consequences. Partial integration of AI into the development process tends to create a structural instability, one that leads logically to what I call a tipping point: a discontinuity in how an organization must configure itself. Getting through this transition also requires a precise understanding of which organizational assets are truly durable, and the answer is less obvious than it appears.

Cognitive Engagement as a Condition of Maintainability

When a developer writes code, they do more than produce text: they build a mental representation of the problem, its constraints, edge cases, and trade-offs. This representation lives in procedural memory and enables effective maintenance: the ability to anticipate where things will break, to understand why a decision was made, and to assess the impact of a change without simulating the entire system.

When a developer merely supervises AI-generated code, this mental representation does not fully form. They can read the code, validate its apparent logic, and approve a pull request, but they have not traversed the reasoning that produced it.

Supervising AI-generated code without engagement in the reasoning that produces it is functionally similar to maintaining a legacy system: one understands what the code does, but not why it does it that way.

I am not criticizing generative AI as such. I am describing a structural property of the situation: intellectual ownership of code is a consequence of the creation process, not of reading the result, and review cannot supply it after the fact.

The Tipping Point: A Structural Discontinuity

Organizations that integrate generative AI without changing the structure of responsibility tend to drift into an unstable intermediate state, which typically becomes visible only during the first serious incidents.

Developers believe they are supervising, but have progressively lost the capacity to intervene autonomously. The system keeps growing, technically modern and cognitively orphaned. In several AI-assisted transitions I have observed, the pattern is consistent: productivity is high for months, velocity metrics look excellent, confidence is strong. Then comes the first non-trivial evolution (a scaling constraint, an architectural shift, or a subtle behavioral regression), and no one can confidently explain why the system behaves as it does.

The problem with gradual transition is precisely that it produces this situation without anyone having made the deliberate choice to accept it. The organization bears the costs of both models without benefiting from the advantages of either.

The relationship between human intellectual ownership and AI integration is not linear. Below a certain threshold of engagement, maintainability tends to collapse in a way that is difficult to reverse once the accumulated gap reaches critical mass. This threshold is the tipping point. It separates two internally stable configurations from a fragile intermediate zone.

The Two Stable Configurations

The Human-Author Model

Humans remain the cognitive authors of the code. Generative AI serves as an accelerator for boilerplate, refactoring, or exploration, but the developer still traverses the reasoning. They can explain every significant decision, debug unexpected behaviors, and anticipate the consequences of changes. This model preserves long-term maintainability and integrates naturally with existing quality practices. Its main constraint is speed: AI amplifies productivity but does not replace the human traversal of reasoning.

The Agent-Author Model

Agents become responsible for producing the code. Humans step out of the traditional technical loop. In exchange, the organization reconfigures itself deeply: code loses its status as a durable strategic asset and becomes a temporary instantiation of behavior defined elsewhere, rewritten on demand from specifications and behavioral tests, which now form the primary reference. Classical technical debt tends to be largely replaced by a different form of accumulated cost centered on specification quality and test completeness. Architecture becomes declarative: focused on what the system must do, not how.

Which of these assets, then, are truly durable over time? Current agent-oriented frameworks largely leave this question unanswered, and it deserves careful examination before committing to this model.

The Hierarchy of Durable Assets

Specification Drift and the Limits of Natural Language Stability

Current agent-oriented frameworks tend to treat specifications as a stable abstraction layer above the model. The assumption is that you write the spec once and can reliably regenerate the system across model versions and technology changes.

This assumption deserves scrutiny. Practitioners already observe prompt drift, LLM drift, and context drift: the gradual degradation in how a specification is interpreted as models evolve. A specification that worked reliably with one model version can produce subtly different behaviors in its successor, not because the spec changed, but because the model’s implicit understanding of its constructs has shifted. The long-term stability of a specification is coupled, implicitly, to the stability of the model that interprets it.

In systems meant to last years or decades, this specification drift becomes more than a prompt engineering inconvenience; it threatens the long-term reproducibility of the system itself. Subtle divergences can accumulate in the spaces between explicit requirements, even when tests continue to pass on covered behaviors. Current frameworks do not yet formally manage this coupling.

The Asset Hierarchy

This leads to a clear hierarchy of durability:

• Code is ephemeral by design, the least durable asset. It is regenerated, not evolved.
• Specifications are semi-stable. More durable than code, but subject to semantic drift relative to evolving models. They require active, periodic re-validation.
• Behavioral tests constitute the most stable anchor. A well-designed test yields a binary, objective verdict (it passes or it fails), independent of any model’s interpretation of intent.

However, the durability of tests ultimately rests on the quality of the human oracle that defines them. A poorly conceived test can protect incorrect behavior as reliably as a good one protects the right one. This brings us back directly to the oracle problem examined in the first article of this series: tests are only as strong as the human reasoning behind them.

In the agent-author model, the true organizational anchor is the behavioral test suite, but only insofar as it crystallizes genuine human understanding of expected behavior. Tests are the formal record of the oracle’s judgment, not a substitute for it.

Quality Assurance as a Foundational Discipline

This inversion is structural. In traditional development, QA is positioned as downstream validation. In the agent-author model, defining, maintaining, and evolving behavioral tests becomes the first step in the process, and the most consequential one.

The quality engineer who designs solid behavioral test suites is no longer in a support role. They steward the behavioral knowledge that makes reliable system regeneration possible across time, model versions, and technology generations. QA shifts from a verification function to a core strategic competency.

The Human Role in the Agent-Author Model

Agents operate within a bounded context, a necessary reduction of reality that always implies information loss. The real world is structurally larger than any context an agent can receive: regulatory constraints, internal political dynamics, implicit contractual commitments, strategic directions, stakeholder relationships. None of this is fully visible to a system operating within a defined context.

A concrete example: agents might correctly choose a technically superior tool within their context, yet overlook a token cost ten times higher, an unevaluated vendor dependency, or a strategic direction not yet formally communicated. These elements simply were not in their context.

The human role is therefore not to supervise code, but to maintain alignment between the space of agents and the real world that will never be entirely captured in a context. It is a translation role: transposing the constraints, objectives, and values of the real world into clear intentions for systems that operate within bounded spaces. Humans retain responsibility for the what and the why. Agents manage the how.

In this model, IT professionals do not disappear; they migrate. Their expertise moves from writing code to mastering specification quality, behavioral verification, and domain knowledge. The longstanding comprehension gap between business and IT dissolves here through a deeper reconfiguration of the IT role itself.

A Historical Precedent: The Transition to Deep Learning

The shift I describe has a direct parallel in AI’s own history. For several decades, symbolic expert systems emphasized full interpretability: every rule was explicit and traceable. The transition to deep learning abandoned this property. Neural networks produce impressive results through mechanisms their creators cannot fully explain. The debate was settled by results rather than philosophy: deep learning produced capabilities that symbolic systems could not reach.

AI became what it is today because the scientific community collectively accepted abandoning internal interpretability as a necessary condition of a system’s validity. Observable performance replaced transparency of mechanism as the primary evaluation criterion.

The parallel with the tipping point is direct. In the agent-author model, one abandons code comprehensibility as a condition of maintainability. It is replaced by the quality of specifications and, above all, the completeness of behavioral tests. Observable performance replaces internal understanding.

This precedent does not prove the tipping point is inevitable everywhere, but it shows that abandoning one form of comprehensibility for another form of validation can produce significant gains, and that resisting the shift can carry a competitive cost.

The Organizational Question: The Greenfield Model

For large organizations with decades of technological history, transforming the existing base is rarely feasible in the short term. Legacy systems (those for which intellectual ownership has already been lost) do not lend themselves to migration toward the agent-author model without massive prior investment in specification.

The coherent pattern is the greenfield model: creating a new entity, such as a division, a subsidiary, or a distinct organization, configured according to the agent-author model from day one. This entity develops the competencies in specification, declarative architecture, and behavioral testing while the existing organization continues under the human-author model.

This pattern is not without precedent. Large financial institutions have used it for digital transformation initiatives. Cooperatives have created subsidiaries to explore new business models without risking their operational core. When transformation requires a reconfiguration too deep to be achieved from within, one creates something new alongside.

The resulting coexistence, with units in human-author mode managing the existing systems and units in agent-author mode building the future, is stable when the boundary between the two models is explicit and deliberate. The danger lies in blurring the line between them, not in having two models.

Implications for Practitioners and Decision-Makers

Three practical observations emerge:

First, diagnose honestly. The relevant question is not “what percentage of our code is AI-generated?” but “can our developers intervene autonomously and confidently in the code that exists?” An uncertain answer signals that the organization is likely already in the unstable intermediate zone, without having made the deliberate choice to be there.

Second, choose deliberately. Maintaining the human-author model requires frameworks that preserve developers’ traversal of reasoning: not excluding AI, but ensuring they remain genuine authors of what they maintain. Moving to the agent-author model demands significant prior investment in specification quality and behavioral tests before the transition, not after.

Third, protect the right asset. Resist the temptation to treat specifications as the primary investment. The behavioral test suite, grounded in rigorous human judgment, is the more stable and strategically critical anchor. Specifications communicate intent to agents; tests verify that the intent was correctly understood. Only the latter survives model evolution without active re-validation.

The intermediate zone, where humans supervise code they have not genuinely inhabited without strong specifications and tests, is a trap rather than a transitional state. It is precisely where tomorrow’s legacy forms, at the accelerated speed of generative AI.

In the previous article in this series, I argued that the capacity to judge the correctness of a result is an irreplaceably human competency. Machines can evaluate outputs; what they cannot do is define what constitutes a correct output, because that requires an understanding of the real world that exceeds any formalizable context.

The tipping point does not contradict this thesis. It extends it upward. In the agent-author model, humans no longer judge the correctness of code. They define the behavioral tests that encode what correctness means, and they translate the real-world constraints that no bounded context will ever fully capture. The oracle does not disappear: it moves upstream and becomes the organization’s most critical competency.

AI is already transforming software development.
The question is whether your organization will deliberately choose its tipping point, or simply drift into one without realizing what it has surrendered.

Gabriel Mailhot
Organizational Engineering for the AI Era
Researcher (2005–2010): Image Processing & Creative AI
Business Expert / Domain Expert (2010-2026): Software Architecture, Software Development and Quality Practices

Series: What AI Cannot Replace in Software Development

An Operational Distinction

I have spent a significant part of my career working with organizations whose human foundation is unstable: high turnover, frequent reassignments, temporary teams assembled for a project and dissolved at its close. In these organizations, something specific happens to software systems over time. The knowledge of why the code is the way it is gradually disappears.

It is most visible with legacy systems. Take VB6 applications, COBOL modules, early Java codebases: the developers who built them have moved on, retired, or simply forgotten. What remains is the code itself, and a thin layer of documentation that rarely captures the decisions and constraints that shaped it. New developers inherit a system they can run but not fully understand.

I had assumed this was a problem of time, in which knowledge erodes because the people who held it leave. Then I started observing something different in teams using AI coding assistants intensively. The developers were still there, yet the knowledge was still eroding. The mechanism was disengagement rather than departure.

AI creates distance through engagement rather than through time, and that distinction changes how we should think about what developers must retain.

The Structural Advantages of AI: Memory and Computational Speed

AI has two advantages that do not depend on the quality of the model or its version: near-unlimited memory and processing speed that vastly exceeds human cognition.

Memory first. A large language model has been trained on billions of lines of code, millions of technical discussions, years of documentation. It can instantly retrieve the exact syntax of a rarely used API, the correct pattern for an obscure edge case, the exhaustive list of parameters for a given function. No developer, however experienced, can compete on this terrain.

Speed next. AI accomplishes in seconds what would take hours: generating boilerplate, converting an algorithm from one language to another, reformatting a data structure, producing variants. This is a real, measurable advantage, and it is not going away.

These two advantages are what they are: memory and performance, not judgment.

What the Developer Must Retain: Causal Understanding

The boundary between what AI does well and what it cannot do is more precise than a split between memory and reasoning in the abstract sense. It runs between pattern recognition and causal understanding.

An experienced developer who identifies a race condition in multithreaded code does more than recognize a familiar pattern. They understand why that pattern is problematic in this specific context: which timing constraint creates the risk, which property of the system makes the bug intermittent, which fix will resolve the problem without creating another.

AI can recognize the pattern. It does not possess the causal understanding that allows one to evaluate whether that recognition is relevant in this context. This understanding of the system, the domain, and the real constraints is what the developer must retain.

The concern has empirical support. A randomized controlled trial examining how AI coding assistance affects skill development found that developers using AI assistance scored 17 percentage points lower on comprehension and debugging tests than those coding manually (50% versus 67% on average). The contrast was even sharper by usage pattern: developers who delegated code generation to AI scored below 40%, while those who used AI for conceptual inquiry while coding independently scored 65% or higher. The engagement pattern mattered more than the tool itself.

This includes, as discussed in the first article of this series, the definition of expected behaviors and the design of tests. These activities call for judgment about what the system must do in the real world, not memorization.

Knowledge Erosion: An Underestimated Organizational Risk

When a developer delegates to AI not only memory and speed, but also understanding, a silent phenomenon takes hold: knowledge erosion.

The traditional form of this erosion is familiar. Developers leave, and with them goes the understanding of why the system is structured the way it is (the decisions, constraints, and trade-offs that shaped it). Call it a distance of time: the gap between the people who understood the system and those who now maintain it.

What AI introduces is structurally different. The developers are still there, but their engagement with the code has diminished. The cognitive effort of reading it, holding its structure in mind, and reasoning about its consequences no longer happens. They generate, accept, and move on, and the knowledge never forms.

This is a distance of engagement, and it is more insidious than the distance of time because it is invisible. The team is stable, the velocity metrics are green, the system runs. Yet the understanding that would allow someone to reason confidently about changing it has quietly failed to accumulate: anticipating the consequences of a modification, recognizing a subtle regression, formulating a test without looking at the code.

Teams using coding assistants intensively report that developers increasingly struggle to explain code they have recently written themselves. Understanding atrophies from lack of exercise, and a developer who does not fully understand their own system can no longer evaluate its quality. This closes the loop with the testing problem from the first article. Such developers can no longer verify that the system does what it should. They may not have lost sight of the intent, but they no longer understand the code well enough to reason about whether it delivers it.

The Optimal Division of Labor

The right question is therefore not “should we use AI?” but “for what should we use it?”

AI as a memory extension: syntax, APIs, known patterns, mechanical conversions, boilerplate. The developer formulates the request, evaluates the result, decides whether to integrate it. AI accelerates access to what they already know how to look for.

The developer as guardian of understanding: architecture, expected behaviors, edge cases, domain constraints, tests, decisions that commit the future of the system. These activities are not delegated. AI may well produce something that resembles them, but their value lies precisely in the human judgment that produces them.

This division is a stable structure rather than a temporary limitation, grounded in what causal understanding requires: lived experience of the system, knowledge of the domain, and accountability for the outcome.

Implications for Organizations and Training

This analysis has direct consequences for how organizations train their developers and evaluate the value of AI.

On training: the goal should not be to teach developers to use AI, but to ensure that AI use does not replace the development of understanding. Practices that require reading code, manual debugging, and peer review, precisely those that delivery pressure tends to eliminate, become more important.

On value assessment: the usual metrics (lines of code produced, delivery speed, test coverage rates) do not capture knowledge erosion. An organization can see its metrics improve while its capacity to master its own system degrades. The indicators that matter are harder to measure: a developer’s ability to explain why an architectural decision was made, to recognize a subtle regression without running the tests, or to reason confidently about the consequences of a change they have not yet made.

AI does not save time; it changes the nature of work by shifting value toward what the machine cannot do. Organizations that understand this invest in human understanding. Those that do not let it atrophy without even noticing.

Legacy systems are already showing us what a system looks like when its knowledge has disappeared. The question is whether we are building the legacy systems of 2035 right now. If the specifications and tests that protect expected behavior are themselves produced by developers who no longer fully understand the system, the circle closes on itself, and the erosion spreads beyond the code to the knowledge that was supposed to protect it.

The distance of engagement is a choice, until it isn’t.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: What AI Cannot Replace in Software Development

The Problem Nobody Names

A few years ago, I reviewed a software development contract between an organization and a vendor. The terms were standard: a fixed delivery date, a penalty clause for late delivery, and an obligation to maintain 80% code coverage. The intent was twofold. It would protect the organization from negligence, and guard against the kind of deliberate opportunism that governance frameworks exist precisely to prevent.

When the project fell behind schedule, the vendor found a way to satisfy the coverage requirement without slowing down: they had the AI generate unit tests after the developers had written the code. The coverage metric turned green, the delivery date was met, and the penalty was avoided.

Then came UAT, and the acceptance phase surfaced problem after problem. The tests had protected nothing, because they had been written to describe what the code did rather than what the system was supposed to do.

The contract had specified a metric, and the metric had been satisfied. The organization had paid, contractually and technically, for a test suite that institutionalized its own blind spots.

I am often asked whether it is a good idea to let AI generate unit tests. That experience is part of my answer. The complete answer is more interesting, because it touches on the nature of testing, the source of truth in a software system, and what AI actually changes in the work of a developer.

The Test Oracle Problem: What Research Already Knows

In the software engineering literature, the problem has a precise name: the test oracle problem. It designates the central challenge of any automated test generation. How do you automatically distinguish correct behavior from incorrect behavior?

Automated generation tools, including those based on large language models, produce what are called regression oracles: tests that capture what the code does today, not what it should do.

When you ask AI to generate tests from source code, you invert the causality of testing. The test becomes a mirror of the implementation, and if the implementation contains a bug, the test will capture it in order to protect it rather than flag it. Beyond introducing a bug into the system, you put in place an infrastructure that resists its correction.

Alan Turing demonstrated formally that one can never prove a program is free of all bugs. This is a consequence of undecidability: no general procedure can determine whether a program behaves correctly in all cases. In practice, this means there will always be incorrect behaviors the code produces without anyone having intended them. When AI takes the code as its source of truth, it freezes these invisible behaviors at industrial scale.

The test oracle problem is not new; what AI changes is its scale. A developer writing tests manually is constrained by the time it takes. An AI generating tests from code can institutionalize incorrect behavior at industrial speed, producing in seconds a test suite that would have taken days to write and that is wrong in exactly the same way throughout.

What Kent Beck Understood, and What Automated Generation Ignores

Kent Beck, in his Test-Driven Development philosophy, establishes a distinction that remains underappreciated: a test must speak to behavior, not implementation. Behavior is the very reason the code needs to exist. Unlike code, it is stable: it survives refactorings, technology changes, and complete rewrites.

A behavior-based test is a living document of the system’s intent. Future developers will refer to it to understand what the system must do, as opposed to what it happens to do today.

A test generated from code lies about that intent, documenting the accident rather than the design.

This has an organizational consequence the technical literature does not make explicit. An untested bug can be discovered and fixed freely. A bug protected by a test becomes a norm. Any attempt to correct it will cause the test to fail, creating institutional pressure not to fix it. At that point the problem is one of governance as much as of technique.

A test generated from code does not protect against bugs. It protects against change, including the change that would fix the bug.

The Limits of Specifications as a Substitute

One might think the problem is solved by asking AI to generate tests from specifications rather than from code. This is a direction academic research is actively exploring, enriching prompts with documentation, developer comments, and semantic context. It is better, but it is not enough.

A specification is always incomplete. Consider a typical example: a spec describes how a search feature should return results ranked by relevance. It says nothing about what happens when two users submit the same query simultaneously, or how the system should behave when the underlying index is being updated, or what “relevance” means when the user’s implicit intent differs from their explicit query. No negligent author forgot these edge cases. They belong to the class of conditions that only become visible when the system meets real users in a real environment.

Human judgment detects these gaps naturally, by confronting the spec with lived experience of how systems fail, how users actually behave, and what the production environment will impose. AI generates tests that are consistent with what is written, without the ability to signal what is missing.

A better model will not remove this limitation, because it is structural rather than temporary: understanding the real world, with its complexity, ambiguity, and unspoken assumptions, remains a capability current systems do not possess.

The Real Asset of a Software Organization

In a world where AI generates code, the real asset of an organization becomes its specifications and its tests.

The code itself will be rewritten, migrated, replaced. What endures is the knowledge of expected behavior, captured by humans who understand the problem in its full complexity.

This conclusion does not appear in the technical literature or in analyst reports, which measure the value of AI in terms of volume produced. It is a thesis about the nature of a software organization’s intellectual asset, and it radically changes what is worth investing in.

Organizations that have understood this invest in the quality of their specifications and in the human rigor of their tests. Those that delegate both to AI, working from existing code, leave their technical debt in place while making it harder to see and harder to correct.

The question of what the developer must retain, and what can legitimately be delegated, extends beyond the problem of tests alone. It touches on the cognitive division between human and machine, which is the subject of the next article in this series.

If the real asset of a software organization is not its code but its understanding of expected behavior, who in your organization is responsible for building and protecting that understanding? And what happens to it when the pressure to deliver is high enough?

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: What AI Cannot Replace in Software Development

In the organization where I work, there is a mainframe COBOL system that has been running at the core of operations for decades. By every conventional definition, it should be legacy: old language, old architecture, a technology that most developers under forty have never touched.

It is not legacy. The team responsible for it is among the most mature and capable in the organization. They understand every decision embedded in that system: the constraints that shaped it, the business rules it encodes, the edge cases it handles. They can explain why a specific field is structured a certain way, what regulatory requirement drove a particular branching condition, and exactly what would happen downstream if you changed it. There is no question about the system they cannot answer.

Contrast that with a microservices architecture I reviewed at another organization. It had been built two years prior on a modern stack, with 85% test coverage and a full CI/CD pipeline. The team that built it had since been reorganized. No one could explain why the service boundaries had been drawn that way. Modifying anything felt like defusing a bomb. That system was legacy from the inside out, despite being less than two years old.

Michael Feathers defined legacy code as code without tests. The definition is pragmatic and useful, since tests reduce the uncertainty of change, but it is incomplete.

Tests are not the cause of human engagement with code. They are a partial substitute for its erosion.

When a team genuinely understands a system (its decisions, its constraints, its intended behaviors), tests are almost redundant as a knowledge preservation mechanism. When that understanding has eroded, tests become the last line of defense against the unknown. They matter enormously in that role. But their presence does not mean the understanding is there.

Legacy is not a property of the code. It is the state of the relationship between the code and the people responsible for it.

A system becomes legacy at the moment when no one can confidently answer: why does it work this way? Not how, since any developer can read code, but why: the reasoning, the trade-offs, the domain constraints that shaped the implementation. When that knowledge is gone, whether through team turnover, disengagement, or the gradual accumulation of changes nobody fully understood, the system has crossed the threshold.

This distinction matters because it changes what the problem actually is. If legacy is a technical property, the solution is technical: rewrite, refactor, add tests, modernize the stack. If legacy is a relational property (a broken link between a system and its human maintainers), then the solution requires restoring that link. Sometimes that means tests. More often it means something harder: rebuilding the shared understanding of what the system is supposed to do, and why.

Tests, documentation, and architecture diagrams are mechanisms for transmitting intent across time and team boundaries. They matter, but they are proxies for something more fundamental: the capacity of a human being to understand a system well enough to change it with confidence.

As long as that capacity exists, the software is alive, regardless of its age, its language, or its test coverage.

The moment it disappears, the system becomes legacy. And no amount of refactoring will fix that without first addressing the human dimension.

This is the foundation on which the rest of this series is built. The next article takes up the question that follows: what happens to that human capacity when AI generates the code?

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: What AI Cannot Replace in Software Development

Why I Am Writing This

I have been thinking about analogy since 2005, longer than I have been thinking about most things professionally.

At the time, I was working as a researcher in Québec City, trying to build a system that could assist creative professionals in finding visual inspiration. The technical problem was tractable. But solving it required first answering a question I had not expected: what is creativity, actually? Not as a personality trait or a cultural value, but as a cognitive mechanism.

The answer I arrived at led to an architecture, a patent specification, and a set of ideas that I could not discuss publicly for fifteen years due to contractual obligations.

By the time those constraints lifted, the world had changed considerably. LLMs had appeared, AI had become a public conversation, and the organizations I was working with were exhibiting exactly the pathologies I had been thinking about. I finally had both the freedom and the context to say so.

This essay is where those two threads meet.

The solutions to most organizational problems already exist. They were developed in other domains, under a different name.

Analogy versus Metaphor: A Distinction That Matters

There is a common confusion between metaphor and analogy that matters more than it might appear. A decorative metaphor makes an idea accessible; it creates recognition, sometimes resonance. A structural analogy reveals a real correspondence between two systems: it diagnoses, and it points toward solutions. The difference is epistemological, not stylistic.

Saying “an organization is like an organism” is a metaphor. It invites a certain way of seeing. Demonstrating that the mechanism of cellular apoptosis and the dysfunction of project management share exactly the same causal structure (a local unit disconnected from systemic feedback, optimizing for its own survival at the cost of the whole) is a structural analogy. The first inspires; the second diagnoses.

The core formulation is this: human creativity is combinatorial, not generative ex nihilo. The only way to produce something genuinely new within a bounded experiential space is to discover a structural correspondence between two distant domains that are already known. Novelty is a function of semantic distance between domains. Utility is a function of the match with the problem and with the evaluator’s own criteria.

This formulation connects to a tradition of research in cognitive science that has approached the same question with more formal rigor. Dedre Gentner’s structure-mapping theory (1983) established that what gets mapped in an analogy is not object attributes but relational structure: the causal and functional architecture of a domain, independent of its surface content. Douglas Hofstadter and Emmanuel Sander, in Surfaces and Essences (2013), argued that analogy is not a special cognitive operation but the very engine of thought, the mechanism by which every act of categorization and understanding operates. Arthur Koestler, in The Act of Creation (1964), called the productive collision of two incompatible frames of reference “bisociation,” the mechanism behind both humor and discovery.

What this research tradition establishes, and what the diagnostic method proposed here builds on, is that structural correspondence is the operative criterion. The question is not whether “these domains feel similar” but whether “these domains share the same relational architecture.” The implication for organizational diagnosis is direct: the value of an analogy is structural rather than rhetorical, and it can be evaluated as such.

A Taxonomy of Analogical Domains

Not all distant domains are equivalent as diagnostic tools, and not all combinations of domains are equally powerful. The patent specification formalized a taxonomy for a metaphor-based search system, and that taxonomy maps directly onto the diagnostic method proposed here.

Three types of relationships between analogical domains matter:

Alternative domains cover the same structural dimension of the problem. They are interchangeable: selecting one or the other yields the same diagnostic contribution. Using both is redundant. They compete rather than combine.

Complementary domains cover distinct structural dimensions of the problem. They are combinable, and their combination produces a structural coverage that neither achieves alone. This is where the power of the method concentrates: finding two or three domains that together cover all dimensions of the problem.

Linked domains are complementary domains that also share an internal overlap with each other. That coherence strengthens the combination and makes it more than the sum of its parts.

The selection criterion for a strong set of analogical domains is therefore maximum structural coverage with maximum internal coherence, not quantity. Three well-chosen complementary domains with strong internal links produce a richer diagnostic than ten loosely related ones.

This taxonomy disciplines the method. Without it, analogical reasoning risks becoming what it seeks to transcend: the accumulation of decorative metaphors that feel illuminating without actually diagnosing anything.

The Constraint of the Judge

A structurally rigorous analogy is not automatically an adopted solution. Its value is co-constructed between the structural correspondence and the human evaluator who receives it.

The 2005 theory was precise on this point: utility is a function of the match with the problem and with the evaluator’s own criteria. For organizational diagnostics, this introduces a constraint that the method cannot dissolve but can make visible: the judges of a proposed solution are often precisely the people whose reward system is aligned with the status quo that the solution diagnoses.

A chief risk officer evaluating a proposal to extend project manager accountability beyond delivery dates is simultaneously the person whose career was built on the existing governance model. A board reviewing a recommendation to shift from process-driven to principle-driven governance is the same board that approved the processes now being questioned.

The method does not resolve this. What it does is name it with precision, which is the first condition for treating it. It also shifts the framing: the resistance is structurally predictable rather than irrational. That means it can be anticipated and designed around, and sometimes dissolved by finding the frame in which the solution resonates with the judge’s own criteria.

This is itself an analogical problem: finding the presentation of the solution that achieves maximum structural coverage of the judge’s own conceptual framework. The method recurses.

The Demonstration: Project Management and the Short Horizon

The Observation

A technology asset with a multi-year lifecycle is managed through a sequence of fixed-budget, fixed-date projects. Each project team is constituted for the duration of the project and evaluated on its ability to deliver within its commitments. Decisions are made to protect delivery dates and budget envelopes, and those decisions degrade the asset over the longer term. The team’s focus has shifted from the organization’s interest to the project’s success, which are not the same thing.

The pathology is consistent and well-recognized by practitioners. What is less well-understood is its causal structure, and therefore what kinds of interventions might actually address it rather than merely managing its symptoms.

Applying the Taxonomy: Three Complementary Domains

The search for analogical domains begins with a structural characterization of the dysfunction: a local unit optimizes for its own constraints, producing decisions whose costs are externalized to the larger system and to the future. The local unit has no mechanism to perceive or weight these externalized costs. Its reward system reinforces the optimization.

Domain 1, Biology (apoptosis): the mechanism

A cancer cell is not malfunctioning within its own frame of reference. It is optimizing perfectly for its own reproduction, which is precisely what makes it pathological for the organism. What is absent is apoptosis: the signal received from the organism that tells the cell when to stop reproducing, when to sacrifice itself for the integrity of the whole. Cancer is cellular disconnection rather than cellular rebellion: the rupture of the feedback channel through which the organism communicates systemic state to its constituent units.

The project team is in the structurally identical situation. It is not irresponsible by nature; it is disconnected from the signals that would allow it to integrate the systemic impact of its decisions. The organizational system has not built the equivalent of apoptosis, the mechanism by which a local unit receives information about what its decisions cost the larger whole.

What this domain contributes: the dimension of mechanism. The pathology is architectural, not motivational. The solution direction is not better incentives alone but the construction of a feedback channel.

Taxonomy check: this domain covers the mechanism dimension. It does not address who bears responsibility for the effects, nor why the disconnection is individually rational.

Domain 2, Law (deferred responsibility): the governance gap

Law has progressively recognized that retrospective responsibility is insufficient when effects are diffuse and temporally distant. The evolution from simple liability to fiduciary duty, from shareholder primacy to stakeholder obligation, from individual fault to systemic accountability, represents a legal tradition grappling with exactly the problem at hand: how to assign responsibility for effects that materialize outside the perimeter and after the horizon of the actor who caused them.

The project manager’s perimeter of responsibility does not correspond to the perimeter of impact of their decisions. That is a governance design problem rather than a competence problem, and law has spent two centuries developing frameworks for precisely this mismatch.

What this domain contributes: the dimension of governance. It reframes the question from “how do we motivate better behavior” to “how do we design a responsibility structure whose perimeter matches the impact perimeter of the decisions being made.”

Taxonomy check: complementary to biology. Biology covers mechanism; law covers governance. Their structural dimensions are distinct, so they combine instead of competing.

Domain 3, Neuroeconomics (reward systems): the deep cause

The human brain discounts the future at a high rate: a certain reward today is structurally worth more than an uncertain consequence in eighteen months. This is a cognitive architecture, not a character flaw. And organizational reward systems, when they encode short evaluation horizons, amplify this natural discounting rather than counteracting it.

Nassim Taleb’s skin in the game formulates the structural response: the person who makes the decision must bear a portion of the risk of its future consequences, as an alignment mechanism rather than a punitive measure. When the decision-maker’s long-term interest is structurally coupled to the long-term consequences of their decisions, the cognitive discounting of the future is partially corrected by the system design.

What this domain contributes: the dimension of deep cause. The disconnection is not merely architectural (biology) or ungoverned (law); it is also individually rational given the reward structure.

Taxonomy check: linked to biology. Both neuroeconomics and biology address adaptive mechanisms, one at the cellular level and one at the cognitive level. This internal overlap strengthens the coherence of the combination without making them redundant. Together, all three domains cover: mechanism + governance + deep cause.

The Synthetic Diagnostic

The local unit is disconnected from systemic feedback (biology). The organizational system has no mechanism to assign it responsibility for its deferred effects (law). And its reward system gives it no reason to seek reconnection (neuroeconomics). Each domain alone produces a partial diagnosis. Together, they produce a complete one.

Solution Directions: What the Source Domains Suggest

The biological analogy suggests constructing a systemic feedback channel: a technology asset health metric that follows the project manager after delivery, visible to them during the project as a forward-looking indicator of the consequences their decisions are accumulating.

The legal analogy suggests redefining the responsibility perimeter. The next team that inherits the asset should have a formal mechanism to evaluate and record the state in which they received it, and that evaluation should be part of the delivering team’s record. Accountability extends to the handoff instead of ending at the launch.

The neuroeconomic analogy suggests realigning the reward system with the asset’s horizon rather than the project’s: evaluating the project manager’s performance at 24 months post-delivery, weighted toward asset quality indicators, as incentive alignment rather than punishment.

These three solution directions are as complementary as the domains that generated them. Each addresses a dimension the others do not, and their combination amounts to a governance redesign rather than a management improvement.

What the Method Does, and What It Does Not

The method produces precise diagnostics and solution directions that the source domains have already explored. It does not produce turnkey solutions: the transposition to the specific organizational context remains a work of judgment that the method cannot replace.

What it avoids: reinventing wheels that other domains have already manufactured, and remaining imprisoned in the managerial vocabulary that masks the real structure of the problem. A problem named in managerial terms produces managerial solutions. The same problem named in biological, legal, and neuroeconomic terms produces a radically different solution space.

The method also has direct implications for agentic AI systems. An agent that reasons purely by similarity, retrieving the nearest known pattern and applying it, is executing the organizational equivalent of process-following. An agent capable of structural analogy (identifying correspondence across distant domains, composing complementary representations, evaluating coverage rather than proximity) would be executing something closer to genuine reasoning. In AI systems, the gap between similarity and analogy is the gap between a sophisticated retrieval engine and a system capable of diagnosis.

Organizations do not lack solutions. They lack the ability to recognize them across domains.

The method remains constant. The domains change. And each time, the question is the same: what is the structural correspondence, who has already solved this problem, and what does that suggest here?

If the pathologies of organizations have already been solved (in biology, in law, in physics, in software design), what are we waiting for to transpose those solutions? And what does it say about our field that we keep reinventing the same diagnoses without looking next door?

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Structural Analogy as an Organizational Diagnostic

The first three articles in this series examined specific symptoms: the instability of the People-Process-Tools model under high human variability, the strategic liability of tool positioning in a fast-moving AI market, and the asymmetric risk that regulated organizations are structurally failing to measure. This fourth article steps back to name the underlying condition, the diagnosis from which those symptoms follow.

AI is not just a technological disruption. It is an organizational architecture disruption.

A Mismatch That Went Unnoticed Until Now

For most of the industrial and information age, there was a comfortable relationship between the pace of technological change and the pace of organizational adaptation. Technology evolved, but slowly enough that organizations could absorb each shift, stabilize their processes around it, and build institutional knowledge before the next wave arrived. The lag between technological possibility and organizational practice was an inconvenience, not a structural threat.

That relationship has inverted. For the first time in the history of organized work, the speed of technological evolution is structurally outpacing the speed of organizational adaptation. Rather than a temporary disruption caused by one particularly fast technology cycle, this is a change of regime: a permanent shift in the relative velocities of technological change and organizational response.

The evidence is visible in every domain. Organizations complete a tool evaluation cycle and find the market has already moved. They design a training program for a capability that AI has partially automated by the time the program launches. They build processes around a set of constraints that are redefined by regulatory guidance six months later. The gap is widening rather than closing, and the organizational models built for a slower world are showing the strain.

Why Processes Were the Right Answer, and What They Assumed

Consider what processes actually are, and why they represented such a powerful organizational technology for so long. Beyond being a list of steps, a process is an encoded solution to a recurring problem, a crystallization of organizational learning into a repeatable, transferable, auditable form. When an organization documents a process, it is converting tacit knowledge into institutional memory, individual judgment into scalable behavior.

This is genuinely valuable, and it rests on three assumptions that held for most of the twentieth century and well into the twenty-first: that the problem being solved is sufficiently stable to justify encoding, that the conditions under which the process operates will remain predictable enough for the steps to stay valid, and that repeatability is itself a source of value (doing the same thing reliably, at scale, is better than improvising every time).

AI attacks all three assumptions simultaneously. It renders stable problems unstable by continuously shifting what is technically possible and economically rational. It introduces permanent uncertainty into operating conditions. And it transforms repeatability from an asset into a fragility: the ability to execute the same steps reliably becomes a liability when those steps are precisely what needs to change.

Processes are not so much wrong as misaligned, optimized for a world that is receding faster than most organizations have recognized.

Processes Are Becoming Legacy Systems

In technology, we use the term ’legacy system’ to describe something specific: not a system that is broken, but a system that was built for a set of constraints that no longer match the environment in which it now operates. A legacy system can be technically functional, even well-maintained. What makes it legacy is the growing gap between its underlying assumptions and current reality.

This is precisely the condition of process-driven organizational architectures in the face of AI-driven technological turbulence. The processes themselves may be executing correctly. The people following them may be doing so diligently. The problem is architectural. The way the organization governs work (through predefined steps, stable roles, documented procedures, sequential approvals) was designed for a world of slower change, and that world is no longer the operating environment.

The recognition is uncomfortable because process-driven governance is deeply embedded in how organizations understand accountability, compliance, and quality. Audits verify process adherence. Performance frameworks reward process execution. Regulatory frameworks often mandate specific processes. Saying that processes are becoming legacy systems does not mean that accountability, compliance, and quality no longer matter. It means that the mechanism through which they have been achieved is reaching the limits of its fitness for purpose.

Principle-Driven Systems as the Architectural Response

If processes assume stability, principles assume change. This is the essential distinction, and it points toward a different architecture for organizational governance.

A principle defines what must be true: the quality threshold that cannot be compromised, the constraint that is non-negotiable, the outcome that must be achieved. It does not prescribe how. It governs by results rather than by steps. Teams operating under a principle-driven system follow guardrails and pursue defined objectives, but they adapt their methods continuously as the environment evolves, while the principle itself stays stable.

This is not a novel idea in theory. Agile movements, outcome-based management, and mission-command doctrine in military organizations have all pointed in this direction. What is new is the urgency and the mechanism. The urgency comes from the acceleration of technological change. The mechanism comes from agentic AI architectures: systems that are natively coupled to objectives and constraints rather than to specific tools or procedures, and that can adapt to changing operating conditions without requiring the governance layer to be redesigned every time the tooling shifts.

Agentic architectures are not simply a more efficient way to execute processes. They are an architectural alternative to them, embedding adaptability at the level of the system itself rather than relying on human judgment to compensate for procedural rigidity.

Consider a concrete illustration. A logistics team operating under a process-driven model has a documented approval workflow for any change to its supply chain routing tools, a cycle that takes weeks and requires sign-off from architecture, security, and procurement. When a new AI-powered routing tool becomes available, the process triggers in full, regardless of how minor the change. Under a principle-driven model, the governing constraint is different: “all routing decisions must maintain delivery reliability above X%, cost variance below Y%, and full auditability.” An agent operating under those principles can evaluate and adopt a new routing tool autonomously, because what is being governed is the outcome rather than the mechanism. The principle holds, and the approval cycle dissolves.

The shift from process-driven to principle-driven governance is therefore primarily an architectural decision rather than a technology one. It concerns where stability should live in an organization. In a world of permanent technological turbulence, the answer is that stability must live in principles and outcomes, not in procedures and tools.

Organizations Must Be Engineered for Technological Turbulence

None of this argues for improvisation, or for abandoning the rigor that processes have historically provided. The argument is that rigor itself must be rearchitected. The question to settle is what to govern and at what level of abstraction, not whether to govern.

The organizations that handle the coming decade well will not be the ones that execute their current processes better, but the ones that have made a deliberate architectural choice: to invest in stable, well-defined principles rather than brittle, step-by-step procedures; to build agentic systems capable of working with continuously shifting tooling; and to develop adaptive governance frameworks that measure outcomes rather than adherence.

Engineering an organization for technological turbulence means building a particular kind of resilience. Bouncing back from disruption is one form of it; being structurally designed to absorb continuous change without losing coherence is another. The distinction matters, because the first is a recovery capability and the second is an architectural property.

The organizations that possess this property will not be immune to the challenges of an AI-accelerated environment. But they will face those challenges with a structural advantage: the ability to adapt their methods while holding their principles constant, and to absorb technological change as a normal operating condition rather than as an exceptional disruption.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

A Time-Tested Model Confronting an Unprecedented Context

The People, Process, Tools (PPT) model has shaped technology governance for decades. Its founding premise rests on the stability of human capital: skilled individuals, carrying a shared culture, apply defined processes using adapted tools. In its mature form, this model has always recognized that processes and tools encode organizational knowledge, with the human dimension serving as the activation vector.

But in an environment defined by high resource turnover, systematic reliance on external consultants, and the proliferation of teams assembled for short-term needs, that premise of stability no longer holds. The PPT model remains theoretically valid. What is in question is whether it can operate effectively when its human pillar is structurally unstable.

The ‘People’ Pillar as an Unstable Variable

When resource turnover is high, organizational knowledge disperses instead of accumulating. Every departure takes with it decision-making context, tacit practices, and domain understanding that formal artifacts only partially capture. Internal culture loses its coherence when a significant proportion of contributors operates within a temporary horizon. Practices imported from outside, heterogeneous by nature, complicate governance and introduce variability that neither documented processes nor available tools can adequately contain.

Under these conditions, structuring quality around a constantly renewing pool of human expertise exposes the organization to real risks: operational discontinuity, practice drift, and erosion of technological maturity. What this calls for is a shift in ratio, not an inversion of the model. The human factor remains central, but it can no longer serve as the sole foundation.

Repositioning the Foundation: Processes, Tools, and Platform Engineering

Faced with this reality, it becomes necessary to shift the model’s foundation toward elements that remain constant: processes, tools, and now the platform. This reconfiguration does not marginalize the human role; it relieves it of a responsibility it can no longer bear alone in a context of high variability. Individuals stop being the source of coherence and become its beneficiaries: they join a structured environment that guides them from day one, regardless of their background.

The natural evolution of this approach is platformization. An internal platform encodes organizational knowledge in a reusable ecosystem of normalized pipelines, pre-configured environments, project templates, automated controls, and standardized practices. It substitutes a human memory that erodes with turnover for an integrated, persistent operational memory.

That said, this approach is demanding. Building and maintaining a quality internal platform requires a competent, stable, and well-governed team. The structural irony is real: to reduce dependence on interchangeable individuals, you create an infrastructure that requires highly specialized individuals over the long term. Many organizations underestimate this cost. A poorly designed or poorly governed platform can become an even greater obstacle than having no platform at all. This repositioning is no magic solution but a long-term investment, with its own governance requirements.

Artificial Intelligence as a Lever and as a Responsibility

The integration of artificial intelligence represents a significant acceleration of this logic. Within a heavily tooled system, AI can transform static processes into adaptive mechanisms: automated code analysis, test generation, continuous review, technical drift detection, and domain knowledge assistance. These capabilities reduce dependence on individual expertise and strengthen the system’s resilience against team turnover.

However, it would be inaccurate to present AI as a frictionless solution. Its effective deployment raises several challenges:

• AI system governance (prompt engineering, continuous output evaluation, data lineage management, bias monitoring) itself creates dependence on specialized competencies (MLOps, LLMOps, Platform AI) that are often rare and expensive.
• AI shifts human dependencies; it does not eliminate them. It generates new layers of specialization, often more demanding than those it replaces.
• The cognitive debt risk is real: junior profiles who become overly reliant on AI suggestions may develop impoverished reasoning, undermining precisely the human capital the system seeks to make less critical.

An organization that adopts AI as a pillar of its quality engineering must simultaneously invest in the governance of that pillar. Without it, you are simply substituting one fragility for another.

Scope of Application and Model Limitations

This repositioning is particularly well-suited to high-variability organizations: fast-growing scale-ups, technology consulting firms, product teams with a significant proportion of contractors, or IT service delivery environments. In these contexts, platformization and AI augmentation represent high-ROI levers for operational resilience.

In high-criticality domains such as aerospace, healthcare, heavily regulated finance, and critical infrastructure, this logic must be applied with considerable care. Individual accountability and accumulated expertise remain non-substitutable pillars in these fields. Automation and standardization can play a supporting role, but they cannot render the human factor ‘interchangeable’ without introducing risks of a fundamentally different nature.

A Hybrid Model for an Asymmetric Environment

The repositioning proposed here aims to rebalance the PPT model rather than invert it. In an environment where human variability has become the norm, operational excellence rests on an asymmetric combination: a solid platform infrastructure, processes that enforce coherence, and well-governed AI that increases resilience. As an indispensable complement, it also needs a core of highly skilled individuals who maintain and evolve the system and embody its vision.

This model does not guarantee excellence on its own. It creates the structural conditions under which excellence becomes reproducible and less dependent on the luck of individual trajectories. What you gain is predictability. You do not eliminate the need for exceptional people; their role concentrates where it is least substitutable, in judgment, innovation, and governance of the system itself.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

In a previous article, I argued that the People-Process-Tools model needs to be rebalanced toward platform engineering in contexts of high resource variability. This article extends that argument one step further: in a world where AI is redefining the available tools every few months, even the ‘Tools’ layer of that platform deserves to be rethought.

The Paradox of Tool Positioning

In large organizations, the process of selecting, evaluating, approving, and deploying a new tool is rarely a lightweight exercise. Between security reviews, architecture assessments, procurement cycles, integration planning, and training programs, the full lifecycle from initial evaluation to production readiness commonly spans six to eighteen months. For highly regulated environments, that timeline can extend further.

This investment was once rational. When technology moved slowly, the cost of a rigorous positioning process was amortized over years of standardized usage. The approved tool became part of the organizational fabric, embedded in workflows, documentation, onboarding paths, and institutional memory.

That calculus has changed. The current cycle of AI-driven tool evolution is measured not in years but in months, sometimes weeks. By the time an organization completes its positioning process for a given tool, the competitive situation may have shifted, the tool itself may have been substantially transformed, and a new generation of alternatives may have emerged. The organization ends up optimized for a world that no longer exists.

Why This Was Rational, and Why It No Longer Is

It would be unfair to dismiss tool positioning processes as bureaucratic excess. They exist for legitimate reasons: security and compliance requirements, interoperability constraints, support and vendor stability considerations, and the very real cost of fragmented tooling across teams. These concerns have not disappeared.

What has changed is the nature of the coupling between an organization and its tools. In a slower-moving environment, investing deeply in a specific tool (building expertise, integrations, and institutional knowledge around it) generated durable returns. That depth was an asset.

In today’s environment, that same depth increasingly functions as a liability. Deep coupling to a specific tool creates switching costs that slow adaptation. Institutional knowledge built around a particular interface or workflow becomes obsolete as AI transforms the tools themselves. The more thoroughly an organization has embedded a tool into its operating fabric, the more painful the inevitable transition becomes.

The issue lies less in the tools themselves than in the strategic weight organizations assign to tool selection. When tool positioning is treated as a long-horizon strategic commitment, the organization assumes a stability that the environment no longer provides.

The Pivot: From Tools to Principles

If tools are no longer a stable strategic variable, what is? I would argue for principles: the articulation of expected behaviors, quality standards, operational constraints, and governance guardrails that define how work should be conducted, independently of which tool happens to be executing it.

This shift goes deeper than it may initially appear. Principle-driven governance asks organizations to invest in defining what good looks like (what outcomes are expected, what boundaries must be respected, what quality thresholds must be met) rather than prescribing the specific mechanism through which those outcomes are achieved. The principle is stable; the tooling that enacts it is fluid.

Consider the difference between these two governance postures:

Tool-centric: “All code reviews must be conducted using platform X, following workflow Y.”

Principle-centric: “All code changes must demonstrate coverage above threshold T, pass static analysis at severity level S, and include a human review sign-off before merging.”

The second posture is tool-agnostic. It can be enacted by a human reviewer, a CI/CD pipeline, an AI-assisted review agent, or any combination thereof. As tooling evolves, the principle remains intact. Only the mechanism of enactment changes, and that change becomes an optimization rather than a disruption.

Agentic Architectures as a Tooling Abstraction Layer

This is precisely where agentic AI architectures become strategically relevant, as a structural response to tooling volatility and not merely as a productivity lever.

A well-designed agent is coupled to an objective, a set of constraints, and a definition of acceptable outputs, rather than to a specific tool. Given those parameters, the agent selects, orchestrates, and adapts its tooling dynamically. The tool becomes an implementation detail, visible to the agent but invisible to the governance layer.

In a multi-agent architecture, this abstraction scales. Individual agents can specialize (one handling code analysis, another managing test generation, another monitoring technical debt), each operating against the same set of organizational principles while independently managing their tooling layer. As new, more capable tools emerge, the agents can incorporate them without requiring a governance review of the tool itself. What gets reviewed is whether the agent’s outputs continue to satisfy the principles.

This represents a meaningful inversion of the traditional governance model. Rather than controlling quality by controlling tools, the organization controls quality by controlling outcomes. The locus of governance shifts from inputs to outputs, from “what tool are you using” to “are the results meeting the standard.”

The implications for large organizations are significant. Tool evaluation cycles shorten dramatically. Shadow tooling, a persistent governance challenge in organizations with slow approval processes, largely dissolves as a concern: if the agent is producing compliant outputs, the underlying tooling becomes an operational detail rather than a governance risk.

Limits and Conditions for Success

This architecture relocates governance complexity rather than eliminating it. Several challenges deserve honest acknowledgment.

Defining good principles is harder than it appears. Principle-driven governance requires organizations to articulate, with precision, what they actually care about. Vague principles produce inconsistent agent behavior. Overly rigid principles reproduce the brittleness of tool-centric governance in a different form. Getting the level of abstraction right requires significant organizational investment and ongoing calibration.

Output evaluation at scale is a partially unsolved problem. For well-defined, measurable outcomes such as test coverage, static analysis scores, or deployment frequency, this is tractable. For more qualitative dimensions like architectural coherence, domain appropriateness, and long-term maintainability, it remains genuinely difficult.

Agent maturity remains a limiting factor. Current agentic systems are capable and improving rapidly, but they are not infallible. Human oversight, particularly for high-stakes decisions, cannot be fully removed from the loop, at least not yet.

Regulated environments require special treatment. In domains where regulatory compliance is tied to specific tools, processes, or audit trails, the fluidity of agentic tooling introduces compliance risks that cannot be resolved through principle-definition alone.

A Governance Model Built for the Speed of Change

The organizations best equipped for the current period of technological acceleration are not necessarily those with the best tools. They are those with the clearest principles, along with the architectural flexibility to let those principles be enacted by whatever mechanisms become available.

This is a direct extension of the argument made in the first article of this series. If the People-Process-Tools model needs to be rebalanced toward platform and process in a context of human variability, then the tooling layer of that platform needs to be rebalanced toward principles and agents in a context of technological volatility.

The strategic question for technology leaders has shifted from “which tools should we standardize on” to “which principles are non-negotiable, and how do we build systems, human and agentic, that reliably enact them, regardless of what the tooling landscape looks like six months from now.”

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

The first two articles in this series examined how to rebalance technology governance toward platform engineering in contexts of high human variability, and why tool positioning is becoming a strategic liability in a world of accelerating AI. This third article steps back from the technical layer to address a more basic challenge: the organizational resistance that makes any of these transformations genuinely difficult, and the asymmetric risk of not moving fast enough.

Organizations have spent decades building systems to control technological risk. They have not built systems to detect technological irrelevance.

An Organization Does Not Have Processes: It Is Its Processes

There is a common way of framing organizational change that sounds reasonable but is misleading: the idea that an organization has processes, in the same way it has office space or software licenses, assets that can be evaluated, updated, or replaced through a sufficiently deliberate management decision.

The reality is more unsettling. An organization does not merely possess its processes. In a meaningful sense, it is its processes. They define how decisions get made, how work gets coordinated, how risk gets assessed, how value gets delivered. They encode the accumulated responses to past failures, regulatory pressures, and hard-learned lessons. Rather than a layer sitting on top of the organization, they are its operating identity.

This is the central insight behind Allen Holub’s work on systems of work: you cannot remove or change one element without affecting the entire system, and the system will actively resist changes that threaten its coherence, pulling the organization back toward its previous state. Organizational resistance to change is therefore not a failure of leadership courage or a deficit of innovation culture; it is the system functioning exactly as designed. The challenge is not to overcome that resistance through force of will, but to understand which parts of the system need to transform, and how to do so without collapsing the coherence that holds everything together.

AI Is Not Waiting at the Door: It Is Already Inside

Regulated organizations (financial institutions, healthcare systems, energy companies, public sector bodies, legal and professional services firms) have historically managed technological adoption through deliberate, controlled processes. This was rational. In a stable technological environment, moving carefully reduced integration risk, ensured regulatory compliance, and preserved operational continuity.

That posture is increasingly misaligned with the current moment. AI does not present itself as a discrete technology that organizations can choose to evaluate and adopt on their own timeline. It is infiltrating through every layer of operations: the productivity tools individual contributors are already using, the platforms vendors are embedding AI capabilities into, the competitors who are quietly compressing delivery timelines and cost structures, the talent market where expectations about AI-augmented work are shifting rapidly.

In financial institutions, the question is no longer whether AI will affect credit risk modeling, fraud detection, regulatory reporting, or client-facing services. It already does, whether through internal adoption or through the competitive and regulatory environment that surrounds the institution. The relevant question has shifted from should we adopt AI? to at what rate are our current processes becoming a competitive and operational disadvantage, and are we measuring that rate?

The Asymmetry of Risk That Does Not Appear in Governance Reports

This is the most structurally important challenge for regulated organizations, and it is one that their governance frameworks are poorly designed to surface.

The risk of moving too fast with AI is visible and auditable. It manifests as compliance failures, model risk incidents, data governance violations, operational disruptions. It appears in risk committee reports, regulatory examinations, and audit findings. Regulated organizations have spent decades building sophisticated machinery to detect, quantify, and contain exactly this type of risk, and they are genuinely good at it.

The risk of not moving fast enough is structurally different. It is diffuse, cumulative, and largely invisible to conventional risk measurement frameworks. It does not generate an incident or trigger a regulatory finding. It accumulates silently as a widening gap between the organization’s operational capabilities and those of its environment: competitors, technology providers, talent expectations, and eventually regulators themselves.

By the time this second type of risk becomes visible, it typically manifests not as a discrete event but as a condition: an inability to attract engineering talent with relevant AI skills, a growing gap in delivery speed relative to competitors, a technological debt so deep that transformation becomes structurally prohibitive.

Consider a concrete illustration. A major bank’s regulatory reporting process relies on manual data consolidation across legacy systems. The cycle takes three to four weeks per quarter, absorbs dozens of analyst hours, and produces results that are already partially stale by the time they reach the board. An AI-augmented equivalent could compress that cycle to days, reduce error rates, and free the analysts for higher-judgment work. The risk of implementing such a system is visible and manageable (model validation, auditability, change management). The risk of not implementing it accumulates invisibly: mounting operational cost, growing talent frustration, and an expanding gap relative to institutions that have already made the transition. The first risk has a line in the risk register; the second does not.

The asymmetry is this: the governance machinery of regulated organizations is optimized for the first type of risk and structurally blind to the second.

Regulation as Constraint, and as Underestimated Lever

In conversations about AI adoption in regulated industries, regulatory constraints are frequently invoked as the primary justification for caution. This framing is not wrong; regulatory constraints are real and consequential.

But it is increasingly incomplete, and in some cases it has become a rhetorical convenience that obscures something less comfortable: the pace of adoption is often constrained less by regulation than by organizational inertia dressed in regulatory language.

Regulators themselves are not standing still. Financial supervisory authorities, including the AMF, OSFI, the European Banking Authority, and others, are actively developing AI governance frameworks, publishing guidance on responsible AI use, and in some cases explicitly encouraging institutions to build AI capabilities in areas such as real-time compliance monitoring, fraud detection, and operational risk management. The implicit message from regulators is not “wait until we have figured this out” but “develop the governance maturity to use these tools responsibly.”

An organization that waits for the regulatory framework to be fully stabilized before investing in AI capabilities is making a specific bet: that the cost of early compliance investment outweighs the cost of late adoption. In a faster-moving environment, that bet is becoming harder to justify.

Regulation, properly understood, is a constraint on the speed and form of AI adoption, not a justification for its absence.

Navigating the Transition: Changing Without Breaking

The response to this challenge is not a wholesale transformation that attempts to change everything at once. Holub’s insight about systems of work applies with particular force here: an organization that tries to revolutionize its entire operating model in response to an external pressure is as likely to collapse its coherence as to improve its capabilities.

This requires organizations to develop a capability that is itself relatively new: the ability to map their own processes according to their strategic value in an AI-augmented environment. Not all rigidity is equivalent. Some processes derive their value precisely from their stability and resistance to change: regulatory compliance mechanisms, audit trails, risk controls, fiduciary obligations. These are not candidates for AI-driven transformation. They are anchors that must be protected even as the surrounding system evolves.

Other processes derive value from their efficiency and adaptability: knowledge management, delivery pipelines, onboarding, tooling, internal reporting, operational monitoring. These are precisely the areas where AI augmentation offers the highest return, and where the cost of inaction is accumulating most rapidly. Treating them with the same conservatism as core compliance processes is a category error, not prudent risk management.

The practical implication is a dual governance posture: rigorous protection of the processes whose value is their stability, combined with active transformation of the processes whose value is their performance. The organizations that handle this transition most effectively will be those that can hold both imperatives simultaneously, and resist the temptation to use the first as cover for avoiding the second.

This is not a call to abandon prudence, but to redefine where prudence actually applies.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era

A Theory of Creativity First

Before building any system, I needed to understand what creativity actually is.

Here is the formulation I arrived at around 2005, working as a researcher in Québec City:

Humans cannot create something entirely new from nothing.

We can only perceive reality through our senses. You cannot imagine a color that does not exist. You cannot conceive a sound you have never heard. The entire domain available to human creativity is bounded by accumulated sensory experience.

Creative thinking is therefore combinatorial rather than generative ex nihilo. The only way to produce something genuinely new within a bounded experiential space is to discover a structural correspondence between two distant domains that are already known.

When that correspondence holds, it is a metaphor.

But novelty alone is insufficient. A creative idea must also be useful, and usefulness is not intrinsic to the idea itself. It is evaluated by a human observer with a specific problem and a specific set of objectives. The same association can be brilliant in one context and irrelevant in another.

This leads to a precise formulation:

A creative idea is an association between two distant known domains whose relevance is judged by a human evaluator as both novel and useful within a specific context.

Novelty is a function of semantic distance between domains.

Utility is a function of the match with the problem and with the evaluator’s own criteria.

From this theory, an architecture follows naturally.

The Architecture (2005–2010)

If creativity is the identification of structural correspondences across distant domains, then a system designed to assist creativity should not search for what is similar. It should search for what is structurally equivalent across distance.

Between 2005 and 2010, working at a private imaging company in Québec City, I designed and implemented such an architecture.

Each object in the system (initially images, but the framework was modality-independent) was described through three structured vectors:

• A composition vector capturing spatial organization, perspective, and luminosity
• An object-property vector encoding detected geometries, shapes, and physical attributes
• A semantic vector containing qualitative keyword descriptors

These vectors were computed automatically using classical computer vision techniques: color histograms, wavelet decompositions, geometric segmentation, texture analysis, spatial frequency distributions. Each image received a multidimensional signature, which we called a “genetic code,” stored in a database and queryable in real time across a collection of 100,000 images.

In today’s terminology: a hand-crafted feature-embedding pipeline feeding a structured vector database, with sub-second query response time. Built in 2008, before those words existed in this context.

But the architectural intent was quite different from similarity search.

The system did not ask: What is nearest?

It asked:

• Which objects share equivalent structural overlaps with a reference? (alternative objects: substitutable, not combinable)
• Which objects contribute complementary, non-overlapping components of a reference? (complementary objects: combinable to form a stronger metaphor)
• Which combinations increase analogical coherence rather than surface resemblance? (linked objects: internal reinforcement as a tiebreaker)

The metaphorical strength of a combination was computed as the aggregate overlap across structured dimensions. Combinations were ranked by analogical coverage, not by proximity.

A red apple and a white tablecloth, taken separately, are only partial metaphors for the Japanese flag. Combined, they cover it completely: one contributes the red circle, the other the white rectangle. Their combination scores higher not because they resemble the flag, but because together they account for its structure. That is analogy, not similarity.

Similar questions were being explored across content-based retrieval and computational creativity research during that period. The problem was recognized; what was missing were the representational tools to address it at scale.

Why This Distinction Still Matters

Modern embedding systems, including the best multimodal foundation models, are extraordinarily capable. They organize high-dimensional spaces where related concepts cluster together. Distance minimization in embedding space has proven to be a remarkably powerful paradigm.

But the analogical operation itself remains largely latent in these systems.

Current architectures optimize for distance, retrieve nearest neighbors, and interpolate within learned manifolds. They do not explicitly evaluate which pairs or sets of representations together form a structurally stronger mapping to a reference than any single element alone.

Foundation models can produce metaphor-like outputs through statistical association, sometimes impressively so. But the mechanism is emergent rather than structured, which means it cannot be controlled, composed, or inspected.

Making analogy a first-class, explicit, steerable operation in AI systems remains an open architectural problem.

What AI Still Needs

Revisiting this research today, three limitations of current AI systems stand out, each rooted in the same theory of creativity I was working from in 2005.

1. Implicit context inference

Human creativity does not operate in a vacuum. The relevance of any idea depends heavily on the context in which the human is operating: their constraints, objectives, mental state, environment. A skilled collaborator reads this context without being explicitly told.

Current AI systems depend almost entirely on what the user explicitly provides. They do not perceive the context in which the human evolves. For AI to become a genuine creative partner, it needs access to richer contextual signals, along with the capacity to infer meaning from them without requiring the human to articulate everything. That is a problem of situated cognition rather than retrieval.

2. Memory as a knowledge reservoir

In my theory of creativity, the quality of associative reasoning is directly proportional to the richness of available memory. More diverse experience means more potential connections across distant domains.

Current AI systems have impressive parametric knowledge, but their memory architecture is largely static between training runs. The strategic management of episodic, contextual, and long-term memory, treated as a dynamic, queryable reservoir that evolves with use, remains underdeveloped. Memory, in this view, is the substrate of association and not just storage.

3. Emotional memory

This is perhaps the most significant gap, and the one most likely to trigger an objection from researchers in reinforcement learning or affective computing.

The objection is predictable: AI systems do incorporate affective signals, through reward modeling, reinforcement learning from human feedback, and preference learning. This is true, and the work is serious.

But it addresses a different problem. These approaches treat affect as an external training signal: feedback injected during learning to shape behavior. Human emotional memory is structurally different. Rather than a signal applied to knowledge from the outside, it is woven into knowledge itself.

The neuroscientist Antonio Damasio demonstrated this precisely. Emotion is not separate from rational cognition; it is constitutive of it. Patients with damage to emotional memory centers do not become more rational. They lose the capacity to make decisions at all, because they can no longer assign differential weight to recalled experiences.

Every human memory carries affective encoding (fear, joy, discomfort, wonder) that influences which associations surface, which combinations feel meaningful, and which ideas resonate. This weighting is embedded in the retrieval structure itself rather than applied post-hoc.

Current AI systems process semantic relationships without this integrated affective architecture. The gap may therefore be architectural rather than merely incremental.

Building systems where affective structure is embedded in memory, instead of applied to it from outside, may be one of the most important open problems in AI research on creativity and reasoning.

Why I Am Writing This Now

The research described here was conducted between 2005 and 2010 and was not publicly discussed at the time due to contractual obligations.

Revisiting it now is less an exercise in retrospection than a recognition that the underlying questions remain open, and that the technological conditions to investigate them meaningfully finally exist.

I am not writing to claim priority. Parallel discovery is the norm in research, and I have no interest in relitigating timing. I am writing because the problem is still in front of us.

If you are working on reasoning architectures, compositional intelligence, contextual AI systems, or human–AI collaboration, I would like to talk.

The research described above is documented in an unpublished patent specification and a research poster produced in 2008.

Gabriel Mailhot
Software Architect and Software Engineering Quality Advisor
Series: Organizational Engineering for the AI Era