Another thought: a large part of why LLMs have been having so much of an effect is that in tech, *most of the work we're currently doing involves exploiting assets that were largely built decades ago*. We aren't really developing new core technologies so much as we're trying to squeeze extra value out of what we already have.
@iris_meredith This! And also, good software design leads to guessable code. You can usually understand a function without having read all the functions that are called. So in a well structured code base, using well structured libraries the big guessing machine somewhat works. What is good for the human is good for the LLM. However, what an LLM spits out is rarely well structured. If an LLM works well on your code base today, it might not tomorrow if you let it write too much code.
Not that I want to encourage Trained #MOLE use, but ...
@uncanny_static
> If an LLM works well on your code base today, it might not tomorrow if you let it write too much code
What about a more centauric approach? Rather than letting the MOLE write the code, we get it to describe potential solutions to a problem *without* using code to do so? Then if it comes up with anything genuinely useful, the human codes it. Like Rubber Duck Debugging, but with a MOLE instead of a duck.
