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

61–70 of 424 posts

Re: The AI coding trap

#61

Post by rwmj »

jayd16 wrote: post #24
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…

My take is just that debugging is harder than writing so I'd rather just write it instead of debugging code I didn't write.

I think it's more like code review, which really is the worst part of coding. With AI, I'll be doing less of the fun bits (writing, debugging those super hard customer bugs), and much much more code review.

Re: The AI coding trap

#62

Post by meindnoch »

mmaunder wrote: post #57

If you know, understand that you are in possession of a massive and temporary information asymmetry advantage, and you should run with it as hard and fast as you can to gain the biggest lead possible, before the author and the rest of the world gain that advantage too. Go, go now, go fast, do it in parallel, and don’t stop until you win. Opportunities like this are extremely rare not just in your life, but in the his…

What are you talking about?

Re: The AI coding trap

#63

Post by fzzzy »

didibus wrote: post #51
_fat_santa wrote: post #40

Earlier quoted context omitted.

> 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. Here's mine, I use Cline occasionally to help me code but more and more I find myself just coding by hand. The reason is pretty simple which is with these AI tools you for the most part replace writing code with writing a prompt. I look at it like this, if writing the prompt, and the inf…

> The reason is pretty simple which is with these AI tools you for the most part replace writing code with writing a prompt I'm convinced I spend more time typing and end up typing more letters and words when AI coding than when not. My hands are hurting me more from the extra typing I have to do now lol. I'm actually annoyed they haven't integrated their voice to text models inside their coding agents yet.

GitHub copilot already does have speech to text and as my sibling comment mentions, on the Mac, it is globally available. It varies according to typing and speaking speed but speaking should be about five times faster than typing.

Re: The AI coding trap

#64

Post by danielmarkbruce »

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.

lol, this is the entire reason LLMs work so well. The bar is so low and most folks don't seem to realize it.

Re: The AI coding trap

#65

Post by danpat »

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…

> 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 seems to me that the introduction of generative code-writing tools is actually not moving the needle as far as people are claiming.

We _already_ live in a world where most of us spend much of our time reading and trying to comprehend code written by others from the past.

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?

Re: The AI coding trap

#66

Post by swiftcoder »

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.

What makes you regard this as an anti-AI take? To my mind, this is a very pro-AI take

Re: The AI coding trap

#67

Post by mmaunder »

meindnoch wrote: post #62
mmaunder wrote: post #57

If you know, understand that you are in possession of a massive and temporary information asymmetry advantage, and you should run with it as hard and fast as you can to gain the biggest lead possible, before the author and the rest of the world gain that advantage too. Go, go now, go fast, do it in parallel, and don’t stop until you win. Opportunities like this are extremely rare not just in your life, but in the his…

What are you talking about?

He doesn’t know.

Re: The AI coding trap

#68

Post by nativeit »

didibus wrote: post #44
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 I think this depends. I prefer the thinking bit, but it's quite difficult to think without the act of coding. It's how white boarding or writing can help you think. Being in the code helps me think, allows me to experiment, uncover new learnings, and evolve my thinking in…

I’m struggling to understand how they are asserting one follows from the other. I’m not a SWE, but do a lot of adjacent types of work (infrastructure automation and scripting, but also electronics engineering, and I’m also a musician), and the “thinking” part where I get to deploy logic and reasoning to solve novel challenges is certainly a common feature among these activities I certainly enjoy, and I feel it’s a core component of what I’m doing.

But the result of that thinking would hardly ever align neatly with whatever an LLM is doing. The only time it wouldn’t be working against me would be drafting boilerplate and scaffolding project repos, which I could already automate with more prosaic (and infinitely more efficient) solutions.

Even if it gets most of what I had in mind correct, the context switching between “creative thinking” and “corrective thinking” would be ruinous to my workflow.

I think the best case scenario in this industry will be workers getting empowered to use the tools that they feel work best for their approach, but the current mindset that AI is going to replace entire positions, and that individual devs should be 10x-ing their productivity is both short-sighted and counterproductive in my opinion.

Re: The AI coding trap

#69

Post by latexr »

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.

Are you genuinely saying you never saw a critique of AI on environmental impact, or how it amplifies biases, or how it widens the economic gap, or how it further concentrates power in the hands of a few, or how it facilitates the dispersion of misinformation and surveillance, directly helping despots erode civil liberties? Or, or, or…

You don’t have to agree with any of those. You don’t even have to understand them. But to imply anti-AI arguments “hinge on the idea that technology forces people to be lazy/careless/thoughtless” is at best misinformed.

Go grab whatever your favourite LLM is and type “critiques of AI”. You’ll get your takes.

Re: The AI coding trap

#70

Post by swiftcoder »

tptacek wrote: post #41
closeparen wrote: post #38

Earlier quoted context omitted.

>First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down Yes, and the thinking time is a significant part of overall software delivery, which is why accelerating the coding part doesn't dramatically change overall productivity or labor requirements.

This logic doesn't even cohere. Thinking is a significant part of software delivery. So is getting actual code to work.

ideally there is an order of magnitude difference between, and the latter is trivially delegable (where the former is not)
Post reply on HN