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

191–200 of 424 posts

Re: The AI coding trap

#191

Post by iambateman »

I spend more time thinking now that I use Claude Code. I write features that are often 400-600 word descriptions of what I want—-something I never would’ve done beforehand.

That thinking does result in some big tradeoffs…I generally get better results faster but I also have a less complete understanding of my code.

But the notion that Claude Code means an experienced developer spends less thinking carefully is simply wrong. It’s possible (even likely) that a lot of people are using agents poorly…but that isn’t necessarily the agent’s fault.

Re: The AI coding trap

#192

Post by lukaslalinsky »

skydhash wrote: post #156
lukaslalinsky wrote: post #102

Earlier quoted context omitted.

This depends entirely on how you use said AI. You can have it read code, explain why was it done this or that way, and once it has the context you ask to think about implementing feature X. There is almost no gambling involved there, at best the level frustration you would have with a colleague. If you start from blank context, tell it to implement full app, you are purely just gambling.

> You can have it read code, explain why was it done this or that way, The thing is that, once you're experienced enough, it's faster to just glance at the code and have the answer right, instead of playing the guessing game with AI. > and once it has the context you ask to think about implementing feature X I'm always amazed at someone using that methodology. When I think about a feature, first is to understand the…

I'm not sure where is the misunderstanding but your second paragraph is exactly why I ask AI the questions you question in the first paragraph. I ask the AI to do the domain research, see what we are starting from and THEN ask it to think about a feature. They are not really for me, they are for the AI to have good context what we are working on. As you said, the implementation is then almost trivial and the AI is less likely to mess it up.

Re: The AI coding trap

#193

Post by itsoktocry »

halfadot wrote: post #167
PessimalDecimal wrote: post #34

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

People will complain about letting the LLM code because you won't understand every nuance. Then they will turn around and pip install a dependency without even glancing at the underlying code.

Re: The AI coding trap

#194

Post by bccdee »

halfadot wrote: post #167
PessimalDecimal wrote: post #34

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

> There's literally nothing about the process that forces you to skip understanding.

There's nothing about C that "forces" people to write buffer overflows. But, when writing C, the path of least resistance is to produce memory-unsafe code. Your position reminds me of C advocates who say that "good developers possess the expertise and put in the effort to write safe code without safeguards," which is a bad argument because we know memory errors do show up in critical code regardless of what a hypothetical "good C dev" does.

If the path of least resistance for a given tool involve using that tool dangerously, then it's a dangerous tool. We say chefs should work with sharp knives, but with good knife technique (claw grip, for instance) safety is the path of least resistance. I have yet to hear of an LLM workflow where skimming the generated code is made harder than comprehensively auditing it, and I'm not sure that such a workflow would feel good or be productive.

Re: The AI coding trap

#195

Post by jmull »

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…

> There's a divide between people who enjoy the physical experience of the work and people who enjoy the mental experience of the work.

Pretty clearly that’s not the divide anyone’s talking about, right?

Your argument should maybe be something about thinking about the details vs thinking about the higher level. (If you were to make that argument, my response would be: both are valuable and important. You can only go so far working at one level. There are certainly problems that can be solved at one level, but also ones that can’t.)

Re: The AI coding trap

#196

Post by WalterSear »

mrcrumb1 wrote: post #178
halfadot wrote: post #167

Earlier quoted context omitted.

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

Let me ask you this: do you understand the code your colleagues produce as well as the code you write yourself?

AI is not my coworker, with different tasks and responsibilities.

The comparison is oniy reasonable if most of your job is spent trying to understand their code, and make sure it did what you wanted. And with them standing next to you, ready to answer questons, explain anything I don't understand and pull in any external, relevant parts of the codebase.

Re: The AI coding trap

#197

Post by keeda »

mrcrumb1 wrote: post #178
halfadot wrote: post #167

Earlier quoted context omitted.

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

Let me ask you this: do you understand the code your colleagues produce as well as the code you write yourself?

We most definitely should, especially so if you're working in a team or organization bigger than a handful of people. Because it's almost certain that you may need to change or interact with that code very soon in the lifetime of the project. When that happens you want to make sure the code aligns with your own mental model of how things work.

