However, all of these rely on a C compiler (indirectly via the JVM in the case of Clojure), and both of the main C compilers now receive significant amounts of LLM commits. I’m not so surprised by LLVM (15.9%), but I am disappointed by GCC (3.1% and apparently rising). Outsourcing your thinking to megacorporations and commercial tools seems out of step with the GNU ethos of freely available source that anyone can modify: code that is generated by machines quickly becomes code that is only parsed and modified by machines, and a subscription to OpenAI or Anthropic becomes the (financial, environmental, and geopolitical) price of entry.

In 1984, in his acceptance speech for the ACM Turing Award, Ken Thompson described a method by which a compiler could be subverted so that it would always insert a backdoor into the UNIX login command, and, furthermore, when used to compile itself would insert a similar subversion into new versions of the compiler. Once this has been achieved, no one has access to an uncompromised compiler.

The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.

Does it matter how slopcoded your language is or isn’t, when everything below it is slop?

Methodology

I cloned the source repositories for implementations of programming languages that ranked highly on TIOBE and LangPop. For each, I performed a shallow clone going back to the start of July:

git clone --shallow-since=2026-07-01 ${url}

I then wrote a short script that takes a three-month period and counts the number of commits that appear to be LLM-assisted. This is determined by:

• The phrase “AI disclosure” or “LLM disclosure”
• An Assisted-by: field
• a Co-authored-by: field with the email address of a known bot

This isn’t perfect – I saw one commit that had a disclosure field followed by “none” and a link to a manifesto opposing LLM-assisted coding, but I don’t think those edge cases are significant.

#!/bin/bash
bots="ai disclosure|llm disclosure|assisted-by:|co-authored-by:.*(noreply@openai.com|noreply@anthropic.com|cursoragent@cursor.com|copilot@users.noreply.github.com)"
date_since="2026-07-05"
date_until="2026-10-06"
cd repos
for repo in *; do
  cd ${repo}
  total="$(
    git log --oneline \
      --since=${date_since} \
      --until=${date_until} \
    | wc -l
  )"
  botted="$(
    git log --oneline \
      --since=${date_since} \
      --until=${date_until} \
      -E -i --grep "${bots}" \
    | wc -l
  )"
  percent="$(printf %.1f $((10000 * ${botted}/${total}))e-2)"
  echo "|${repo}|${botted}|${total}|${percent}%|"
  cd - >/dev/null
done
cd - >/dev/null

Results

This yielded the following table, which I have sorted and annotated:

Repositories don’t map one-to-one to programming languages: some implementations cover multiple languages, and some languages have multiple implementations.