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

The peril of laziness lost

bcantrill.dtrace.org

Post reply on HN
Print view View original

111–120 of 148 posts

Re: The peril of laziness lost

#111

Post by greazy »

njarboe wrote: post #21

German General Kurt von Hammerstein-Equord (a high-ranking army officer in the Reichswehr/Wehrmacht era): “I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent — their place is the General Staff. The next lot are stupid and lazy — they make up 90% of every army and are suited to routine duties. Anyone who i…

I much prefer the Napolean attributed joke version where diligent is replaced with energetic. It ends with Napolean being asked "but general what about the fourth group, stupid and energetic?"

"I have them shot".

Re: The peril of laziness lost

#112

Post by bdangubic »

marcus_holmes wrote: post #108
reenorap wrote: post #87

As someone who has switched to exclusively coded using AI after 30 years of coding by myself, I find it really weird when people take credit for the lines of code ad features that AI generates. Flexing that one "coded" tens of hundreds of thousands of lines per day is a bit cringe, seeing as though it's really just the prompt that one typed.

Yes! I don't mind it so much when it's a newbie or non-techie who has never actually written code before, because bless their hearts, they did it! They got some code working! But if you've been developing for decades, you know that counting lines of code means nothing, less than nothing. That you could probably achieve the same result in half the lines if you thought about it a bit longer. And to claim this as an ach…

here’s one thing that somewhat worked for my team. when we first started using LLMs we decided to run the same process as if they did not exist, same sprint planning meetings, same estimation. we did this for 6 months and saw roughly 55% increase in output compared to pre-LLM usage. there are biases in what were tried to achieve, it is not easy to estimate something will take XX hours when you know some portion (for example writing documentation or portions of the test coverage) you won’t have to write but we did our best. after we convinced ourselves of productivity gains we stopped doing this.

Re: The peril of laziness lost

#113

Post by eucyclos »

njarboe wrote: post #21

German General Kurt von Hammerstein-Equord (a high-ranking army officer in the Reichswehr/Wehrmacht era): “I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent — their place is the General Staff. The next lot are stupid and lazy — they make up 90% of every army and are suited to routine duties. Anyone who i…

I think this heuristic used to be more useful before it became widely known. Laziness is a fine quality if diligence is publicly rewarded, but once people game the metrics to look more lazy than they really are, things break

Re: The peril of laziness lost

#114

Post by arthurjj »

ocrow wrote: post #107
arthurjj wrote: post #9

LLMs not being lazy enough definitely feels true. But it's unclear to me if it a permanent issue, one that will be fixed in the next model upgrade or just one your agent framework/CICD framework takes care of. e.g. Right now when using agents after I'm "done" with the feature and I commit I usually prompt "Check for any bugs or refactorings we should do" I could see a CICD step that says "Look at the last N commits a…

I've tried this approach of instructing the LLM to look for opportunities to abstract, but it's not good at finding the commonalities after the fact, when possibly related functions have already diverted unnecessarily. It writes "sloppy" code, that is to say code that is locally correct but which fails to build towards overall generalizations, but that sloppy code is a cul-de-sac: easy to write, but adding to messine…

> When a good programmer writes a new feature, they are looking for both existing and new abstractions that can be applied. They are considering their mental model of the whole system and examining whether it can be leveraged or needs to be updated. That's how they avoid compounding complications.

This is actually a pretty good argument that it's a permanent issue. I haven't tried with writing, or having an LLM write, a summary of the coding style of any of my code bases but my hunch is it wouldn't do a good job either writing it or taking it into account when coding a new feature

Re: The peril of laziness lost

#115

Post by suzzer99 »

marcus_holmes wrote: post #106
suzzer99 wrote: post #3

> Generally, though, most of us need to think about using more abstraction rather than less. Maybe this was true when Programming Perl was written, but I see the opposite much more often now. I'm a big fan of WET - Write Everything Twice (stolen from comments here), then the third time think about maybe creating a new abstraction.

"Duplication is far cheaper than the wrong abstraction" Sandi Metz https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

And adding an abstraction later is much easier than removing an unneeded one, which can be very hard or even impossible depending on the complexity of the app.

Re: The peril of laziness lost

#116

Post by eucyclos »

The reference to 'literature by the pound ' made me think of an apocryphal story about a pottery teacher who at the end of the year would grade his students on either the quality of a single piece or the weight of all finished pieces. With very few exceptions, the best piece of the year would be one of the ones where a student went for volume.

Which is plausible if you need to touch each piece- more repetitions lead to more improvement if you're already motivated to improve anyway - but if the output is coming from an llm, I'm not sure ..

Re: The peril of laziness lost

#117

Post by marcus_holmes »

bdangubic wrote: post #112
marcus_holmes wrote: post #108

Earlier quoted context omitted.

Yes! I don't mind it so much when it's a newbie or non-techie who has never actually written code before, because bless their hearts, they did it! They got some code working! But if you've been developing for decades, you know that counting lines of code means nothing, less than nothing. That you could probably achieve the same result in half the lines if you thought about it a bit longer. And to claim this as an ach…

here’s one thing that somewhat worked for my team. when we first started using LLMs we decided to run the same process as if they did not exist, same sprint planning meetings, same estimation. we did this for 6 months and saw roughly 55% increase in output compared to pre-LLM usage. there are biases in what were tried to achieve, it is not easy to estimate something will take XX hours when you know some portion (for…

wow, great experiment. I'm amazed the whole team went through with duplicating everything for that long. Nice work :)

I resorted to feels. After decades of programming, I know when I'm being productive, and I can reasonably estimate when a colleague is being productive. I extrapolate that to the LLM, too. Absolutely not an objective measure, but I feel that I can get the LLM to do in a day a task that would take me 2-3 weeks (post-Nov 25 and using parallel agents).

Re: The peril of laziness lost

#118

Post by crabmusket »

ocrow wrote: post #107
arthurjj wrote: post #9

LLMs not being lazy enough definitely feels true. But it's unclear to me if it a permanent issue, one that will be fixed in the next model upgrade or just one your agent framework/CICD framework takes care of. e.g. Right now when using agents after I'm "done" with the feature and I commit I usually prompt "Check for any bugs or refactorings we should do" I could see a CICD step that says "Look at the last N commits a…

I've tried this approach of instructing the LLM to look for opportunities to abstract, but it's not good at finding the commonalities after the fact, when possibly related functions have already diverted unnecessarily. It writes "sloppy" code, that is to say code that is locally correct but which fails to build towards overall generalizations, but that sloppy code is a cul-de-sac: easy to write, but adding to messine…

"Programming as theory building" undefeated still.

Re: The peril of laziness lost

#120

Post by Centigonal »

stratts wrote: post #97
reenorap wrote: post #87

As someone who has switched to exclusively coded using AI after 30 years of coding by myself, I find it really weird when people take credit for the lines of code ad features that AI generates. Flexing that one "coded" tens of hundreds of thousands of lines per day is a bit cringe, seeing as though it's really just the prompt that one typed.

It's a spectrum, isn't it? From targeted edits that you approve manually - which I think you can reasonably take credit for - all the way to full blown vibe-coded apps where you're hardly involved in the design process at all. And then there's this awkward bit in the middle where you're not necessarily reviewing all the code the AI generates, but you're the one driving the architecture, coming up with feature ideas,…

I think LOC and "writing code" are largely irrelevant as metrics of productivity in a world with LLMs that love to churn out overly loquacious code.

I think the right way to explain the work done sounds something like, "I worked with Claude to create an app that does ______. I know it works because ______."

Post reply on HN