I think he’s kinda right in that competent engineers can write good code using LLMs. I don’t know whether they’re actually more productive that way though. The problem lies in the fact that incompetent engineers can write a lot of bad, but good-looking code using LLMs, which might be a pretty big burden on the maintainers.
Also, comparing LLMs to compilers doesn’t really work in my opinion. Compilers follow strict rules and translate one kind of logic into a different kind of logic, while LLMs turn natural language and vague notions into some kind of logic. Writing code is telling the computer precisely what it should do and prompting is vaguely telling it what end result you want and those are two fundamentally different things.
But your analogy also breaks down because once an AI has written the code it’s very much concrete, right? The AI may choose to modify that concreteness into something differently concrete, but it’s not like you are in any doubt about what the AI comes out with (if you bother to check it, which you should).
I use to write asset systems during the AAA gaming part of my career and the elusive “[my] perfect file format” always eluded me.
Over the years I spent many a showers and long drives thinking about what the “perfect file format” needs and what kind of architecture would support this. I started formulating these into long text files and over time things crystallised into “yes this would work”.
I never had the time to write the code fully. A couple of false starts, coupled with “I should do this in rust even though I’ve been in C++ my whole life” meant it lingered and lingered.
The architecture felt right though.
Enter AI; feeding the spec text files to an AI made me resolve a couple of “ah, yes, but in practice this bit of information isn’t available yet” gotchas but the code worked. I worked in architectural layers, carefully checking input, internals and output of each before proceeding to higher layers. And tests and tests, that’s you would never have bothered to write yourself, kept each layer verifiable, even out in the far corners of reasonable.
It worked and it was real affirmation to see 20 years of pontification made real.
But then I started profiling it. And hot damn, an LLM knows nothing about cache, file systems nor does it think about ways memory allocators and virtual memory systems work.
There was 200-300% speed ups to gain from hand tuning it and iterating with a proper profiler.
And all of this happened at code level, with real concrete code.
So yeah, an AI can be a wonderful tool. And the code it produces and iterates on is concrete. It’s not like the AI starts from scratch every time you have a thought. So the very, very first pass is not deterministic. But the thing you deliver forwards very much is.
I agree with you here (and also cool project/idea). What I’m trying to get at with my analogy is that, if you understand a programme’s source code, you understand and are able to predict its behaviour in a meaningful way (although of course you lose some amount of knowledge of what the processor exactly does with which registers etc). When you only know the prompt used to generate a programme, you can’t do that. That’s why you have to manually check the code an LLM writes, but not the assembly generated by a compiler.
I think he’s kinda right in that competent engineers can write good code using LLMs. I don’t know whether they’re actually more productive that way though. The problem lies in the fact that incompetent engineers can write a lot of bad, but good-looking code using LLMs, which might be a pretty big burden on the maintainers.
Also, comparing LLMs to compilers doesn’t really work in my opinion. Compilers follow strict rules and translate one kind of logic into a different kind of logic, while LLMs turn natural language and vague notions into some kind of logic. Writing code is telling the computer precisely what it should do and prompting is vaguely telling it what end result you want and those are two fundamentally different things.
But your analogy also breaks down because once an AI has written the code it’s very much concrete, right? The AI may choose to modify that concreteness into something differently concrete, but it’s not like you are in any doubt about what the AI comes out with (if you bother to check it, which you should).
I use to write asset systems during the AAA gaming part of my career and the elusive “[my] perfect file format” always eluded me.
Over the years I spent many a showers and long drives thinking about what the “perfect file format” needs and what kind of architecture would support this. I started formulating these into long text files and over time things crystallised into “yes this would work”.
I never had the time to write the code fully. A couple of false starts, coupled with “I should do this in rust even though I’ve been in C++ my whole life” meant it lingered and lingered.
The architecture felt right though.
Enter AI; feeding the spec text files to an AI made me resolve a couple of “ah, yes, but in practice this bit of information isn’t available yet” gotchas but the code worked. I worked in architectural layers, carefully checking input, internals and output of each before proceeding to higher layers. And tests and tests, that’s you would never have bothered to write yourself, kept each layer verifiable, even out in the far corners of reasonable.
It worked and it was real affirmation to see 20 years of pontification made real.
But then I started profiling it. And hot damn, an LLM knows nothing about cache, file systems nor does it think about ways memory allocators and virtual memory systems work.
There was 200-300% speed ups to gain from hand tuning it and iterating with a proper profiler.
And all of this happened at code level, with real concrete code.
So yeah, an AI can be a wonderful tool. And the code it produces and iterates on is concrete. It’s not like the AI starts from scratch every time you have a thought. So the very, very first pass is not deterministic. But the thing you deliver forwards very much is.
I agree with you here (and also cool project/idea). What I’m trying to get at with my analogy is that, if you understand a programme’s source code, you understand and are able to predict its behaviour in a meaningful way (although of course you lose some amount of knowledge of what the processor exactly does with which registers etc). When you only know the prompt used to generate a programme, you can’t do that. That’s why you have to manually check the code an LLM writes, but not the assembly generated by a compiler.