It's not. And if your team is doing this you're not "advanced."
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.
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.
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 source into machine code instead of more traditional approaches, it most definitely remains a compiler. The function is unchanged.
[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
Wow. No, I actually don't want to participate in a discussion where the default is random hostility and immediate personal attack. Sheesh.
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."
We had a method for this before LLMs; it was called "Haskell".
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.
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.