Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical, cognitive, and intent debt

martinfowler.com

Post reply on HN
Print view View original

71–80 of 103 posts

Re: Technical, cognitive, and intent debt

#71

Post by lmm »

didericis wrote: post #3
kvisner wrote: post #2

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…

> 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.

> If you are thinking through deterministic code, you are thinking through the manipulation of bits in hardware.

No I'm not. If I want the machine to evaluate 2+2, I don't know or care what bits in hardware it uses to do that (as long as it doesn't run out of memory), I just want the result to come back as 4.

Re: Technical, cognitive, and intent debt

#72

Post by coalstartprob »

dc_giant wrote: post #14
hibikir wrote: post #6

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 s…

Mind sharing the instructions you give Claude to go for minimal code changes etc?

[dead]

Re: Technical, cognitive, and intent debt

#73

Post by destring »

kvisner wrote: post #2

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…

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.

Re: Technical, cognitive, and intent debt

#74

Post by globular-toast »

xdennis wrote: post #34
backprop1989 wrote: post #26

> 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 fi…

I've seen them adding "ignore" for linter errors I don't even catch in my CI. For example, adding Pylint stuff when I don't even use Pylint. This isn't laziness. It's just parrot-fashion regurgitation of code, which is by design for LLMs.

Re: Technical, cognitive, and intent debt

#75

Post by friendzis »

kvisner wrote: post #15
layer8 wrote: post #5

Earlier quoted context omitted.

Translating your intent into a formal language is a tool of thought in itself. It’s by that process that you uncover the ambiguities, the aspects and details you didn’t consider, maybe even that the approach as a whole has to be reconsidered. While writing in natural language can also be a tool of thought, there is an essential element in aligning one’s thought process with a formal language that doesn’t allow for an…

I agree, but that formal language doesn't need to be executable code.

A formal language is executable. It might need some translation pass to be eventually executable on a particular system, but it is executable nevertheless.

"A sufficiently detailed specification is code"

Re: Technical, cognitive, and intent debt

#76

Post by croon »

kranner wrote: post #62
__mharrison__ wrote: post #46

Earlier quoted context omitted.

My anecdotes for using LLMs to modernize legacy (20-year-old systems): - 40x speed improvement - Painless env setup - 20 Second deploy - 90+% test coverage - Ability to quickly refactor - Documentation (The original system that I wrote with one other programmer 20 years ago took 1.5+ years to write. Modern rewrite: 2 days)

Presumably the 1.5 years for the first version involved work other than coding that the LLM rewrite didn’t entail?

I can only assume there's a ton of domain knowledge accrued over those years and beyond baked into the legacy code, that an LLM can just scoop up in a minute.

Re: Technical, cognitive, and intent debt

#77

Post by didericis »

lmm wrote: post #71
didericis wrote: post #3

Earlier quoted context omitted.

> 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.

> If you are thinking through deterministic code, you are thinking through the manipulation of bits in hardware. No I'm not. If I want the machine to evaluate 2+2, I don't know or care what bits in hardware it uses to do that (as long as it doesn't run out of memory), I just want the result to come back as 4.

When you press the 2 button, the plus button, the 2 button and the equals button, you are translating your question into bits and operations which are logically guaranteed to yield bits that represent your answer.

When you think through what will happen as a result of deterministic code, you are also thinking through what the bits will do, albeit at a higher level of abstraction.

When you ask an LLM to do something, you have no guarantee that the intent you provide is accurately translated, and you have no guarantee you’ll get the result you want. If you want your answer to 2+2 to always be 4, you shouldn’t use a non deterministic LLM. To get that guarantee, the bit manipulation a machine does needs to be logically equivalent to the way you evaluate the question.

That doesn’t mean you can’t minimize intent distortion or cognitive debt while using LLMs, or that you can’t think through the logic of whatever problem you’re dealing with in the same structured way a formal language forces you to while using them. But one of my pet peeves is comparing LLMs to compilers. The nondeterminism of LLMs and lack of logical rigidity makes them fundamentally different.

Re: Technical, cognitive, and intent debt

#78

Post by croemer »

meander_water wrote: post #44

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.

It uses "not merely" 7 times! I wonder if an LLM would repeat a phrase that often. It could be the author starting to write like LLMs, instead.

Re: Technical, cognitive, and intent debt

#79

Post by ehnto »

kranner wrote: post #62
__mharrison__ wrote: post #46

Earlier quoted context omitted.

My anecdotes for using LLMs to modernize legacy (20-year-old systems): - 40x speed improvement - Painless env setup - 20 Second deploy - 90+% test coverage - Ability to quickly refactor - Documentation (The original system that I wrote with one other programmer 20 years ago took 1.5+ years to write. Modern rewrite: 2 days)

Presumably the 1.5 years for the first version involved work other than coding that the LLM rewrite didn’t entail?

Business logic is usually the most substantial part of legacy systems in my experience, so I imagine so.

Not to be too negative but a lot of modern software complexity is a prison of our own making, that we had time to build because our programs are actually pretty boring CRUD apps with little complex business logic.

Re: Technical, cognitive, and intent debt

#80

Post by russellthehippo »

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.
Post reply on HN