これは直接的に逆転した内容だね。

どこまで読んだ？彼らはそのフレーズのかなり特定の文脈での使い方（リーナス、2000年）を指しているんだよ。

ヘッドラインに過剰に反応してると思うよ、あれはただのジョークだから。記事の内容からは、著者がコードについて無知だとは思えないし、調べてみれば、かなりの数のオープンソースへの貢献があることが分かるよ。要するに、2000年には良いデザインを良いコードで支えるのがすごくコストがかかったけど、今はずっと安くなったってこと。だから、デザインが良いことがより重要だってことだね。ほんとそれだけ。

そう、元のフレーズには特定の意味があるよ。でも別の文脈では、「話す」ことがコードよりも重要な場合もあるんだ。ソフトウェア開発では、コードは開発者が頭の中に持ってる理解やモデルよりも実際には重要じゃない。コードは、あまり良い表現じゃないけど、プロセスの一種の排泄物みたいなもので、人間の解釈なしには意味がないんだ。たとえ運用上の価値があってもね。モデルは実装の一部ではなくて、ソフトウェアは人間の観察者なしでは純粋に文法的な構造に過ぎないから（それすらも、文法は心や言語に属するから、そうじゃないって言えるかも）。これはLLMの使い方に影響を与えるよ。

そうだね、いろんな意味で、私の主張は「コードは安い」というのは、実際にはみんなが思っていることの逆を意味しているってこと。ソフトウェアエンジニアリングは、ここ20年ほどで発展させてきた実践にもっと関係しているんだ。リーナスの観察は今でも当てはまるよ。君が提供したコードが、君が思っている通りに正確に動くことを示してみて。LLMに数行入力するのは簡単だけど、低レベルのコードを安全かつ効果的に変更する方法を正確に理解するのは別の話だよ。リズ・フォン＝ジョーンズがLinkedInでHoneyCombのことについて話してたけど、彼女は悪いPRをリポジトリに落としたことで批判されたんだ。変更の提示の仕方をあまり考えていなかったからね。

こういう意見は、「ソフトウェア開発」が何を意味するのかについて、私とはまったく違う理解を持っているように感じるし、どう折り合いをつければいいのか分からない。君の言う通り、コーディングは全体の努力の20％未満だよ。私の経験では、10％が中央値に近いと思う。このことは、企業がLLMを適用してROIを追跡することで解決されるだろう。一年単位で見ると「まだ活用方法を学んでいる」と言えるかもしれないけど、数年経つと100倍の生産性向上の主張は崩れるだろうね。まだガートナーのハイプサイクルの上り坂にいるから、どれだけ早く失望の谷に落ちるか見てみたいな。

デザインドキュメントを書くのにもすごく便利で、これもSWEにとっては大きな時間の無駄なんだよね。

実は、君はこの作品の著者と全く意見が対立しているわけじゃないと思うよ。彼らは「ソフトウェアエンジニアリングは終わった」とは言ってない。彼らが言ったのは、> 「数十年にわたって行われてきたソフトウェア開発は終わった。」君は、コーディングを書くことがその技術の10-20％だと主張している。それは彼らも同じポイントを言っているんだ！彼らは残りの部分を「話すこと」としてフレーミングしていて、今はコードを書く部分がずっと安くなったおかげで、以前よりもさらに重要になっているんだよ。

Googleの「ソフトウェアエンジニアリング」って本では、ソフトウェアエンジニアリングとプログラミングの違いが説明されてるよ。主な違いは、ソフトウェアエンジニアリングはプログラミングよりも長い時間をかけて行われるってこと。この意味では、AIツールはプログラミングを速くするけど、ソフトウェアエンジニアリングを速くするわけではないんだ。

最近の経験がこれを示してるんだ。数週間、Claudeの助けを借りて新しいコードやリファクタリングをサクサク進めてたんだけど、その後の1週間は完全に停滞してる感じがして、今はまた高速度に戻った。真ん中で何が起こったかっていうと、自分が何をしたいのか分からなかったんだ。アプリケーションのための正しいデータモデルがまだ決まってなかったから、Claudeに何をしてほしいか言えなかった。で、その時に「もっとコード書いて」って言うと、すごく悪いことが起こるんだよね。

記事読んだ？著者はこういうことに関して、もっとも考え深くて、過剰な宣伝をしない人の一人だよ。

自分がやってきた20年の間に、そこまで大きな変化はなかったと思う。ツールは進化したし、新しいものも増えたけど、開発者の基本的なワークフローはあまり変わってない。

1995年から2005年の変化は、その後の数十年よりも大きかった。1995年には、ほとんどの情報が紙媒体かリバースエンジニアリングで集められてたからね。

そうそう、何年も前にVisual Age for Javaで保存時に即時インクリメンタルコンパイルに驚いたのを覚えてる。今のneovimユーザーは、その当時の最も進んだIDEにもなかった機能を持ってる。業界の多くの人は、30年間のインクリメンタルな進歩からどれだけの変化があったかを忘れてると思う。

これの一番の例が、Claudeのターミナルプログラムだね。どうやら60fpsでreactをレンダリングして、それをANSI文字に変換してターミナルの内容を差分取って上書きするみたい。要するに、cursesが簡単にできることを真似してるだけなんだよね。

これは実際に状況をよく表してると思う。でも、あなたが言った第二のクラスの仕事をしていることを誇りに思っていた自分としては、自分の仕事がどれだけ誤分類されているかに非常に懸念を抱いている。第二のクラスでやっていた仕事が自動化されているように感じるし、以前はそれが自分の自尊心を過剰に膨らませていたかもしれない。

