We are in fact seeing software improvement, in the form of fewer bugs and better performance.

In general, I feel like there are more bugs now. More software behaves erratically or in subtly wrong ways and my hunch is that it’s due to one of these “bug fixes and performance improvements” from LLMs, but lack of tests or (whatever) caused a regression.

Often when raising that something is broken, the answer is usually “Claude can fix it” (work around). Which…if we build a culture of workarounds for workarounds then finding and fixing the root of problems becomes socially harder and harder. LLMs are good at finding bugs, they’re not always good at gauging the relative importance of which are trivial and which are important.

You can write high rigor software aided by LLMs, but it is not the norm or the default for most users.

score 2 · canonical

Love that the question was “why” and my answer for why got negative downvotes. Sure there alternatives, maybe those alternatives are better. Also…someone asking “why” and getting met with a genuine attempt at an answer should never get downvoted IMHO. Also the downvote is marking this as spam which? I’m not sure what I’m spamming? A paid advertisement for “big type” ??!?!?

Ahh, this is literally a duplicate comment. That makes sense. Lobsters has been hitting me with anubis failures on my iOS phone when I’m typing by hand and I had to type this one out and submit it several times to get it to work. I didn’t realize some of the others actually went through.

score 1 · canonical

It’s just hard to pick a good trade-off between code size, compile time, and run time.

I wonder what a stable (or semi stable) interface for a higher level hint could be. I’m thinking metadata in Cargo.toml. One thought could be an ability to cap the final binary size and have the compiler try to deopt if that’s hit (for example). But that might be too exact. Too brittle.

Thankfully this specific thing could also be pushed to a crate. So we could have a cold::Debug and a inline::Debug etc. or have it configurable with a container attribute.

score 2 · canonical

I’m trying to contribute to clippy now and the situation looks bleak for maintainers.

Previously the signal was: could make a PR. Things like docs and tests were “wow this person is good” and a description that linked to the issue it closes and actually explained that it did was a 10/10.

Mantainers have always relied on signals to determine where to invest their limited time. When they do invest it, it was clear their empathy is met and reciprocated. Now those signals are gone and there’s not a good way to distinguish between “I spent days and hours meticulously promoting fans getting reviews and iterating combined with my own human iteration” and “told Claude to get me internet points to boost my resume in a Ralph loop”. There’s not even a guarantee the person on the other side is in fact a person.

The rust/clippy policy is very thoughtful and clearly spells out how to use LLMs with empathy for the eventual maintainer/reviewer. I ran afoul of it by some degrees and even though I’m in the “meticulous code” camp of LLM users cannot genuinely say code produced by the machine isn’t in the final product. I can though, and will. So closed it and will rewrite it.

I think LLM scanning is good. But LLM issues and PRs are not. We need a human who has the skills and empathy for reviewers to make it easy enough for them. The challenge has never been the work, the challenge has always been doing the work in a way that is reviewable, maintainable, and sustainable. We need to find community standards and guidelines to reflect that reality.

score 1 · canonical

I think there’s also an argument for “when it starts to be a problem” rather than “we must be hyper vigilant at all times.” Also depends on the blast radius. If it’s just me on the project, a refactor is easier. If there are lots of devs I don’t want to break their rebases and inflight work all the time (though LLMs make this cheaper).

I get the sense that I edit and prune my LLM generated garden MUCH more than most. And it’s already a lot of time and work. And being pedantic takes time away from other coding tasks and is exhausting. Especially since the iteration seems to follow Zeno’s paradox. It gets closer and closer but rarely is “perfect” and often I don’t even know what “perfect is” so it diverges back and forth between a few similar solutions and I shout (to no one) I’m tired it is “good enough”.

I also use these tools at work where we have a compliance requirement that a second human must approve and review all code. (It existed before we used LLMs). In the before times I had a healthy respect for “they did it differently than I would have but I respect their decisions” I.e. don’t bikeshed.

Okay, sorry that’s the word I needed. How do we do better and demand higher quality while also avoiding bike shedding?

score 1 · canonical

I made the mistake of approving a function name I didn’t like once. It described something as a “leaf” which, whatever it was a helper function. Later other agents picked up on that name and LOVED it and it started showing up in comments and even a suggested changelog.

I think this is the kind of thing people think of when they say “slop” it’s sloppy. And it bleeds into the codebase and replicates.

Humans have decades of experience of what cause each other common mistakes and how to guard against them (best practices etc.). It’s unclear in LLM generated code when I’m being pedantic because it’s not exactly how I would have done it and when it’s the start of slop that should be nipped in the bud. I think naming is one area we need to take care or it can unexpectedly bleed into other areas.

score 1 · canonical

The whole idea is “make invalid state impossible to represent”. The head element cannot be empty, therefore constructing the type is enough to prove the collection is non empty.

Doing it your way is possible but requires the programmer who implemented it to have done so in a bug free way.

It means you have to reallocate + copy the entire vec in the constructor

IIRC the compilation process can optimize away some of that. Depending on how it is used.

It would be interesting to see a comparison to see the real world differences. Also there might be implementations with more efficient implementations out there.

score 1 · canonical