9 ms·

We're just moving up the abstraction ladder, like we did with compilers. I don't care about the individual lines of code, I care about architecture, code struc

We're just moving up the abstraction ladder, like we did with compilers. I don't care about the individual lines of code, I care about architecture, code structure, rigorous automated e2e tests, contracts with comprehensive validation, etc. Rather than waste a bunch of time pouring over agent PRs I just make them jump over extremely high static/analytic hurdles that guarantee functionality, then my only job is to identify places where the current spec and the intended functionality differ and create a new spec to mitigate.

blibble 1y ago
I can count the amount of times in my 20 year career that I've had to look at compiler generated assembly on one finger and I've never looked at the machine code produced by an assembler (other than when I wrote my own as a toy project) is the same true of LLM usage? absolutely not and it never will be, because it's not an abstraction
- elAhmo 1y ago
  It is an abstraction. Just because you end up looking at what the prompt looks like “under the hood” in whichever language it produced the output, doesn’t mean every user does. Similar as with assembly, you might have not taken a look at it, but there are people that do and could argue the same thing as you. The lines will be very blurry in the near future.
  - card_zero 1y ago
    I can fart in the general direction of the code and that's a kind of abstraction too. It distills my intent down to a simple raspberry noise which could then be interpreted by sufficiently intelligent software.
    - joenot443 1y ago
      Sort of like when people argue about "what is art?", some folks find it clever to come up with the most bizarre of examples to point to, as if the entire concept rests on the existence of its members at the fringe. Personally, I think if your farts are an abstraction that you can derive useful meaning from the mapping, who are we to tell you no?
      - card_zero 1y ago
        So, can derive useful meaning from is the point of contention. (Also: bizarre examples = informative edge cases. Sometimes.)
    - chaps 1y ago
      Could you please expand on this thought? I'm curious where this abstraction's inflection points are.
    - Phemist 1y ago
      The final result of course depending on how many r's there are in the raspberry.
  - rsynnott 1y ago
    > Just because you end up looking at what the prompt looks like “under the hood” in whichever language it produced the output, doesn’t mean every user does. > Similar as with assembly, you might have not taken a look at it, but there are people that do and could argue the same thing as you. ... No. The assembler is deterministic. Barring bugs, you can basically trust that it does exactly what it was told to. You absolutely cannot say the same of our beloved robot overlords.
- joenot443 1y ago
  "SwiftUI red circle with a white outline 100px" ``` Circle() .fill(Color.red) .overlay( Circle().stroke(Color.white, lineWidth: 4) ).frame(width: 100, height: 100) ``` Is the mapping 1:1 and completely lossless? Of course not, I'd say the former is most definitely a sort of abstraction of the latter, and one would be being disingenuous to pretend it's not.
- KoolKat23 1y ago
  It's still early stages, that is why. It is not yet good enough or there is not yet sufficient trust. Also there are still resources allocated to checking the code. I saw a post yesterday showing Brave browser's new tab using 70mb of RAM in the background. I'm very sure there's code there that can be optimized, but who gives a shit. It's splitting hairs and our computers are powerful enough now that it doesn't matter. Immateriality has abstracted that particular few line codes away.
  - rafterydj 1y ago
    I feel like I'm taking crazy pills or misunderstanding you. Shouldn't it matter that they are using 70mb of RAM more or less totally wastefully? Maybe not a deal breaker for Brave, sure, but waste is waste. I understand the world is about compromises, but all the gains of essentially every computer program ever could be summed up by accumulation of small optimizations. Likewise, the accumulation of small wastes kills legacy projects more than anything else.
    - KoolKat23 1y ago
      Yes it can be construed as wasteful. But it's exactly that, a compromise. Could the programmer spend their time better elsewhere generating better value, not doing so is also wasteful. Supply and demand will decide what compromise is acceptable and what that compromise looks like.
    - Mtinie 1y ago
      It could matter but what isn't clear to me is if 70MB is wasteful in this specific context. Maybe? Maybe not? Flagging something as potentially problematic is useful but without additional information related to the tradeoffs being made this may be an optimized way to do whatever Brave is doing which requires the 70MB of RAM. Perhaps the non-optimal way it was previously doing it required 250MB of RAM and this is a significant improvement.
      - deleted 1y ago
        [deleted]
