同じく。フロントエンドにはすごくいいよね。

面白いね、私は逆のことを感じてる。とはいえ、効果は少しだけど（多分50%くらい）。Ruby/Py/Javaのバックエンド開発に無理やり入れられたけど、日常の改善にはあまり役立ってないな。特にCに関しては、複雑だけど一般的なデータ構造をミスなく作り出せるから、自分なら一発でエラーを出しちゃうだろうな。趣味でCをやってるから、UIライブラリの仕様に基づいて動的なCディスパッチャーの配列を生成するような、もっと面白くて複雑な問題を解決することが多いんだ。Gemini Proは数回の試行/修正の後にYAML方言のパーサーを出力してくれたし。AIを使う問題の慣れ具合によるのかもしれないね。

これはGell-Mannの忘却効果に似てる気がする。最近、私の会社はコーディングのためのAIツールを調査してるんだ。遅れてるって思うかもしれないけど、私たちはDoDのコンサルタントで、ソフトウェア開発とはあまり関係ないところなんだ。だから、会社のほとんどの人はAIの出力にすごく感心してる。私は最近入ったばかりで、特に「ワイルドカード」として雇われたんだ。つまり、3000人の会社の中でソフトウェアに関して何をしているか知ってるのは10人くらい（それも多めに見積もってるけど、会社の半分も見えてないし）。だから、99.7%の人は良いソフトウェア開発がどういうものか分からないんだ。AIを使ってる人たちが出してるものは、ミルオプスのアナリストが書いてたPythonスクリプトよりはマシだけど、品質のあるソフトウェアとは言えない。バックエンドとフロントエンドの両方でかなりの経験があるけど、「生涯にわたって維持される必要があるソフトウェアを書くことに全く経験がない賢い人たちが書いたコード」よりは一歩上だけど、「生涯にわたって成功裏に維持できるソフトウェア」には程遠い。

最近、ちょっとシステム寄りのRustコードをいじってて、約1年前の初期のコーパイロットを使ってC++のシステムコードにも使ったことがあるんだ。この場合、スマートなオートコンプリートが大幅な時間節約になることが分かった。実際、インタラクティブな機能やエージェント機能よりも私には価値がある。最近のバッファにあるコードの一部を紹介するね： // すべての名前付き出力が統合されている場合、命令はスキップされるべきです。 if ! self.should_keep_instr(instr) { return; } // 非ドロップは選択肢を持つべきです。 let instr_choice = choices.maybe_instr_choice(instr_ref) .expect("命令に対する選択肢がありません"); self.pick_map.set_instr_choice( instr_ref, instr_choice.clone(), ); // PIR選択肢に対してすべての名前付き定義入力をインクリメントします。 instr_choice.visit_input_defs(|input_def| { self.def_incref(input_def); }); // SIR命令に対してすべての名前付き定義入力をデクリメントします。 instr.visit_inputs( |input_def| self.def_decref(input_def, sir_graph) ); 実際に私が書いたのはコメントだけなんだ。構文を打ち込む必要がないのはかなり大きな節約だよ。手動コーディングの80%はそれに費やされてたと思う。ちょっとしたタイプミスやフォーマットを整えるための微調整が多いからね。もう一つの良い点は、LLMを信頼する必要がないこと。各スニペットをその場で評価できるし、通常は機械が他のコードベースやファイルから構文スタイルやセマンティクスをうまく拾って適用してくれる。スニペットは明らかでない場合、私が作業しているコンパイラのバックエンドコードの一部からのものだよ。この支援がなければ、余暇にコンパイラのバックエンドを書くことなんて絶対に試みなかったと思う。経験豊富な開発者にとって、オートコンプリートは開発スピードの大幅な効率向上に十分だね。エージェントインターフェースにはまだ慣れてないけど、LLMが正しいコードを信頼性高く生成するとは思えないから、いつもレビューしちゃうし、グリーンフィールドコードのレビューは書くよりも多くの作業になることが多い（特に今はオートコンプリートが書くのを速くするのに役立ってるから）。

