5 ms·

> Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP.

by senko 19d ago

> Just five years ago, the only way to build a working project of moderate complexity was to learn the basic to intermediate concepts required to make an MVP. > Now, if you can steer an LLM reasonably well, you can quickly build an MVP that goes well beyond your own understanding of the implementation. Somewhat agree. Five years ago you could build an MVP without understanding how to open TCP sockets or how to parse HTTP headers. You didn't need to understand relational databases, let alone B-trees or cache locality. You didn't need to know how to install Linux. Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster. > You have to intentionally build your understanding as you build your projects. Some things you need to understand-others, not so much. Depends on what you're doing, the scale, risks, etc, but that's always been the case.

skydhash 19d ago
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 19d 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 19d 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 19d 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_ 18d 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 18d ago
        Well said!
- falcor84 19d 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 19d 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 19d 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.
aposm 19d ago
There's a pretty significant difference there, even in some of the examples you picked to make your point. TCP and HTTP are well defined standards that, for all their flaws, were designed and conceived to be useful abstractions that you didn't need to understand deeply in order to use. The things that LLMs allow novices to skip nowadays aren't designed with that in mind, and generally aren't something you can just skip over without getting yourself into hot water later. If you mess up Stripe or Auth0 setup because you don't understand the implications of the boilerplate the LLM spit out, you can very easily get your whole app compromised or end up on the hook for a lot of fraudulent credit card charges, etc. I see the point you're making and I don't entirely disagree, but I think current iterations of LLM coding tools still make it far too easy for beginners (or even fairly experienced engineers) to convince themselves that a detail falls into the former category of abstractions they can safely skip understanding, when they're very much the latter.
- moomoo11 19d ago
  imo that’s a good thing and people will gravitate towards companies that build actually good platforms. with a bunch of competition, the best will be incentivized to not have these noob tier issues.
7speter 19d ago
>Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster. Ehhh, if you're smart you want to at the very least gloss over the details, and look at the code being generated by whatever model you're using for this solution.
musebox35 19d ago
> Some things you need to understand-others, not so much. This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished. You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language. The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now. Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.
- pferde 19d ago
  That's just it. you didn't "build so much", you didn't build anything. You asked someone (or something) to build it for you. How can people look at LLM-generated code and think "this is mine, I made this" is beyond me.
  - FuckButtons 19d ago
    I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.

by senko 19d ago

skydhash 19d ago

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 19d 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 19d 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 19d 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_ 18d 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 18d ago
      Well said!
falcor84 19d 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 19d 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 19d 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.

aposm 19d ago

There's a pretty significant difference there, even in some of the examples you picked to make your point. TCP and HTTP are well defined standards that, for all their flaws, were designed and conceived to be useful abstractions that you didn't need to understand deeply in order to use. The things that LLMs allow novices to skip nowadays aren't designed with that in mind, and generally aren't something you can just skip over without getting yourself into hot water later. If you mess up Stripe or Auth0 setup because you don't understand the implications of the boilerplate the LLM spit out, you can very easily get your whole app compromised or end up on the hook for a lot of fraudulent credit card charges, etc. I see the point you're making and I don't entirely disagree, but I think current iterations of LLM coding tools still make it far too easy for beginners (or even fairly experienced engineers) to convince themselves that a detail falls into the former category of abstractions they can safely skip understanding, when they're very much the latter.

moomoo11 19d ago
imo that’s a good thing and people will gravitate towards companies that build actually good platforms. with a bunch of competition, the best will be incentivized to not have these noob tier issues.

7speter 19d ago

>Now you don't need to understand the details of connecting to Stripe or Auth0 or setting up a Kubernetes cluster. Ehhh, if you're smart you want to at the very least gloss over the details, and look at the code being generated by whatever model you're using for this solution.

musebox35 19d ago

> Some things you need to understand-others, not so much. This is the core of the matter though, knowing what you need to understand and what you can ignore is the actual programmer's skill. It requires you to have a clear mental picture of both what you are trying to build and what the underlying machine will do when you are finished. You need to understand the abstractions, but also where they leak, when they won't match reality, and how. This is why knowing computer architecture and assembly helps you to optimize your code even if you are coding in a high level language. The problem with coding agents is that they are tuned to work on all contexts so they always fill an underspecified request by optimizing the average case and often without stating all the assumptions that they make. So you still need to understand what you specified and what got filled in automagically by the agent. My experience is that they (even the paid frontier models) are poor judges of the most important assumptions they make, which will might be corrected by a prompt or a tool output in which case it is fine. Otherwise it will be ignored and steer the model into a weird loop. It then tries to fix things but can not do so since its mental model is totally broken now. Do not get me wrong, I am so happy to let the agent handle tool building (especially those that involve a web UI) and fill in the CLI command line argument parser. But every time I trust the agent by relying on it to drive the mental model of what we are doing, I got seriously bitten. Well, maybe that should not be surprise me, but I can understand the confusion of less experienced programmers and non-coders. It must really be frustrating to be able to build so much, but also not to be able to fix seemingly small issues.

pferde 19d ago
That's just it. you didn't "build so much", you didn't build anything. You asked someone (or something) to build it for you. How can people look at LLM-generated code and think "this is mine, I made this" is beyond me.
- FuckButtons 19d ago
  I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.