Earlier quoted context omitted.
You should go get attention at conferences. You could write a book called Practical LLM Coding
Do you think O'Reilly would still put an animal on the cover?
A mockingbird?
Technical, cognitive, and intent debt
61–70 of 103 posts
Re: Technical, cognitive, and intent debt
#62Earlier 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…
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?
Re: Technical, cognitive, and intent debt
#63Earlier 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?
Not the poster you replied to but I’m sure it did. But still manual rewrite under the same constraints would be much less feasible.
Re: Technical, cognitive, and intent debt
#64I 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
The interpreter is deterministic but LLMs aren't.
Re: Technical, cognitive, and intent debt
#65Earlier 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?
Yep, coders do more than just code.
Re: Technical, cognitive, and intent debt
#66Earlier quoted context omitted.
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 exampl…
in Tidy Code, Kent Beck explains that the main tradeoff os what we can get now vs what will be able to do later. A hacky decision can keep the company afloat, but can reduce the velocity to a snail pace in the future.
It’s easier to keep the balance by keeping everything simple and maintaining a good hygiene in your codebase.
Re: Technical, cognitive, and intent debt
#67This 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 human…
cool dataviz but it's editable! trying to pan and zoom and scoll on my phone led to moving elements around on the canvas
Activate the “Hand” tool to avoid that.
Re: Technical, cognitive, and intent debt
#68Where's the other half of the article? What an abrupt ending...
This isn't one article, it's a "fragments" post with five separate small thoughts. They happen to all be about LLMs so I can see why it would read as a single article, but it's not.
There is a paper linked which is describing the whole thing!
Re: Technical, cognitive, and intent debt
#69Earlier quoted context omitted.
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 exampl…
I don't deny that TDD is generally useful. I like it as well.
What I meant is that, like any powerful tool, there are situations where it shouldn't be used.
Thanks for the thoughtful comment.
Re: Technical, cognitive, and intent debt
#70Intent debt is a useful framing. A few comments explaining "why" instead of "what" would have saved hours of guessing.