@polymutex.eth

I agree. I think this is now a new dimension that frameworks need to take into consideration when making breaking changes. Prior to LLM-coding, the cost was cognitive burden on developers to re-learn and adapt, but that was it. Now, human developers still need to re-learn and adapt, but also need to hand-write sufficient amount of open-source code so that LLMs have sufficient data to re-learn. Ideally, that also has to outnumber the previous version's training data, so that the LLM uses the updated version by default. Then there's another delay for the LLMs to get trained on that training data, and trickle down to consumer models so they can get their hands on it. Only then they can generate code with the new version. If the working assumption is that LLM-coding will take over, then there's a possibility that the volume of LLM-generated-code of the prior version consistently outpaces human-written code of the newer version. If that happens, the new version may never reach critical mass of training data.

1 reply

0 recast

2 reactions