Verbose code can have less ambiguity than terse code.

(It's only 'can' because it's possible to make any bit of code more verbose without removing ambiguity; that's easy!)

Terse code can be precise code if the abstractions are precisely what you wanted and intended.

The magic of programming is that often those formal abstractions are good enough to capture your intent that they allow you to have extraordinary leverage with terse utterances.

But all abstractions are fundamentally leaky.

And sometimes terse code gives you a result only approximately like what you were going for, with differences that are hard to characterize or get a handle on.

Sometimes systems that allow you to express things tersely lull you into a false confidence.

"This is easy!"

"Yes, because you've punted on understanding a number of fractal complexities that will bite you hard later."

Before, all code had to be understood by humans, meaning that shorter, better factored code was strictly better.

Humans are impatient, after all, and if some other maintainer of the code has to be able to fix a bug in production when everything is on fire, being terse and easy to understand is paramount.

But LLMs are infinitely patient.

They have no problem wading through verbose details.

So maybe for domains like sync where precision of intent is important, verbose code is now more OK?

Now if humans can engage with the spec, and the spec is an accurate representation of the code and vice versa, it doesn't matter.