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

Did Claude increase bugs in rsync?

alexispurslane.github.io

Post reply on HN
Print view View original

471–480 of 611 posts

Re: Did Claude increase bugs in rsync?

#471

Post by yw3410 »

Daishiman wrote: post #395
yw3410 wrote: post #278

Earlier quoted context omitted.

I am anti-vibe coding if that meets your criteria? Reviewing vibe-coded PRs and features has been utterly exhausting over the past few months. I work on critical, mature software - a small change in behaviour can mean data loss or non-compliance with regulations for our customers. The biggest problem with AI PRs is the sheer amount of churn, extra code and lack of intent with the PRs it generates. The only way I can…

> The biggest problem with AI PRs is the sheer amount of churn, extra code and lack of intent with the PRs it generates. But this isn't an LLM problem; this is a problem of undisciplined engineers who feel they need to cram extra stuff in a PR. If an engineer doesn't look at the output of the LLM and generate extra work then it's still on them, right? > The only way I can describe the latter is that an AI-only PR fee…

I don't believe so - it's not as though the original prompts asked for extra code churn (note that as soon as you look and edit the LLM code output extensively it ceases to be vibe coding, which I was talking about in my OP).

I'm not talking about extra feature s; I'm talking about for the same single feature the code is either convoulted because the algorithm is overly complicated or the abstractions are just wrong for the domain.

The PRs typically are already focused in that they address a single feature; or at least a single "usable" feature in a complex system which necessarily has a lot of connected parts and behaviors.

> then the tool is probably not fit for the job.

Perhaps; but with an LLM I haven't found which jobs it _does_ work for and which it doesn't. I already use planning mode extensively; and capture the major points, but then it makes a stupid decision mid implementation and just starts churning.

Re: Did Claude increase bugs in rsync?

#472

Post by Joel_Mckay »

TZubiri wrote: post #277

I haven't used this thing for like 10 years, when my modus operandi was googling my question and installing whatever stackoverflow suggested. Can someone explain why one would ever use rsync (pre vibecode version) instead of cp and dd? Can't we just 'apt remove rsync' and save ourselves the time even spent on evaluating this dependency? Thanks

If you deal with large numbers of files, the ability to dynamically skip compressing media and zipped files for transfer can be extremely handy.

While stuff like sshfs is great for a few small files (and win11), it will be an order of magnitude slower than an rsync task.

Most smart folks automate backup/recovery scripts, and only sometimes edit them with a new OS install. =3

Re: Did Claude increase bugs in rsync?

#473

Post by Joel_Mckay »

classified wrote: post #399
xmddmx wrote: post #338

