[thunky]

> It's really hard to know what/how to even describe real problems to these tools

I would argue that if you can't describe the problem in plain language then you don't have a very good chance of solving it with code or otherwise.

Personally I find that the act of describing the problem will often reveal a good solution...then it's just a matter of seeing if the LLM agrees with me or if it has a difference idea (for better or worse).

[majormajor]

As software grows the problems go such that the effort to completely describe the necessary changes in plain language is often not all that much shorter than the code. Especially if you have a really really good autocomplete for the boilerplate parts of the code. So LLMs being really good at the tedious autocomplete makes LLMs have less marginal utility for the "write the whole thing" for certain types of work.

But the sneakier part of the problem is that as business rules get more complex it's usually harder to completely describe the problem in plain language than in a more formally specified language. For instance, plain-language "apply the user's promo code" doesn't capture the nasty if/else tree you might hit when you're deep in the codebase and see that there's already a bunch of restrictions on other types of promo codes and the product manager didn't think about which of those restrictions should apply to this new promo code. And at this point you're gonna need to use plain language to describe and refine the problem with the product manager - but if you instead were relying on an LLM to turn your short sentence into the right code, it might pick the wrong thing when it comes to modifying that existing code.

[thunky]

> For instance, plain-language "apply the user's promo code" doesn't capture the nasty if/else tree you might hit when you're deep in the codebase and see that there's already a bunch of restrictions on other types of promo codes and the product manager didn't think about which of those restrictions should apply to this new promo code

Sure, but you've already lost at this point. Your code is so jacked up that you can't even describe what it does in words.

Now imagine what happens when a customer calls customer service and asks why their promo code isn't working.

> And at this point you're gonna need to use plain language to describe and refine the problem with the product manager - but if you instead were relying on an LLM to turn your short sentence into the right code, it might pick the wrong thing when it comes to modifying that existing code.

I think you're agreeing with me here...

But TBH this all feels like the establishment trying to protect it's turf, which is understandable. But using the argument of "my code is so overcomplicated and confusing that nobody but me can understand it but me" probably isn't the best position to take.

[Verdex]

> ...describe the problem in plain language...

Oh, I get it. They're saying you should be able to write it in C.

[Jokes aside, I would be interested in hearing from bridge builders, aerospace engineers, or nuclear scientists. Pretty sure they're using math and not 'plain language'.]