Latest

All our houses are built on sand now

They took all the rock away

And every one that heareth these sayings of mine, and doeth them not, shall be likened unto a foolish man, which built his house upon the sand: And the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell: and great was the fall of it.

This was originally going to be called something like, “How slopcoded is your programming language?” But as I gathered the data, I found something else – something worse.

Almost every popular language is now substantially developed using LLMs. Particularly notable are C# and Ruby (both approximately one third of recent commits) and Julia (over half!). The languages that stand out in retaining their humanity are Chicken Scheme, Perl, Lua, Clojure, and – perhaps surprisingly for a project so closely associated with Oracle, a company who have gone all-in on hyperscale data centres and “AI” in everything – Java.

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:.*([email protected]|[email protected]|[email protected]|[email protected])"
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.