3 ms·

> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. Absolutely. The difference is that

by xienze 7mo ago

> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. Absolutely. The difference is that the amount of bad code that could be generated had an upper limit on it — how fast a human can type it out. With LLMs bad code can be shat out at warp speed.

tombert 7mo ago
Oh I don't disagree with that. I am getting pretty tired of people making multi-thousand-line pull requests with lots of clearly AI-generated code and expecting it to be merged in. I think the better unit to commit and work with is the prompt itself, and I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.
- xienze 7mo ago
  > I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important. The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.
  - tombert 7mo ago
    If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic. Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.
    - ben-schaaf 7mo ago
      How is "fairly close to deterministic" anywhere near good enough? LLMS aren't anywhere near cheap enough to do this either. That said it's so trivial to do, why haven't you done that already?
      - tombert 7mo ago
        I have actually, for my personal projects. I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists. I have a Java version that works right now and I will likely be pushing it within the next week. But more generally, I actually have been building some CI stuff to automate how I'm saying. I don't have much of a say how this is handled at work so they're just committing the generated code, but I actually am doing what I am talking about.
        ben-schaaf 7mo ago
        Sounds like a fun project. And are you committing code for this library? Because it sounds like you are, and if that's the case I don't think you're actually doing what you're talking about.
        tombert 7mo ago
        I'm writing the "assume" code by hand. Regular non-artificial intelligence, or the closest that I ever get to it, so no hypocrisy on that.
        thesz 7mo ago
        > I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists. This is very much like good old djinn [1], which would generate code from Haskell type specification. [1] https://mail.haskell.org/pipermail/haskell/2005-December/017098.html https://mail.haskell.org/pipermail/haskell/2005-December/017... And this is why I boldly compare current LLM craze to the much less hyped craze of strong type systems. I was a part of that strong type system discussion, advocating for them. ;)
        tombert 7mo ago
    - thesz 7mo ago
      > If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic. Your prompt may work on the specific state of code base and not before or after some changes. Your tests can check for the specific behavior but not for the absence of undesirable behaviors induced by absence of some specific code or by addition of other specific code. > I assure you that's already happening. A lot. Thank you for assurance. Can we have less of it? Thank you again.
      - nephanth 7mo ago
        Hell sometimes the ai may look at values in .env or other uncommited stuff. Its execution path may depend on which commands are available in the environment. The specific model and settings. On top of the inherent randomness if you havent set model heat to 0. i suspect it is very hard to get consistent reproducible ai runs
- nephanth 7mo ago
  But then who's responsible for reviewing and correcting the ai-written code ?

by xienze 7mo ago

tombert 7mo ago

Oh I don't disagree with that. I am getting pretty tired of people making multi-thousand-line pull requests with lots of clearly AI-generated code and expecting it to be merged in. I think the better unit to commit and work with is the prompt itself, and I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.

xienze 7mo ago
> I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important. The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.
- tombert 7mo ago
  If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic. Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.
  - ben-schaaf 7mo ago
    How is "fairly close to deterministic" anywhere near good enough? LLMS aren't anywhere near cheap enough to do this either. That said it's so trivial to do, why haven't you done that already?
    - tombert 7mo ago
      I have actually, for my personal projects. I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists. I have a Java version that works right now and I will likely be pushing it within the next week. But more generally, I actually have been building some CI stuff to automate how I'm saying. I don't have much of a say how this is handled at work so they're just committing the generated code, but I actually am doing what I am talking about.
      - ben-schaaf 7mo ago
        Sounds like a fun project. And are you committing code for this library? Because it sounds like you are, and if that's the case I don't think you're actually doing what you're talking about.
        tombert 7mo ago
        I'm writing the "assume" code by hand. Regular non-artificial intelligence, or the closest that I ever get to it, so no hypocrisy on that.
      - thesz 7mo ago
        > I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists. This is very much like good old djinn [1], which would generate code from Haskell type specification. [1] https://mail.haskell.org/pipermail/haskell/2005-December/017098.html https://mail.haskell.org/pipermail/haskell/2005-December/017... And this is why I boldly compare current LLM craze to the much less hyped craze of strong type systems. I was a part of that strong type system discussion, advocating for them. ;)
        tombert 7mo ago
  - thesz 7mo ago
    > If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic. Your prompt may work on the specific state of code base and not before or after some changes. Your tests can check for the specific behavior but not for the absence of undesirable behaviors induced by absence of some specific code or by addition of other specific code. > I assure you that's already happening. A lot. Thank you for assurance. Can we have less of it? Thank you again.
    - nephanth 7mo ago
      Hell sometimes the ai may look at values in .env or other uncommited stuff. Its execution path may depend on which commands are available in the environment. The specific model and settings. On top of the inherent randomness if you havent set model heat to 0. i suspect it is very hard to get consistent reproducible ai runs
nephanth 7mo ago
But then who's responsible for reviewing and correcting the ai-written code ?