3 ms·

That’s the power of abstraction when there’s a good API around something to hide the internal that doesn’t matter much at an higher level. You only need ‘open’

That’s the power of abstraction when there’s a good API around something to hide the internal that doesn’t matter much at an higher level. You only need ‘open’ and ‘read’ instead of dealing with disk access and file system trasversal. But those abstraction are deterministic in nature, so there’s a very good guarantee of their behavior. Someone using LLM and not caring about the generated code is just asking for trouble. The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).

bbmatryoshka 10d ago
non deterministic abstraction are absolutely useful, outside of software sector they have been used since the start of civilization ("a worker" is a very very non deterministic abstraction, outside from the most basic tasks)
- skydhash 10d ago
  I’m sure that in every case where there such non deterministic abstraction, it’s been always statistically or with a lot of hand waving. So with a heavy dose of expected errors. Pro LLM users don’t want to talk about the error margins of whatever practice or product they’re putting out.
- juvvel 10d ago
  > "a worker" is a very very non deterministic abstraction, outside from the most basic tasks Sure but we (usually) don't fool ourselves into believing otherwise. The problem with AI is that it suggests near-perfect intelligence with reproducible results. So many people are not acknowledging the fundamental limitations of LLMs, whereas we all have an intuition for the limitations of humans.
  - Terr_ 10d ago
    In addition to the reliability/security aspect, there's the claim to expertise and unwarranted confidence. We also don't (usually) fool ourselves into believing that the manager has gained the skills and expertise of the worker, simply because they gave abstract orders and a good result was achieved. In other words, "I can code because I prompt an LLM" is like "I can do metalworking because I sign the paychecks of a blacksmith."
    - juvvel 9d ago
      Well said!
falcor84 10d ago
> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases). But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden. My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
- trey-jones 10d ago
  This is exactly true in my experience. I find myself trusting the LLM better than I ever trusted a development team to deliver accurate work. Just like you would managing a team of junior developers, you have to keep an eye on the output, but I think the agent is more transparent about that than your team would be. And it works faster, and you don't have to deal with emotional meltdown or active sabotage if you criticize in the wrong way. The trick for the guy controlling the agent is to know about the gotchas that one would normally encounter when doing the work. Asking the right questions and mentioning the right things to pay extra attention to can make all the difference. I think that's why it will be much more difficult for people to learn how to make software now. Those of us who have been doing it for years and years have experience that is valuable in steering the LLM. It will be hard for people new to software to get that same experience. But then things are changing so quickly right now, everything I just wrote my be irrelevant in a week.
  - skydhash 10d ago
    > find myself trusting the LLM better than I ever trusted a development team to deliver accurate work That’s the main issue. You’re talking about the development side guarante, while the most important is the user side guarantee. There’s a lot of talk about liking LLM interaction, but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets. Which is why the most enthusiastic comments are about projects not released yet. Greenfield and released projects are different.

bbmatryoshka 10d ago

non deterministic abstraction are absolutely useful, outside of software sector they have been used since the start of civilization ("a worker" is a very very non deterministic abstraction, outside from the most basic tasks)

skydhash 10d ago
I’m sure that in every case where there such non deterministic abstraction, it’s been always statistically or with a lot of hand waving. So with a heavy dose of expected errors. Pro LLM users don’t want to talk about the error margins of whatever practice or product they’re putting out.
juvvel 10d ago
> "a worker" is a very very non deterministic abstraction, outside from the most basic tasks Sure but we (usually) don't fool ourselves into believing otherwise. The problem with AI is that it suggests near-perfect intelligence with reproducible results. So many people are not acknowledging the fundamental limitations of LLMs, whereas we all have an intuition for the limitations of humans.
- Terr_ 10d ago
  In addition to the reliability/security aspect, there's the claim to expertise and unwarranted confidence. We also don't (usually) fool ourselves into believing that the manager has gained the skills and expertise of the worker, simply because they gave abstract orders and a good result was achieved. In other words, "I can code because I prompt an LLM" is like "I can do metalworking because I sign the paychecks of a blacksmith."
  - juvvel 9d ago
    Well said!

falcor84 10d ago

> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases). But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden. My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".

trey-jones 10d ago
This is exactly true in my experience. I find myself trusting the LLM better than I ever trusted a development team to deliver accurate work. Just like you would managing a team of junior developers, you have to keep an eye on the output, but I think the agent is more transparent about that than your team would be. And it works faster, and you don't have to deal with emotional meltdown or active sabotage if you criticize in the wrong way. The trick for the guy controlling the agent is to know about the gotchas that one would normally encounter when doing the work. Asking the right questions and mentioning the right things to pay extra attention to can make all the difference. I think that's why it will be much more difficult for people to learn how to make software now. Those of us who have been doing it for years and years have experience that is valuable in steering the LLM. It will be hard for people new to software to get that same experience. But then things are changing so quickly right now, everything I just wrote my be irrelevant in a week.
- skydhash 10d ago
  > find myself trusting the LLM better than I ever trusted a development team to deliver accurate work That’s the main issue. You’re talking about the development side guarante, while the most important is the user side guarantee. There’s a lot of talk about liking LLM interaction, but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets. Which is why the most enthusiastic comments are about projects not released yet. Greenfield and released projects are different.