181–190 of 291 posts
Earlier quoted context omitted.
Means the temperature should be set to 0 (which not every provider supports) so that the output becomes entirely deterministic. Right now with most models if you give the same input prompt twice it will give two different solutions.
Do LLMs inference engines have a way to seed their randomness? so tho have reproducible outputs with still some variance if desired?
Earlier quoted context omitted.
I feel like using a compiler is in a sense a code generator where you don't commit the actual output
> I feel like using a compiler is in a sense a code generator where you don't commit the actual output Compilers are deterministic. Given the same input you always get the same output so there's no reason to store the output. If you don't get the same output we call it a compiler bug! LLMs do not work this way. (Aside: Am I the only one who feels that the entire AI industry is predicated on replacing only development…
Except when they aren't. See for instance https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Developer-Opti... or the __DATE__/__TIME__ macros.
Earlier quoted context omitted.
My work has involved a project that is almost entirely generated code for over a decade. Not AI generated, the actual work of the project is in creating the code generator. One of the things we learned very quickly was that having generated source code in the same repository as actual source code was not sustainable. The nature of reviewing changes is just too different between them. Another thing we learned very qui…
> One of the things we learned very quickly was that having generated source code in the same repository as actual source code was not sustainable My rule of the thumb is to have both in same repo, but treat generated code like binary data. This was informed by when I was burned by a tooling regression that broke the generated code and the investigation was complicated by having to correlate commits across different…
Earlier quoted context omitted.
Can we please stop using the em-dash as a metric to “detect” LLM writing? It’s lazy and wrong. Plenty of people use em-dashes, it’s a useful punctuation mark . If humans didn’t use them, they wouldn’t be in the LLM training data. There are better clues, like the kind of vague pretentious babble bad marketers use to make their products and ideas seem more profound than they are. It’s a type of bad writing which looks…
Very few people use n dashes in internet writing as opposed to dashes as they are not available on the default keyboard.
Humorous that this article has a strong AI writing smell - the author should publish the prompts they used!
I don’t like to accuse, and the article is fine overall, but this stinks: “This transparency transforms git history from a record of changes into a record of intent, creating a new form of documentation that bridges human reasoning and machine implementation.”
That's where I stopped reading. If they needed "AI" for turning their git history into a record of intent ("transparency"), then they had been doing it all wrong, previously. Git commit messages have always been a "form of documentation that bridges human reasoning" -- namely, with another human's (the reader's) reasoning.
If you don't walk your reviewer through your patch, in your commit message, as if you were teaching them, then you're doing it wrong.
Left a bad taste in my mouth.
Earlier quoted context omitted.
My work has involved a project that is almost entirely generated code for over a decade. Not AI generated, the actual work of the project is in creating the code generator. One of the things we learned very quickly was that having generated source code in the same repository as actual source code was not sustainable. The nature of reviewing changes is just too different between them. Another thing we learned very qui…
I think the biggest difference here is that your code generator is probably deterministic and you likely are able to debug the results it produces rather than treating it like a black box.
I've been working on a recent project with heavy use of AI (probably around 100 hours of long-running autonomous AI sprints over the last few weeks), and if you tried to re-run all of my prompts in order, even using the exact same models with the exact same tooling, it would almost certainly fall apart pretty quickly. After the first few, a huge portion of the remaining prompts would be referencing code that wouldn't exist and/or responding to things that wouldn't have been said in the AI's responses. Meta-prompting (prompting agents to prepare prompts for other agents) would be an interesting challenge to properly encode. And how would human code changes be represented, as patches against code that also wouldn't exist?
The whole idea also ignores that AI being fast and cheap compared to human developers doesn't make it infinitely fast or free, or put it in the same league of quickness and cheapness as a compiler. Even if this were conceptually feasible, all it would really accomplish is making it so that any new release of a major software project takes weeks (or more) of build time and thousands of dollars (or more) burned on compute.
It's an interesting thought experiment, but the way I would put it into practice would be to use tooling that includes all relevant prompts / chat logs in each commit message. Then maybe in the future an agent with a more advanced model could go through each commit in the history one by one, take notes on how each change could have been better implemented based on the associated commit message and any source prompts contained therein, use those notes to inform a consolidated set of recommended changes to the current code, and then actually apply the recommendations in a series of pull requests.
Many of you are failing to conprehend the potential scale of AI generated codebases. Take note - there is no limit. Every feature you or the AI can prompt can be generated. Imagine if you were immortal and given unlimited storage. Imagine what you could create. That’s a prompt away. Even now you’re still restricting your thinking to the old ways.
You're talking ahead of the others in this thread, who do not understand how you got to what you're saying. I've been doing research in this area. You are not only correct, but the implications are staggering, and go further than what you have mentioned above. This is no cult, it is the reorganization of the economics of work.
and the overwhelming majority of humanity will be worse off for it
Why is this such a big deal? This library is not even that interesting. It is very straightforward task I expect most programers will be able to pull off easily. 2/3 of the code is type interfaces and comments. The rest is by book implementation of a protocol that is not even that complex.
Please, there are some React JSX files in your code base with a lot more complexities and intricacies than this.
Has anyone even read the code at all?
These posts are funny to me because prompt engineers point at them as evidence of the fast-approaching software engineer obsolescence but the years of experience in software engineering necessary to even guide an AI in this way is very high. The reason he keeps adjusting the prompts is because he knows how to program. He knows what it should look like. It just blurs the line between engineer and tool.
Earlier quoted context omitted.
> I feel like using a compiler is in a sense a code generator where you don't commit the actual output Compilers are deterministic. Given the same input you always get the same output so there's no reason to store the output. If you don't get the same output we call it a compiler bug! LLMs do not work this way. (Aside: Am I the only one who feels that the entire AI industry is predicated on replacing only development…
> Compilers are deterministic. Given the same input you always get the same output Except when they aren't. See for instance https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Developer-Opti... or the __DATE__/__TIME__ macros.
> You can use the -frandom-seed option to produce reproducibly identical object files.
Deterministic.
Also, with regard to __DATE__/__TIME__ macros, those are deterministic, because the current date and time are part of the inputs.