Post B46IYdhaooSShvjqpE by JamesWidman@mastodon.social
 (DIR) More posts by JamesWidman@mastodon.social
 (DIR) Post #B46IYc0f6wWVSUe3Gq by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc First of all: to the parenthetical at the end: the feeling of respect iscompletely mutual. Also, i appreciate that you took the time to write this, and i'm glad you sent it.[the rest of my reply is gonna exceed the character limit several times; i should probably switch mastodon instances at some point...]
       
 (DIR) Post #B46IYcJnxlpsPrbL6m by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc Secondly: i don't mean to be hostile; the "infection" metaphor is only there because of the "zombie" metaphor. And although there is a specific reason why i used it, i'd be open to alternative phrasing.The problem to which the metaphor refers is as follows:
       
 (DIR) Post #B46IYcVVGHC3094gLI by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc If someone feels that an LLM has enabled them to write code much faster than they could have done without the LLM, then i question that programmer's understanding of the LLM-generated code, and of the problem that they think they want to solve with that code.Here's why i have that suspicion:
       
 (DIR) Post #B46IYcpi39MA0oWoq0 by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc Suppose we're back in the pre-LLM days and you've been working on a PR. From the time when you start reading the bug report to the time that you make your last non-formatting edit before the change would be accepted, it takes some amount of time; call it t1.
       
 (DIR) Post #B46IYd0LPbraXnVJPk by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc Now suppose that sequence of commits is somehow lost. (This part is unrealistic bc you'd have to lose it on both your local machine and on github, but please allow it for the sake of argument.) The point is that, for this hypothetical scenario, you now need to re-type all of it. Say the amount of time to re-type, and make sure that it's as correct as before, is t2.
       
 (DIR) Post #B46IYdDobWdfDZo4PY by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc Now, unless you had recently been spending a lot of time on the region(s) of the code that were modified, and the problem was trivial, t2 would most likely represent a very small percentage of t1.
       
 (DIR) Post #B46IYdQvol89sFwXr6 by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc That means the product is not _just_ the code; it's also the _understanding_ that you couldn't have developed without working the problem. (That can include e.g.: the leg work of talking to clients & colleagues to find out what "correct" even means for the current task; coming up with a few potential solutions; the reasons for selecting the solution that you did; etc.)
       
 (DIR) Post #B46IYdZnHoDgJk5cfY by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc So much for that scenario. Back to the present day: it sounds as if people are claiming that they're getting the code they want (or think they want) in spans of time that are much shorter than t1. (Otherwise, why all the excitement about "productivity"?)
       
 (DIR) Post #B46IYdhaooSShvjqpE by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc But that means they didn't allow themselves the time required to build the same understanding that they would have built previously.So if someone isn't allowing themself _at least_ t1 hours/days/weeks to work the problem, then it is fair to at least _suspect_ that their understanding is not as complete as it would have been in the pre-LLM days.
       
 (DIR) Post #B46IYdrsCagJDoY3qi by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc And furthermore, i would bet money (if we had a good way to test this) that, a few months after the merge of such an LLM-assisted PR, the programmer's recall of their own thought process will be worse than if they'd worked the problem without an LLM. (Basically, the more excited they are about the amount of time they saved, the more money i would be willing to bet.)
       
 (DIR) Post #B46IYdzfjav5c0CI0O by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc Knowledge gained without much effort or significant emotion is knowledge that you're definitely going to forget in less time than you would have otherwise.
       
 (DIR) Post #B46IYe7TGb9s0BqWA4 by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc Again, I do not intend to be hostile about this!But these are the reasons why i sincerely don't see how, in the long run, anyone is going to understand code that was produced with the "high productivity" offered by an LLM.
       
 (DIR) Post #B46IYeEYqEpUMBABDE by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc And if the _author_'s memory fades like that when they lean on LLM assistance, then it is probably the case that in a year or two, nobody will understand it.That means it'll be **as if** that code is unmaintained. And that's why i'm reminded of the decades-old terms "living project" and "dead project": if there is no living person who maintains & understands the code, people would say it's "dead" (though ofc with effort a codebase can be revived).
       
 (DIR) Post #B46IYePuA3u4vMTEtU by JamesWidman@mastodon.social
       1 likes, 0 repeats
       
       @chandlerc One of the things that i've respected about Clang, ever since Doug told me about it, is the policy on unmaintained features: If nobody claims ownership of a feature, it's removed. Clang is the first project I ever learned about that has that policy. It's a really good policy!I think the same principle applies to code for which nobody's memory can be jogged to produce an accurate understanding of the motives & considerations around design & implementation.
       
 (DIR) Post #B46IYenIl4cQ5vPvMW by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc And it's possible that i'm wrong! (But again, i'm not exactly sure about the best way to test that.)
       
 (DIR) Post #B46IYfj5IEq6z8S4Qa by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       @chandlerc [end of way-too-long-reply]
       
 (DIR) Post #B46IdtWtOrbPF9EuPI by JamesWidman@mastodon.social
       0 likes, 0 repeats
       
       PSA: neovim is contaminated. Don't know how long it'll take for their infection deteriorate into full zombie status, but it would be best to kick them out of the party before that point.Now looking forward to the neovim-before-ai fork.
       
 (DIR) Post #B46Idtiwg3F9qWsXC4 by JamesWidman@mastodon.social
       1 likes, 0 repeats
       
       A "living" software project is one that is maintained & understood by a team of engineers.A "dead" software project is one that is unmaintained: nobody works on it, and the people who understand (or understood) it are either unavailable or literally deceased.If you use "a.i." to generate more code than you can understand, then nobody understands the code, which means that part of the project is dead. But that means it's both active (being modified) _and_ dead; i.e. it's a zombie project.