This originally began as one lengthy post but I’ve broken it into multiple posts that are more digestible. This is part 2.
One significant gripe I have with LLMs is that they are equally confident about their responses whether they are spot on or completely wrong. When you point out they’re mistaken they say “you’re correct, how about this?” and give you another answer that may or may not be correct. I’ve heard it called “mansplaining as a service” because it’s high-confidence in an answer that looks convincing but without actual basis of expertise.
Spot the error
For example, if you were shown this after asking for some PHP code that would replace the word ‘fizz’ with the word ‘buzz’ from a POSTed param named ‘input’:
<?php
if (strpos('fizz', $_POST['input'])) {
$result = str_replace('fizz', 'buzz', $_POST['input']);
} else {
$result = $_POST['input'];
}
echo $result;
?>
Looks convincing, right? It’s even got semicolons in the right places!
What’s the mistake here? hint 1, hint 2.
Answer
In my decade+ span of using PHP, the argument order of `str_replace` and `strpos` was perennially confusing to me. In this case, they are both reversed, the correct order: `str_replace($needle, $replace, $haystack)` and `strpos($haystack, $needle)`. So it _should_ be: `strpos($_POST['input'], 'fizz')`Anecdotal example
I recently had a coworker throw up a quick PR to fix some Javascript that we had written for one of our intranet forms. There was a bug in the existing code and this fix was to address that new behavior. My coworker generated a fix using an LLM service because they weren’t comfortable with their level of Javascript skill.
Upon review, it was pretty clear there were some issues. It added a new global-space class (appending to window), for one. The fix was an atomic unit that technically fixed the issue, but did so by adding a bunch of extra cruft that essentially “tacked-on” the solution instead of actually correcting the underlying buggy behavior.
It took me a couple hours, but I managed to detangle the generated Javascript, refactor the behavior into modules, and then integrate it into the existing code to both resolve the bug and add the enhanced behavior.
Trust, but verify
For this reason, my policy, and advice, around the use of LLMs in development is to treat it as you would a junior dev: trust it to do what you ask, but verify its correctness.
By contrast, don’t treat it as a senior dev (or at least, one that is “senior to you”) – that means don’t ask it to do things for you that you do not know how to do yourself.
In other words, if you want to delegate it work that you could have done yourself but will save you time by having it generated, where your time spend is just on the reviewing (and change-requests / modifications), then fine. But avoid delegating it work that you don’t know how to do yourself. There be dragons.