Part of the issue is that I think you are underestimating the number of people not doing "advanced" programming. If it's around ~80-90%, then that's a lot of +1s for AI
"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.
I used to hand roll the assembly, but now I delegate that work to my agent, clang. I occasionally override clang or give it hints, but it usually gets it right most of the time.
clang doesn't "understand" the hints because it doesn't "understand" anything, but it knows what to do with them! Just like codex.
Given an input clang will always give the same output, not quite the same for llms. Also nobody ever claimed compilers were intelligent or that they "understood" things
An LLM will also give the same output for the same input when the temperature is zero[1]. It only becomes non-deterministic if you choose for it to be. Which is the same for a C compiler. You can choose to add as many random conditionals as you so please.
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.
"Went" is a curious turn of phrase, but I take it to mean that you used an LLM on someone else's hardware of unknown origin? How are you ensuring that said hardware isn't faulty? It is a known condition. After all, I already warned you of it.
Do you need to reproduce them? You can simply look at how an LLM is built, no? It is not exactly magic.
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?
This is all a bit above my head. But the effects a compiler has on the computer are certainly not deterministic. It might do what you want or it might hit a weird driver bug or set off a false positive in some security software. And the more complex stacks get the he more this happens.
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.
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?
What the hell? You can't comment like this on HN, not matter how right you are or feel you are. The guidelines make it clear we're trying for something better here. These guidelines are particularly relevant:
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.
I beginning to think most "advanced" programmers are just poor communicators.
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."
Some of the best programmers I know are very good at writing and/or speaking and teaching. I struggle to believe that “advanced programmers” are poor communicators.
Genuine reflection question, are these excellent communicators good at using llms to write code?
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.
Most good programmers that I know personally work, as do I, in aerospace, where LLMs have not been adopted as quickly as some other fields, so I honestly couldn’t say.
> I beginning to think most "advanced" programmers are just poor communicators.
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.
The issue here is that LLM’s are not human and so having a human mental model of how to communicate doesn’t really work. If I communicate to my engineer to do X I know all kinds of things about them, like their coding style, strengths and weaknesses, and that they have some familiarity with the code they are working with and won’t bring the entirety of stack overflow answers to the context we are working in. LLM’s are nothing like this even when working with large amounts of context, they fail in extremely unpredictable ways from one prompt to the next. If you disagree I’d be interested in what stack or prompting you are using that avoids this.
One added note. This rigidness of instruction is a real problem that the models themselves will magnify and you need to be aware of. For example if you ask a Claude family of models to write a sub-agent for you in Claude Code. 99% of the time it will define a rigid process with steps and conditions instead of creating a persona with motivations (and if you need it suggested courses of action).
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.