There's a meta-level of irony here that's important to note. TFA is defending the use of AI, and it very clearly (to me) used AI to analyze the data and present the results. In doing so, the author used statistics in a way they do not appear to understand, and ended up making numerous false claims (you can see the thread discussing these here https://news.ycombinator.com/item?id=48417626 ) In short, the study doesn't…

AI is so much like a religion. There is nothing you can say to a believer that will make them question their believes. Or more generally, you cannot reason anyone out of something that they want to believe.

It gets pretty dark if you pull that thread of reason. =3

https://en.wikipedia.org/wiki/The_True_Believer

Re: Did Claude increase bugs in rsync?

#474

Post by gverrilla »

wolletd wrote: post #453
kelnos wrote: post #432

Earlier quoted context omitted.

Unless you're willing to step up and be that person, it's not your place for you to suggest it.

I don't agree with that, I can very well still discuss that. He clearly sounds like someone who doesn't want to do this work anymore and should have searched for a successor. That's my impression from that sentence, at least. Don't you agree? So, why didn't he do it? Because just firing up Claude and let it rip is way easier than finding real people and building up trust? Did Claude increase bugs in rsync? Or did Cla…

Congratulations, you have an opinion.

Re: Did Claude increase bugs in rsync?

#475

Post by el_io »

dnnddidiej wrote: post #385
matheusmoreira wrote: post #285

Earlier quoted context omitted.

This should be the top comment. I think it's pretty sad that he even had to write it. Quite a lot of judgement from people who aren't paying his bills.

The title at least sounds less like judgement and more analysis and more about AI assistance (and claude in particular) than rsync. Maybe I am too used to postmortems!

I think they're talking about the whole twitter and github issue things.

Re: Did Claude increase bugs in rsync?

#476

Post by Joel_Mckay »

int_19h wrote: post #330
jarym wrote: post #256

I've been coding for over 2 decades. I love it, I've always loved it and I likely always will. I was an AI skeptic some months ago but truly Claude and Codex have changed my development style and velocity in a way I never imagined would ever be possible. With that, yes, I produce more code and am finding more bugs. So looking over at comments in HN articles the amount of polarising hate to anything produced with AI i…

I was similarly an AI skeptic 3 years ago. When GPT-4 was the state of the art, I thought we're going to plateau soon because of context size limits (remember back when you had to pay insane money just to get 32K)? Last year was the first time I saw an AI agent actually debug and fix a non-trivial bug in a satisfactory way. Even then, trying to use it on larger tasks made it clear that it wasn't something I could jus…

Good code is a living document that shows intent, and allows ease of maintainability.

Most people feel more productive with chat bots, but often end up wasting more time chasing self-inflicted issues. Same clown-car of Dev-ops proponents no doubt billing by the hour. =3

Re: Did Claude increase bugs in rsync?

#478

Post by andrekandre »

ethagnawl wrote: post #378
block_dagger wrote: post #197

Earlier quoted context omitted.

At my employer, if AI is not used, it shows up on your performance report and you’ll be told if you don’t start using it, you will be dismissed. I work at a medium sized successful YC-backed SaaS. So here, the attribution is meaningless - they look at your Bedrock and LLM API calls as well as Claude Code history.

> they look at your Bedrock and LLM API calls as well as Claude Code history. This is fucking insane. How does this correlate with productivity in any way ? The results are all that matters, who cares how you got there?

  > The results are all that matters, who cares how you got there?
i actually said this at $JOB to a manager, to which they replied "yes, but in the future all code will be ai generated, so thats the 'results' we are looking for"....

Re: Did Claude increase bugs in rsync?

#479

Post by wzdd »

jagged-chisel wrote: post #262
delusional wrote: post #248

Earlier quoted context omitted.

You don't really have to guess. The guy told us the AI didn't suggest this specific change: > The change to zero memory was my idea and my change. It was a reaction to a security report I got which caused use of an element past the end of an array. By zeroing the allocation I could ensure that misuse of that memory if a similar bug came up in the future could only cause a null ptr deref, which is better than the chan…

> … By zeroing the allocation … How does that prevent reading past the end of the buffer? Or change how bytes outside the buffer are used? Are these arrays of pointers so that the “null ptr deref” comment makes sense? Or am I the bozo and don’t know what’s happening here?

The code is part of a function called expand item list. It looks like it over allocates memory and uses a bump pointer for internal allocation, only expanding the allocation when necessary. Thus OOB writes to the list would hit the allocated memory.

You’re not a bozo but it is helpful to read the code.

Re: Did Claude increase bugs in rsync?

#480

Post by wzdd »

GodelNumbering wrote: post #261
delusional wrote: post #248

Earlier quoted context omitted.

You don't really have to guess. The guy told us the AI didn't suggest this specific change: > The change to zero memory was my idea and my change. It was a reaction to a security report I got which caused use of an element past the end of an array. By zeroing the allocation I could ensure that misuse of that memory if a similar bug came up in the future could only cause a null ptr deref, which is better than the chan…

okay I had not read this or any discussions there (except the one linked in the post), but this looks weirder. the comment you linked is a dev responding to what is very clearly a bot comment. I am sure they have good intentions and I have no reason to believe otherwise as I have no connection to the project whatsoever, but the original commit being 4-5 lines long (what did claude do then?) and the revert description…

It is certainly unkind, when a developer asserts the opposite of what you have assumed about their code, to double down and imply they are lying.
Post reply on HN