> Of course, at the moment everything’s still a bit very much difficult to tell, but “productivity”, at least in applicable areas of work, might really come down to who can let go of the most understanding the easiest? Incredibly thought-provoking stuff.

I cannot see it being a good thing to "let go" of understanding. If you don't understanding anything, then why would anyone keep you around? An example hypothetical situation is, if I have a colleague that outputs a bunch of productive things, but they don't understand it, and I do, then of what use are they? I have LLMs too and also have the understanding.

It isn't clear to me why people are so comfortable with letting go of understanding. And it's a bit bizarre because it always seems to be framed as "you're going to get left behind if you care about understanding". I also never hear or read anyone who has any real and deep experience say these things.

My read of what is being suggested is that the level at which one should aim to understand and be comfortable with is slightly more abstract than reading the code and reviewing every line of it. It is like how one is comfortable not understanding the byte-level code or assembly language code. I know that this analogy doesn’t hold very well because compilation is a deterministic process while llms are not, but that is precisely the point being made. “Trust” that llm will produce the right output, even though the output might not be reproducible word for word the next time you give the same prompt.

To your point about becoming redundant without understanding, not understanding things will be a problem when an issue arises and the other person isnt able to handle it the right way. However, if llm can address the issue, does the fact that they did not understand the details really matter? From the perspective of a person who gets to decide who gets fired, would they fire someone who is productive but sometimes introduces bugs that they quickly address or would they fire someone who is comparatively slow but rarely introduces bugs? The answer probably depends on the domain, and how costly a bug can be. For most of us, the work is not so critical that you cannot afford bugs. So, productivity wins.

Don't shoot the messenger, but maybe the idea is this:

You're smart, and you know what can go wrong, so you use models slowly, and you check their work. Your bet is that it will make a bad mistake.

Your coworker is reckless, they don't know or care what can go wrong, so they use models quickly. Their bet is that the model won't make a bad mistake.

If the model doesn't make a bad mistake, your coworker is creating more value to your employer, and your employer doesn't really care if you understand the code. They just want something that works.

Over the last year, it sure seems like models are making less mistakes, so the expectations on the bets are changing too.

You're misinterpreting what they mean as understanding and inserting your own doomer definition where this imagined person has been stripped of all ability to investigate a result or ask questions.

I too love to downvote and edit instead of admitting that I'm talking and acting in a way where nobody would want to be my coworker anyways. Where exactly are you demonstrating that you're doing anything to justify being kept around if that's such a big concern for you?

> It isn't clear to me why people are so comfortable with letting go of understanding.

It really does feel like people have embraced rolling around in the cognitive version of those Wall-E chairs.