3 ms·

> And I haven't written a single line of code myself since what - February maybe? Have you measured the impact of that on your ability to create good code? Fro

> And I haven't written a single line of code myself since what - February maybe? Have you measured the impact of that on your ability to create good code? From my experience, relying on AI tends to degrade that ability. Also, you seem to be able to do all of what you say and benefit from AI tools because you seem to understand the overall bigger picture well enough to be able to drive the AI agents to do their work properly. In other words, you operate in a familiar territory where you do not need to learn much new things. But what about the junior people with little experience? Will they be able to manage such AI workflow? And more importantly, if junior people are given such AI tools, how will they learn? These are all questions which may not matter in the short term and one might ignore them if they just want to see the profits and efficiency gains during the next cycle. But what about the long term?

designerarvid 5mo ago
How good are you at writing assembly? What about junior people that take an introductory course in assembly but never practice it. Maybe I’m pushing it a bit, I know, but a couple of decades ago you could’ve been asking this instead.
- gloflo 5mo ago
  That's a apples vs oranges comparison. Higher programming languages are still deterministic and not full of superstition.
  - richardfulop 5mo ago
    are you saying ai writes code that is semantically wrong? because i dont think humans write deterministic code - they come up with different solutions to the same problem.
- ares623 5mo ago
  The usual response to this is the "but high level languages are deterministic blah blah blah" (which IMO would be a good enough argument but well, we know how this goes now) I posit a different argument. When you install a compiler on your computer, that compiler is "yours" for as long as you have the binary. You are able to completely forget about assembly because of 1. reliable _enough_ compiler 2. reliable access to said compiler. Let's rewind decades back and pretend that the very first assembly compiler was behind a monthly subscription*. Do you think we'd be in the same place now? Now the natural follow up to this "but the open models are close to SotA now". Well why aren't we using them? Do we really think we'd have a GNU moment for """open""" models? And are we willing to bet our industry on that? But my point is, _these are not the same things_ and positing them as such is frankly insulting. How good are you at writing assembly when your compiler is inevitably taken away? * I'm not a historian so I wouldn't be surprised some version of them were
  - designerarvid 5mo ago
    Zoom out and take an anthropological view: relevant human skills become irrelevant over time. I’m not here to say that’s good or fun.
  - lentil_soup 5mo ago
    This is a great point! And not only a compiler behind a subscription, it's also a compiler whose financial interests are not aligned to be the best compiler but the one that makes the most money, which is unclear what it means at this moment. Will it have ads? Will it give preference to some technology over another? Will it steal your code? It's an unreliable and opaque compiler!
  - rblatz 5mo ago
    There is an argument that I’ve been seeing more recently that argues why we should expect open models to eventually reach good enough status that people use them over frontier commercial models. Basically it boils down to geopolitics, the US economy is currently being propped up by a small subset of companies, and a lot of that is based on proprietary models and speculation in the market around them. China is going to continue to dump better and better free models out to complete. Thus pulling the rug out on all that speculation. Helping neutralize their biggest rival.
  - fc417fc802 5mo ago
    > Well why aren't we using them? We are though? It just depends on the task and the costs. > Do we really think we'd have a GNU moment for """open""" models? And are we willing to bet our industry on that? Yes and yes. We're in the mainframe era. But history this time around is passing us by at a ridiculously fast clip. Local models become "good enough" for new tasks by the day, after which they continue to shrink for a given performance level. I'm not going to bet against either moore's law or relentless increases in model efficiency any time soon.
- Nautman 5mo ago
  I understand what you mean, but in my opinion there's a big difference between writing in natural language and actively engaging your brain with writing code, looking up documentation, etc. It also sort of feels like "you don't know what you don't know", i.e. would you have considered an alternative better solution if you thought about it yourself, went to the documentation, found a tutorial on the web? Of course, production is arguably a lot faster but it feels like there's starting to become a trade-off where the models feel so capable that we stop trying to find the solution to the problem ourselves and thus perhaps degrading our personal reasoning capabilities. I say this as something I'm afraid is happening, not something I'm certain of.
