Policy on vibe coded nix tools?

So, as the author (after a fashion, one supposes…) of one of these tools, I do want to point out a few things:

  • There is a big difference between a tool that just gets yeeted up there and a tool which undergoes a bunch of testing and tweaking.
  • It’s annoying to go to the trouble of being honest about this code’s origins when people dogpile and say shitty things solely due to that fact. I consider myself an honest person, but there’s nothing stopping anybody from just…not mentioning in their repo or commits that an LLM helped.
  • Seeing people complain about attribution and hallucinations is rich when I’ve gotten feedback on PRs specifically to remove comments explaining where some code or idea came from. Bit of a double-standard…either we care about provenance, or we don’t.
  • It’s really annoying to take time out of my life and spend it on tooling that solves a real need only to have the first comment be snark.

Let’s get some facts out there:

We have something like 8.6K packages that are broken.

We have 47K packages that are orphans.

We have 89K packages without tests, and 64K without automated update scripts. That’s right around half or more of nixpkgs.

We need all the help we can get.

P.S. –

I would appreciate bug reports, since even with a lot of human testing sometimes I do see behavior that might suggest an issue. For example, it may be possible that my script is miscounting packages maintained.

(And yes, the tongue-in-cheek directory name is what it is because I do like keeping my LLM stuff clearly delineated in my own work patterns when it is significantly LLM-generated…even when I do a bunch of testing and workshopping. Again, that’s just being organized–and computer-assisted is a lot to type.)

6 Likes