まさに私の経験と同じだね。エージェントにバックエンドコードの一部を書かせたことがあるけど、いつも小さな部分だけ。自分が書いてないコードでもすぐにデバッグできるくらいの経験があるから、失敗したときもすぐに対応できる（最初の実行から必ず失敗するけど）。AIを使ってレポートを書くのと同じで、アウトラインにはいいけど、詳細はいつも品質的にランダムな感じ。フロントエンドに関しては？私があまり専門じゃないところ（1997年にFrontPageで始めたHTMLの一部があるけど）、本当に助かってる。プロンプトには気をつけないといけないけど、今や多くのフロントエンドフレームワークは基本的にバックエンドコードだからね。

フロントエンドがただ通過するだけのものであればいいけど、仕事がフロントエンドに移行するなら最悪だね。自分でスキルを身につけることはできなくなるから。

低レベルのC/C++では、関連する定義をしっかり含めて、非明示的なコンテキスト（いろんなオブジェクトのライフサイクルとか）を提供して、プロンプトを集中させれば問題なく動くよ。「この既知のアルゴリズムをそのプロジェクト特有のデータ構造に適用する」みたいなことはすごくうまくいくし、時間も節約できる。メモリの組織に対する直感が必要なことは、モデルを見守る覚悟がないと上手くいかないね。

フルスタックエンジニアとして、チーム内で大体65/35の割合でバックエンドとフロントエンドを担当してるけど、毎日こういうのをレビューするのが本当に嫌だ。バックエンドの人がフロントエンドのチケットを書くのも、その逆も。先週も、バックエンドの人が書いたフロントエンドのチケットのレビューをしなきゃいけなかったんだけど、「90%はできてるから、引き継いでも大丈夫だよ」ってコメントがついてた。ほとんど全部捨てて、ゼロから書き直さなきゃいけなかった。俺の解決策は150行くらい修正したけど、AIの出力は機能しないし、見た目も悪いし、パフォーマンスも最悪で800行くらいあった。コミットメッセージも「素晴らしいものにした！！1!1!!」みたいな、全然役に立たない一般的なものだった。彼らを責めることもできないけど、Cレベルの人たちがAIに夢中になってるから、こういうことをやらないと scrutinized されて PIP されるんだよね。少なくともフロントエンドの人たちは、良い解決策かどうかわからないって謙虚に言ってくれるけど、バックエンドの人たちはなぜかフロントエンドの仕事をいつも軽視してる（このスレッドでも見えるし）。本当に不思議だわ。

サンプルサイズは16人の開発者じゃなくて、246件の問題だよ。

多くの人が絶賛する生産性の向上って、経験があればライブラリYを使ってXをやるのは簡単で、しかもそのライブラリYは結構人気で、LLMが一発で完璧にやってくれるって感じだと思う。そこで10〜20倍の効果が出るんだよね。でも、ニッチなことをやってると、うまくいかないか、うまくいっても効果が薄い。例えば、今ffmpegのフィルターがXのことをスムーズにやらない理由を考えなきゃいけないんだけど、そのフィルターのCコードは小さいし、自己完結してるのに…Geminiはコードにコメントを追加することを拒否するんだ。150行のコードにコメントを追加できないことを謝るだけで笑っちゃう。でも、Pythonでffmpegのパイプラインを構築する時は、プロトタイピングがめちゃくちゃ早くて、結構複雑なフィルターのチェーンを作るのが楽しかった。もし手作業でドキュメントを読みながらやってたら、もっと時間と労力、イライラがかかったと思うけど、Geminiと一緒にやるのは楽しかった。だから、研究に戻るけど、個人的には欠陥があると思う。オープンソースプロジェクトの新機能に取り組むことは、LLMの主な仕事じゃないから、ほとんどの人はそんなことしてないし、10000人が書いた同じコードを自分のちょっとしたアレンジで書き直してるだけなんだよね。