Posts

We may assume that a creative idea is a distant analogy, connecting two things no one had connected before. That assumption is wrong. The distance between domains explains almost nothing about whether an idea will be novel, useful, or transformative. What actually matters is far less intuitive, and it changes how we should think about LLMs as instruments for creativity. The Broken Promise of the Creative Prompt Ask any major LLM for novel solutions to a real problem and you usually get back a polished recombination of known best practices. ...

Part I ended with a puzzle. I had a method that reliably extracted powerful ideas from distant domains, but some of those ideas were immediately actionable and others resisted application. The difference turned out to be granularity and compression: single causal rules, stripped bare, are portable. Systems of relationships are not. But even after solving that puzzle, something was still missing. 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. ...

In Part I, I showed that creative transfer depends on two variables: semantic distance ensures novelty, but granularity predicts applicability, and granularity is controlled through compression to a discrete level. In Part II, I introduced two missing operations, inversion and composition, and formalized them as the Extraction-Inversion-Composition framework (EIC). The model is complete. But does it work in practice? 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: ...

The Anatomy of a Eureka, Part IV: When Solutions Become Probes 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 problem is knowing what already exists 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. ...

We assume sycophancy in AI is a politeness problem, solvable with a sharper prompt that demands directness and tells the model to disregard our feelings. It isn’t. The sharper prompt produces a different version of the same failure. 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. ...

On why large organizations structurally produce technical debt, select for political behavior, and reliably defeat every attempt at reform, including Agile. 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 Tipping Point 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. ...

What AI Cannot Replace in Software Development, Part 2 What the developer must retain, what can legitimately be delegated, and why confusing the two leads to the erosion of knowledge. 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. ...

What AI Cannot Replace in Software Development, Part 1 A perspective on the structural limits of automated test generation, and what they reveal about the nature of work in software engineering. 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. ...