I’d say AI assisted; you still decided to follow that design and code the thing yourself, but the overview was suggested by the AI. The assets themselves weren’t generated though.
Previously, a bad coder wouldn’t be able to create an entire operating system. With LLMs, that is possible now, even if they don’t understand 1% of the output.
Implying that this doesn’t change the dynamics of open source is, honestly, absurd.
Perhaps, but that is neither “code completion” or “minor use cases”, and fails to distinguish between even “I asked for a design in output tokens and evaluated it” vs. “I proposed a design as input tokens and asked to interrogate it”.
And so if that’s the standard people are asked to meet, then the effective outcome will be that nearly everything will be marked as “AI-assisted” and it will be a significantly less useful signal.
Fascinating to see the examples raised so far…
- Lennart’s MicroHS: good quality, contains AI code
- GHC: good quality, contains AI code
- Cabal: bad quality, doesn’t contain AI code
The “good” ones here aren’t really good signals imo.
MicroHs is one guy who clearly knows what he’s doing.
GHC is an old project - most of it isn’t AI. And it has a strong stewarding team to manage AI patches.
The downsides of AI are at the software engineering level. They have rippling effects.
AI changes are good in a vacuum. The diff is good. But they tend to be gradient-descent-y changes. N% better. Can’t argue.
But if you just ride N% better blindly, you end up in a pit called a local maximum. This isn’t my opinion or taste - this is fact!
You need culture [1] and skill to ensure you don’t fall into that pit.
Easier said than done. Doubly so in industry where short term-ism is the norm. I can’t tell you how many high level engineers/execs subscribe to the “make things 1% faster, multiply it by my big org chart and their salaries, and QED millions of dollars of value” fallacy.
[1] Even small projects need culture. Even individuals! A culture of 1 person is called “taste”
Give me examples of Haskell packages that are bad because of AI-generated code.
This feels a bit like a non sequitur to me.
What’s your point exactly? Do I need existing examples to “prove” that AI code can be bad? That feels like a fallacy but I don’t know the name.
Because there’s plenty of examples generally of AI coding is harmful out there in the world today. Actual egregious bugs and vulnerabilities. Nines dropping like flies (github lol).
If it hasn’t hit Haskell specifically, it’s likely due to it not being deployed heavily in our world yet.
(Why is it that so often when someone defends AI, they use arguments that are built on fallacy? It keeps happening to me across forums. Rough out there.)
The purpose of '“vibecode-scanner” is to identify Haskell packages that include AI-written code, on the assumption that this is an indicator of poor quality. However, no evidence for this assumption (Haskell packages of poor quality due to AI-written code) has been presented, while evidence against this assumption (Haskell packages of good quality with AI-written code, and just for good measure a Haskell package of poor quality without AI written code) has been presented. Nevertheless you dismissed this evidence using the fallacy of special pleading.
(Why is it that so often when someone attacks AI, they use arguments that are built on fallacy? It keeps happening to me across forums. Rough out there.)
lol i gave you evidence though. all the non-haskell AI code being deeply garbage making the news lately. you have fintechs releasing excel clones that exfiltrate user data. that’s a whole program in prod [1] that passed a whole company’s release process and made it to prod lol.
it’s pretty clear that AI written code is problematic. it has been measured to have more bugs and - worse - more vulns
just because haskell doesn’t have a rich zoo of examples doesn’t mean it’s immune
it just means that haskell is teeny tiny and doesn’t have a glut of AI activity going on
maaaaybe it also means haskell has a slight inborn immunity to AI cancer. whether that is from its niche nature (less training data) or its type system or its culture ..idk
AI code is used everywhere these days. The amount of bad AI code is just indicative of the amount of AI code, not that AI code is necessarily bad.
This feels like a meme. People keep telling me “AI is here - it’s happened. Get used to it.”
And yet I only push natty code..get good performance reviews..to me AI hasn’t happened.
am I really surrounded by AI code? Did it pass me by? I try to use Claude weekly to vibe code to get my token usage up on the leaderboard. It’s always trash and not something up to my standards. I don’t want my name on that commit lol. I then code it by hand and pay Claude to tell me how much better I am than it (tokens++)
Regardless, it doesn’t feel like anything is that much different at work. I am not seeing velocity gains. I am seeing outages and pushed deadlines still. So AI isn’t doing much (besides shaving some $ off the top of the comp budget.)
I am deeply smelling that the emperor has no clothes.
you have fintechs releasing excel clones that exfiltrate user data. that’s a whole program in prod [1] that passed a whole company’s release process and made it to prod lol
Seems to me that this vulnerability is due to an AI agent being integrated into the application, which is different from the application possibly being vibecoded.
that’s true ..but..you think they didn’t vibe code it?
Maybe they did (and ramp’s leadership seems strongly pro-vibecoding, so the odds are pretty good). But, there’s no hard evidence, as far as I can tell.
For the topic of vibecoded dependencies, it would be good if there was an example (not necessarily in Haskell) of a regression being caused by a vibecoded PR that got merged. Here’s an almost good enough example (summary: PR with vibecoded assembly that is slower than C). However, in this case, the PR was not merged, so one could make an argument that maintainers do a good job of keeping out bad AI-generated PRs. It would be better if there was an example where the vibecoded regression was actually accepted.
I don’t have any.
But I also think that’s largely besides the point. There is indication that AI assisted code is on average more buggy and less secure than entirely human written code. I’ve already linked those articles earlier in this thread, I don’t think it needs to be repeated.
It’s quite possible that all my fears are unfounded when it comes to specifically the Haskell community. And if it turns out that way, I’ll be very happy. But so far all things point to LLM slop becoming a problem.
Although it was in rust, we already have cases where people posted their low-effort slop projects: Why We Built a Haskell Package Manager in Rust
Many such cases. I’ve started to subliminally treat “in Rust” as a marker for slop projects.
I use Opus to generate almost all of my code these days … bounded, however, by structural review enabled by srid/agency.
The last few PRs in Emanote are all generated by Claude Code.
Closing this because the original question has been answered. Further discussion about vibe coding can take place in other topics.