80コミット全てClaudeと共著

これらのコミットを支えたワークフローは、モデルが入れ替わっても同じままだった。バグ報告はWordPress.orgのフォーラムかメールで届き、claude.aiのチャットに取り込んでコードを読ませ、原因と修正をまとめた引き継ぎドキュメントにする。そのドキュメントをClaude Codeに渡し、変更を実装させてコミットを生成する。9月15日の一例では、チャット回答下の参照カードが無関係なページを指すというフォーラム報告を追跡したところ、ベクター検索の結果にフラグが立っていないことが原因と判明し、同じ日の午後にOpus 4.8との共著で1.19.5のコミットが生まれた。

引き継ぎドキュメント自体も決まった形に沿っていた。症状、原因があるファイルと行、直す点と直さない点、検証項目、changelogの下書き1行。開発者は、この均一な入力がコミットの形式をこれほど一貫させたのかもしれないと示唆する。80件のうち60件が同じコミットでreadme.txtを更新し、80件のうち50件の件名がバージョン番号で始まっていた。ただしこれは推測であり、引き継ぎドキュメントを使わない場合と比較したことはないという。

記録からは分からないのは、人間の判断がどこで終わりAIの判断がどこから始まったかだ。共著行はAIの関与を示すだけである。9月30日、PDF Image Creatorは画像再生成の作業をめぐって1日に8回のリリースを出したが、それをどう8回に分けると決めたかは記録されていない。価格や締め切りの判断、PowerShellでStripe APIを叩く、レンタルサーバー上のImageMagickを調べるといった実サーバーでの確認はコミットの外で行われ、リポジトリには痕跡を残していない。