Comment by malfist
If AI is writing the code and the unit tests, how do you really know its working? Who watches the watchman
If AI is writing the code and the unit tests, how do you really know its working? Who watches the watchman
No, that's a much stronger statement. I'm not talking about ideals. I'm talking about running a business that is mature, growing and going to be around in five years. You could literally kill such a business running it on a pile of AI slop that becomes unmaintainable.
How much of the code do you review in a third party package installed through npm, pip, etc.? How many eyes other than the author’s have ever even looked at that code? I bet the answers have been “none” and “zero” for many HN readers at some point. I’m certainly not saying this is a great practice or the only way to productively use LLMs, just pointing out that we treat many things as a black box that “just works” till it doesn’t, and life somehow continues. LLM output doesn’t need to be an exception.
That's true, however, not so great of an issue because there's a kind of natural selection happening: if the package is popular, other people will eventually read (parts of, at least) the code and catch the most egregious problems. Most packages will have "none" like you said, but they aren't being used by that many people either, so that's ok.
Of course this also applies to hypothetical LLM-generated packages that become popular, but some new issues arise: the verbosity and sometimes baffling architecture choices by LLM will certainly make third-party reviews harder and push up the threshold in terms of popularity needed to obtain third party attention.
The trick is to not give a fuck. This works great in a lot of apps, which are useless to begin with. It may also be a reasonable strategy in an early-stage startup yet to achieve product-market fit, but your plan has to be to scrap it and rewrite it and we all know how that usually turns out.