It looks like git after 2.22 was dropped because it took an LLM commit. Same with ghc.
If I have to choose between this or git and the latest ghc, I think I'm going to just wait for someone to fork annex.
I don't even feel strongly one way or the other on AI stuff; pragmatically, I'm just not going to stop using the most widely used version controller, or Haskell, just for some guy's (forkable, AGPL licensed) hobby project.
Looks like they are aware, and git-annex has been around for decades written by one of the best Haskellers. “Some guys hobby project” is not fair
They said git-annex supports git back to 2.22. Not git after 2.22 was dropped.
An incompatible change in ghc would break compilation of other software also.
And those we've let into our codebases with no concerns. Hell, some even threw parties inviting in more of them.
At least LLMs don't call HR on you when you rightfully tell them that they're full of shit. Though.. well. Claude probably might.
I am wondering though if that was really the world we were living in just before chatGPT launched, given that the whole OSS thing was already harvested super hard.
The "mentoring opportunities" often were just extracting free consulting out of experts + building a portfolio for getting hired by big tech.
Would we really want to go back to that?
So I agree with the idea but only in a vacuum, I think.
Or rather I envy you for your experience with humans so far.
I disagree. Behind an LLM sits a developer. They steer the LLM. For them, directions to the LLM is the preferred form of modification of the software. The output of the LLM is not a preferred form anymore. This poses a huge problem for free software, especially when the LLM that translates preferred form into "source code" is not FOSS.
The low-tier dev was not used in this way.
If there is a bug, its because you are a lazy piece of shit, not because humans make mistakes, and you missed it. It is branded slop.
We're living in interesting times, socially, OSS will die because of this.
Contributors are dwindling, and will continue to do so. If you want to play in your sandbox, please do. Don't open-source, keep it to yourself.
The sloppers are diving head-first into a world where not knowing how a basic idea translates to code is embraced. This is not true of every slopper, but it is true of enough that sloppers are a threat.
The problem is you've redefined LLM-coding as slopping. "This is not true of every slopper".
I'd venture to say that a large number of developers are using LLM tooling at this point. Not all of those developers are out there generating massive, poorly engineered PRs and wasting project maintainer time. For me there are at least those 3 broad categories of user of LLMs for software development, maybe more if I sat and thought about it for a while.
How do you get your code to the point where it has no dependencies? How do you do any sort of database writing without a library, or web access without sockets from an os library?
What sort of code has no dependencies? I'm now very curious as I can't see how you can do anything without altest including the std lib from your OS to do any file i/o.
But other than that, totally dependency free!
With SO there's an unclear problem and a closed as duplicate being served if we're being real.
(FYI I'm not disputing that the LLM vendors didn't steal, that doesn't mean the technology is shit)
These days, my only deps are TinyUSB and LVGL - stuff that would be completely pointless and absurd to recreate.
I would be surprised if there is no LLM-assisted code in there prior to this commit, this is just the first where the author chose to disclose it.
LLM detection in writing is basically today's polygraph test pseudoscience. There was a blog a while ago where someone fed classic literature into one and it was detected as probably AI.
Agents as a super powered (re)search assistant is underrated.
(Update: you're a Debian developer so you're even more familiar with how that world works than I am.)
If you aren’t happy with their stance towards LLMs you can fork and fix yourself if you feel it’s necessary.
I can imagine LLMs becoming a mainstay, but what you are describing isn't wholly different from sufficiently advanced static code analysis - where you'd want more determinism than most LLMs normally provide.
The problem is that such a thing might take a decade and billions of dollars of investments to create per-language (e.g. actually useful code analysis for Java, for Spring Boot, for processing and validating form data, and DB schemas and document processing and rendering reports etc., literal domain checks for anything and everything that is common across various enterprises) so nobody wants to do that, so it's easier to throw LLMs at it and call it good enough.
Most bugs are far too nuanced to be caught by static analysis imo, you do need to actually understand what's going on in the program, the intent, the environment, etc. instead of blindly verifying if everything technically checks out, compilers already do a perfect job at that.
Man do I enjoy my totally real full self driving.
For me, for all intents and purposes, self driving is here today.
And they shan't be missed.
I think it will force us to adopt stronger type systems, formal methods, and more automated verification.
The sorts of folks who "won't be missed" put pedantry over productivity. To paint with a very broad brush, it's been my experience that they also tend to be stubborn and frustrating team members who don't understand that there's a time to debate and the rest of the time is for shipping.
A recent analysis on my Claude Code prompts showed 1.5B input tokens over the last few months. I use 4-5 provider agents (all CLI) DAILY, so this is a small subset. I spend a lot of time using transcription services to drone on about how some agent fucked things up and how I want it fixed and how to do it.
To assist with that process, I'm currently building out a search engine that is exposed via MCP to allow auditing of the dev runs. I already have the foundation of file changes (ala Splunk style) that let me keep an eye on the agents, and an agentic terminal that allows one agent to keep an eye on what the other agent is whacking on. Combined with my constant badgering for proper systems development, these things are improving the process at an acclerated rate.
Look, I get being an "engineer" on these types of things, and I think there is an absolute purity in pushing LLM generated code out of a codebase you control. That said, that's not the ONLY way to do things, and your milage will vary based on your systems thinking hat. I prefer to push hard on getting the outcomes and sacrifice the exhaustive process of reviewing every single line of code.
Consider frameworks. They make things easier to do, if they are complete and stable. There's an argument here that LLM harnesses should probably not ALSO be maintained by LLMs (something I'm completely ignoring so probably ironic I'm mentioning it). But the point being is the harnesses SHOULD have eyes on most lines of code. Eyes on every package though? Hard to say. I've settled on doing most stuff in Rust nowadays, just because it keeps the LLM more honest. And, we can build most "packages" by hand so we can change them to match our outcomes without code bloat. By bitching at it about code refactoring constantly, annealing the codebase by high level overview, not exhaustive review, I've found things get easier to work on as I go and still stay sane.
I do catch the LLMs occasionally hard coding things that belong in their own file or configs, and am a hardass about that and file length. I do read some code and hate it being overly long (and it sucks for burning tokens).
FWIW, I typed all this out on my keyboard myself. However, if I ran it through an LLM for cleanup or whatever, the very wall of text itself helps FORCE the LLM to stick to the substantive argument and steers it away from slop prompts. The same applies to code, if you are careful.
Legally, it's probably also unlawful, unless you believe that smoke they're selling that it was trained on code that was open licensed or in the public domain.
Professionally, it's a poor choice to ship code that wasn't produced with human care and consideration or even thorough oversight or understanding based on recent trends.
Software developers like to call themselves "engineers", but more and more they're showing they're more than happy to be configurators of black boxes of modular software. Whether that means pulling random NPM packages with thousands of other random packages as dependencies (none of which are even browsed or licenses checked), or "vibe coding" slop the LLM spits out.
When the main problem was people assembling random packages, I always likened it to "sandwich artists" at Subway. They just stand behind the counter and configure the product of random combinations of ingredients (someone else's NPM packages). Now it's like they can't even see the selection of ingredients, they just grab handfuls and shove it together until they get something sandwich shaped. Bad times in software.
You won't be selling software. You'll be selling a service of assisting someone so they can build software for themselves.
Everyone and their cat can look at open source projects, which can and will result in being called out publicly. This can also have legal ramifications on the project itself.
But maybe we are thinking about it backward. Have you ever wondered why there is so much "free software"? Beware of strangers bearing gifts.
I have always wondered and been suspicious of people who are so eager for you to use their software. Which isnt to say OSS isnt high quality. Im just saying that maybe when people are pushing free software on you they are kind of in it for themselves.
As for whats next, me personally, last year I pulled all my personal repos about 80 of them off of bitbucket and self host that all now. I think OSS projects should setup a paywall and charge money to create PRs.
Like 10-100 bucks per PR to cover the cost of the extra vigilance. Also I could see migrations away from github, to AI free dependency hosting or something like that. Its an interesting challenge. But its not insurmountable.
Either paywall OSS projects or take them off the interwebs. Also one option the OP didnt explore I dont think is forking and freezing the dependencies. Huge maintenance burden, but its better than source corruption.
Also use fewer dependencies. Maybe set a limit of 5.
I strongly disagree with this. The free (as in both freedom and as in free beer) software movement was to provide an alternative to proprietary and closed-source software, which is developed by people and corporations who are openly in it for themselves.
> Like 10-100 bucks per PR to cover the cost of the extra vigilance. Also I could see migrations away from github, to AI free dependency hosting or something like that. Its an interesting challenge. But its not insurmountable.
You could just leave your project where it's at, keep it open source, and simply not accept outside contributions. Lots of open source software operates this way. The Ladybird browser notably switched to this model recently as a reaction to AI pull requests.