4 ms·

I think this expresses what I've been trying to form in my mind. I've been trying to map the LLM advancements and the current state of software development ont

I think this expresses what I've been trying to form in my mind. I've been trying to map the LLM advancements and the current state of software development onto prior technological improvements. History is littered with similar cases where the abstraction layer ends up getting lifted, and people struggle with getting accustomed to working at that higher abstraction level. For the people that fall in love with a single abstraction layer or don't have an interest in learning new paradigms, when their known pattern is abstracted away, they're condemned to being left behind, either unwilling or unable to adapt. I don't think any industry is free from this, any person in any industry/profession over a period of 20 years or more has likely had to undergo massive adjustments as technology changed their field. We're not unique, but that doesn't stop it from feeling so jarring when it happens to us

skydhash 1mo ago
> History is littered with similar cases where the abstraction layer ends up getting lifted, and people struggle with getting accustomed to working at that higher abstraction level. But there's no abstraction layer that ends up getting lifted. When I use a library like SDL or a standard like POSIX, I don't tend to look at the underlying implementation. Instead I work with the high level concepts that they come up with. There's no such things with AI tooling. The most similar is when fully vibing software and everyone knows the quality of the result. I've learned something at every abstraction layer in computing from electronics (hardware), theory of computation (software) to high level programming languages with their paradigms. Same with several domains embodied by libraries. LLM tooling is more like shamanic ritual than engineering.
- WarmWash 1mo ago
  >and everyone knows the quality of the result. Yeah, a bespoke program that does exactly what I need it to do, at a speed that I had forgotten was possible on computers, with customization that is an exact fit to me, at a cost that is smaller than a rounding error. I get that LLMs struggle with the old paradigm of a single piece of software meant to serve every conceivable use case of every conceivable user, but I kinda hope that paradigm dies.
- _aavaa_ 1mo ago
  > There's no such things with AI tooling. The most similar is when fully vibing software and everyone knows the quality of the result. This is the same “but the ai can’t even do fingers” argument all over again, and it will age just a well. The whole vibe coding thing only really started taking hold with the release of opus 4.5. That wasn’t even a year ago. you absolutely can be quality software without looking at the code. The only thing up for debate in my mind is how big that software can get before you need to look under the hood. But that’s dictated by current model capabilities. And I don’t see any reason to believe that they will suddenly stop improving on this front.
- esafak 1mo ago
  With AI you learn contributor, project, and product management.
- DanHulton 1mo ago
  Exactly this. You still have to understand the abstraction layer the LLM is working at in order to be able to form an opinion about the quality of the code. (If you DON’T care about the quality of the code, there’s always been ways to get an extra 1000% short-term speed improvement by just not giving a shit.) AI isn’t “a code abstraction layer” any more than Jira is, or the engineer themselves is.
  - massagedpelican 1mo ago
    I think "the engineer themselves" is much closer to the abstraction layer I'm referring to. Imagine for a moment that, rather than using a compiler to translate c++ into assembly, that it instead has to be done by a person on the team. If that were the case, the resulting assembly code would certainly have to be reviewed and assessed before it was accepted. Why? Because people can also be leaky, non-deterministic abstraction layers. The only reason that the output of a compiler isn't regularly reviewed (in 99% of cases) is because it's extraordinarily reliable and consistently correct, or correct enough for most cases. It's not terribly dissimilar from delegating engineering tasks to other engineers. When I ask someone else to develop one component of a larger application, I'm not telling them exactly what lines to write, I'm giving them some kind of structure and they're filling in the rest. The communication to them is above the implementation layer. Agents are increasingly letting us work at that same boundary. Just because the current state of LLMs requires engineering knowledge to review the result doesn't mean an abstraction hasn't occurred. It speaks more to the current quality of that abstraction than the absence of one. I think that if LLMs were able to achieve the same consistency as a compiler, most people wouldn't ever bother to check the underlying code it produced. I also think it would be difficult to not acknowledge that LLMs have gotten better at converting natural language into functioning software. The abstraction is certainly not perfect, but it is clearly improving.

skydhash 1mo ago

> History is littered with similar cases where the abstraction layer ends up getting lifted, and people struggle with getting accustomed to working at that higher abstraction level. But there's no abstraction layer that ends up getting lifted. When I use a library like SDL or a standard like POSIX, I don't tend to look at the underlying implementation. Instead I work with the high level concepts that they come up with. There's no such things with AI tooling. The most similar is when fully vibing software and everyone knows the quality of the result. I've learned something at every abstraction layer in computing from electronics (hardware), theory of computation (software) to high level programming languages with their paradigms. Same with several domains embodied by libraries. LLM tooling is more like shamanic ritual than engineering.

WarmWash 1mo ago
>and everyone knows the quality of the result. Yeah, a bespoke program that does exactly what I need it to do, at a speed that I had forgotten was possible on computers, with customization that is an exact fit to me, at a cost that is smaller than a rounding error. I get that LLMs struggle with the old paradigm of a single piece of software meant to serve every conceivable use case of every conceivable user, but I kinda hope that paradigm dies.
_aavaa_ 1mo ago
> There's no such things with AI tooling. The most similar is when fully vibing software and everyone knows the quality of the result. This is the same “but the ai can’t even do fingers” argument all over again, and it will age just a well. The whole vibe coding thing only really started taking hold with the release of opus 4.5. That wasn’t even a year ago. you absolutely can be quality software without looking at the code. The only thing up for debate in my mind is how big that software can get before you need to look under the hood. But that’s dictated by current model capabilities. And I don’t see any reason to believe that they will suddenly stop improving on this front.
esafak 1mo ago
With AI you learn contributor, project, and product management.
DanHulton 1mo ago
Exactly this. You still have to understand the abstraction layer the LLM is working at in order to be able to form an opinion about the quality of the code. (If you DON’T care about the quality of the code, there’s always been ways to get an extra 1000% short-term speed improvement by just not giving a shit.) AI isn’t “a code abstraction layer” any more than Jira is, or the engineer themselves is.
- massagedpelican 1mo ago
  I think "the engineer themselves" is much closer to the abstraction layer I'm referring to. Imagine for a moment that, rather than using a compiler to translate c++ into assembly, that it instead has to be done by a person on the team. If that were the case, the resulting assembly code would certainly have to be reviewed and assessed before it was accepted. Why? Because people can also be leaky, non-deterministic abstraction layers. The only reason that the output of a compiler isn't regularly reviewed (in 99% of cases) is because it's extraordinarily reliable and consistently correct, or correct enough for most cases. It's not terribly dissimilar from delegating engineering tasks to other engineers. When I ask someone else to develop one component of a larger application, I'm not telling them exactly what lines to write, I'm giving them some kind of structure and they're filling in the rest. The communication to them is above the implementation layer. Agents are increasingly letting us work at that same boundary. Just because the current state of LLMs requires engineering knowledge to review the result doesn't mean an abstraction hasn't occurred. It speaks more to the current quality of that abstraction than the absence of one. I think that if LLMs were able to achieve the same consistency as a compiler, most people wouldn't ever bother to check the underlying code it produced. I also think it would be difficult to not acknowledge that LLMs have gotten better at converting natural language into functioning software. The abstraction is certainly not perfect, but it is clearly improving.