プロジェクトのメンテナーとして、みんなが守らないって分かってるようなルールを作るのはよくないよ。そういうことをすると、無力に見えちゃって、ルールへのリスペクトも薄れるから。ルールを作ることで期待を示したり、道徳的な立場を取ることができるって言うかもしれないけど、ルールとして装飾しなくても意見を表明することはできるよね。でも、そういうやり方では偽善者になっちゃうかもね。

ちゃんと気にした方がいいよ。誰かが大きなPRを出したら、その意図を理解するのに時間を無駄にすることになるから。もしその人が自分でレビューしてないって分かってたら、次のステップのためにLLMに戻すことを考えた方がいい。レビューされてない生成されたPRでも、望ましい結果を得られれば次のLLM作業の出発点にはなるからね。でも、著者の意図を考慮して詳細なコメントをしたり、コードを書いてない人が質問するのは時間の無駄だよ。だから、貢献が生成されたものかどうかを知る必要があるんだ。

PRがどこから来たかは重要だよ。レビューアーは完璧じゃないし、限られてるから、必然的に信頼が関わってくる。だから「これがどこから来たのを信頼できるか？」って考えなきゃいけない。その答えを出すには、どこから来たかを知る必要がある。信頼が重要じゃなかったら、Linuxカーネルチームがミネソタ大学をPRプロセスを通じてバグを意図的に持ち込もうとしたことで禁止する必要なんてなかったはず。今のところ、もしあなたやあなたのPRが信頼できないなら、レビュー過程にすら入れない方がいいよ。

「ただのツール」とは言えないね。AIは結果として得られるコードの所有権が明確じゃない新しい種類のツールを導入してる。もし、ディストピアな未来で、あなたが受ける裁判所がClaudeがOracleのコードで訓練されたと決定したら、Claudeのユーザーは著作権侵害の可能性がある。そうなると、すべてのAIの貢献を一掃するのが簡単になる。

片方がもう一方よりも「スケーラビリティ」がはるかに高いと、もう一方はそれに合わせようと強い動機を持つことになる。 - 人々はカバーレターを書くためにAIを使ってる。もし企業がそれを自動的にフィルタリングしなければ、終わりだ。 - 企業は候補者の面接にAIを使ってる。誰もロボットと話すために自分の時間を使いたくないから、候補者はAIを使って面接を受けさせるようになる。などなど。少なくとも自分自身に「AIのPRは許可しない」と言わないと（たとえそれが白い嘘でも）、いつかAIを使ってPRをレビューすることになるよ。

PRの最終結果に至るまでの過程なんて、正直どうでもいいんだよね。AIを使ってオープンソースプロジェクトに対して1,000個のPRを今日中に作れるし。君は気にしてると思うよ、誰かがちょっとAIを使ってちゃんとしたPRを作るハッピーパスだけ考えてるんじゃない？AIを使ってプロジェクトのメンテナーを簡単に圧倒する方法はいくらでもあるからね。

メンテナーがPRを出す前に「ジャンプしろ」って言ったら、丁寧に「どのくらい高く？」って聞くか、「フォークしろ」って言うんだ。

君はリンク先の内容からの主な理由を取り上げてないよね。「経験の浅い貢献者を支援して、ゴールまで導くのが僕の役割なんだ。PRが受け入れられるのは誇りに思うべき成果だから。でも、もし向こうにいるのがただのAIなら、そんな努力をする必要はないし、騙されてやらされるのは失礼だよ。」

現実として、いくつかのOSSプロジェクトを維持する手助けをしている者として、AI支援ツールが生み出した問題を過小評価しすぎてるよ。一方で、特定の貢献のための参入障壁が下がったのは事実。でも、プロジェクトの仕組みを全く理解していない人からの、雰囲気で書かれた1k LOCの差分を受け取るのは深刻な問題だよ。フィードバックを得て正しく実装するための反復サイクルが、これだとかなり悪化するからね。また、人間とAIツールで導入されるエラーの種類もかなり違う。AIの使い方を開示するのは小さなお願いだけど、役に立つことだよ。