- pbasista 5mo ago
  > How good are you at writing assembly? How is that relevant to the topic of this discussion? Compilation from higher order languages to the machine code is deterministic. It is sufficient to review and well-test the tool which does the translation. Given the same input, the output will always be the same. Transformation of a natural language prompt to code by an AI tool is non-deterministic. The outputs will vary between runs. Therefore, it is always necessary to verify them. That is the difference.
  - richardfulop 5mo ago
    > Compilation from higher order languages to the machine code is deterministic. but that's not the analogy. there are problems that you can solve better if you can go deeper in the stack, and they can have different solutions.
  - js8 5mo ago
    Compilation is not deterministic, see JITs and GCs. What is deterministic is the resulting program output, but not its performance. So with compilers, we traded away the determinism over performance in exchange for ease of programming. With LLMs, we are trading away the determinism of the program output as well, in exchange for even more easier programming. Is it a good or bad thing? There are ways to mitigate the problem, just like there are with compilers. You could argue the determinism of the program output was never really there, because the specification at the high enough level was always unclear. So we are not really losing that much, just accepting more messy reality. Then the only question remains, can these computer programs (LLMs) do a better job (and where) than a SW developer, who is supposed to translate unclear specifications into a formal language (source code). It happened with compilers - eventually they got better than all of assembler programmers. Same happened to chess players.
    - skydhash 5mo ago
      > Compilation is not deterministic, see JITs and GCs. What is deterministic is the resulting program output, but not its performance. Does JIT compiles some other program code instead of the one being run? Does it produce bytecodes for a differenr VM? Does it tries to compile parts of the program that have not been executed or aren’t going to be? Does GC destroy objects being in use? Does it ignores instances and memory that has been properly released? JITs and GC are deterministic algorithms, you can predict its behavior by just reading their code. LLM tooling involves an actual random generator for its output.
- stefanlindbohm 5mo ago
  This would only be somewhat equivalent if you compiled your code into assembly and committed that output to the repo, and then had to continue development within the assembly codebase using the same method.
- alanfranz 5mo ago
  > How good are you at writing assembly? This is a false equivalence. A compiler is a predictable, testable, deterministic piece of software. An LLM is not. Sure, all abstractions leak; so, at some point in time, for some reason, you may need to check its compiled code ( cough cough gcc 2.96 ). But, if today your code compiles properly, it will properly compile tomorrow as well.
  - js8 5mo ago
    LLMs can be deterministic as well - same prompt on the same model produces the same input. On the other hand, compilers can be quite undeterministic - you get a new version of compiler, or change compiler options (turn on optimizations) - you might get a very different binary. And JIT compilers (and GC languages) even less deterministic, their compilation can depend on the nature of the inputs. But I think, in the analogy compiler ~ LLM, the issue is more of a trust than determinism. It took decades to assembler programmers to trust compilers enough not to write code in assembler. The similar will happen with AI - some will embrace it sooner than others.
    - skydhash 5mo ago
      > LLMs can be deterministic as well - same prompt on the same model produces the same input > compilers can be quite undeterministic - you get a new version of compiler, or change compiler options (turn on optimizations) That’s a whole other level pf bad faith argument right here. Flags and options are input too. > It took decades to assembler programmers to trust compilers enough not to write code in assembler. You do realize that Cobol, Algol, and Lisp are very old, and they were not assembly. And that Unix were written in C shortly after the language was created.
      - js8 5mo ago
        > That’s a whole other level pf bad faith argument right here. Not sure where you see the bad faith argument. (Btw I mean "same output", not "same input", it was a typo.) Take for example JVM. It used to be horribly bad and unpredictable, performance wise, in the 90s. Sun tried to base a desktop environment on it - it didn't work. > You do realize that Cobol, Algol, and Lisp are very old, and they were not assembly. Of course! But people have been hand-writing assembler until late 2000s, because compilers were simply not that good. The same will happen with LLMs - some people will not trust it and won't use it for decades, possibly. Some have already embraced it.
