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

面白いね、私は逆のことを感じてる。とはいえ、効果は少しだけど（多分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人が書いた同じコードを自分のちょっとしたアレンジで書き直してるだけなんだよね。

これは俺のLLMをツールとして使った経験に似てる。すでに深く慣れ親しんでいるプラットフォームや言語、フレームワークで作業している時は、あまり時間を節約できないと思う。この文脈で使おうとすると、状況によっては時間を節約できることもあるけど、逆に時間を浪費することもあって、結局トントンになることが多い。俺にとっては、そのトントンは、コードに触れられなくなる長期的なコストには見合わない。でも、あまり詳しくない環境では、技術的なドキュメントやコードサンプルを試行錯誤するよりも、ずっと楽に始められる経験を提供してくれる。

使い方を理解するためにあちこち探す。Leafletのドキュメントは、コピー＆ペーストできる例が載ってる1ページの文書だよ。上にページナビゲーションもあるし、ctrl/cmd+fでキーワード検索する方がプロンプトを書くより早いみたい。

それで、君が稼いでるお金はどうなの？それって指標にならない？君は多分俺より稼いでるから、同じことをしてても君の方が成功してるってことだよね。

なんで誰かがこれを判断できると思うのか、ちょっと混乱してる。医者や弁護士、ジャーナリスト、パティシエの生産性を測れるのか？ どんな仕事がそんなにシンプルで、労働者のポジティブな影響とネガティブな影響を意味のある形で測れるのか、さらに労働者間の条件の違いも考慮できるのか。プロのポーカープレイヤーの生産性を測ることができるという考えには賛成できるかもしれないけど（評価期間が長ければね）。他に思いつくものはあまりないな。

チームメンバーは誰が生産的で誰がそうでないかをいつも知ってるけど、一般的には管理職に密告しないよね。そうすると、自分に不利になるか、同僚との対立を引き起こすから。チームレベルの生産性が会社にとってポジティブなものに必ずしもつながるわけじゃない。管理職は、ゲーム化されたり不正確なさまざまな指標に頼らざるを得ない。

でも、それでも生産性は客観的に存在するよね。人やチームによって生産性は違うし。標準的な「ノーマライズされた」タスクで生産性を比較する方が簡単かもしれないけど、プログラマーに与えられるタスクは毎回違うし、開発者によっても異なるタスクが与えられる。実際の仕事に基づいて生産性を測るのは難しいけど、人工的な実験を作ることはできる。N人のプログラマーに同じMの「普通」の日常タスクを与えて、AIツールを使っている人がそれをより早く終わらせるか観察するんだ。これは、運動競技に似てる — 本質的には人工的だけど、ランナーのパフォーマンスを比較する方法として広く受け入れられてる。

こういう研究のために、生産性を測ることはできるよね。同じタスクを与えて、どれだけ早く欠陥のないソリューションを作れるかを測るとか。ただ、残念ながらこの研究ではそれができてなかったんだ。開発者たちが自分でタスクを選んだから。

それに関しては、「プロダクト」をどう定義するかも関係してると思う。僕はずっと「出荷」するソフトウェアを書いてきたから、自分の「プロダクト」が何かは言いやすい。でも、僕はかなり小規模なチーム（ほとんどが自分一人）で働いてきたんだ。チームを管理するためにお金をもらってたけど、実際は小さなチームで、成果も測りやすかった。個人的には、フリーのオープンソースのソフトウェアを書いてきたから、それも測りやすかった。前に、ほとんどのソフトウェアエンジニアが実際には何も出荷したことがないって話を見たことがあるけど、全く想像できないよ。それはすごく落ち込むと思うし、生産性を測るのも難しくなるよね。もし僕が6ヶ月間、何かに取り組んで、それが全く出荷されなかったら、全ての努力が無駄だったってことになるのかな？それに、経験豊富なエンジニアは、実際にはずっと少ないコードを書く（でも、もっと多くのことをする）。彼らは4時間かけて、効率的な20行のメソッドを書く一方で、経験の浅いエンジニアは2時間で100行のまあまあなメソッドを書くかもしれない。経験豊富なエンジニアの仕事は「一発で終わり」になることが多く、修正が必要ないことが多いけど、経験の浅いエンジニアの仕事はバグだらけで（何百万ドルのセキュリティ脆弱性の負債を抱えている）、実際には経験豊富なエンジニアの生産性が先送りされることになる。マネージャーは、経験の浅いエンジニアの仕事が好きかもしれない。なぜなら、彼らは騒がしくて、早くて、たくさんの行を提供するから。将来的な技術的負債なんて、マネージャーには関係ない。僕が働いていた会社では、エンジニアが出荷後2年経ってから問題が出ても責任を持たされていた。だから、エンジニアはちゃんと宿題をやるように促されて、各チームにはバグを出さないようにするための専任のテストセクションがあった。例えば、ChatGPTにコードの解決策を求めると、だいたい「素朴」な（ちょっと冗長な）ものが返ってくることが多い。結局、僕はそれを再構築することになる。でも、それが悪いことだとは思わないよ。役立つ「出発点」を提供してくれて、実験に数時間の時間を節約できるから。

