@shriramk @lindsey @cross @krismicinski @jfdm @csgordon @jeremysiek Do you think that the "no one will look at the generated code anymore" future is inevitable? Given how often the industry has tried to generate programs directly from English-like specs before and failed, I'm quite skeptical, even if we have notably different tech this time around.

Internally at Google many folks (including high-level ones) are making this claim without evidence, as if it's obvious from its face, and I'm surprised how few people push back on it or at least ask for more proof.

@shriramk @jschuster @lindsey @krismicinski @jfdm @csgordon @jeremysiek why is it a foolish position, though? (Serious question: I'm not trying to be either obtuse or confrontational). Most people don't look at the object code in an executable binary, and even most programmers have no working knowledge of an assembly language or machine's instruction set at this point.

This is something I was just thinking about while walking over to the corner store. Consider my ham radio example: I consider that a pretty impressive accomplishment, despite all the deficiencies I mentioned earlier. And while I don't think it's possible right now, it is _conceivable_ that at some point in the future, I may be able pop up one of these things and say, "rewrite the Linux kernel in Rust" and it would make a passable go at doing so.

But then it struck me, what would be the point? If the premise is that the machine is going to be able to write better code than I can, perhaps not now, but at some point in the future, then what does it matter what notation it uses to do so? The value-adds of Rust, the borrow checker and so on, are there to help human programmers. But if the machine gets good enough to work around our inability to reason about thorny concurrency issues, memory, and type safety, UB, etc, in C, and it does a better job than me _anyway_, then there's no reason to convert it to a language that's optimized for humans. Maybe that's just a big matrix of numbers; meaningful to it, but not to most of the rest of us, just as object code is not meaningful to most of us.

Surely the best course of action is to settle on something that's optimized _for the LLM_. Almost all extant programming languages seem to be optimized for the _programmer_ (not you, APL).

Perhaps this is similar to what you were referring to when you mentioned the source and intermediate languages?

@cross @shriramk @lindsey @krismicinski @jfdm @csgordon @jeremysiek My understanding is that Waterfall in the most extreme sense means you can't go back to a previous phase (hence the name waterfall: it only goes in one direction). So in a technical sense, that feedback cycle isn't taking us back to waterfall.

But will LLMs encourage a doc/spec-heavy style of development? Most people I know seem to think yes. In particular, the software architecture folks I know are excited about having a space to talk about architecture again. But what exactly those "specs" look like and how similar they will be to our current docs and specs is very much up for debate.

@shriramk @jschuster @lindsey @krismicinski @jfdm @csgordon @jeremysiek it's not meant to be exact. The point being, one develops a very thorough spec before ever attempting to generate a line of code, and spec writing becomes a major focus of the process, with a spec as one of the primary artifacts produced. I never tried Spiral (for that matter, I was never _really_ subjected to Waterfall in its full glory, either), but if you feel that fits better, good to go.

In a chat with some colleagues yesterday, most of them were saying that, when using LLMs, they're spending most of their time writing very precise specifications in the form of "prompts." I find that interesting, and very different from from the Agile world of "yolo just write some code, amirite, bruh? lmao."