- CuriouslyC 1y ago
  I like to think of it as a duck-typed abstraction. I have formal specs which guarantee certain things about my software, and the agent has to satisfy those (including performance, etc). Given that, the code the agent generates is essentially fungible in the manner of machine code.
  - sarchertech 1y ago
    Only if you can write specs precisely enough. For those of us who remember the way software used to be built, we learned that this is basically impossible and that English is a terrible language to even attempt it in. If you do make your specs precise enough, such that 2 different dev shops will produce functionally equivalent software, your specs are equivalent to code.
    - CuriouslyC 1y ago
      This is doable, I have a multi-stage process that makes it pretty reliable. Stage 1 is ideation, this can be with a LLM or humans, w/e, you just need a log. Stage 2 is conversion of that ideation log to a simple spec format that LLMs can write easily called SRF, which is fenced inside a nice markdown document humans can read and understand. You can edit that SRF if desired, have a conversation with the agent about it to get them to massage it, or just have your agent feed it into a tool I wrote which takes a SRF and converts it to a CUE with full formal validation and lots of other nice features. The value of this is that FOR FREE you can get comprehensive test defintions (unit+e2e), kube/terraform infra setup, documentation stubs, openai specs, etc. It's seriously magical.
      - sarchertech 1y ago
        Imagine that when you deploy you have an LLM that regenerates code based on your specs, since code is fungible as long as it fits the spec. Keeping in mind that I have seen hundreds to thousands of production errors in applications with very high coverage test suites? How many production errors would you expect to see over 5 years of LLM deployments.
- theptip 1y ago
  > and it never will be The only thing I’m certain of is that you’re highly overconfident. I’m sure plenty of assembly gurus said the same of the first compilers. > because it's not an abstraction This just seems like a category error. A human is not an abstraction, yet they write code and produce value. An IDE is a tool not an abstraction, yet they make humans more productive. When I talk about moving up the levels of abstraction I mean: taking on more abstract/less-concrete tasks. Instead of “please wire up login for our new prototype” it might be “please make the prototype fully production-ready, figure out what is needed” or even “please ship a new product to meet customer X’s need”.
  - sarchertech 1y ago
    >“please ship a new product to meet customer X’s need” The customer would just ask the AI directly to meet their needs. They wouldn’t purchase the product from you.