同意するよ。AI（コンプリーションとクロードコード）を使っている者として、聞かれたら必ず開示するけど、明示的に聞かれない限り「一般的な礼儀」だとは思わないな。多くの人（僕も含めて）は気にしないし、多分AIが使われていることを前提にしていると思うし、すでに様々なことに対して無駄な小さな指標がたくさんあって、逆に気が散るからね。

そうなるかもしれないね。でも、AIが大量に見た目は正しいけど結局は悪いコードを生成できるから、人々がAI生成コードに偏見を持つようになるのは、AIの問題であって人間の問題じゃないと思う。AIのコーディングツールがもっと良くなるべきだね。

それっていいことじゃない？

知識のある返信をして「chat-gptを使った」と言うと、コメントはすぐに埋もれちゃう。知識のある返信をしてAIのことには触れなければ、コメントは称賛される。もうすでに「AIの使用を隠す」道を全速力で突き進んでるよ。

それは違うと思うな。ミッチェルは自分がLLMを使ってるって書いてるから、白黒はっきりしないよ。自分の変更を深く理解していて、便利さのためにLLMを使ったPRの著者は、信頼性を失うことなくそのことを伝えられると思う。

いい指摘だね。それがまさにポイントだよ。パッチを書くのにAIを使うな。全く。なんで驚いてるの？企業は「正直な」人を雇いたいと思ってるの？その履歴書がLLMに書かれたら。

AIが書いた仕事を読むのは楽しいし、非支援のPRよりも良いことが多いよ。

誰もAIを使うなとは言ってないよ。ここでの意図は、PRでのAIの使用について正直でいることだよ。

まるでそれが問題かのように聞こえるね。

あと、StackOverflowやほとんどの教科書も禁止すべきだね。現実として、プログラマーは他のプログラマーのコードを見ることになるから。

「AI」を使うとIPの汚染もあるよね。みんなそれを無視してるだけなんだ。お金のインセンティブがない人がIPや著作権の問題があるって思ってるとは思えない。幸いなことに、ほとんどの人がそれを無視していて、法制度もちゃんと機能していて、進歩を止める隙を与えてないよ。

裁判所（少なくともアメリカでは）は、取り込んだデータをトレーニングに使うことが変革的だとすでに判断してるよ。細かいことはまだたくさんあるけど、もう元には戻れない。確かに、IP法を再考して、生成されたIPが経済的な成果物として有効であり続けるという社会的な欲求に合わせるのは大変だけど、それが必要なんだ。

俺も同じような経験をしてるよ。今、うちの職場では「ハックウィーク」をやってて、全員がグループでAIツールを使って実験できるようにしてる。特に普段使わない人たちがね。分析的アプローチやガードレール、グラウンデッドジェネレーションの素晴らしい応用が見られたよ。俺の視点かもしれないけど、チャットボットのハイプからしっかりしたMLへの急激なパラダイムシフトがあったように感じる。

AIは扱う人間の賢さ次第だよね。僕もこの考え方に少しずつ賛同し始めてる。どうしてこんなに多くの人が全然違う経験をしているのか、全然理解できなかったんだ。AIは魔法じゃないし、チームメンバーに説明するのに苦労している人たちが、ほぼ完璧な文脈を持っているのに、AIに価値のあることを伝えられるわけがないじゃん。最初はAIがほとんどのエンジニアをより高いレベルで働かせると思ってたけど、実際は普通のエンジニアと優れたエンジニアの差を大きく広げるだけのように思える。まだそのことについてどう感じるかは分からないけど、少なくともなぜ一部の人がこの技術を無駄だと思っているのかは理解できるようになった。

