- GitHubとMicrosoftがGitHub Copilot Agentのパブリックプレビューを発表し、.NET Runtimeリポジトリで実際にこのエージェントがPRを自動生成するテストが進められている
- しかし、これらのPRには粗雑または不要な修正が含まれており、レビュー担当者が苦労させられている。Redditユーザーたちはこれを笑うに笑えない光景として受け止めている
- 例のPR:
- 投稿者は「これが業界の未来なら、自分は降りる準備ができている」と述べ、AI導入に対する疲労感と懐疑をあらわにした
- ただ同時に、「レビューを担当した社員には同情する」と強調し、この状況は上から降りてきたCopilot導入指示による負担である可能性が高いとも付け加えた
> 私の「schadenfreude（ほくそ笑み）」の対象は、AI誇大宣伝をあおっているMicrosoft経営陣です。開発者を尊重してください。
> * schadenfreude はドイツ語由来の単語で、直訳すると「害から来る喜び」。つまり、他人の不運にひそかに快を感じる感情
主なコメントの要約
1. AIが書いたPRは不正確で、文脈を理解しないまま単に「推測」を繰り返している
- 実際のPRコードが何をしているのか理解しないまま変更を提案している
- 繰り返しエラー修正 → それでも間違ったコード → また別のエラー修正…という終わりのないループ
- 「直しました」→「まだ間違ってる」→「今度こそ直しました」…という流れがJunior Devのパターンに見えるという意見も
2. 複雑な問題の解決には、むしろ余計に時間がかかる
- 単純な修正には役立つが、本当に時間を節約したい複雑な問題には役に立たない
- 問題理解 → Copilotの理解 → 比較 → 確認 → 手動対応が必要
- 実際には自分で直接解決したほうが早い
3. 企業リーダーの「AI万能主義」が開発者を疎外している
- 「Copilotを使えば遅れを取らない」というメッセージは、現場の開発者とかけ離れている
- PRレビュー時間は長くなり、責任は開発者に押し付けられる
- Copilotが作ったコードで学習したAIが、再びコード品質を悪化させる**「AIがAIのために学習するループ」**への懸念
4. AIは自信満々に「間違った答え」を出すだけで、「これが正しい」という確信はない
- 間違っているというフィードバックにも「修正しました！」→ さらに妙な修正案を提示
- 「これは問題ないコードだから、直す必要はない」という判断はしない
- これは法的責任回避のための設計かもしれない、という指摘もある
5. 継続的なAI導入の強制で、開発者体験は疲弊している
- 管理職の指示や実績評価のために、AI導入実験が続いている
- 開発者たちは、自分がAIのベビーシッターになったような疲労感を訴えている
- この流れが続けば「開発者はAIにうんざりして業界を去るだろう」という悲観的な見方も
主要な文言
- 「AIは、間違った推測を繰り返しながらも自説に自信満々なインターンみたいだ」
- 「Copilotのコードレビューに時間を使うくらいなら、自分で書き直したほうがいい」
- 「これは開発者が機械を助ける『reverse centaurs』状態だ」
- Cory Doctorowが使った言葉で、「私たちは機械の助けを受ける人間ではなく、機械を助けるよう強いられている人間だ」という意味
- 「Copilotは、開発者が雑な絆創膏を貼るのと同じだが、自動化されているので何千もの厄介な絆創膏になる」
- 「LLMのデフォルトは『間違うことはあっても、不確かではない』に見える」
12件のコメント
問題を投げて、答えが間違っていれば捨てる非同期ワークフローで生産性はかなり上がったのですが、これは静的ツールと似ていませんか？ とても進化した静的解析ツールだと考えれば、良い相棒です。正直、分析も速いし、ジュニアエンジニアよりもずっと詳しいです
AIは活用しているけれど、こいつが間抜けなので、こちらが修正してやれないとまともに実装できません。バイブコーディングでやっているのを見ると、どれもこれもエラーだらけのコードばかり……
LLMを使うたびに、いつもこんな経験をします。できない部分はどれだけ延々と指摘しても、結局ずっとできないままです。
最終的にはこちらが疲れ果てて、自分で分析して直すことになります。こういう経験が積み重なると、LLMだろうが何だろうが全部ゴミみたいに思えて、使う気がなくなります。
AIが人間にコーディングさせるよう逆プロンプトするというウェブ漫画を思い出します。
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
本当に、AIが人間のように問題解決と学習を同時にしない限り、起こり続ける問題のように思います
締め切りや要件さえきちんと守っていれば、コーディングするときにAIを使ったのか、IDEも使わず男らしくメモ帳だけを使ったのかなんて、あまり重要ではないでしょう。
これが単なる新技術だと思っていたときは、好奇心まじりの目で見ているだけでしたが、
今ではこうした技術を理由に実際に雇用主が採用や賃金カットを進めているので、あまり気分のいいものではないですね..
どうやらまだ過渡期なので、いろいろなハプニングが起きているようですね。
今後さらに良く変わるかもしれないし、このまま続くかもしれないだけに、どう変わっていくのかを見るのも面白そうですね（笑）
GitHub に Gemini をつないで PR レビューを受けているのですが、まさにああいう時がたまにあるんですよね。
すぐ上の行で null チェックをしているのに、null チェックなしで使っているとして、すぐ上にある行をそのまま同じように追加しろとレビューしてきたり。
人が業務をするときに自然に身につく背景知識や業務パターン、期待される結果やその形式などを
すべてプロンプトに書けるわけでもないですし、書けるとしても LLM のような複雑な AI ではなく、
ディープラーニング以前の従来型アルゴリズムで自動化するほうが現実的ではないか、という気もします。
使ってみると、バイブコーディングやコーディングエージェントには確かに便利な面もありますが、便利に使うにはプロンプトをかなり厳密に作る必要がありますし、そもそもプロジェクトの性質によってはうまくいかないものも多いですよね。MSA構造のWebサーバーのように、機能が簡潔に細かく分割されていればうまく働きますが、大きなモノリスに多くのモジュールが絡み合っていて、複雑なロジックをAIで修正しようとすると、かなり厳密にタスク計画を立ててプロンプトをきちんと作らないといけません。
Hacker Newsの意見
すべてのコメントに「Help improve Copilot by leaving feedback using the or buttons」というメッセージが付いているのに、実際にフィードバックが付いているのを見たことがない状況の面白さを共有。LLM活用時にシステムプロンプトの設定がきちんとしていないと、こういうことはよく起きるという体験談。いちばん笑ったPRの例としては、テスト失敗を直すと言いながらテストケースを丸ごと消したりコメントアウトしたり、assertionをそのまま変えてしまうもの。GoogleやMicrosoftのモデルはOpenAIやAnthropicよりもこういう状況をより頻繁に見せる気がするという推測と、各社の内部プロセスの違いが結果に表れているようだという話。実際のPRで人間が3回さらに指摘した末に諦める過程の紹介。こうしたPRをレビューする人たちの気持ちは想像するのも難しく、まるで言うことを聞かない新人開発者を相手にしている感じだが、そもそも文脈理解自体がない存在。特定のPRの90%が「Check failure」で埋まり、コードや差分自体を確認するのが難しい例や、単体テストに「Test expressions mentioned in the issue」としか書かれていない悲しさ。もしこういう状況が人間側にとってあまりに苦痛でなければ、本当に面白い出来事だという率直な意見
新人開発者との比較は大げさすぎる。自分も新人開発者と一緒に働いているが、彼らはLLMのようなおかしなミスを頻繁にはせず、そこまで手もかからず、すぐに学ぶ。LLMは注意深く使うべきそれなりに良い補助ツールで、速度改善にも役立ち、アイデアのブレインストーミング相手としても悪くない。ただし、インターンや本物の開発者の代わりにはなれないという考え
ソフトウェアエンジニアリング分野に80年代後半に入った頃には楽しさがあったが、今では面接プロセス、中小企業のビッグテックごっこ、そして現在のAI PR実験などによって、有毒な環境へと変わってしまった。今日、プロの開発者としての仕事に本当に喜びが残っているのか懐疑的だという感情
少なくとも新人開発者には、PRを送る前にローカルでテストを回してみろと言うことくらいはできる。いずれ人間の開発者がただ諦めて「AIゴミ」PRを閉じ、ちゃんと動くものだけ残してあとはすべて捨てるようになるのではないかという懸念。機械の実験を延々と耐え続け、限界に達したら皆が疲れ果ててやめてしまう日が来そうだという考え
わざわざフィードバックシステムが必要なのかという疑問。開発基準では成功とは最初の試行でマージされるPRであり、失敗とはエージェントが要求された修正の回数ぶん累積的に悪化していくことだと捉えられる。手動フィードバックの要求は非効率であり、開発者と同じようにサイクルタイム、承認率、変更失敗率といった指標で成果を測るほうがよいという主張
Microsoftサポートとやり取りしたとき、壁に向かって話しているような感覚を覚えた経験の共有。いくつものケースを起票しても満足のいく解決に至ったことはなかった。Microsoftが自社の技術を自分たちで使ってみるのは理解できるが、それをこちらに強要しないでほしいという願い。Microsoftにはサポート体制の整っていない製品をリリースしないでほしいという意見
最近、GoogleのEricがAIについて話す動画を見た経験。この人物はAIが現在過小評価されていると主張していた。ロケット会社を買った理由や、Deep Researchなどの非専門分野にAIで挑戦する過程で「自分は専門家ではない」と強調していた点を引用。自分もAIが嫌いなわけではないが、現世代のパターン復元ベースの生成AIは「初心者を感心させる」能力に長けている。その分野の知識がなければ結果はすごく見えるが、深く知るようになると穴がすぐ見えて失望する。Microsoftのように最前線で働く人は何が問題かを明確に理解しているが、経営陣、特にEricのような人物は、AIが派手なことを言うだけでも簡単にだまされやすいという欠点がある。いつかAIがきちんと動くコードを直接書ける日が来るだろうという期待はあるが、今はまだ遠いという見方
AIは注意深く、ごく限定的にしか使わないという自分のやり方。一方で、ああいう「ロケット会社を買った」億万長者たちはAIに熱狂し、自分たちの資産をさらに膨らませる投資判断にも使う。たとえ大失敗しても失うのはアクセサリーの一部程度で、社会的な変動には大した痛手にならないだろう。反対に、現場のITの仕事はどちらに転んでも悪い結果につながりかねないという危機感
専門家ではないリーダーがAIに簡単に感心してしまう状況とあわせて、Googleが米軍と協力し、大規模な自律型ドローンにGeminiを搭載したら何が起きるのか想像してしまう
Microsoft社員が実際の問題を解決する代わりに、LLMと何時間も言い争っている様子を見ることが、.NET上に製品を構築している企業にどれだけの信頼感を与えるのか疑問
以前、LLM導入前からGitHub issueでユーザーが問題をうまく説明できず、管理者がだんだん苛立っていく場面を見たことがあった。今では、苛立つエンドユーザーすらもう必要なくなった
むしろこういう結果こそ、ひどい管理と雑な指示の自然な帰結だ。今回はもう新人のせいにはできず、自分たちだけを責めるしかない状況だという見方
とりわけ、有名な .net パフォーマンスブログで知られるStephen Toubまでこうした過程に参加しているときのつらさを強調
こういう新技術の実験を止めたいわけではないが、違いは、今はその実験が皆に公開されているだけだという説明
Microsoftは昔から問題が起きると「そのエラーは無視しろ」というようにWill Not Fixで流し、管理者の自己満足に浸る文化があったのだから、結局いま起きていることはすべて自業自得だという皮肉な主張
最初のPRに付いたコメントで文脈を説明。さまざまな実験を通じてツールの限界を把握し将来に備えており、マージの責任は従来のPRと同じくメンテナにあること、品質基準を満たすまでは何もマージされないことが述べられている
そのコメントを書いたMicrosoft社員は、AI活用を真剣に考えないなら取り残されるという意見も示していた。MicrosoftではAIによってソフトウェアエンジニアリング業界がひっくり返るのではないかという不安と興奮が渦巻いている雰囲気があり、この実験はツールの限界把握というより仕事を守るためにやみくもに乗っているようにも読めて、かえって信頼感が下がるという受け止め
管理者たちはモデル能力についてすでに結論を出しているわけではなく、現実世界の文脈で強みと弱みを把握するための合理的な実験だという点を理解すべきだという意見
CIを通っていないPRをわざわざ誰かにassignする状況自体がおかしい。少なくとも通ったPRだけ割り当てるべきで、そのくらいは正常なら当然できるはずなのに、システムがあまりにぐちゃぐちゃでそれすら不可能に見えるという冷笑
すべてを最悪のシナリオとして解釈しないでほしいという願い。実際に関わっている人間たちは実験であることを理解し、期待値も調整されているはずだ。こうした実験的アプローチなしにシステムは進歩しにくく、実環境でチューニングやテストを進めているのかもしれない。自分の会社でもAIコーディング支援ツール導入初期に同じ実験をしたが、人間が直接コーディングした場合よりコード品質は悪かったものの、その過程で多くの新しいことを学べた。基準点ができたことで改善の推移も明確に分かった
コメントには、ファイアウォールの問題でテスト通過可否を確認できない状態だという説明があり、その問題さえ解決すれば正常に動作する可能性がある
AIエージェントの代わりに別の新技術を当てはめてみても、以下のような企業の典型的な姿に見える。オープンに実験すること（ビッグテック式のdogfooding）、業界の技術力向上に実際に貢献すること、問題が起きても被害は完全にチーム内部に限定されること。こうした実験を支持しない理由は特にないのではないかという問い
こうしたオープン実験にひたすら非難ばかり集まる空気が不思議だという意見。非公開forkに隠さず、実際の能力を透明に公開するほうがはるかに有益であり、営業やマーケティングの大げさな宣伝よりましだと考える
ソフトウェア開発の中核インフラとなるフレームワークでこういう実験をするのは議論の余地がある
「私たちが」なぜ、どうやって、何を支持・不支持しなければならないのか分からない。個人的には、MSが大げさに失敗している様子がただ面白いだけだという声
本当の「進歩」とは呼びにくい。内部POC（事前検証）もなしに対外的にシステムの問題をさらしたのはむしろ無責任であり、ファイアウォールなど基礎的な環境検証や、他の社内コードベースで先に試さなかった理由も疑問だ。インフラコードには高い基準が必要なのだから、たとえdogfoodingを名目にするにしても下位プロジェクトから始めるべきで、「state of the art」ですらないという批判。投じたコストに対して結果があまりに粗雑だという冷笑
多くの開発者が依存している人気プロジェクトでこうした実験をするのは問題で、AIが作ったひどいコードによって品質低下が懸念される。役に立たないコードが積み上がったり、チームメンバーの生産性だけを削ったりする危険がある
何かへの受動的な服従なら、依頼をレビューもせず全部承認してしまい、Microsoftの技術スタックが世界的に崩壊したらそのとき退職して、コンサルタントとして3倍の給料をもらえばいいという皮肉な提案
そんな皮肉な態度で仕事はしたくない。会社の経営陣との敵対的な「我々対彼ら」という構図や、わざと壊そうとする発想そのものが理解できない。不完全さに不満を持つことと、組織全体を妨害したり攻撃したりすることは別であり、自分の良心には合わないという意見
そもそもMicrosoftの技術スタックはもう壊れているのでは、という皮肉な反応
実際には、Copilotで生成したPRそのものを運営側が直接提出しているのだという指摘
いつかCopilotがコードベース全体を上書きし、コードがなくなればテスト失敗もなくなるだろうという冗談
いつでもレイオフ対象になり得るのだから（TypeScriptコンパイラをGoで作った人のように）、こういう組織にわざわざ忠誠を尽くす必要はないだろうという意見
PRを開くこと自体は少なくとも安全な実験方法であり、役に立たなければすぐ破棄できる。新しい試みには常に試行錯誤と失敗が伴うが、その経験自体が重要であり、実際のコードと実際の問題で厳しく鍛えればツールは急速に発展しうるという期待。たとえば将来は、テストが通るまで反復学習する機能や、テスト削除を防ぐチェックなどの改善が行われるかもしれない。結局、開発プロセスの反復的で単純な仕事はAIが担い、開発者は本質的で創造的な作業に集中する未来を予想
ただし、こうした実験はパブリックリポジトリではなく非公開forkで行うほうが安全であり、営業面でもこうした事例が公開されたのが正しい判断だったのかは疑問。社内の意思決定者が雑誌でCopilotを見て同じことをやろうと言い出したとき、こうした現実の事例は参考になるかもしれない。たいていの企業はアプリケーションの不具合事例をできるだけ隠し、完成度の高い姿だけを見せるのが普通だ
表面上は問題なさそうに見えるPRにも、目立たない問題が潜んでいるのでむしろ危険だという指摘
AIコードレビューは、単純反復作業よりむしろいら立たしいという体験。特にバグが潜んでいるときは、開発者の苦労がさらに増える
PRを開くこと自体がプロジェクト管理に負荷と複雑さを加える。別forkで実験するほうがコミュニティにとって良い前例になるだろう。多くのオープンソースプロジェクトでは、積み上がったPRの管理に疲弊してメンテナンス自体が止まったり、誰かがforkして生き残ったPRだけ拾っていくようなことがよくある。こういう形で放棄されたプロジェクトやforkが増えるのではないかと心配している
もしLLMが本当にバグのある状態からまともにコーディングを学習できると信じるなら、その後にはバグがほとんどないデータセットの構築が必要になるはずだ。しかし実際にはそうなっておらず、ただ何でもかんでもデータをかき集めているのが現実だという批判
GitHubは、世界で最も成熟したリポジトリの1つで、空白に関するlintにすら頻繁に失敗するAIを何十億ドルもかけて作った。趣味の実験ならともかく、実際の価格を付けて「革新的な製品」として売るのは議論を呼ぶ
研究者の立場なら当然の実験だが、問題はそういう未完成の状態のものを今すぐ売っている企業の姿勢だという指摘
元CEOのNat Friedmanは「もう亡くなっているだろうね……いや、まだ生きているか」という冗談
本当の問題は、ソフトウェア開発者の成果測定に客観的な指標がないことだ。年末評価のような主観的評価しかない状況では、AI活用が実際に効率的なのか非効率なのかも把握しにくい。juniorより安く見えても、seniorの時間を浪費し、指示にも従わず、さらにCEO崇拝と結びつくことで組織内の意見の不一致が深まる。開発者の反発は「代替されることへの恐怖」として片付けられ、CEO側は推進成果を最大化する。どちらの側にも皆が同意する業界標準がない以上、真実は把握しようがなく、極端な推論をすれば、組織がAI PRを増やすためにレビュー基準そのものを下げるよう求める可能性すらある