The industry has institutionalized this by making code reviews a very standard best practice. People think of code reviews mainly as a mechanism to reduce bugs, but turns out the biggest benefits (born out by studies) actually are better context-sharing amongst the team, mentoring junior engineers, and onboarding of new team-mates. It ensures that everyone has the same mental model of the system despite working on different parts of it (c.f. the story of the blind men and the elephant.) This results in better ownership and fewer defects per line of code.

Note, this also doesn't mean everybody reviews each and every PR. But any non-trivial PR should be reviewed by team-mates with appropriate context.

Re: The AI coding trap

#198

Post by godelski »

bccdee wrote: post #186
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…

> the idea that technology forces people to be careless I don't think anyone's saying that about technology in general. Many safety-oriented technologies force people to be more careful, not less. The argument is that this technology leads people to be careless. Personally, my concerns don't have much to do with "the part of coding I enjoy." I enjoy architecture more than rote typing, and if I had a direct way to imp…

(Adding to your comment, not disagreeing)

  > The argument is that this technology leads people to be careless.
And this will always be a result of human preference optimization. There's a simple fact: humans prefer lies that they don't know are lies over lies that they do know are lies.

We can't optimize for an objective truth when that objective truth doesn't exist. So while doing our best to align our models they must simultaneously optimize they ability to deceive us. There's little to no training in that loop where outputs are deeply scrutinized, because we can't scale that type of evaluation. We end up rewarding models that are incorrect in their output.

We don't optimize for correctness, we optimize for the appearance of correctness. We can't confuse the two.

The result is: when LLMs make errors, those errors are difficult for humans you detect.

This results in a fundamentally dangerous tool, does it not? Tools that when they error or fail they do so safely and loudly. Instead this one fails silently. That doesn't mean you shouldn't use the tool but that you need to do so with an abundance of caution.

  > I could slow down and review it line-by-line, picking all the nits, but that moves against the grain of the tool.
Actually the big problem I have with coding with LLMs is that it increases my cognitive load, not decreases it. Bring over worked results in carelessness. Who among us does not make more mistakes when they are tired or hungry?

That's the opposite of lazy, so hopefully answers OP.

Re: The AI coding trap

#199

Post by kjkjadksj »

anotheryou wrote: post #183

This omits the deep knowledge required for traditional coding. This opens up coding to non devs, e.g. product managers. For vibe coding you need systems thinking, planning and logic, but less craftmansship. For PO's the chart looks different, here the traditional flow contains: "polish concepts, make mocks, make stories, dailies, handovers, revisions, waiting for devs busy with other things" The vibing PO has none of…

The deep knowledge really isn’t all that deep. A couple years in the weeds and you have it. What this really hurts is outsourced devs. In the past a non coding person could come up with the spec and hire someone from a developing nation to make it on the cheap to that spec. It is still possible to work like this of course, resulting in working code compared to llm that might hallucinate a passing test condition that you can’t appreciate with your lack of coding chops. It is just the ai seems “faster” and the way it is paid for less in front of your face. Really in practice, nothing new was really gained. Pm always could hire code. Now they hire nondeterministic generated code but they are still essentially hiring code, submitting spec, having something else write the code.

Re: The AI coding trap

#200

Post by anotheryou »

kjkjadksj wrote: post #199
anotheryou wrote: post #183

This omits the deep knowledge required for traditional coding. This opens up coding to non devs, e.g. product managers. For vibe coding you need systems thinking, planning and logic, but less craftmansship. For PO's the chart looks different, here the traditional flow contains: "polish concepts, make mocks, make stories, dailies, handovers, revisions, waiting for devs busy with other things" The vibing PO has none of…

The deep knowledge really isn’t all that deep. A couple years in the weeds and you have it. What this really hurts is outsourced devs. In the past a non coding person could come up with the spec and hire someone from a developing nation to make it on the cheap to that spec. It is still possible to work like this of course, resulting in working code compared to llm that might hallucinate a passing test condition that…

But the feedback cycle wait time and the communication workload is almost eliminated.
Post reply on HN