俺が考えてるのは、人間が重要な決定をして、AIがそれをつなげるってこと。重要な決定とつなげる点はアプリやドメインによって違うけど、一般的にコードの大部分はつなげる作業だから、正しく線を引けば大きな生産性向上が得られるよ。逆に、AIが重要な決定をするように線を引くと、ひどいことになる。そういう場合は、AIが作ったものを全部削除して、最初からやり直した方がいいよ。通常、重要な決定とは： - データベースのテーブルレイアウトとインデックス - コアタイプ - 重要な依存関係（影響が少ない場合を除いてAIに選ばせないこと） - システム設計—キャッシュ、キューなど - インフラ設計—VPCレイアウト、ネットワーク権限、秘密管理 - UI画面が何で、何が含まれているか、ユーザーフローなど - カラースキーム、タイポグラフィ、視覚的階層 - 何をテストして何をテストしないか（AIに任せると不必要なテストやテストの複雑さが増える） - コードの整理：ディレクトリレイアウト、コンポーネントの境界、DRYにするタイミング 通常、つなげる作業とは： - CRUDのためのデータベースアクセスメソッド - APIハンドラー - APIリクエストを行うクライアントサイドのコード - データを再構築したり、型を変換したりするヘルパー - デプロイスクリプト/CIとCD - 開発環境のセットアップ - テストハーネス - テスト実装（何をテストするかを決めるのとは別） - UIコンポーネントの実装（クライアントサイドの型とデータモデルが整った後） - スタイルコード - データクリーンアップや分析のための一時的なスクリプト どちらの側も網羅的ではないけど、要はそういうこと。AIもリサーチやアイデア出し、選択肢の探求、問題点を指摘するのに役立つけど、最終的な選択とそれに対応するコードを書くのは人間が手動でやるか、かなり近くで監視しながらやるべきだと思う。

AIはそれを扱う人間と同じくらい賢い。面白い意見だね。「AIを使って一日でこのクールなライブラリを作った」ってスタイルの投稿は、質の高いライブラリをすぐに出すことで知られている本当に賢い開発者たちによって書かれているからね。

今日、フレデリック・P・ブルックスのエッセイ「ノー・シルバー・バレット、リファイアード」の結論部分で次のことを読んだんだ。とても的を射た内容で、真にポジティブなメッセージで締めくくられているから、章全体を引用するよ。 > ネット上の弾丸 - 立場は変わらず > だから、基本に戻るんだ。複雑さが私たちのビジネスであり、複雑さが私たちを制限している。1988年にR.L.グラスが書いたことは、1995年の私の考えを正確に要約している。 >> では、振り返って、パーナスとブルックスは私たちに何を言ったのか？ソフトウェア開発は概念的に難しいビジネスだということ。魔法のような解決策はすぐそこにはないということ。実務者は革命的な解決策を待つのではなく、進化的な改善を検討する時期だということ。 >> ソフトウェアの分野の中には、これを落胆する絵だと感じる人もいる。彼らはまだ突破口がすぐそこにあると思っている人たちだ。 >> でも、私たちの中には、現実主義者だと思うほど頑固な人たちがいて、これを新鮮な空気のように感じている。やっと、空想ではなく、もう少し実現可能なことに集中できるんだ。今こそ、来るかどうかわからない突破口を待つのではなく、ソフトウェア生産性の漸進的な改善に取り組むことができるかもしれない。

今はvscodeでspecsytoryとcursorを使ってるんだけど、これがすごく便利なんだ。全てのLLMとのやり取りをきれいにmdドキュメントにまとめてくれるし、ソース管理にチェックインしておけばPRに含められるし、コードレビューの時にも参照できるよ。

レビュー中にメンテナーが集中できるように助けるんだ。もし君がそのままの文を書いたら、メンテナーは「コードベースの理解」を誤った仮定の潜在的な源として、より意識するようになるよ。

僕はあまり開発者じゃないけど、答えを探すためにコードベースを掘り下げることがよくあるんだ。AIアシスタントのおかげで、これがすごく早くなったよ。これは僕にとって大きな助けになってる。