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

21–30 of 103 posts

Re: Technical, cognitive, and intent debt

#21

Post by michaelrpeskin »

ryanisnan wrote: post #18

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, 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 repeated assembly code that is duplicated. You don't care that it's duplicated because the compiler is doing it for you.

I've had some projects recently where I was using an LLM where I needed a few snippets of non-trivial computational geometry. In the old days, I'd have to go search for a library and get permission from compliance to import the library and then I'd have to convert my domain representations of stuff into the formats that library needed. All of that would have been cheaper than me writing the code myself, but it was non-trivial.

Now the LLM can write for me only the stuff I need (no extra big library to import) and it will use the data in the format I stored it in (no needing to translate data structures). The canon says the "right" way to do it would be to have a geometry library to prevent repeated code, but here I have a self contained function that "just works".

Re: Technical, cognitive, and intent debt

#22

Post by zingar »

michaelrpeskin wrote: post #21
ryanisnan wrote: post #18

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

We have confidence in the extra code a compiler generates because it’s deterministic. We don’t have that in LLMs, neither those that wrote nor read the code.

Re: Technical, cognitive, and intent debt

#24

Post by mettamage »

awesome_dude wrote: post #20
dc_giant wrote: post #14

Earlier quoted context omitted.

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

I often say to Claude "you're doing X when I want Y, how can I get you to follow the Y path without fail" and Claude will respond with "Edit my claude.md to include the following" which I then ask Claude to do.

Ah yea I do that too. I often have reflection sessions with Claude where I ask it "how can I make sure you do behavior X so we get outcome Y?"

It works relatively well but not always.

Re: Technical, cognitive, and intent debt

#25

Post by awesome_dude »

mettamage wrote: post #24
awesome_dude wrote: post #20

Earlier quoted context omitted.

I often say to Claude "you're doing X when I want Y, how can I get you to follow the Y path without fail" and Claude will respond with "Edit my claude.md to include the following" which I then ask Claude to do.

Ah yea I do that too. I often have reflection sessions with Claude where I ask it "how can I make sure you do behavior X so we get outcome Y?" It works relatively well but not always.

[dead]

Re: Technical, cognitive, and intent debt

#27

Post by archagon »

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…

AI is not an abstraction layer.

Re: Technical, cognitive, and intent debt

#28

Post by bluGill »

jdw64 wrote: post #11
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…

I like the word intent, but Martin Fowler’s essay made me think more carefully about it. When Thomas Kuhn talked about paradigm shifts, “paradigm” ended up carrying more than twenty different meanings. In the same way, I think intent has recently become one of the most polluted and overused words in programming. My own toy language project uses the word intent, so I am not really in a position to criticize others too…

architecture is about the choices you will regret in this future if you get wrong today. You will regret not having testable code so tdd isn't bad - but that is not the whole storyand there are many things you will regret that tdd won't help with.

there is the famious bowling game tdd example where their result doesn't have a frame object and they argue they proved you don't need one. That is wrong though, the example took just a couple hours - there is nothing so bad in a a two hour program you will regret. If you were doing a real bowling system with pin setters, support for 50 lanes and a bunch of other things that I who don't work in that area don't even know about - you will find places to regret things.

Re: Technical, cognitive, and intent debt

#29

Post by jazzypants »

michaelrpeskin wrote: post #21
ryanisnan wrote: post #18

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

This kind of thinking only works as long as the machine can actually fix its own errors.

I've had several bugs that required manual intervention (yes, even with $YOUR_FAVORITE_MODEL -- I've tried them all at this point). After the first few sessions of deleting countless lines of pointless cruft, I quickly learned the benefits of preemptively trimming down the code by hand.

Re: Technical, cognitive, and intent debt

#30

Post by stickfigure »

awesome_dude wrote: post #19
marktani wrote: post #16

Earlier quoted context omitted.

I agree with your sentiment here. However: > 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. In this side sentence you're introducing so much vagueness. Can you share insights to get some validation on your claim? What metrics are you using and how is your code from 10, 5, 0 years perform…

The anecdote the GP is providing there rings true for me too - although I'm not sure if I am going offer better detail. I'm a proponent of architectural styles like MVC, SOLID, hexagonal architecture, etc, and in pre-LLM workflows, "human laziness" often led to technical debt: a developer might lazily leak domain logic into a controller or skip writing an interface just to save time. The code I get the LLM to emit is…

I don't think I'd like your code. But apparently there's enough implied YAGNI in my CLAUDE.md to prevent the unnecessary interfaces and layers of separation that you apparently like. So I guess there is a flavor for everyone.
Post reply on HN