Remix.run Logo
▲ msdz 2 hours ago

If you liked this phrasing as much as I did, here’s an article that might resonate a lot with you:

https://danluu.com/ambitious/

In particular, footnote eight:

> This is not a claim about the future. Perhaps almost all or perhaps even all of the software skills I have will become irrelevant in the near future. But we're not there yet. At the moment, programming skills seem higher leverage than ever before.

> There's something a bit funny about the current moment, where it seems like having the skills that models are replacing makes one much more effective than people who are trying to use models without having those skills. I like Max Bittker's framing that models are very good at counterfeiting and the level of expertise it takes to distinguish a counterfeit from the real thing has been increasing as models improve.

As well as this section fairly at the start:

> As far as I can tell, these problems are problems because people are implicitly carrying around a pre-agentic cost model. Ten years ago, the kind of person who implemented a new compiler because their compiler was slow was the kind of person who started programming a new 3d game engine when they wanted to make an indie game, i.e., the kind of person who never ships anything. Most productive programmers I know still have an aversion to this kind of thing, even though it is now actually reasonable to implement this kind of thing now.

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.

▲michaelchisari an hour ago | parent | next [-]

| the level of expertise it takes to distinguish a counterfeit from the real thing has been increasing as models improve

This is Bainbridge's 1982 paper Ironies of Automation restated.

https://en.wikipedia.org/wiki/Ironies_of_Automation

https://ckrybus.com/static/papers/Bainbridge_1983_Automatica...

▲bmitc an hour ago | parent | prev [-]

> 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.

▲fullofideas 20 minutes ago | parent | next [-]

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.

▲xscott 7 minutes ago | parent | prev | next [-]

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.

▲monster_truck an hour ago | parent | prev | next [-]

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?

▲ 10 minutes ago | parent [-]
[deleted]
▲arcticbull an hour ago | parent | prev [-]

> 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.