- manmal 5mo ago
  Interactions with agents are conversational, while higher order langs are declarative. Spec driven development has been failing us, because there is no feedback loop from the runtime to the spec.
vividfrier 5mo ago
[flagged]

designerarvid 5mo ago

How good are you at writing assembly? What about junior people that take an introductory course in assembly but never practice it. Maybe I’m pushing it a bit, I know, but a couple of decades ago you could’ve been asking this instead.

gloflo 5mo ago
That's a apples vs oranges comparison. Higher programming languages are still deterministic and not full of superstition.
- richardfulop 5mo ago
  are you saying ai writes code that is semantically wrong? because i dont think humans write deterministic code - they come up with different solutions to the same problem.
ares623 5mo ago
The usual response to this is the "but high level languages are deterministic blah blah blah" (which IMO would be a good enough argument but well, we know how this goes now) I posit a different argument. When you install a compiler on your computer, that compiler is "yours" for as long as you have the binary. You are able to completely forget about assembly because of 1. reliable _enough_ compiler 2. reliable access to said compiler. Let's rewind decades back and pretend that the very first assembly compiler was behind a monthly subscription*. Do you think we'd be in the same place now? Now the natural follow up to this "but the open models are close to SotA now". Well why aren't we using them? Do we really think we'd have a GNU moment for """open""" models? And are we willing to bet our industry on that? But my point is, _these are not the same things_ and positing them as such is frankly insulting. How good are you at writing assembly when your compiler is inevitably taken away? * I'm not a historian so I wouldn't be surprised some version of them were
- designerarvid 5mo ago
  Zoom out and take an anthropological view: relevant human skills become irrelevant over time. I’m not here to say that’s good or fun.
- lentil_soup 5mo ago
  This is a great point! And not only a compiler behind a subscription, it's also a compiler whose financial interests are not aligned to be the best compiler but the one that makes the most money, which is unclear what it means at this moment. Will it have ads? Will it give preference to some technology over another? Will it steal your code? It's an unreliable and opaque compiler!
- rblatz 5mo ago
  There is an argument that I’ve been seeing more recently that argues why we should expect open models to eventually reach good enough status that people use them over frontier commercial models. Basically it boils down to geopolitics, the US economy is currently being propped up by a small subset of companies, and a lot of that is based on proprietary models and speculation in the market around them. China is going to continue to dump better and better free models out to complete. Thus pulling the rug out on all that speculation. Helping neutralize their biggest rival.
- fc417fc802 5mo ago
  > Well why aren't we using them? We are though? It just depends on the task and the costs. > Do we really think we'd have a GNU moment for """open""" models? And are we willing to bet our industry on that? Yes and yes. We're in the mainframe era. But history this time around is passing us by at a ridiculously fast clip. Local models become "good enough" for new tasks by the day, after which they continue to shrink for a given performance level. I'm not going to bet against either moore's law or relentless increases in model efficiency any time soon.
Nautman 5mo ago
I understand what you mean, but in my opinion there's a big difference between writing in natural language and actively engaging your brain with writing code, looking up documentation, etc. It also sort of feels like "you don't know what you don't know", i.e. would you have considered an alternative better solution if you thought about it yourself, went to the documentation, found a tutorial on the web? Of course, production is arguably a lot faster but it feels like there's starting to become a trade-off where the models feel so capable that we stop trying to find the solution to the problem ourselves and thus perhaps degrading our personal reasoning capabilities. I say this as something I'm afraid is happening, not something I'm certain of.
pbasista 5mo ago
> How good are you at writing assembly? How is that relevant to the topic of this discussion? Compilation from higher order languages to the machine code is deterministic. It is sufficient to review and well-test the tool which does the translation. Given the same input, the output will always be the same. Transformation of a natural language prompt to code by an AI tool is non-deterministic. The outputs will vary between runs. Therefore, it is always necessary to verify them. That is the difference.
- richardfulop 5mo ago
  > Compilation from higher order languages to the machine code is deterministic. but that's not the analogy. there are problems that you can solve better if you can go deeper in the stack, and they can have different solutions.
