4 ms·

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 expectin

by tombert 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo ago
        You don't have to convince me. LLMs are neat, code generation is neat, but I do wish that people had learned type theory and instead used those. I'm not aware of djinn, but I do remember the "Type Driven Development" that Idris had that I thought was absurdly cool; when you make the type specification clear enough, there ends up being basically exactly one reasonable way of writing the code, in which case it can just be "deduced" by machinery. I'm a huge advocate for formal methods, and it does sort of bother me that pretty much all work on that seems to have been refocused on AI.
  - thesz 6mo 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 6mo 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 6mo ago
But then who's responsible for reviewing and correcting the ai-written code ?

by tombert 6mo ago

xienze 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo ago
        You don't have to convince me. LLMs are neat, code generation is neat, but I do wish that people had learned type theory and instead used those. I'm not aware of djinn, but I do remember the "Type Driven Development" that Idris had that I thought was absurdly cool; when you make the type specification clear enough, there ends up being basically exactly one reasonable way of writing the code, in which case it can just be "deduced" by machinery. I'm a huge advocate for formal methods, and it does sort of bother me that pretty much all work on that seems to have been refocused on AI.
- thesz 6mo 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 6mo 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 6mo ago

But then who's responsible for reviewing and correcting the ai-written code ?