I was out of town for a couple days and upon return, a git pull on main produced a ton of changed files. git log showed a bunch of recent edits, many apparently co-authored by Claude (with attribution). A find ... | grep ... on the source looking for references to Claude or anthropic.com only yielded a single hit:
% find . -type f -print0 | xargs -0 egrep 'noreply@anthropic.com|Claude (Code|Sonnet|Opus)'
./Tools/picklebench/memory_dos_impact.py:# Author: Claude Sonnet 4.5 as driven by gpshead
I have no particular problem with the use of LLMs in core Python code. I trust the core dev team to properly manage such tools. Still, I think it would be useful to mention how they are used somewhere in the source code repository. In particular, “co-authored” might mean a few things w.r.t. LLMs:
The LLM uncovered a bug
The LLM at least helped write a bit of code (bugfix, new features, new tests, etc)
Some combination of the two
Picking one commit, mostly because it seems to have a detailed commit message:
commit 6f103fab178c07cbb5f701b8ad97e275b6eb6c4c
Author: Serhiy Storchaka <storchaka@gmail.com>
Date: Tue Jun 30 12:19:43 2026 +0300
gh-50966: Fix unbounded recursion in turtle drag handlers (GH-152626)
TurtleScreenBase._update() redraws with cv.update(), which also reprocesses
input events, so a handler that moves the turtle (such as
screen.ondrag(turtle.goto)) reenters _update() for every queued event until
the interpreter crashes. A reentrant _update() now only flushes drawing with
update_idletasks().
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
I didn’t see any mention of Claude other than the above bit in the commit message. It would be nice to know if @storchaka found the bug or Claude did. Again, maybe “co-authored” is too vague. (Add a “bug-hunter” heading? ¯_(ツ)_/¯)
Back to the more general issue, I assume that Python’s core devs – like many organizations – are using Claude to find previously undetected bugs lurking in the code (sometimes for years). It would be useful to have an idea what the workflow is like for this sort of thing. Maybe something as simple as a q&a in the FAQ? If there’s something there already, my find/grep fu wasn’t up to the task. If that’s the case, I’d appreciate a pointer. If this has been discussed ad nauseum and you’re sick of it, a little blurb might go a long way to deflecting further inane queries.
Can you tell us more about what information you are looking for? A policy? Per-commit details of where and how Claude was involved? Overall notes about how individual core team members are using AI? Maybe something else?
That’s fine, but I think it would be worthwhile to reference that document from the code repository somewhere. I suspect there are others like me who no longer (or never did) actively work on core Python and thus wouldn’t immediately think to check the dev guide. I don’t want to burden the people who document this stuff. In the spirit of the Zen of Python (There should be one-- and preferably only one --obvious way to do it), just a reference is enough I think.
As I indicated, simply tagging “co-authored” in a commit message might not be sufficiently precise. Did Claude author the changed code? Did it find the bug? Did it suggest the feature enhancement?
While it occurs to me, is someone keeping score of bugs found by LLMs?
Most of this are my commits. With the help of AI I was able to close large gaps in tkinter and curses (it would take months or even years to do all this work manually, I would died from exhauting), implemented nice but complex features in re, and currently sweep through turtle, IDLE and imaplib issues. Just yesterday I opened 23 new PRs. I will publish more detailed reports later.
The PR mentioned in the original post was on easy side. The bug was reported earlier, and the AI created the PR from beginning to end. I ask to search for open bug issues and PRs in pearticular domain, the AI classifies them, then we move through the list by picking bug issues one by one (or more than one if they are related). The AI reads the issue, examine existing patches, writes a fix with tests and corresponding doc changes, run tests. Then I review uncommitted code. This does not differ much from revieving other people’s PRs, except that I do not need to wait hour for reply, and it is more tolerant to my bad English. Then I approve commit, and review the commit message and all changes yet one more time. Then I authorise push and creation of a PR, and move to other issue.
It is not always so simple, sometimes the process of revieving and polishing takes hours or even days (but I can work on several complex issues simultaneously). The AI is able to read documentation and sources of the underlying third-party library. For curses issues, it built the curses module agains two alternative curses implementations (NetBSD curses and PDCurses, which it downloaded and build itself), built with different modes (narrow and wide), ran tests with different builds on various locales and terminals. I could do all this myself (I did in past), but I would spent much more time on this.
So, some of these PRs are almost 100% AI generated, others are results of hard collaborative work. I am still better in writing optimal complex regexps, and my many years of experience allow me to spot a simpler way. In any way the decision is on me.
I agree that at present, mentioning the AI tells me nothing useful. It looks like a product placement. (Soon we shall have different companies counting how many PRs they’ve assisted in prominent free projects.) It can’t be a way of diverting blame for any shortcomings, since the human author bears all the responsibility. But in view of that, why do I need to know how it assisted?
When AI assistance becomes the norm, I think readers will find such text unnecessary.
I think there is the seed here of a process guide for good practice in the use of AI on the project, in the same way we have a Git cheatsheet and the “reviewing other’s PRs” section. I refer to those a lot in projects where I do that.
When AI assistance becomes the norm, I think readers will find such text unnecessary.
As a software developer for many decades now, I find it interesting that people consider adoption of these unproven months-old technologies inevitable when it may still be merely a passing fad.
When you see Co-authored-by: in a commit message, that is a default behavior of Claude Code and several work-a-like agentic harnesses (Codex, Antigravity?, Copilot?) when making git commits. We as a project intentionally leave the choice of whether to leave these in up to the individual contributor.
It is not feasible to meaningfully, in any accurate sense, track which bugs were found using what methods or how. That is up to the individual working on them to choose to describe if they want. This is not new, that statement applies pre-AI just as well.
For people who don’t want “Co-authored-by” on their own work when using these tools, it is configurable and you can also just leave instructions in your claude or agents markdown instructions file as to how you want your commits to look. If you change your mind after working on a branch, easy, just ask claude to rewrite the git history to your liking.
I intentionally leave these in some of my CPython commits (depends on the dev machine i’m using, on some i have it configured not to) and do not specifically aim to remove them from squashed commit messages in order to to get the point across that this is normal and perfectly okay to do.
Likely >90% of my own contributions in the past year have flowed through Claude Code regardless of whether commits say anything about that or not.
I’ll note that git Author: lines and Co-authored-by: text is wholly free-form and has no verifiable relation to actual human identities or who did what. Anyone can push commits with any text in them to git repos claiming to be whomever we want. How open source CLA systems operate is a choice by convention based on the only hopes of figuring out who the responsible human is as best we can. It is technically wrong to claim that free form git commit text actually carries any indication of identity at all. Legal council has generally been consulted about all of these CLA systems (including ours) as to what is an appropriate good faith effort.
Can text in commit messages be advertising? Yep. Any text can. Are these default generated co-authored-by lines? Quite possibly. That is one reason some projects choose to block them. Just respect the stated devguide wishes of any project you’re working on.
Pedantry around exact formatting and declarations of things adds developer friction to contributions. To the ironic point that it becomes easier for agents to comply than for humans.
I haven’t been using AI coding long by comparison!, but it multiplies my output by some large factor, while still allowing me to generate quality code that “looks like me”.
This is probably not that important in the grand scheme of things, but
This seems to not be in agreement with the following part of the AI usage guide:
We expect PR authors and those filing issues to be able to explain their proposed changes in their own words.
(Bold added by me)
This suggests to me that at least the PR message should be done in the developers own words.
If this is the way AI is used, I suggest maybe removing that paragraph from the guide or rewording it to make it clear this is not a hard requirement.
(In this case I personally have no preference either way. This post is not meant pro or anti AI, it is just pro-‘if there is a guide it should mirror the actual development culture’.)
I don’t see it this way. The expectation is to "be able to … ". To me it means that if anyone asks for more info, then I’ll explain more and elaborate.
