By the way, you can listen to me read this post aloud on my Patreon, along with many other audio recordings. Four ginever glasses sit on a mirrored table at Distilleerderij’t Nieuwe Diep in F…
this is AI but it felt a lot more guy with broken gear
OK sorry this is rambly but I gotta get these programmer feelings off my chest… If anything 4 hours is an understatement.
Back in university I once spent an entire week tracking down a latent bug in my program after the professor changed the project requirements a week before the due date. It was an accidental use of =instead of a copy in Java. We’re talking every waking moment both in and out of class (I was not the best at debugging back then…).
Now in the working world there’s bugs-- but they’re not just my bugs anymore. Rather there’s decades of bugs piled on top of bugs. Code has dozens of authors, most of whom quit long ago. The ones that remain often have no memory of the code.
Just last week I did a code review of a co-workers bugfix for a bug introduced in 2008. The fix was non-trivial due to:
The code being a tangled mass of overlapping state and (more importantly)
No one actually remembering anything about the code or where it is called or why it is there in the first place or what the implications of changing it are. Except that it’s causing problems (An O(n^2) slowdown case harming production) now in 2024.
The original design doc was in the personal folder of the original author (no longer at the company), which was garbage collected years ago.
So reviewing the code involved comparing every iteration of the code, from the initial commit, up to where the bug was introduced, up to the state it was in today before my coworkers fix, and my coworkers fix. It turns out he got it wrong, and I can’t exactly blame him because there is no right in this sort of environment. Fortunately the wrongness was caught by me and whatever meager unit-tests were written for it.
This all took maybe half a day for me, and a day for my coworker, for 1.5 days of work between the two of us. All to fix a condition which was accidentally negated from what it should have been.
And this is indeed what LLM for code enthusiasts miss.
Even if the LLM saves some time with writing boilerplate code, it’ll inevitably mess up in subtle ways, or programmers will think the LLM can do more than they actually can. Either way they’ll end up introducing subtle bugs; so you have a situation where someone saving 20 seconds here or there leads to hours of debugging effort, or worse, at an unpredictable point in the future.
At least with human written code you can go back and ask them what they were thinking, or read the design doc, or read comments and discussion. Even the most amateurish human author code has the spark of life to it. It was in essense a manifestation of someone’s wish.
On the other hand with code that’s just statistical noise there’s no way to tell what it was trying to do in the first place. There is no will / soul / ego in the code, so there is no understanding, so there is no way to debug it short of reverting the whole change and starting over.
This is a good piece, both on the gap between how gen AI is sold and what it does, and on the reality of what professional programming is.
This, I feel, sums up the reality of professional programming in a nutshell. 🤣
OK sorry this is rambly but I gotta get these programmer feelings off my chest… If anything 4 hours is an understatement.
Back in university I once spent an entire week tracking down a latent bug in my program after the professor changed the project requirements a week before the due date. It was an accidental use of
=instead of a copy in Java. We’re talking every waking moment both in and out of class (I was not the best at debugging back then…).Now in the working world there’s bugs-- but they’re not just my bugs anymore. Rather there’s decades of bugs piled on top of bugs. Code has dozens of authors, most of whom quit long ago. The ones that remain often have no memory of the code.
Just last week I did a code review of a co-workers bugfix for a bug introduced in 2008. The fix was non-trivial due to:
So reviewing the code involved comparing every iteration of the code, from the initial commit, up to where the bug was introduced, up to the state it was in today before my coworkers fix, and my coworkers fix. It turns out he got it wrong, and I can’t exactly blame him because there is no right in this sort of environment. Fortunately the wrongness was caught by me and whatever meager unit-tests were written for it.
This all took maybe half a day for me, and a day for my coworker, for 1.5 days of work between the two of us. All to fix a condition which was accidentally negated from what it should have been.
And this is indeed what LLM for code enthusiasts miss.
Even if the LLM saves some time with writing boilerplate code, it’ll inevitably mess up in subtle ways, or programmers will think the LLM can do more than they actually can. Either way they’ll end up introducing subtle bugs; so you have a situation where someone saving 20 seconds here or there leads to hours of debugging effort, or worse, at an unpredictable point in the future.
At least with human written code you can go back and ask them what they were thinking, or read the design doc, or read comments and discussion. Even the most amateurish human author code has the spark of life to it. It was in essense a manifestation of someone’s wish.
On the other hand with code that’s just statistical noise there’s no way to tell what it was trying to do in the first place. There is no will / soul / ego in the code, so there is no understanding, so there is no way to debug it short of reverting the whole change and starting over.