CodeSOD: Raise VibeError

Ronan works with a vibe coder- an LLM addicted developer. This is a type of developer that’s showing up with increasing frequency. Their common features include: not reading the code the AI generated, not testing the code the AI generated, not understanding the context of the code or how it integrates into the broader program, and absolutely not bothering to follow the company coding standards.

Here’s an example of the kind of Python code they were “writing”:

<span class="hljs-keyword">if</span> <span class="hljs-built_in">isinstance</span>(o, Test):
    <span class="hljs-keyword">if</span> o.requirement <span class="hljs-keyword">is</span> <span class="hljs-literal">None</span>:
        logger.error(<span class="hljs-string">f"Invalid 'requirement' in Test: <span class="hljs-subst">{o.key}</span>"</span>)
        <span class="hljs-keyword">try</span>:
            <span class="hljs-keyword">raise</span> ValueError(<span class="hljs-string">"Missing requirement in Test object."</span>)
        <span class="hljs-keyword">except</span> ValueError:
            <span class="hljs-keyword">pass</span>

    <span class="hljs-keyword">if</span> o.title <span class="hljs-keyword">is</span> <span class="hljs-literal">None</span>:
        logger.error(<span class="hljs-string">f"Invalid 'title' in Test: <span class="hljs-subst">{o.key}</span>"</span>)
        <span class="hljs-keyword">try</span>:
            <span class="hljs-keyword">raise</span> ValueError(<span class="hljs-string">"Missing title in Test object."</span>)
        <span class="hljs-keyword">except</span> ValueError:
            <span class="hljs-keyword">pass</span>

An isinstance check is already a red flag. Even without proper type annotations and type checking (though you should use them) any sort of sane coding is going to avoid situations where your method isn’t sure what input it’s getting. isinstance isn’t a WTF, but it’s a hint at something lurking off screen. (Yes, sometimes you do need it, this may be one of those times, but I doubt it.)

In this case, if the Test object is missing certain fields, we want to log errors about it. That part, honestly, is all fine. There are potentially better ways to express this idea, but the idea is fine.

No, the obvious turd in the punchbowl here is the exception handling. This is pure LLM, in that it’s a statistically probable result of telling the LLM “raise an error if the requirement field is missing”. The resulting code, however, raises an exception, immediately catches it, and then does nothing with it.

I’d almost think it’s a pre-canned snippet that’s meant to be filled in, but no- there’s no reason a snippet would throw and catch the same error.

Now, in Ronan’s case, this has a happy ending: after a few weeks of some pretty miserable collaboration, the new developer got fired. None of “their” code ever got merged in. But they’ve already got a few thousand AI generated resumes out to new positions…

[Advertisement]
Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.

Source: Read More