←back to thread

AI’s coding evolution hinges on collaboration and trust

(spectrum.ieee.org)
183 points WolfOliver | 4 comments | 29 Aug 25 15:24 UTC | HN request time: 0.753s | source
Show context
MorehouseJ09 ◴[29 Aug 25 18:09 UTC] No.45067492[source]▶
“If it takes longer to explain to the system all the things you want to do and all the details of what you want to do, then all you have is just programming by another name,”

I think this is going to make the difference between junior and senior engineers even more drastic than it is today. It's really hard to know what/how to even describe real problems to these tools, and the people who invest the most in their tooling now, are going to be most successful. It's hard for someone who hasn't designed a large codebase already to do this in an ai native way where they don't have the experience of abstracting at the right level and things like that.

Today's equivalent, I've often found some of the best engineers I know have insane setups with nvim or emacs. They invest in their tool chain, and are now bringing AI into.

replies(3): >>45067904 #>>45071016 #>>45071192 #
1. thunky ◴[30 Aug 25 00:58 UTC] No.45071016[source]▶
> 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).

replies(2): >>45071366 #>>45071896 #
2. Verdex ◴[30 Aug 25 02:16 UTC] No.45071366[source]▶
> ...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'.]

3. majormajor ◴[30 Aug 25 04:19 UTC] No.45071896[source]▶
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.

replies(1): >>45075761 #
4. thunky ◴[30 Aug 25 16:07 UTC] No.45075761[source]▶
> 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.