Which is great! But it's not a +1 for AI, it's a -1 for them.
" Is you, right?
Doesn't everyone work that way?
clang doesn't "understand" the hints because it doesn't "understand" anything, but it knows what to do with them! Just like codex.
But there is nothing about a compiler that implies determinism. A compiler is defined by function (taking input on how you want something to work and outputting code), not design. Implementation details are irrelevant. If you use a neural network to compile C code into machine code, it most definitely remains a compiler.
[1] "Faulty" hardware found in the real world can sometimes break this assumption. But a C compiler running on faulty hardware can change the assumption too.
Did you do that stupid HN thing where you failed to read the entire comment and then went off to try it on faulty hardware?
Now try it on deterministic hardware.
But what are you asking for, exactly? Do you want me to copy and paste the output (so you can say it isn't real)? Are you asking for access to my hardware? What does sharing mean here?
Symbolica is working on more deterministic/quicker models: https://www.symbolica.ai
I also wish it was that easy, but compiler determinism is hard, too: https://reproducible-builds.org
Are they, though? Obviously they are in some cases, but it has always been held that a natural language compiler is theoretically possible. But a natural language compiler cannot be deterministic, fundamentally. It is quite apparent that determinism is not what makes a compiler.
In fact, the dictionary defines compiler as: "a program that converts instructions into a machine-code or lower-level form so that they can be read and executed by a computer." Most everyone agrees that it is about function, not design.
> AI isn't just another tool
AI is not a tool, that is true. I don't know, maybe you stopped reading too soon, but it said "AI systems". Nobody was ever talking about AI. If you want to participate in the discussions actually taking place, not just the one you imagined in your head, what kind of system isn't just another tool?
Wow. No, I actually don't want to participate in a discussion where the default is random hostility and immediate personal attack. Sheesh.
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Please don't fulminate. Please don't sneer, including at the rest of the community.
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Please don't post shallow dismissals...
Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
HN is only a place where people want to participate because others make the effort to keep the standards up. Please do your part to make this a welcoming place rather than a mean one.
Incorrect. LLMs are designed to be deterministic (when temperature=0). Only if you choose for them to be non-deterministic are they so. Which is no different in the case of GCC. You can add all kinds of random conditionals if you had some reason to want to make it non-deterministic. You never would, but you could.
There are some known flaws in GPUs that can break that assumption in the real world, but in theory (and where you have working, deterministic hardware) LLMs are absolutely deterministic. GCC also stops being deterministic when the hardware breaks down. A cosmic bit flip is all it takes to completely defy your assertion.
It really comes mostly down to being able to concisely and eloquently define what you want done. It also is important to understand what the default tendencies and biases of the model are so you know where to lean in a little. Occasionally you need to provide reference material.
The capabilities have grown dramatically in the last 6 months.
I have an advantage because I have been building LLM powered products so I know mechanically what they are and are not good with. For example.. want it to wire up an API with 250+ endpoints with a harness? You better create (or have it create) a way to cluster and audit coverage.
Generally the failures I hear often with "advanced" programmers are things like algorithmic complexity, concurrency, etc.. and these models can do this stuff given the right motivation/context. You just need to understand what "assumptions" the model it making and know when you need to be explicit.
Actually one thing most people don't understand is they try to say "Do (A), Don't do (B)", etc. Defining granular behavior which is fundamentally a brittle way to interact with the models.
Far more effective is defining the persona and motivation for the agent. This creates the baseline behavior profile for the model in that context.
Not "don't make race conditions", more like "You value and appreciate elegant concurrent code."
This is a interesting take take considering that programmers are experts in communicating what someone has asked for (however vaguely) into code.
I think you're referring to is the transition from 'write code that does X' which is very concrete to 'trick an AI into writing the code I would have written, only faster', which feels like work that's somewhere between an art form and asking a magic box to fix things over and over again until it stops being broken (in obvious ways, at least).
Understandably people that prefer engineered solutions do not like the idea of working this way very much.
1. Basing on how the engineer just responded to my comment, what is the understanding gap?
2. How do I describe what I want in a concise and intuitive way?
3. How do I tell an engineer what is important in this system and what are the constraints?
4. What assumptions will an engineer likely make that are will cause me to have to make a lot of corrections?
Etc.. this is all human to human.
These skills are all transferrable to working with an LLM.
So I guess if you are not used to technical leadership, you may not have used those skills as much.
We had a method for this before LLMs; it was called "Haskell".
My supposition was: Many programmers that say their programming domain was too advanced and llms didn't work for their kind of code are simply bad at describing concisely what is required.
Lots of people are outing themselves these days about the complexity of their jobs, or lack thereof.
Which is great! But it's not a +1 for AI, it's a -1 for them.