- js8 5mo ago
  Compilation is not deterministic, see JITs and GCs. What is deterministic is the resulting program output, but not its performance. So with compilers, we traded away the determinism over performance in exchange for ease of programming. With LLMs, we are trading away the determinism of the program output as well, in exchange for even more easier programming. Is it a good or bad thing? There are ways to mitigate the problem, just like there are with compilers. You could argue the determinism of the program output was never really there, because the specification at the high enough level was always unclear. So we are not really losing that much, just accepting more messy reality. Then the only question remains, can these computer programs (LLMs) do a better job (and where) than a SW developer, who is supposed to translate unclear specifications into a formal language (source code). It happened with compilers - eventually they got better than all of assembler programmers. Same happened to chess players.
  - skydhash 5mo ago
    > Compilation is not deterministic, see JITs and GCs. What is deterministic is the resulting program output, but not its performance. Does JIT compiles some other program code instead of the one being run? Does it produce bytecodes for a differenr VM? Does it tries to compile parts of the program that have not been executed or aren’t going to be? Does GC destroy objects being in use? Does it ignores instances and memory that has been properly released? JITs and GC are deterministic algorithms, you can predict its behavior by just reading their code. LLM tooling involves an actual random generator for its output.
stefanlindbohm 5mo ago
This would only be somewhat equivalent if you compiled your code into assembly and committed that output to the repo, and then had to continue development within the assembly codebase using the same method.
alanfranz 5mo ago
> How good are you at writing assembly? This is a false equivalence. A compiler is a predictable, testable, deterministic piece of software. An LLM is not. Sure, all abstractions leak; so, at some point in time, for some reason, you may need to check its compiled code ( cough cough gcc 2.96 ). But, if today your code compiles properly, it will properly compile tomorrow as well.
- js8 5mo ago
  LLMs can be deterministic as well - same prompt on the same model produces the same input. On the other hand, compilers can be quite undeterministic - you get a new version of compiler, or change compiler options (turn on optimizations) - you might get a very different binary. And JIT compilers (and GC languages) even less deterministic, their compilation can depend on the nature of the inputs. But I think, in the analogy compiler ~ LLM, the issue is more of a trust than determinism. It took decades to assembler programmers to trust compilers enough not to write code in assembler. The similar will happen with AI - some will embrace it sooner than others.
  - skydhash 5mo ago
    > LLMs can be deterministic as well - same prompt on the same model produces the same input > compilers can be quite undeterministic - you get a new version of compiler, or change compiler options (turn on optimizations) That’s a whole other level pf bad faith argument right here. Flags and options are input too. > It took decades to assembler programmers to trust compilers enough not to write code in assembler. You do realize that Cobol, Algol, and Lisp are very old, and they were not assembly. And that Unix were written in C shortly after the language was created.
    - js8 5mo ago
      > That’s a whole other level pf bad faith argument right here. Not sure where you see the bad faith argument. (Btw I mean "same output", not "same input", it was a typo.) Take for example JVM. It used to be horribly bad and unpredictable, performance wise, in the 90s. Sun tried to base a desktop environment on it - it didn't work. > You do realize that Cobol, Algol, and Lisp are very old, and they were not assembly. Of course! But people have been hand-writing assembler until late 2000s, because compilers were simply not that good. The same will happen with LLMs - some people will not trust it and won't use it for decades, possibly. Some have already embraced it.
manmal 5mo ago
Interactions with agents are conversational, while higher order langs are declarative. Spec driven development has been failing us, because there is no feedback loop from the runtime to the spec.

vividfrier 5mo ago

[flagged]