Microsoft Uses Slop to Find Defects and Then Uses Slop to Replace Code, What Could Go Wrong?

posted by Roy Schestowitz on Aug 07, 2026

Botspam is the problem, it's not a constructive approach in any shape or form

5 days ago a message was sent to libreplanet-discuss. It was only authorised by a moderator days later and it explains how slop turns Microsoft's notorious "spaghetti code" into a soup of slop:

Up to now my posts on this subject have mostly dealt with Project
Glasswing and free software.  Anthropic/Glasswing has published
detailed figures for issues found in "open source" projects.


A recent article by ProPublica reports on how Microsoft is dealing
with the findings.  Microsoft is a member of Project Glasswing.
It gives some insight in what is going on inside the proprietary
software company.


Anthropic's New AI Model Can Identify More Software Bugs Than
Ever.  Microsoft Is Struggling to Fix Them Fast Enough.


https://www.propublica.org/article/anthropic-mythos-microsoft-software-vulnerabilities


The article identifies the general direction of Microsoft's response.
As for details, there are limits:


  Microsoft declined to answer questions about how many bugs engineers
  had patched since the presentation.


  Anthropic declined to comment.


  While the internal documents reviewed by ProPublica do not include
  updates on the entire breadth of Microsoft's offerings, they do give a
  sense of the scale of the problem. One document noted that, since the
  company started using Mythos earlier this year, it had collectively
  found hundreds of bugs that Microsoft categorized as either critical
  or important in popular products such as Microsoft 365, the Teams
  conferencing platform and the Copilot AI tool. As of mid-May, most of
  them had yet to be patched.


Microsoft is using "AI"-assisted coding to patch the problems.  Management
is encouraging the practice:


  "What was heard on that call and is true today is that security is
  Microsoft's most important priority and teams across the company are
  prioritizing using AI to discover and remediate vulnerabilities as
  quickly as possible."


Whether keeping source code private enhance security is a subject of
debate:


  [O]ne staffer appeared to take comfort in the belief that adversaries
  "don't have the source code" that such an AI tool would scan for
  weaknesses. His colleagues, however, quickly corrected him. Portions
  of Microsoft's code have, in fact, fallen into hackers' hands over the
  years.


  "It might not be this week's source code," one person said. "But
  they've got source code. It's out there."


  In a statement to ProPublica, Microsoft downplayed the comment, saying
  engineers "design our security processes on the expectation that
  determined adversaries may gain access to code."


Akira Urushibata

It should be noted that ProPublica received a bribe (or bribes) from Bill Epsteingate.

Based on the above it is not clear if "Glasswing" (or "Mythos") is barely mentioned anymore because it was mostly hype and also whether the above approach will make things better rather than worse. Introducing new code can lead to new bugs. Introducing slop in place or real code is Russian roulette. There are bugs that are worse than security holes.

The secrecy says a lot though.

Meanwhile in 'Linuxland' the Microsoft apologist acknowledges that slop bug reports are a pain in the bum and he wants an end to the "recent "onslaught" of LLM-generated kernel patches":

Hi all,


Given the recent "onslaught" of LLM-generated kernel patches for the
drivers/staging/ subsystem, I'd like to clarify my position going forward with
regards to taking patches made with these tools.


First off, drivers/staging/ exists PRIMARILY as a place for new kernel
developers to learn how to get involved in kernel development.  It contains
loads of "low hanging fruit" with regards to code cleanups and api changes,
perfect for new developers to learn the process in a safe and friendly way,
with no pressure as no one _should_ be relying on the code in these directories
(as proof of the TAINT_CRAP flag that gets set if you ever actually load any of
this code into your kernel tree.)


We don't just take "fix all the coding style issues in this file!" type of
patches that are generated by tools, as that would defeat the whole purpose of
drivers/staging in the first place.  We could do that tomorrow if we actually
_cared_ about the code in here, but rather, we live with the issues just
because this is where people can start out and learn and grow from.


So this mean that anyone attempting to use a LLM to cleanup or "fix" any code
in drivers/staging/ is EXPLICITLY defeating the whole purpose of it existing in
the first place.  Because of this, going forward I am going to automatically
reject any patches generated with a LLM for the drivers/staging/ subsystem,
with one exception noted below.


And yes, it is VERY obvious when people submit LLM-generated patches, so don't
think that just not disclosing the use of them will allow you to "get away"
with anything here.  The goal is for people to be able to learn, not to try to
"trick" a maintainer.  If anyone is determined to have deliberately "tricked"
us, well, consider this your warning ahead of time...


Note, LLMs are very good at finding suspect "security issues" in kernel code
these days.  But even with the best of the current and next generation tools,
at least 1/3 of the results they generate are flat out wrong or harmful.  So,
if you think your LLM-found/fixed issue in a drivers/staging/ file is really
valid, it's fine to submit it BUT you must have first tested it on the actual
hardware for the driver, and described how you have done so, in order for us to
be willing to take the change.  This testing process should _hopefully_ weed
out the 1/3 wrong reports, but that isn't always the case, so you MUST be
willing to defend your submission and prove that it really is correct in fixing
a bug that a user can actually hit.


In other words, drivers/staging/ here is a "gym" that is here to learn and grow
your skills with.  A LLM is turning into a reasonable tool to do "heavy
lifting" for some things but that should only be done by those that have
already properly trained their skills to know what type of lifting can be done,
and in what way.  See this great essay by Bruce Schneier for where he explains
this in much better detail:
        https://www.schneier.com/blog/archives/2026/07/should-you-use-ai-for-a-task-heres-a-simple-way-to-decide.html


thanks,


greg k-h

Unless they caution the culprits, it might not be long before bots ruin the project, e.g. most (>50%) of commits are just botspam. "The Largest RC6 in Recent Years" is not a sign of a healthy community; it's a sign of slop companies sabotaging the kernel with total apathy/disregard. █