The glib response here would be to say that no technology is ever inevitable and that everything is contingent. This has the advantages of being technically true and sounding wise, but unfortunately technologies very much exist that a reasonable person might well label that way. Firearms are a good example of the latter case: once they've been developed, you quite quickly hit the situation where if you want to maintain your independence and safety in a society, you have to either use one or have one used on your behalf: no other options really work.
The code I get from coding agents is better than code I can write myself. It’s better than most of the code I’ve seen from collaborators over the course of my career. I think it takes skill to get those results out of a coding agent,
So if you are weaker at programming than an LLM, why do you think you are better at prompting LLMs? There are skills required in either case, and from what I’ve read, it seems it requires just as much attention to detail to keep the LLM from going “off-script” and time that used to be spent getting code past the compiler (or unit tests) is now spent getting code past the LLM.
I can produce thousands of lines of good, tested, understood code in a day
Well, “good” and “understood” are doing some heavy lifting there. From what I’ve read, the moves made by AlphaZero (Google’s AI Go playing engine) are upsetting to Go masters because the moves are rarely understood by them. While AlphaZero plays by the rules, the “output” (so to speak) is so alien that it might as well be random moves that just happen to win. It’s hard to determine if the moves are good if the reasoning behind them are not understood.
On your coding thousands of lines of code, over the past forty years we’ve slowly hammered into upper management that “lines of code” is not a good metric, and now that’s suddenly tossed out the window and “more more more” is the mantra of the day? I thought “no code” was the best code.
Without a coding agent I tap out at a few hundred lines per day.
The last year at my previous job, I wrote less than 100 lines of code, and it wasn’t because I’m a slow typist. It wasn’t even because I wrote 10,000 lines then deleted 9,900 of them. No, it was the constant meetings that slowed the pace down for everybody!
One of my least popular opinions is that lines of (good, tested, understood) code is actually a useful metric.
It only becomes useless the moment you start measuring it and telling employees that it’s part of how you evaluate their work.
There are skills required in either case, and from what I’ve read, it seems it requires just as much attention to detail to keep the LLM from going “off-script”
Right, that’s what I’m getting at when I talk about skill. You need to know what good code looks like, and understand the peccadillos of coding agents, and know how to productively counteract those peccadillos and get them to produce good code.
Without a coding agent I tap out at a few hundred lines per day.
The last year at my previous job, I wrote less than 100 lines of code, and it wasn’t because I’m a slow typist. It wasn’t even because I wrote 10,000 lines then deleted 9,900 of them. No, it was the constant meetings that slowed the pace down for everybody!
And given that many people read emails during those meetings but try not to type full-speed all the time, automatic code generation produces something to review during a pointless meeting. What company does is dictated by how internal communications are structured, a version of Conway’s Law…
So if you are weaker at programming than an LLM, why do you think you are better at prompting LLMs? There are skills required in either case, and from what I’ve read, it seems it requires just as much attention to detail to keep the LLM from going “off-script” and time that used to be spent getting code past the compiler (or unit tests) is now spent getting code past the LLM.
Well, “good” and “understood” are doing some heavy lifting there. From what I’ve read, the moves made by AlphaZero (Google’s AI Go playing engine) are upsetting to Go masters because the moves are rarely understood by them. While AlphaZero plays by the rules, the “output” (so to speak) is so alien that it might as well be random moves that just happen to win. It’s hard to determine if the moves are good if the reasoning behind them are not understood.
On your coding thousands of lines of code, over the past forty years we’ve slowly hammered into upper management that “lines of code” is not a good metric, and now that’s suddenly tossed out the window and “more more more” is the mantra of the day? I thought “no code” was the best code.
The last year at my previous job, I wrote less than 100 lines of code, and it wasn’t because I’m a slow typist. It wasn’t even because I wrote 10,000 lines then deleted 9,900 of them. No, it was the constant meetings that slowed the pace down for everybody!
score 1 · canonical
One of my least popular opinions is that lines of (good, tested, understood) code is actually a useful metric.
It only becomes useless the moment you start measuring it and telling employees that it’s part of how you evaluate their work.
Right, that’s what I’m getting at when I talk about skill. You need to know what good code looks like, and understand the peccadillos of coding agents, and know how to productively counteract those peccadillos and get them to produce good code.
score 1 · canonical
A fine example of Goodhart’s law.
score 1 · canonical
And given that many people read emails during those meetings but try not to type full-speed all the time, automatic code generation produces something to review during a pointless meeting. What company does is dictated by how internal communications are structured, a version of Conway’s Law…
score 1 · canonical