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

The AI coding trap

chrisloy.dev

Post reply on HN
Print view View original

161–170 of 424 posts

Re: The AI coding trap

#161

Post by johnfn »

lelanthran wrote: post #80
reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

> If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting. This argument is wearing a little thin at this point. I see it multiples times a day, rephrased a little bit. The response, "How well do you think your thinking will go if you had not spent years doing the 'practice' part?" , is always followed by either silence or a non…

Do you think that all managers and tech leads atrophy because they don’t spend all day “doing”? I think a good number of them become more effective because they delegate the simple parts of their work that don’t require deep thought, leaving them to continue to think hard about the thorniest areas of what they’re working on.

Or perhaps you’re asking how people will become good at delegation without doing? I don’t know — have you been “doing” multiple years of assembly? If not, how are you any good at Python (or whatever language you currently use?). Probably you’d say you don’t need to think about assembly because it has been abstracted away from you. I think AI operates similarly by changing the level of abstraction you can think at.

Re: The AI coding trap

#162

Post by sofal »

cgh wrote: post #113
bgwalter wrote: post #15

Earlier quoted context omitted.

"AI" does not encourage real thinking. "AI" encourages hand waving grand plans that don't work, CEO style. All pro-"AI" posts focus on procedures and methodologies, which is just LARPing thinking. Using "AI" is just like speed reading a math book without ever doing single exercise. The proponents rarely have any serious public code bases.

A surprising conclusion to me at least is that a lot of programmers simply don’t like to write code.

Well, yeah. I like getting computers to automate things and solve problems. Typing in boilerplate and syntax is just a means to that end, and not even remotely the most interesting part. I don't like managing my own memory garbage collection either, so I prefer to use tools that handle that for me.

I mean, I guess when I was really early in my career I'd get a kick out of writing a clever loop or whatever, and I drank deep from all the low level coding wisdom that was available, but the scope of what I care about these days has long since expanded outward.

Re: The AI coding trap

#163

Post by dxxvi »

There is this statement in the article: LLMs are lightning fast junior engineers. I don't know if that is right or wrong. To me, good LLMs are a lightning fast better version of me. That means that I can write code like some LLMs but it'll take me days to do it (if I use a language that I'm not good at, for example Rust) but with carefully crafted prompts, LLMs take maybe half an hour or less.

Re: The AI coding trap

#164

Post by danielbln »

Vegenoid wrote: post #148
danpat wrote: post #65

Earlier quoted context omitted.

> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project. This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing. There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it see…

> What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions? Messy codebases made by humans are known to be a bad thing that causes big problems for software that needs to be maintained and changed. Much effort goes into preventing them and cleaning them up.

If you want to work with AI code systems successfully then you better apply these exact same efforts. Documentation, composition, validation, evaluation, review and so on.

Re: The AI coding trap

#165

Post by mattlutze »

PessimalDecimal wrote: post #34
reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…

> The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding.

In any of my teams with moderate to significant code bases, we've always had to lean very hard into code comments and documentation, because a developer will forget in a few months the fine details of what they've previously built. And further, any org with turnover needs to have someone new come in and be able to understand what's there.

I don't think I've met a developer that keeps all of the architecture and design deeply in their mind at all times. We all often enough need to go walk back through and rediscover what we have.

Which is to say... if the LLM generator was instead a colleague or neighboring team, you'd still need to keep up with them. If you can adapt those habits to the generative code then it doesn't seem to be a bit leap.

Re: The AI coding trap

#166

Post by danielbln »

grim_io wrote: post #43
analog8374 wrote: post #28

Earlier quoted context omitted.

Here's one AI can only recycle the past.

Most of us do nothing but remix the past solutions. Since we don't know what else might already exist in the world without digging very deep, we fool ourselves into thinking that we do something very original and unique.

And even truly novel and unique things are more often than not composites of things that have come before prior. We all stand on the shoulders of giants/priors.

Re: The AI coding trap

#167

Post by halfadot »

PessimalDecimal wrote: post #34
reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…

> The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding.

No it isn't. There's literally nothing about the process that forces you to skip understanding. Any such skips are purely due to the lack of will on the developer's side. This lack of will to learn will not change the outcomes for you regardless of whether you're using an LLM. You can spend as much time as you want asking the LLM for in-depth explanations and examples to test your understanding.

So many of the criticisms of coding with LLMs I've seen really do sound like they're coming from people who already started with a pre-existing bias, fiddled with with for a short bit (or worse, never actually tried it at all) and assumed their limited experience is the be-all end-all of the subject. Either that, or they're typical skill issues.

Re: The AI coding trap

#168

Post by n8cpdx »

johnfn wrote: post #161
lelanthran wrote: post #80

Earlier quoted context omitted.

> If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting. This argument is wearing a little thin at this point. I see it multiples times a day, rephrased a little bit. The response, "How well do you think your thinking will go if you had not spent years doing the 'practice' part?" , is always followed by either silence or a non…

Do you think that all managers and tech leads atrophy because they don’t spend all day “doing”? I think a good number of them become more effective because they delegate the simple parts of their work that don’t require deep thought, leaving them to continue to think hard about the thorniest areas of what they’re working on. Or perhaps you’re asking how people will become good at delegation without doing? I don’t kno…

I hear all the time from people who have moved into management that their engineering skills atrophy. The only antidote is to continue doing IC work while managing.

Re: The AI coding trap

#169

Post by m0rde »

strogonoff wrote: post #121
reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

I never made a case against LLMs and similar ML applications in the sense that they negatively impact mental agility. The cases I made so far include, but are not limited to: — OSS exploded on the promise that software you voluntarily contributed to remains to benefit the public, and that a large corporation cannot tomorrow simply take your work and make it part of their product, never contributing anything back. Com…

Good points here, particularly the ends not justifying the means.

I'm curious for more thoughts on "will drive more and more people out of jobs”. Isn't this the same for most advances in technology (e.g., steam engine, computers s, automated toll plazas, etc.). In some ways, it's motivation for making progress; you get rid of mundane jobs. The dream is that you free those people to do something more meaningful, but I'm not going to be that blindly optimistic :) still, I feel like "it's going to take jobs" is the weakest of arguments here.

Re: The AI coding trap

#170

Post by discreteevent »

johnfn wrote: post #161
lelanthran wrote: post #80

Earlier quoted context omitted.

> If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting. This argument is wearing a little thin at this point. I see it multiples times a day, rephrased a little bit. The response, "How well do you think your thinking will go if you had not spent years doing the 'practice' part?" , is always followed by either silence or a non…

Do you think that all managers and tech leads atrophy because they don’t spend all day “doing”? I think a good number of them become more effective because they delegate the simple parts of their work that don’t require deep thought, leaving them to continue to think hard about the thorniest areas of what they’re working on. Or perhaps you’re asking how people will become good at delegation without doing? I don’t kno…

> Do you think that all managers and tech leads atrophy because they don’t spend all day “doing”?

People have argued for years that software architects must write code.

Regarding your second paragraph: When you write python you then debug it at the level of the abstraction. You never debug the python interpreter. You can try to treat AI like an abstraction but it immediately breaks down as soon as you go to debug. It would only be a complete abstraction if you never had to deal with the generated code.

Post reply on HN