Hacker News Reader

Comment by bmitc | Hacker News Reader

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

View on HN

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.

> comparatively slow but rarely introduces bugs

If you are suggesting humans before LLMs rarely introduced bugs, you probably haven’t got the latest models to review your old code. It’s shocking how many bugs we had before but couldn’t see!

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.

Right or wrong is this the future we want? Shouldn’t we say and do something?

For instance: we have calculators. We’ve had them for decades in their “current” form more or less. They are readily accessible and far more reliable than LLM’s - if you a problem 1000 times it’ll be right 1000 times, the rare bug or glitch notwithstanding. But we still teach people basic arithmetic. We teach times tables. We didn’t just offload basic math.

I agree we don’t need to know assembly to use a computer but there is a balance here and companies do not care about a balance.

Adults can, under most circumstances, do some limited slow arithmetic but are generally piss-poor at it, notwithstanding the occasional rainman, and only rely on it in trivial matters.

You see cashiers summing groceries? Salary calculations on paper? Tax, inventory, accounting, you name it? Nobody does any of it by hand.

We most definitely offloaded basic math.

I didn’t say we were universally good at it but in many countries we are (more or less) all exposed to it and taught it in school. There is a baseline even if we are far from mastery, and frankly a cynical hand wave of “well everyone’s bad at it” is not a real argument. In the US it is very clear that people are at least exposed to it and if we weren’t we would be operating very differently. I went to dinner last night, everyone did the tips in their head right there at the table. The average person can do some simple multiplication and division in their head. It’s not a mysterious script done on a box that they repeat the output of. Most people even if they’re bad at it understand the fundamental concept and, gun to their head, could probably do a series of very basic math problems with pencil and paper.

I imagine you and most of your peers can calculate a tip or at least approximate it without pulling out their phones yes?

Analogies can be good when you're explaining something you know, but they kinda fall apart when making arguments or decisions.

How many of your friends and extended family can write hello-world or fizzbuzz in any programming language at all? Should they be allowed to vibe code apps for themselves? If they get good at vibe coding, should an employer be allowed to pay them for it?

I think we mostly DID offload basic math, for better or worse.

For software engineering I don't know the right balance.

I've used the "we mostly stopped caring about machine code generated by a compiler; maybe we should stop caring about LLM-generated code as well?" analogy myself.

But even I have to admit there's two big holes in that analogy: if I use a compiler to turn C into machine code... (a) compiler bugs are orders of magnitude rarer than LLM-generated bugs (b) my C code remains the source of truth, or at least source of intent. Whereas with LLM-generated vibecode, there's no source of truth, just an ever-evolving mudball. I (kinda?) like the ideas of "documentation as source of truth" and/or "tests as source of truth" ideas, but I don't think we're nearly at the point of viability.

TL;DR yeah I think actual understanding of what LLMs produce is gonna be important for the forseeable future

If the work can be checked by the next iteration of LLMs, does it really matter? Won't the work converge correctly?

This is just moving to a higher level of abstraction. Nowadays people don't verify the compiler generated assembly code anymore. We don't care if our source generates a few million extra instructions. Source code is just an intermediate between specs and binary at an abstraction level decided by the developer. We do requirements -> code -> assembly.

To resolve this we should aim for a new intermediate format that is more high level than source code, the generated code is too monotonic to properly review manually. Something like requirements -> detailed specs for llm -> code -> assembly . Then let one agent implement the specs and have another review it. If we stay at the current abstraction level, humans become the major bottleneck.

I think your hypothetical is incomplete. What if the person that lets go, generates more productive things then somebody understands? In this case I know a lot of ppl will value the producer of value more. I always pushed the bounds of learning more about the underlying stack or problem, and always found them in no time.

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

I like to build software products. I don’t like to build software, but it’s the only way to build software products.

“Understanding” is quite an overloaded word.

Understanding architecture, robustness, the “crumple zones” of a system? I’m all for it.

Taking three days to “understand” how postgres transactions work under the hood for your generic SaaS? Uh..

I have seen a lot(!) of the last type of “understanding” and it’s infuriating. The same types will often not understand the business, its stakeholders, the architectural constraints beyond the technical, etc. Understanding takes many forms.

I feel like the real value is in probing the extents of your own understanding. If you don't understand something it's doing, you can ask. You do kind of move up a level of abstraction, from the IC to a PM or team lead. So maybe you don't know what every line of code does but if you understand code and how to drive you can trust that it's doing the right thing and you don't have to be as deep in the weeds of every refactor etc.

You do have to keep a sense of when it did the wrong thing and how that was a valid interpretation of what you asked and how to better specify what you want. But that's how it really just shows you the gaps in your own understanding of a problem.

Also I think there's huge differences to the kinds of tasks and workloads people are throwing at it, leading to wildly different perspectives, but everyone's talking about the same "Fable".

> Also I think there's huge differences to the kinds of tasks and workloads people are throwing at it, leading to wildly different perspectives, but everyone's talking about the same "Fable".

This right here. Humans are really prone to over indexing on a handful of personal experiences vs a representative sample. And once someone has formed an opinion, confirmation bias helps cement it, despite evidence to the contrary. Reality is probably somewhere in the middle.

That's where I think benchmarks are a huge red herring. Everyone wants a simple performance evaluation of a repetitive task but that's missing the point entirely IMO. Just try talking to it, asking questions. I spend so much time just reading responses. I have to like really think about how to specify the question I'm asking, fire it off, and I often can't wait to see what it says and what I'll learn. How anyone thinks it's making us dumber is crazy to me...you're missing out if you're just trying to offload thinking.

> If you don't understanding anything, then why would anyone keep you around?

They don’t keep you around, of course. The better these models become, the worse the human job markets get, I’d predict.

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?

Reply on news.ycombinator.com