Wrong link. Technical, Cognitive and Intent Debt was discussed here: https://martinfowler.com/fragments/2026-04-02.html
Thanks! we updated the link.
Technical, cognitive, and intent debt
31–40 of 103 posts
Re: Technical, cognitive, and intent debt
#32LLMs don't lack the virtue of laziness: it has it if you want it to, by just having a base prompt that matches intent. I've had good success convincing claude backed agents to aim for minimal code changes, make deduplication passes, and basically every other reasonable "instinct" of a very senior dev. It's not knowledge that the models haven't integrated, but one that many don't have on their forefront with default s…
Mind sharing the instructions you give Claude to go for minimal code changes etc?
I regularly prompt and re-prompt the clanker with esoteric terms like "subtractive changes", "create by removing" and more common phrases like "make the change easy, then make the easy change", "yagni", and "vertical slices", and "WET code is desirable".
It mostly works. CC's plan mode creates a plan by cleaning up first, then defining narrow, integrated steps. Mentioning "subtractive" and "yagni" appears to be a reliable enough way for an LLM to choose a minimal path.
To my mind these instructions remain incantations and I feel like an alchemist of old.
Re: Technical, cognitive, and intent debt
#33I see what Martin is saying here, but you could make that argument for moving up the abstraction layers at any point. Assembly to Python creates a lot of Intent & Cognitive debt by his definition, because you didn't think through how to manipulate the bits on the hardware, you just allowed the interpereter to do it. My counter is that technical intent, in the way he is describing it, only exists because we needed to…
> you didn't think through how to manipulate the bits on the hardware, you just allowed the interpreter to do it If you are thinking through deterministic code, you are thinking through the manipulation of bits in hardware. You are just doing it in a language which is easier for humans to understand. There is a direct mapping of intent.
Most programmers who write reasonably deterministic code don't even know how many bits it allocates.
Re: Technical, cognitive, and intent debt
#34> The problem is that LLMs inherently lack the virtue of laziness. I assure you, they do not.
I completely agree. This is one of the most annoying things about LLMs. I always see them fixing linter errors by adding ignore comments, typing many things as "Any", duplicating test fixtures instead of extracting them, sometimes deleting tests they don't like, etc.
My most recent Claude Code fix consisted of one line: calling `third_party_lib._connect()`. It reaches into the internals of an external library. The fix worked, but it is improper to depend on the specific implementation. The correct fix was about 20 lines.
(Tangentially, this is why I think LLMs are more useful for senior developers because junior developers tend to not have a sense for what's good quality and accept whatever works.)
Re: Technical, cognitive, and intent debt
#35I think Martin isn't wrong here, but I've first hand seen AI produce "lazy" code, where the answer was actually more code. A concrete example, I had a set of python models that defined a database schema for a given set of logical concepts. I added a new logical concept to the system, very analogous to the existing logical set. Claude decided that it should just re-use the existing model set, which worked in theory, b…
Is more code really bad? For humans, yes we want thing abstracted, but sometimes it may make more sense to actually repeat yourself. If a machine is writing and maintaining the code, do we need that extra layer now? In the olden days we used Duff's devices and manually unrolled loops with duplicated code that we wrote ourselves. Now, the compiler is "smart" enough to understand your intent and actually generates repe…
But someone needs to review and maintain the computational geometry code; or edit it to use a novel algorithm/optimize it.
And even if they didn't every line of extra code without sufficient abstraction adds cognitive overload.
Re: Technical, cognitive, and intent debt
#36Earlier quoted context omitted.
Mind sharing the instructions you give Claude to go for minimal code changes etc?
I regularly prompt and re-prompt the clanker with esoteric terms like "subtractive changes", "create by removing" and more common phrases like "make the change easy, then make the easy change", "yagni", and "vertical slices", and "WET code is desirable". It mostly works. CC's plan mode creates a plan by cleaning up first, then defining narrow, integrated steps. Mentioning "subtractive" and "yagni" appears to be a rel…
Was just listening to the Lenny’s Podcast interview with Simon Willison, who mentioned another such incantation: red/green TDD. The model knows what this means and it just does it, with a nice bump in code quality apparently.
I’m trying out another, what I call the principle of path independence. It’s the idea that the code should reflect only the current requirements, and not the order in which functionality was added — in other words, if you should decide to rebuild the system again from scratch tomorrow, the code should look broadly similar to its current state. It sort of works even though this isn’t a real thing that’s in its training data.
Re: Technical, cognitive, and intent debt
#37[dead]
Re: Technical, cognitive, and intent debt
#38the framing as "debt" is fair but in our case the bigger pain isn't lazy code, it's overzealous code. claude will happily refactor three unrelated files because it spotted a "pattern". we've ended up with a CLAUDE.md that's basically a list of "do not touch unless asked". probably says more about us than the model but yeah.
Re: Technical, cognitive, and intent debt
#39This is my current visualization of the problem: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU...
I think the "cognitive bottlenecks" in software engineering live between artifacts, where code is simply one of them.
outcome → requirements → spec → acceptance criteria → executable proof → review
I'm making experimental tooling that automates the boring parts around those transitions, while keeping humans focused on validating that intent survived each step.
Re: Technical, cognitive, and intent debt
#40[dead]