実際、最適化したいと思っていることのほとんどを定量化することはできない。

正直、AIを使ってコーディングした経験から言うと（主にClaude Sonnetを使ってる）、その「余分な47%」はほとんどが技術的負債だと思う。AIがループを使わずに同じことを繰り返してる部分とか、実際には何もテストしないテストを書いてる部分とか、単純な抽象を作れずに手作業で同じことを続けてる部分とか。AIは、私の経験上、簡潔さが苦手なんだよね。逆に、コードが悪化することもあるし。人間は簡潔すぎることがあるけど、同じレベルではないから不思議だよ。

AIタスクでは平均して47%多くのコードを生産したけど、時間は20%しか増えなかった。このレポートはその点を偏って扱ってるけど、ちょっと気になるのは、追加されたコードは余計だったのか、それともより良い構造を生んだり、負債をうまく管理できたのか？もしその47%のコードが長期的に負債を減らして、より一貫したスループットにつながるなら、負債でプロジェクトが潰れることを考えると、受け入れるかもしれない。逆に言えば、コードが47%長くなるのは、技術的負債が増えて悪化してるからじゃない？（例えば、関数にまとめる代わりに複数の場所でコードが繰り返されるとか。）

僕には過激な意見がある：全てのソースコードは技術的負債だ。コードの量を増やすと、負債も増える。もっとコードを増やしても、負債は減らせない。負債を減らす唯一の方法は、コードを減らすことだ。（ここでバイト数でコードを測っているわけじゃないからね；単一文字の変数名に切り替えても負債は減らない。文、式、命令で測っているから、それらを機能を減らさずに減らすことで負債が減るんだ。）

俺もそう思う。これは怠け者のためのツールだね。

いくつかのメンタルブロックを乗り越えるのに役立つよ。間違ってても、コードを見ながらアイデアを考え始めることができるからね（ライティングと同じように）。プロトタイピングのために使い捨てコードを書くのが悪いとは思わないし、どうやって取り組むか分からないプロジェクトを始めるにはいい方法だと思う。ウォーターフォール（前もってたくさんのリサーチとデザインをする方法）も、AIを使わなくても結局はうまくいかないと思う。

特定のシナリオでLLMを使うことが多いな。例えば、(i)「ライターズブロック」に悩んでいる時や「始めるのが難しい」時、(ii) 普段使わない言語やフレームワーク、(iii) 疲れてたり、燃え尽きてたり、やる気が出ない時。自分が「ゾーン」に入っている時はLLMには近づかないけど、「ゾーン」から外れた時には、戻るための便利なツールになるし、1つのタスクを終わらせるのにも役立つと思う。「LLMの利用が開発者の生産性を助けるか妨げるか」という問いには、「使い方次第だよ」と言えると思う。

その変動がすごいと思う。勝つ時は本当に大勝ちするけど、負けるとその週が台無しになることもある。10倍から20倍ってのは比喩的な意味だよね。ボリュームで20倍はできるかもしれないけど、スティーブ・バルマーの表現を借りると、それは飛行機をキロで測るようなもんだ。すでに自分の能力の限界で、高い複雑さや認知負荷、詳細が多いタスクをこなしている人にとっては、完璧なコードを渡されても実際の出力を20倍にはできない。たとえ20倍の洗練されたソースファイルをもらっても、それを構築してデプロイすることはできないし、変更を加えることもできない。でも、すでに限界で頑張っている時に、最後の5〜20%を助けてもらえるのは大きい。そうすると、「現実的じゃない」から「やった！」に変わることがある。

Claudeが最も役立つのは、非常に特定の知識が必要な問題に対してだね。例えば、「これがうまくいかないのはなぜ？」とか。「この90ページのPDFを読んで、SDKとのインターフェースでどこが間違ってたか教えてくれ。」ああ、async_context_thread_safe_pollの代わりにasync_context_background_threading_safeを渡しちゃったから、今パニックになってるんだ。これには時間がかかるところだったな。

オープンソースのプロジェクトで見せられるものある？

こういう数字を見ると、ちょっと引いちゃう。20倍良くなるってことは、4年かかることを2ヶ月でできるってことだから、声に出して言うとバカみたいだよね。さらに、60年の働き盛りの仕事を3年でやるって言ったら、もっとバカバカしい。どんなタスクでこの20倍のブーストを見てるの？

