I 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 translate human intent into machine language. You can still think deeply about problems without needed to formulate them as domain driven abstractions in code. You could mind map it, or journal about it, or put post-it notes all over the wall. Creating object oriented abstractions isn't magic.
The thing is that you paid that debt once. The mappings are well defined and deterministic.
The whole purpose of an abstractions is to not have to look underneath it to make sure what you did with the abstraction is still correct. You can make sure because you, or someone you trust, did the work of paying that debt once.
With LLMs you always need to verify the output, for every generation you need to pay that debt. So it is not an abstraction.
How does it --if it does-- relate to your idea of "affordability porn" :)
That line (between your other values?) was uproarious; I apologise for not u*voting it, partially because I couldn't vocalise my peculiar fetish att (+ "gnarliness-pornstar" doesn't sound nearly as enticing as "AI-affordability-pornstar" X)
LLMs 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 settings. I bet we've all seen the models that over-edit everything, and act like the crazy mid-level dev that fiddles with the entire codebase without caring one bit about anyone else's changes, or any risk of knowledge loss due to overfiddling.
And on Jess' comments on validating docs vs generating them... It's a traditional locking problem, with traditional solutions. And it's not as if the agent cannot read git, and realize when one thing is done first, in anticipation of the other by convention.
I'm quite senior: In fact, I have been a teammate of a couple of people mention in this article. I suspect that they'd not question my engineering standards. And yet I've no seen any of that kind of debt in my LLM workflows: if anything, by most traditional forms of evaluating software quality, the projects I work on are better than what they were 5, 10 years ago, using the same metrics as back then. And it's not magic or anything, but making sure there are agents running sharing those quality priorities. But I am getting work done, instead of spending time looking for attention in conferences.
> ...to develop the powerful abstractions that then allow us to do much more, much more easily. Of course, the implicit wink here is that it takes a lot of work to be lazy
This lines up with YAGNI, but most people believe the opposite, often using YAGNI to justify NOT building the necessary abstractions.
I 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, but caused the consumers to have to do all sorts of gymnastics to do type inference at runtime. It "worked", but it was definitely the wrong layer of abstraction.
the 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.
I'm making experimental tooling that automates the boring parts around those transitions, while keeping humans focused on validating that intent survived each step.
I like the "between artifacts" framing. One layer I'd add is proxies/metrics. In a lot of analytics-heavy systems, the real loss isn't spec -> code, it's question -> proxy. Once the proxy gets baked into acceptance criteria, dashboards, or evals, people optimize that and gradually forget it was only a proxy.
Unfortunately large parts of the paper that he linked to from the Wharton school is entirely AI generated, and yet to be peer reviewed.
I realize that most researchers use AI to assist with writing, but when the topic of your paper is "cognitive surrender", I struggle to take any content in there seriously.
Best thing I've read on hacker news in so long. I relate so hard. Simon Willison's stuff on cognitive debt and "your job is to ship code you have proven to work" have led me to work on a project about Intent-Driven Development, because prior intent always seemed to dim with each set of changes. Might put it together into a real protocol and post here on hacker news sometime.
It's very nerve-racking for people who like to have a deep understanding of everything they ship. A modernization project that would take you 2 months now can be done in a week or less because you don't need to go deep into the business logic to replicate it and instead you can just focus on designing the boundaries and interfaces properly. Then like the article mentions, just create a good test harness to test parity as much as you can. I was feeling very conflicted about this myself, but then I thought: I have these other systems I have to maintain on a daily basis and I also don't understand the internals and business logic that well because I wrote them years ago and haven't changed much. I just rely on the test suite if something needs to be changed or the code structure if I need to see how something in particular works.
> The most creative act is this continual weaving of names that reveal the structure of the solution that maps clearly to the problem we are trying to solve.
From Confucius, The Analects, 13.3:
If names are not rectified, then language will not be in accord with truth. If language is not in accord with truth, then things cannot be accomplished. If things cannot be accomplished, then ceremonies and music will not flourish.
Well written. I also wrote in my personal notes yesterday that if you don't organically and continuously develop code, it's hard to say you truly "own" it.
Like self-driving cars, at least you remember the scenery along the way, but now it just teleports you to another place and then shows you the recording.
This kind of review is ineffective. Such ghosted code might be acceptable for small tools, but for databases or similar systems, it's really worrying.
I've now basically stopped granting the agent any write permissions and returned to how I wrote codes 2 years ago with manual QA. The thing is, it's actually more efficient in turns of tokens and the results.
The "intent debt" framing is the most underappreciated category here. Cognitive and technical debt are at least visible in the code. Intent debt is invisible — it only surfaces when someone makes a change that's locally reasonable but globally wrong because the original constraint no longer exists in any artifact. The hardest version of this is in enterprise systems where the constraint was a regulatory requirement that quietly changed three years ago, but nobody updated the code because the tests still passed. You can't recover intent from a test suite.
28 comments
[ 29.5 ms ] story [ 354 ms ] threadMy counter is that technical intent, in the way he is describing it, only exists because we needed to translate human intent into machine language. You can still think deeply about problems without needed to formulate them as domain driven abstractions in code. You could mind map it, or journal about it, or put post-it notes all over the wall. Creating object oriented abstractions isn't magic.
The interpreter is deterministic but LLMs aren't.
The whole purpose of an abstractions is to not have to look underneath it to make sure what you did with the abstraction is still correct. You can make sure because you, or someone you trust, did the work of paying that debt once.
With LLMs you always need to verify the output, for every generation you need to pay that debt. So it is not an abstraction.
That line (between your other values?) was uproarious; I apologise for not u*voting it, partially because I couldn't vocalise my peculiar fetish att (+ "gnarliness-pornstar" doesn't sound nearly as enticing as "AI-affordability-pornstar" X)
And on Jess' comments on validating docs vs generating them... It's a traditional locking problem, with traditional solutions. And it's not as if the agent cannot read git, and realize when one thing is done first, in anticipation of the other by convention.
I'm quite senior: In fact, I have been a teammate of a couple of people mention in this article. I suspect that they'd not question my engineering standards. And yet I've no seen any of that kind of debt in my LLM workflows: if anything, by most traditional forms of evaluating software quality, the projects I work on are better than what they were 5, 10 years ago, using the same metrics as back then. And it's not magic or anything, but making sure there are agents running sharing those quality priorities. But I am getting work done, instead of spending time looking for attention in conferences.
This lines up with YAGNI, but most people believe the opposite, often using YAGNI to justify NOT building the necessary abstractions.
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, but caused the consumers to have to do all sorts of gymnastics to do type inference at runtime. It "worked", but it was definitely the wrong layer of abstraction.
I assure you, they do not.
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.
I realize that most researchers use AI to assist with writing, but when the topic of your paper is "cognitive surrender", I struggle to take any content in there seriously.
Like self-driving cars, at least you remember the scenery along the way, but now it just teleports you to another place and then shows you the recording.
This kind of review is ineffective. Such ghosted code might be acceptable for small tools, but for databases or similar systems, it's really worrying.
I've now basically stopped granting the agent any write permissions and returned to how I wrote codes 2 years ago with manual QA. The thing is, it's actually more efficient in turns of tokens and the results.
That's just my personal experience.