Re: AI slop "contributions" to IETF working groups

[Robert Moskowitz <[e-mail]>]

On 2/10/26 2:07 PM, Jeffrey Walton wrote:
>
>
> 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.

One of the side discussions we were having.  I think some of this is 
going on behind security walls.

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

Also discussed.  Test cases are needed more....

>
> Jeff