1週間で6ヶ月分の仕事を終わらせてるの？

そんな数字信じられないよ。本当にそうなら、仕事辞めて10個のiOSアプリを作ればいいじゃん。

確かに、もっと生産的になった気がする。AIツールは実際に楽にしてくれるし、脳のエネルギーも少なくて済む。これが生産性を上げると思うかもしれないけど、もしかしたらただそう感じるだけかも。マジシャンは、トリックが終わった後に観客の記憶の中で魔法が行われるって言うけど、活動の効果なんだよね。AIコーディングツールは開発者を幸せにして、実際に難しいことにもっと脳の力を使えるようにしてくれる。でも、全体的には、仕事の量が桁違いに増えてるわけじゃなくて、ただそう感じるだけかも。ナビゲーションアプリのWazeは、標準的じゃないルートを案内してくれるから、渋滞にハマらずに進んでる気がするけど、実際には時間がかかって距離も長いかもしれない。渋滞にハマって全然動かないと、時間が止まったように感じるし、退屈でイライラするよね。今や開発者は渋滞にハマることはないけど、長いルートを取るかもしれない。AIツールを使って作業することで、ちょっとしたドーパミンのブーストを得てるかも。もしかしたら、これらの信号を生産性の指標として使ってるのかも。「ああ、今日はいい仕事したな、たくさんやった」って。

パフォーマンスを測る基準は、与えられた時間内にどれだけの機能を実装できるかだ。測定基準が目標になると、それは良い測定基準ではなくなる。

まあ、20倍ってことは、基本的に自分と同じスキルを持った19人に急にアクセスできるってことだよね。20人で新しいプロダクト会社を作れるかも。多分、今いる分野と同じような感じで。

俺は確信してる。研究に参加してた人たちもそうだった。だからこそ、こういうことをするんだ。自分たちの理解がどこで欠けているのかを理解するために。もしかしたら君は特別で、余分な利益を得てるのかもしれない。でも、もしかしたら君も他の人と同じように自分を過大評価していて、実際には得ていると思っている利益が過大評価かもしれない。

他にもいくつかの側面があると思う。- ある人は他の人よりも質問をたくさんする（AIが好きか嫌いかは関係ない）。つまり、ある人は自分で調べることを好むから、GoogleやStack Overflowを最後の手段として使うことが多い。だから、AIに対する質問はもっと複雑になる可能性が高い。簡単な部分は自分で調べちゃってるからね。- AIに必要なことを十分に説明しなきゃいけない場合（これをよくやるんだけど）、その回答が本当に良いものであることを期待するよ。そうじゃなかったら、AIに問題を説明したのは単なる時間の無駄だったってことになる。

その二項対立は全く正しくないと思う、少なくとも経験豊富なソフトウェアの人たちに関しては。僕が知っている多くの人は、ハイプに懐疑的だったり、完全に反対だったりする理由は、僕が妥当だと思う理由から来ている。でも、そういう人たちの中には、llmツールを試してみた人もいて、チャットGPTやコパイロット、カーソルなどの価値を認めている人もいる。中には、claude codeのようなツールを使って、そこに本当の可能性を見出した人もいる。豪華なオートコンプリートやジャストインタイムエージェントを超えた一歩先の話だけど、そこでもウサギの穴にはまったり、ひどいデザインに溺れたりすることもある。君のすごく単純化したスケールでは、僕は「愛」に近いけど、「懐疑的」でもあることが多い。でも、本当に仕事のために「typescriptを書いて」みたいなプロンプトを書くことはないし、正直言ってそれに近いこともない。ミームやデモのためだけなら別だけど。実際にプログラムを書く人は、そんなプロンプトを使わないよ、少なくとも本当の仕事のためには。それはただの馬鹿げた話だ。

君が重要な側面に触れたと思うけど、さらに掘り下げていないね。AIをツールと考えるなら、そのツールの性質は個人によって大きく異なるから、問題が生じる。これが、定期的に使っている人たちの自己報告の間にあるばかげた違いの一因だと思う。それに、僕の質問がそれほど珍しくないか、あるいは良く文書化されている可能性もある（十分にあり得る）から、回答の有用性に対する認識が歪んでいるかもしれない。最近のo4とのやり取りは、業界基準では非常に新しい開発に関してかなり良好だったし、ドキュメントも存在するけど、僕の視点から見るとそれは狂気の渦巻きだ。4oがいくつかの不一致をどれだけ簡単に見つけて、可能性のある落とし穴を教えてくれたかに驚いた。予測がどうなるかはすぐに分かるだろう。言いたいのは、それには使い道があるってこと。