144
git-llmfs, a git filter that will reduce your repo code size through the power of LLMs! (codeberg.org)
submitted 1 month ago by to c/programmer_humor@programming.dev
17 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 11 points 1 month ago (3 children)

Well, I'm not going to downvote, but something in my brain is screaming "lossy compression!" and so you might say I'm at least wary.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 4 points 1 month ago (1 child)

    It is a tremendously stupid idea, which is why I found it funny (also, it's one of those things where name came first and inspired the rest).

    But, to take it seriously for a moment (and I'm not trying to defend it, not a fan of LLMs as most of the people here), is it necessarily lossy? I mean, you basically have to include the 5Gb large model for it to work, and you just move the data from the file to hoping the summary can trigger a correct combination of parameters.

    I didn't run any larger tests, and I assume that if you managed to keep the API/function names and behavior, the summary would be actually longer than the actual implementation in most cases anyway, so it's probably not even a compression (especially if you include the model).

    It's just a food for thought, it's definitely a bad idea to do something like this, to the point where I'm pretty sure you could get millions from investors if you made a startup working on something like this (and that one already exists), but I do honestly wonder if the fact that you kind of have the data in the model would still count as lossy.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 month ago

    When I first saw this, I thought it was obviously a toy to learn something and as an excuse use an LLM. I wasn't sure if the use of an LLM was serious or not (e.g. did the originator know the limitations); however, I did take it seriously for the sake of argument after one of the other comments talked about compression.

    I decided that I actually like this project quite a bit as an example to introduce information theory to students. What the compression comment gets wrong imo is that compression is about taking an instantiation of information, reducing it to a minimum set of measurable units of infirmation (i.e. bits) to recreate that instantiation.

    What this would aim to do, assuming it works (or rather what a competent human could do) is reduce the instantiation to a set of information that can recreate an instantiation of said information (changing the problem into a non-unique inversion problem) to recreate functionality but not an exact duplicate of the input. To the degree that the description converges on one result then one would end up with the exact same input; however, as human language is notoriously verbose and imprecise this would not compress anything.

    Kudos.

  • permalink
  • fedilink
  • source
  • parent