LLMを持ってるソフトウェアエンジニアは、一般人が持ってるLLMよりも無限に強いよ。エンジニアはデバッグしたり、指導したり、アプローチを変えたり、何をすべきか分かってれば具体的な指示も出せるからね。一般人は「これ動かないんだけど、直してくれない？」ってプロンプトを繰り返すだけ。だから、確かに仕事は急速に変わってるけど、すぐに廃れるとは思わないな。

「AIがその第二のクラスの仕事を自動化してるんだ！」って反論が多いのは知ってるけど、うーん、それが問題じゃないんだよね。問題は、その第二のクラスの仕事に対する需要があまりないってこと。少なくとも今はね。第一のクラスの仕事は、何十億もの家族を養ってるから。うん、労働の塊の誤謬については知ってるよ。

僕の仕事は、お金を持ってる人に自分が彼らの目標達成に欠かせない存在だと思わせることだよ。AIがこれを十分に偽装できる可能性が高い。競争が少ない経済では、偽装するだけでも十分かもしれないし、これが今の経済かどうかはみんな自分で判断できると思う。

あなたが言ってるのは、AIの前の伝統的な（決定論的な？）自動化だね。今日の最先端のLLMのような一般的なAIシステムは、クラスIかクラスIIに関係なく仕事を引き受けるよ。「今年の車のデザインをどう改善すべきか？」ってロボットアームに聞いたら、絶対に行き詰まるだろうけど、AIに聞いたら人間の意見と同等の本物の意見をくれるよ。もし会社が「AIがアイデアを出す -> AIがプロトタイプをデザインする -> AIロボットが実際に車を作る -> AIロボットが車を試乗する -> AIがすべてのプロトタイプを評価して来年のデザインを確認する」ってフィードバックループを完成させるためのツールを十分に整備したら、理論的にはこれが機能することもある。だからAIが大きな話題になってるのは、これまでの技術とは根本的に違うからなんだ。AIにとっては、クラスIとクラスIIを区別するラインなんて存在しないんだよ。

まだこれが問題だとは思わないな。どんなクラスであっても、CEOは気にしないってことだ。平凡なAIの仕事でも、彼らには大きなリターンと出口をもたらすからね。彼は不運な持ち株者のことなんて考えてない。世界は常に、分散したクソみたいなものには寛容だから。Windowsを見てみて。

たくさんのマネージャーは、従業員が前者のようにやってると思ってるけど、実際には後者をやってるんだよね。

いつも言ってるけど、1行1行が負債なんだよ。それを制限するのが私たちの仕事なのに、最近はそれがほとんど無視されてるよね。

コードを生成するのはいつも安いんだ。それがこの技術をチームに強制しなきゃいけない理由の一部でもある。クラウド移行と似てて、そのコストは後でしか現れないタイプなんだよね。クラウド移行よりも早く現れると思うけど、場合によっては正しい選択になることもある。

私が見てきた主な問題は、テストが通るコードを書くことなんだ。コードが正しいっていうのは大きな（しかもしばしば間違った）前提なんだよね。

現在、LLMによるテスト作成はちょっと危険な気がします。 使えるケースもあれば、そうでないケースもあります。 どちらのケースを特定するための体系的な基盤を明確にできるとは思えませんが、見ればわかると思います。 例えば、先日、いくつかのユースケースを与えてテストを書かせたんですが、ユースケースは正しかったのにコードは間違っていました。 そのテストが壊れているのを見て、テストを再作成しようとしました。 エージェントが自分の成功基準を決めると、最適でない結果を招くリスクがあります。 一度、別のClaudeのインスタンスを使ってテストを書かせ、その後、テストを知らない別のインスタンスに実装を書かせようとしましたが、ちょっと手間がかかりすぎました。

これがこのゲームに新しく参加する人がやるべきことです。 他の二つの異なるLLMにコードを徹底的にレビューさせてください。 もし自動化された方法がなければ、苦労して最終的に仕事を失うことになります。 このアプローチを使えば、ほとんどのソフトウェア開発者が出すコードよりも良いコードが得られます。 それがあれば、仕上げを加える必要があるときに良い基盤になります。

「今日はReduxのユニットテストを書いて」 これは「犬を描いて」と同じくらいのもの -> 傑作じゃないの！？ 誰がそんなことを思ったでしょう？ テスト方法論を考え出して、それを書き留めてから、モデルにそれを通過させるように頼む必要があります。 指定されていないことについて仮定を作るのが好きなので、注意が必要です。 もっと根本的には、テストが私たちが考えるべき核心的な要素になっていると思います。 AIコードを「バイブチェック」するのではなく、コードチェックすべきです。 もちろん、実際のテストコードは書いてくれますが、あなたの主な優先事項は「これをどうテストするか？」を考えることです。 コードの価値は、そのテストのレベルまでしかわかりません。 リポジトリに目をコミットできないので、AIコードの「LGTM」バイブテストはしないでください。 それはバイクに乗っているようなものです。

こんにちは、私は主なReduxのメンテナーです。 生成された例を見てみたいです！ （これに影響を与えることができるかは疑問ですが、ここで何が起こったのか興味があります。） 参考までに、私たちのテストアプローチに関するドキュメントがありますし、しばらくの間、より統合的なスタイルのテストアプローチを推奨しています： - https://redux.js.org/usage/writing-tests

私の理論では、これがプログラミングに対するLLMの見解の違いの原因だと思います。 プログラミング言語を思考の道具と見る人と、コンピュータに何かをさせるための道具としか見ない人がいます。 前者はプログラミング自体にもっと価値を見出すのは当然で、後者はコードを隠すことに満足しています。 私はこう仮定します：ほとんどの人はLLMを思考の道具として見ています。 プログラマーもLLMをプログラミングの道具として見ています。 現在、一部のプログラマーは両方に非常に優れたスキルを持ち、二つを結びつけています。