aprilthird2021 1y ago
> We're just moving up the abstraction ladder, like we did with compilers. We're not because you have to still check every outputted code. You didn't have to check every compilation step of a compiler. It was testable actual code, not non-deterministic output from English language input
- pessimizer 1y ago
  > We're not because you have to still check every outputted code. To me, that's what makes it an abstraction layer, rather than just a servant or an employee. You have to break your entire architecture into units small enough that you know you can coax the machine to output good code for. The AI can't be trusted as far as you can throw it, but the distance from you to how far you can throw is the abstraction layer. An employee you can just tell to make it work, they'll kill themselves trying to do it, or be replaced if they don't; eventually something will work, and you'll take all the credit for it. AI is not experimenting, learning and growing, it stays stupid. The longer it thinks, the wronger it thinks. You deserve the credit (and the ridicule) for everything it does that you put your name on. ----- edit: and this thread seems to think that you don't have to check what your high level abstraction is doing. That's probably why most programs run like crap. You can't expect something you do in e.g. python to do the most algorithmically sensible thing, even if you wrote the algorithm just like the textbook said. It may make weird choices (maybe optimal for the general case, but horrifically bad for yours) that mean that it's not really running your cute algorithm at all, or maybe your cute algorithm is being starved by another thread that you have no idea why it would be dependent on. It may have made correct choices when you started writing, then decided to make wrong choices after a minor patch version change. To pretend perfection is a necessary condition for abstraction is not even somebody would say directly. Never. All we talk about is leaky abstractions. Remember when GTA loading times, which (a counterfactual because we'll never know) probably decimated sales, playtime, and at least the marketing of the game, turned out to be because they were scanning some large, unnecessary json array (iirc) hundreds of times a second? That's probably a billion dollar mistake. Just because some function that was being blindly called was not ever reexamined, and because nobody profiled properly (i.e. checked the output.)
- elAhmo 1y ago
lr4444lr 1y ago
I'd be very cautious about calling LLM output "an abstraction layer" in software.
bgwalter 1y ago
Compilers are sound abstractions. CompCert is literally a proven compiler. LLMs make up whatever they feel like and are pretty bad at architecture as well.
matthewdgreen 1y ago
It is possible to use LLMs this way. If you're careful. But at every place where you can use LLMs to outsource mechanical tasks, there will also be a temptation to outsource the full stack of conceptual tasks that allow you to be part of what's going on. This will create gaps where you're not sitting at any level of the abstraction hierarchy, you're just skipping parts of the system. That temptation will be greater for less experienced people, and for folks still learning the field. That's what I'm scared about.
e3bc54b2 1y ago
As the other comment said, LLMs are not an abstraction. An abstraction is a deterministic, pure function, than when given A always returns B. This allows the consumer to rely on the abstraction. This reliance frees up the consumer from having to implement the A->B, thus allowing it to move up the ladder. LLMs, by their very nature are probabilistic. Probabilistic is NOT deterministic. Which means the consumer is never really sure if given A the returned value is B. Which means the consumer now has to check if the returned value is actually B, and depending on how complex A->B transformation is, the checking function is equivalent in complexity as implementing the said abstraction in the first place.
- stuartjohnson12 1y ago
  It's delegation then. We can use different words if you like (and I'm not convinced that delegation isn't colloquially a form of abstraction) but you can't control the world by controlling the categories.
  - robenkleene 1y ago
    One argument for abstraction being different from delegation, is when a programmer uses an abstraction, I'd expect the programmer to be able to work without the abstraction, if necessary, and also be able to build their own abstractions. I wouldn't have that expectation with delegation.
    - Jensson 1y ago
      > I wouldn't have that expectation with delegation. Managers tend to hire sub managers to manage their people. You can see this with LLM as well, people see "Oh this prompting is a lot of work, lets make the LLM prompt the LLM".
      - robenkleene 1y ago
        Note, I'm not saying there are never situations where you'd delegate something that you can do yourself (the whole concept of apprenticeship is based on doing just that). Just that it's not an expectation, e.g., you don't expect a CEO to be able to do the CTO's job. I guess I'm not 100% sure I agree with my original point though, should a programmer working on JavaScript for a website's frontend be able to implement a browser engine. Probably not, but the original point I was trying to make is I would expect a programmer working on a browser engine to be able to re-implement any abstractions that they're using in their day-to-day work if necessary.
__loam 1y ago
Leakiest abstraction of all time.
chii 1y ago
> my only job is to identify places where the current spec and the intended functionality differ and create a new spec to mitigate. and to be able to do this efficiently or even "correctly", you'd need to have had mountains of experience evaluating an implementation, and be able to imagine the consequences of that implementation against the desired outcome. Doing this requires experience that would get eroded by the use of an LLM. It's very similar to higher level maths (stuff like calculus) being much more difficult if you had poor arithmetic/algebra skills.
- CuriouslyC 1y ago
  Would that experience get eroded though? LLMs let me perform experiments (including architecture/system level) quickly, and build stress test/benchmark/etc harnesses quickly to evaluate those experiments, so in the time you can build human intuition with one experiment I've done 10. I build less intuition from each experiment, but I'm building broader intuition, and if I choose a bad experiment it's a small cost, but choosing a bad experiment and performing it manually is brutal.
  - jplusequalt 1y ago
    >Would that experience get eroded though? Yes. If you stop doing something, you get worse at it. There is literally no exception to this that I'm aware of. In the future where everyone is dependent on ever larger amounts of code, the possibility that nobody will be equipped to write/debug that code should scare you.
    - CuriouslyC 1y ago
      The amount of weightlifting a strength athlete needs to do to stay near their peak (but outside medal range) is ~15% of a full training workload. People can play instruments once a month and still be exceptional once the pathways are set down. Are you getting slightly worse at direct code jockeying? Sure, but not a lot, and you're getting superpowers in exchange.
      - 1y ago
notTooFarGone 1y ago
If you had google maps and you knew the directions it gives are 80% gonna be correct, would you still need navigation skills? You could also tweak it by going like "Lead me to the US" -> "Lead me to the state of New York" -> "Lead me to New York City" -> "Lead me to Manhattan" -> "Lead me to the museum of new arts" and it would give you 86% accurate directions, would you still need to be able to navigate? How about when you go over roads that are very frequently used you push to 92% accuracy, would you still need to be able to navigate? Yes of course because in 1/10 trips you'd get fucking lost. My point is: unless you get to that 99% mark, you still need the underlying skill and the abstraction is only a helper and always has to be checked by someone who has that underlying skill. I don't see LLMs as that 99% solution in the next years to come.
bdhcuidbebe 1y ago
> We're just moving up the abstraction ladder, like we did with compilers. Got any studies about reasoning decline from using compilers to go with your claim?
MobiusHorizons 1y ago
At some point details _will_ matter. Usually when you don't want them to like during an outage, or at a very late stage blocker on an already delayed project. What you don't understand, you can't plan for.
soraminazuki 1y ago
That's untrue, as many others have pointed out. Furthermore, compilers don't cause the kind of cognitive decline that's shown in the study.
soraminazuki 1y ago
Why is every discussion about AI like this? We get study after study and example after example showing that AI is unreliable [1], hurts productivity [2], and causes cognitive decline [3]. Yet, time and time again, a group of highly motivated individuals show up and dismiss these findings, not with counter-evidence, but through sheer sophistry. Heck, this is a thread meant to discuss evidence about LLM reliance contributing to cognitive decline. Instead, the conversation quickly derailed into an absurd debate about whether AI coding tools resemble compilers. It's exhausting. [1]: https://arxiv.org/abs/2401.11817 https://arxiv.org/abs/2401.11817 [2]: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... [3]: https://publichealthpolicyjournal.com/mit-study-finds-artificial-intelligence-use-reprograms-the-brain-leading-to-cognitive-decline/ https://publichealthpolicyjournal.com/mit-study-finds-artifi...
rkagerer 1y ago
Good luck once you find out how impossible it is to maintain all that AI generated slop, over the long term.

blibble 1y ago

I can count the amount of times in my 20 year career that I've had to look at compiler generated assembly on one finger and I've never looked at the machine code produced by an assembler (other than when I wrote my own as a toy project) is the same true of LLM usage? absolutely not and it never will be, because it's not an abstraction

elAhmo 1y ago
It is an abstraction. Just because you end up looking at what the prompt looks like “under the hood” in whichever language it produced the output, doesn’t mean every user does. Similar as with assembly, you might have not taken a look at it, but there are people that do and could argue the same thing as you. The lines will be very blurry in the near future.
- card_zero 1y ago
  I can fart in the general direction of the code and that's a kind of abstraction too. It distills my intent down to a simple raspberry noise which could then be interpreted by sufficiently intelligent software.
  - joenot443 1y ago
    Sort of like when people argue about "what is art?", some folks find it clever to come up with the most bizarre of examples to point to, as if the entire concept rests on the existence of its members at the fringe. Personally, I think if your farts are an abstraction that you can derive useful meaning from the mapping, who are we to tell you no?
    - card_zero 1y ago
      So, can derive useful meaning from is the point of contention. (Also: bizarre examples = informative edge cases. Sometimes.)
  - chaps 1y ago
    Could you please expand on this thought? I'm curious where this abstraction's inflection points are.
  - Phemist 1y ago
    The final result of course depending on how many r's there are in the raspberry.
- rsynnott 1y ago
  > Just because you end up looking at what the prompt looks like “under the hood” in whichever language it produced the output, doesn’t mean every user does. > Similar as with assembly, you might have not taken a look at it, but there are people that do and could argue the same thing as you. ... No. The assembler is deterministic. Barring bugs, you can basically trust that it does exactly what it was told to. You absolutely cannot say the same of our beloved robot overlords.
joenot443 1y ago
"SwiftUI red circle with a white outline 100px" ``` Circle() .fill(Color.red) .overlay( Circle().stroke(Color.white, lineWidth: 4) ).frame(width: 100, height: 100) ``` Is the mapping 1:1 and completely lossless? Of course not, I'd say the former is most definitely a sort of abstraction of the latter, and one would be being disingenuous to pretend it's not.
KoolKat23 1y ago
It's still early stages, that is why. It is not yet good enough or there is not yet sufficient trust. Also there are still resources allocated to checking the code. I saw a post yesterday showing Brave browser's new tab using 70mb of RAM in the background. I'm very sure there's code there that can be optimized, but who gives a shit. It's splitting hairs and our computers are powerful enough now that it doesn't matter. Immateriality has abstracted that particular few line codes away.
- rafterydj 1y ago
  I feel like I'm taking crazy pills or misunderstanding you. Shouldn't it matter that they are using 70mb of RAM more or less totally wastefully? Maybe not a deal breaker for Brave, sure, but waste is waste. I understand the world is about compromises, but all the gains of essentially every computer program ever could be summed up by accumulation of small optimizations. Likewise, the accumulation of small wastes kills legacy projects more than anything else.
  - KoolKat23 1y ago
    Yes it can be construed as wasteful. But it's exactly that, a compromise. Could the programmer spend their time better elsewhere generating better value, not doing so is also wasteful. Supply and demand will decide what compromise is acceptable and what that compromise looks like.
  - Mtinie 1y ago
    It could matter but what isn't clear to me is if 70MB is wasteful in this specific context. Maybe? Maybe not? Flagging something as potentially problematic is useful but without additional information related to the tradeoffs being made this may be an optimized way to do whatever Brave is doing which requires the 70MB of RAM. Perhaps the non-optimal way it was previously doing it required 250MB of RAM and this is a significant improvement.
    - deleted 1y ago
      [deleted]
CuriouslyC 1y ago
I like to think of it as a duck-typed abstraction. I have formal specs which guarantee certain things about my software, and the agent has to satisfy those (including performance, etc). Given that, the code the agent generates is essentially fungible in the manner of machine code.
- sarchertech 1y ago
  Only if you can write specs precisely enough. For those of us who remember the way software used to be built, we learned that this is basically impossible and that English is a terrible language to even attempt it in. If you do make your specs precise enough, such that 2 different dev shops will produce functionally equivalent software, your specs are equivalent to code.
  - CuriouslyC 1y ago
    This is doable, I have a multi-stage process that makes it pretty reliable. Stage 1 is ideation, this can be with a LLM or humans, w/e, you just need a log. Stage 2 is conversion of that ideation log to a simple spec format that LLMs can write easily called SRF, which is fenced inside a nice markdown document humans can read and understand. You can edit that SRF if desired, have a conversation with the agent about it to get them to massage it, or just have your agent feed it into a tool I wrote which takes a SRF and converts it to a CUE with full formal validation and lots of other nice features. The value of this is that FOR FREE you can get comprehensive test defintions (unit+e2e), kube/terraform infra setup, documentation stubs, openai specs, etc. It's seriously magical.
    - sarchertech 1y ago
      Imagine that when you deploy you have an LLM that regenerates code based on your specs, since code is fungible as long as it fits the spec. Keeping in mind that I have seen hundreds to thousands of production errors in applications with very high coverage test suites? How many production errors would you expect to see over 5 years of LLM deployments.
theptip 1y ago
> and it never will be The only thing I’m certain of is that you’re highly overconfident. I’m sure plenty of assembly gurus said the same of the first compilers. > because it's not an abstraction This just seems like a category error. A human is not an abstraction, yet they write code and produce value. An IDE is a tool not an abstraction, yet they make humans more productive. When I talk about moving up the levels of abstraction I mean: taking on more abstract/less-concrete tasks. Instead of “please wire up login for our new prototype” it might be “please make the prototype fully production-ready, figure out what is needed” or even “please ship a new product to meet customer X’s need”.
- sarchertech 1y ago
  >“please ship a new product to meet customer X’s need” The customer would just ask the AI directly to meet their needs. They wouldn’t purchase the product from you.

aprilthird2021 1y ago

> We're just moving up the abstraction ladder, like we did with compilers. We're not because you have to still check every outputted code. You didn't have to check every compilation step of a compiler. It was testable actual code, not non-deterministic output from English language input

pessimizer 1y ago
> We're not because you have to still check every outputted code. To me, that's what makes it an abstraction layer, rather than just a servant or an employee. You have to break your entire architecture into units small enough that you know you can coax the machine to output good code for. The AI can't be trusted as far as you can throw it, but the distance from you to how far you can throw is the abstraction layer. An employee you can just tell to make it work, they'll kill themselves trying to do it, or be replaced if they don't; eventually something will work, and you'll take all the credit for it. AI is not experimenting, learning and growing, it stays stupid. The longer it thinks, the wronger it thinks. You deserve the credit (and the ridicule) for everything it does that you put your name on. ----- edit: and this thread seems to think that you don't have to check what your high level abstraction is doing. That's probably why most programs run like crap. You can't expect something you do in e.g. python to do the most algorithmically sensible thing, even if you wrote the algorithm just like the textbook said. It may make weird choices (maybe optimal for the general case, but horrifically bad for yours) that mean that it's not really running your cute algorithm at all, or maybe your cute algorithm is being starved by another thread that you have no idea why it would be dependent on. It may have made correct choices when you started writing, then decided to make wrong choices after a minor patch version change. To pretend perfection is a necessary condition for abstraction is not even somebody would say directly. Never. All we talk about is leaky abstractions. Remember when GTA loading times, which (a counterfactual because we'll never know) probably decimated sales, playtime, and at least the marketing of the game, turned out to be because they were scanning some large, unnecessary json array (iirc) hundreds of times a second? That's probably a billion dollar mistake. Just because some function that was being blindly called was not ever reexamined, and because nobody profiled properly (i.e. checked the output.)
elAhmo 1y ago

lr4444lr 1y ago

I'd be very cautious about calling LLM output "an abstraction layer" in software.

bgwalter 1y ago

Compilers are sound abstractions. CompCert is literally a proven compiler. LLMs make up whatever they feel like and are pretty bad at architecture as well.

matthewdgreen 1y ago

It is possible to use LLMs this way. If you're careful. But at every place where you can use LLMs to outsource mechanical tasks, there will also be a temptation to outsource the full stack of conceptual tasks that allow you to be part of what's going on. This will create gaps where you're not sitting at any level of the abstraction hierarchy, you're just skipping parts of the system. That temptation will be greater for less experienced people, and for folks still learning the field. That's what I'm scared about.

e3bc54b2 1y ago

As the other comment said, LLMs are not an abstraction. An abstraction is a deterministic, pure function, than when given A always returns B. This allows the consumer to rely on the abstraction. This reliance frees up the consumer from having to implement the A->B, thus allowing it to move up the ladder. LLMs, by their very nature are probabilistic. Probabilistic is NOT deterministic. Which means the consumer is never really sure if given A the returned value is B. Which means the consumer now has to check if the returned value is actually B, and depending on how complex A->B transformation is, the checking function is equivalent in complexity as implementing the said abstraction in the first place.

stuartjohnson12 1y ago
It's delegation then. We can use different words if you like (and I'm not convinced that delegation isn't colloquially a form of abstraction) but you can't control the world by controlling the categories.
- robenkleene 1y ago
  One argument for abstraction being different from delegation, is when a programmer uses an abstraction, I'd expect the programmer to be able to work without the abstraction, if necessary, and also be able to build their own abstractions. I wouldn't have that expectation with delegation.
  - Jensson 1y ago
    > I wouldn't have that expectation with delegation. Managers tend to hire sub managers to manage their people. You can see this with LLM as well, people see "Oh this prompting is a lot of work, lets make the LLM prompt the LLM".
    - robenkleene 1y ago
      Note, I'm not saying there are never situations where you'd delegate something that you can do yourself (the whole concept of apprenticeship is based on doing just that). Just that it's not an expectation, e.g., you don't expect a CEO to be able to do the CTO's job. I guess I'm not 100% sure I agree with my original point though, should a programmer working on JavaScript for a website's frontend be able to implement a browser engine. Probably not, but the original point I was trying to make is I would expect a programmer working on a browser engine to be able to re-implement any abstractions that they're using in their day-to-day work if necessary.

__loam 1y ago

Leakiest abstraction of all time.

chii 1y ago

> my only job is to identify places where the current spec and the intended functionality differ and create a new spec to mitigate. and to be able to do this efficiently or even "correctly", you'd need to have had mountains of experience evaluating an implementation, and be able to imagine the consequences of that implementation against the desired outcome. Doing this requires experience that would get eroded by the use of an LLM. It's very similar to higher level maths (stuff like calculus) being much more difficult if you had poor arithmetic/algebra skills.

CuriouslyC 1y ago
Would that experience get eroded though? LLMs let me perform experiments (including architecture/system level) quickly, and build stress test/benchmark/etc harnesses quickly to evaluate those experiments, so in the time you can build human intuition with one experiment I've done 10. I build less intuition from each experiment, but I'm building broader intuition, and if I choose a bad experiment it's a small cost, but choosing a bad experiment and performing it manually is brutal.
- jplusequalt 1y ago
  >Would that experience get eroded though? Yes. If you stop doing something, you get worse at it. There is literally no exception to this that I'm aware of. In the future where everyone is dependent on ever larger amounts of code, the possibility that nobody will be equipped to write/debug that code should scare you.
  - CuriouslyC 1y ago
    The amount of weightlifting a strength athlete needs to do to stay near their peak (but outside medal range) is ~15% of a full training workload. People can play instruments once a month and still be exceptional once the pathways are set down. Are you getting slightly worse at direct code jockeying? Sure, but not a lot, and you're getting superpowers in exchange.
    - 1y ago

notTooFarGone 1y ago

If you had google maps and you knew the directions it gives are 80% gonna be correct, would you still need navigation skills? You could also tweak it by going like "Lead me to the US" -> "Lead me to the state of New York" -> "Lead me to New York City" -> "Lead me to Manhattan" -> "Lead me to the museum of new arts" and it would give you 86% accurate directions, would you still need to be able to navigate? How about when you go over roads that are very frequently used you push to 92% accuracy, would you still need to be able to navigate? Yes of course because in 1/10 trips you'd get fucking lost. My point is: unless you get to that 99% mark, you still need the underlying skill and the abstraction is only a helper and always has to be checked by someone who has that underlying skill. I don't see LLMs as that 99% solution in the next years to come.

bdhcuidbebe 1y ago

> We're just moving up the abstraction ladder, like we did with compilers. Got any studies about reasoning decline from using compilers to go with your claim?

MobiusHorizons 1y ago

At some point details _will_ matter. Usually when you don't want them to like during an outage, or at a very late stage blocker on an already delayed project. What you don't understand, you can't plan for.

soraminazuki 1y ago

That's untrue, as many others have pointed out. Furthermore, compilers don't cause the kind of cognitive decline that's shown in the study.

soraminazuki 1y ago

Why is every discussion about AI like this? We get study after study and example after example showing that AI is unreliable [1], hurts productivity [2], and causes cognitive decline [3]. Yet, time and time again, a group of highly motivated individuals show up and dismiss these findings, not with counter-evidence, but through sheer sophistry. Heck, this is a thread meant to discuss evidence about LLM reliance contributing to cognitive decline. Instead, the conversation quickly derailed into an absurd debate about whether AI coding tools resemble compilers. It's exhausting. [1]: https://arxiv.org/abs/2401.11817 https://arxiv.org/abs/2401.11817 [2]: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... [3]: https://publichealthpolicyjournal.com/mit-study-finds-artificial-intelligence-use-reprograms-the-brain-leading-to-cognitive-decline/ https://publichealthpolicyjournal.com/mit-study-finds-artifi...

rkagerer 1y ago

Good luck once you find out how impossible it is to maintain all that AI generated slop, over the long term.