Re: AI slop "contributions" to IETF working groups

[Jeffrey Walton <[e-mail]>]

On Tue, Feb 10, 2026 at 1:36 PM Phillip Hallam-Baker <[e-mail]>
wrote:

> How is using an AI different from using fuzzing though?
>
> One of the most effective hacking tools is to simply spam the inputs with
> garbage and see what happens. So it isn't exactly surprising that when
> people write code in unsafe languages without null pointer and array bounds
> checking, they can discover low hanging fruit vulnerabilities faster than
> others.
>
> What such testing doesn't show is that the code is secure because AI
> generated tests aren't exhaustive. Just as 'write slop, check it by
> fuzzing' isn't a valid method for producing secure code, neither is 'check
> with AI'.
>

A dangerous (?) trend I am seeing at $dayjob... We perform static scans on
an app's code base, and dynamic scans on a running application in a test
environment.  A tool produces a finding that triggers a code review.  The
dev team will often say the finding is a false positive because "<favorite
AI tool> says it is Ok."

I like to remind the dev teams that Edsger Dijkstra's observation still
holds.  AI tools can be used to confirm the presence of a bug, not the
absence of them.

I feel AI tools would be much more useful during development if they
produced boatloads of negative test cases that attempted to break the
application.  Since AI is supposed to be smart, it should be easy for it to
create the boundary test cases that developers often miss.

Which brings up another interesting question: should AI be allowed to write
the code and the test cases?  Would that violate separation of duties?

Jeff