面白い取り組みだね。これらのリストの背後にある理由は何なんだろう？ AIポリシーに機能的な理由が思いつかない。動けばそれでいいじゃん、誰が作ったかなんて関係ないし。それに、AI生成のスラップを避けても、人間が生成したり人間+AIが生成したスラップをフィルターから完全に避けるのは無理だよね。でも、良い非機能的な理由は思いつくな。出所、責任、作業証明、自分でコードを書くことを促すこと、人間がコードベースをどう開発するかを実証的に追跡すること、などなど。

• ネガティブ: 提出者がスタイルマーカーを追加して、自分のアカウントや出力を人間が生成したように見せる。これは構文糖みたいなもので、コアコンテンツや貢献のサイズは変わらないけど、スタイルがちょっと変わる。私の経験上、ほとんどの貢献者はポリシーを読んでないよ。特に「クイックAI PR」を作る人たちはね。新しいポリシーがこれを大きく変えるとは思わない。> ポジティブ: 提出者が実際に要点を押さえた、無駄のないコミットやコメントを提供する。それは夢みたいだね。

完全に同意するよ。貢献者は良い意図を持っていても、冗長さや自動的に提出された問題の数がそれを台無しにする。数日前、人気のソフトウェアの小さなjsonベースのバグを見つけたんだ。それで、Claudeが書いた問題を提出したんだけど、説明がバグ自体よりも長すぎてさ :) だから、テキストを手動で短くしなきゃならなかった。これに対する/skillはないの？

AIが書いたコードを受け入れない理由は、ここが守られていないからだよね。=>「提出者が実際に要点を押さえた、無駄のないコミットやコメントを提供する」。人間の思考が権威主義に抵抗できる能力に過信しすぎだよ。AIは人間の監視なしにコードを人間らしくすることはできない。

まるで人間の思考に対するサービス妨害攻撃みたいだ。これは意図的な敵対的デザインの例かもしれないね。ユーザーにLLMベースのソリューションを採用させて、その膨大な出力を要約させようとしている。こういった文脈でAIの貢献に対抗するのは理にかなっている。特に、Godotのように価値提供の実績があるソフトウェアではね。

提出者は、自分のアカウントや出力を人間が生成したように見せるためにスタイルマーカーを追加する。 https://xkcd.com/810/

これがLinuxカーネルの元々のルールでもあった。パッチごとに200行を超えないこと。これをgitのコミットやプルリクエストの説明にも導入すべきだと思う。1. コミットごとに400文字/10行 1b. 初回のプルリクエストでは3つ以上のコミットを含めないこと 2. プルリクエストの説明は20行以内 3. 一度にオープンできるプルリクエストは3つまで

個人的には、内容が後者のカテゴリーに合っていれば、AI生成かどうかは気にしない。問題は、多くのAIの貢献がレビューなしでだらだらと生産されていること。正確性がきちんとレビューされたもの（実際に動作していて、明らかな副作用がないことをテストし、読みやすく理解しやすくするために調整され、プロジェクトの他のガイドラインに合致しているもの）は、人間だけの貢献と区別がつかないけど、そういう努力をしない人が多いから、大半はそんなに良くない。

AIが書いたコミットでも、人間が書いたように見えれば、開発者はちゃんと仕事をしたってことになるから、何も問題視されないよね。AIが書いたコミットが大きく違わないなら、拒否する必要もないし。だから、AIを使ったコーディングが減ることはないと思うよ。でも、それが目的でもないしね。

より良い方法は、強いスタイルガイドラインとローカル要件を持ったClaude.mdを提供することだね。そうしないと、AIからのものかどうかのチキンレースになっちゃうよ。