@krismicinski @shriramk @jfdm @csgordon @lindsey @jeremysiek goodness, I hope that prompting an LLM will not be a *huge* part of software engineering going forward. It's an incredibly inefficient way to go about the task. Frankly, I'm amazed at just how shoddy the current set of tools are.
@cross @krismicinski @shriramk @jfdm @csgordon @lindsey @jeremysiek It’s amazingly depressing to me, not because I worry about AI tools making the work obsolete, but because the remarkable effectiveness of AI tools in the face of their shoddiness drives home to me that the vast majority of programmers are redoing a thing that’s already been done most of the time. What a waste of human capital.

@steve @cross @krismicinski @shriramk @jfdm @csgordon @lindsey @jeremysiek As a professional programmer now almost 20 years out from defending a thesis that was about code generation, I can't upvote this enough.

LLMs are an incredibly inefficient way to do code reuse.

@gwozniak @steve @krismicinski @shriramk @jfdm @csgordon @lindsey @jeremysiek yeah, I was going to comment that you had said something similar a few days or a week ago.

It's wild to me that we keep writing the same program over and over again and calling it "progress."

@cross @gwozniak @steve @[email protected] @jfdm @csgordon @lindsey @jeremysiek
We were already doing this. The entire low-code/no-code movement was all about making sure we stopped doing that in some domains, though we built 20+ systems that each tried to do that. (-:

@shriramk @cross @steve @krismicinski @jfdm @csgordon @lindsey @jeremysiek At a certain level I am on board for the "coding assistant" kind of approach that LLMs allow for, especially for throwaway code or prototypes in research. Hell, that's the kind of thing I was into when I was doing research. I wanted this sort of thing!

Leaving aside the major externality problems with the current tools (but please, don't ignore them), I firmly believe LLMs are deeply inefficient. To me there is an interesting research area here: what is a more efficient version that works? And why did all the "no code" approaches before not work? Is it because they tried to be formal? Or is it not a technical problem?

I guess I lied a bit because I find the inefficiency of them to be at the heart of the externality problems that come with them.

And from an industry standpoint, massive code generation is a very sharp double-edged sword. That stuff has to be maintained. So when there is a problem and you have reams of generated code to debug, do you debug it or just generate it all again? But if you do that, will it be the same as it was before? Because latent bugs often become vital features.

@shriramk @cross @steve @krismicinski @jfdm @csgordon @lindsey @jeremysiek I will say that I still don't use them because of the externality problems. I consider them too great.

Plus, I spend a lot of my time trying to make existing messes make other messes. And debugging other people's messes. So they aren't a thing that will do much for me.

@gwozniak @cross @steve @[email protected] @jfdm @csgordon @lindsey @jeremysiek
I don't disagree re. the externalities. That's why I think "open source agentic loop + open-weight models" is a useful baseline. I also think we're just at the start of this revolution — literally ~4 months in — and if the core compute becomes too expensive, great, it'll spur all kinds of other innovation outside that core. RL will only become more important, and PLs can offer amazing kinds of RL!