怠惰の美徳を失う危険

 (bcantrill.dtrace.org)
2 ポイント 投稿者 GN⁺ 17 일 전 | 1件のコメント | WhatsAppで共有
  • プログラミングにおける 怠惰 は単なる怠慢ではなく、抽象化と単純さを追求する知的な美徳として定義される
  • 真の怠惰とは、問題を深く考え抜いて未来の時間を節約する過程であり、それは後世の開発者にも利益をもたらす
  • 現代の高水準抽象化と 「brogrammer」文化 はこの美徳を失わせ、偽りの勤勉さに置き換えている
  • LLM はこの傾向を極大化し、コード量を価値だと錯覚させる 過剰生産の道具 として機能する
  • 人間の有限な時間に由来する 美徳としての怠惰 を保ちながら、LLM を 単純で持続可能なシステム設計 に活用すべきである

プログラマーの美徳としての怠惰と、その喪失の危険

  • Larry Wall が『Programming Perl』で提示したプログラマーの三つの美徳、怠惰(laziness)、短気(impatience)、傲慢(hubris) のうち、怠惰が最も深い意味を持つと強調している
    • 怠惰は単なる自虐ではなく、抽象化の必要性と美学 を内包した概念である
    • システムをできる限り単純にし、強力な抽象化によってより多くの仕事をより容易に行えるようにする原動力である
  • 真の怠惰とは、「hammock-driven development」 のように、一見すると休んでいるようでいて、実際には問題を深く考え抜き、未来の時間を節約するための 知的労働 を行う過程である
    • 正しい抽象化が生み出されれば、それは開発者自身だけでなく 後世の開発者たち にも利益をもたらす
    • このような怠惰は、ソフトウェアをより書きやすくし、システムをより構築しやすくする

  • 怠惰の美徳が消えた時代

    • 過去20年でソフトウェア開発の裾野が広がり、自らをプログラマーだと考えない人々 が増えた
      • 彼らにとって、怠惰の美徳は本来の意味を失ってしまった
    • 現代の高水準抽象化がもたらした 生産性の爆発 は、むしろ 偽りの勤勉さ(false industriousness) を助長している
      • これは 「brogrammer」文化 や 「hustle porn」 として現れ、皮肉を帯びた怠惰ではなく、コードを際限なく吐き出すふるまい に置き換えられている

  • LLMがもたらした新たな過剰

    • LLM(大規模言語モデル) の登場は、この傾向を極大化している
      • LLM は人間の創作姿勢を増幅する道具であり、「brogrammer」文化のステロイド のような役割を果たす
    • 例として Garry Tan は、LLM を使って1日に 37,000行のコード を書いたと言及している
      • 比較のために、DTrace 全体のコードベース はおよそ60,000行の規模である
    • しかし、このようなアプローチは 怠惰の美徳を欠いた悪徳 であり、コード量でソフトウェアの価値を測るという誤りを示している

  • LLMの限界と人間の怠惰の価値

    • LLM は 労働コストが0 であるため、未来の時間節約を考慮せずに 無限に複雑なシステムを生成 する
      • その結果、システムはより大きく複雑になり、虚栄心に基づく指標 を満たす一方で、本質的な品質 を損なう
    • 人間の怠惰は 有限な時間という制約 から生まれ、それが 明快な抽象化と単純化されたシステム設計 を強いる
      • 最高のエンジニアリングは常に 制約から生まれ、人間の時間的制約が 認知負荷を制限 し、単純さを追求させる
      • LLM にはこのような制約がないため、自ら単純さを求める動機がない

  • LLMを道具として活用する方向

    • LLM は今なお ソフトウェアエンジニアリングの強力な道具 として重要な役割を果たしうる
      • Oxide の LLM 利用ガイドラインによれば、LLM は あくまで道具 にすぎず、人間の美徳を代替することはできない
    • LLM は 技術的負債(technical debt) のような非生産的な怠惰の問題を解決したり、エンジニアリングの厳密さ を強化したりするために活用できる
    • しかし、その利用目的は必ず 「美徳としての怠惰」 を実現する方向であるべきだ
      • つまり、より単純で強力なシステム を作り、未来世代の開発者たち に役立つ結果を残さなければならない

関連記事

1件のコメント

 
GN⁺ 17 일 전
Hacker Newsのコメント

  • 私の分野である Computational Fluid Dynamics でも、LOC自慢のようにテスト数の多さを誇る人がいる
    でもよく見ると、そのテストはあまり厳密ではなく、私が手動で作ったテストよりずっと甘い
    100万件の簡単なテスト でも、コードの核心部分をカバーしていなければ何の意味もない

    • 私もテストは自分で書くべきだと気づいた
      そして Claude がコードが動かないときにテストを「直してしまう」のを防ぐため、必ず git diff でテスト変更を確認している
      テストを厳格に管理すれば Claude は難しい論文のアルゴリズムでもうまく実装してくれて時間の節約になるが、かなり手がかかる
    • これは一種の reward hacking のようだ
      テストという報酬関数を、モデルが「勝利宣言」のために悪用しているわけだ
      おそらく RL の事前学習データにこうしたパターンが入っているのではないかと推測している
    • LLM に間抜けでないテストを生成させるのは本当に難しい
      assert(1==1) のような役に立たないテストが何百個もできる
      そのため「こういうテストは作るな」という 禁止リスト を別に管理しなければならない

  • 30年間自分でコーディングしてきたが、今では完全に AIコーディング に移行した。それなのに、人々が AI 生成コードの LOC や機能を自分の手柄にしているのは奇妙に感じる
    1日に何十万行も「コーディングした」と誇るのは、結局 数行のプロンプト を打っただけではないかと思う

    • これはスペクトラムのようなものだ
      自分で承認した修正ならある程度は手柄と言えるが、完全な vibe-coded アプリ にはほとんど関与していない
      私はその中間あたりにいる — AI が作ったコードを全部レビューはしないが、アーキテクチャ設計とリファクタリングの方向性は私が主導している
      成果物は自分で直接作ったときと似ているが、はるかに速く完成する
    • Meta には今 AI使用量リーダーボード があり、Claude トークンを最も多く消費する人を表示しているらしい
      Meta が Claude を使っているのだから、Anthropic にとってはかなりうれしいだろう
    • 実際、LOC が多いことは 悪い結果の兆候 かもしれない
    • LoC は品質指標として無意味だと主張する人もいる
      今では実装・テスト・保守をすべて エージェントが担当 する時代だからだ
      LoC は、エージェントがどれだけ要求を押し通せるかを示す 能力指標 にすぎないと見ている
      人間の批判的レビューは依然としてフィードバックとして注入できる

  • 「もっと抽象化を使うべきだ」という言葉は昔は正しかったかもしれないが、今はむしろ逆だと感じる
    私は WET(Write Everything Twice) の哲学が好きだ — 2回書いてみて、3回目になって初めて抽象化を考える

    • これは一般に Rule of Three とも呼ばれる
      Wikipediaの記事 参照
    • ソフトウェアの本当の美しさは 正しい抽象化 にある
      オペレーティングシステム、RDBMS、クラウドオーケストレーションのような革新がその例だ
      しかし大半のコードは単純なビジネスロジックであり、抽象化はむしろ邪魔になる
      そのため私は「3つの実運用ユースケース が立証されるまではプラットフォームを作るな」という原則を置いている
    • 2回以上書くというのは低い基準で、Perl の引用とも矛盾しないと思う
    • 2回目を書くのは、問題をよりよく理解した状態で改善する機会だ
      3回目で抽象化を試みるときには Second-System Effect に注意すべきだ — 過剰な自信が複雑なシステムを生む
    • 1991年の Programming Perl 以降に起きた 抽象化レイヤーの爆発的増加 には驚かされる

  • ドイツの将軍 Kurt von Hammerstein-Equord の有名な引用を共有する
    頭が良く勤勉な人は参謀に、愚かで怠惰な人は日常業務に、頭が良く怠惰な人はリーダーに、
    そして 愚かで勤勉な人は危険 なので絶対に責任を持たせてはならないという

    • 「私のような 90%怠け者の部類 はどこなんだ？」と冗談交じりの反応をしていた

  • LLM で20万 LOCを書いたと自慢するのも愚かだが、それを見て「そのコードはひどい」と嘲笑するのも同じくらい間違った態度だと思う
    結局重要なのは コード出力ではなく価値創出 だ
    Garry Tan が実際に価値あるものを作ったのかは分からない

    • コード品質が重要でないと思うのは危険だ
      Horizon IT scandal のような事例を見ると、悪いコードが実害を生む
      Garry のプロジェクトを分析したポーランドの開発者 Gregorein のレビューによれば、そのアプリには テストハーネス、Hello World アプリ、重複したロゴファイル などのめちゃくちゃなものが含まれていた
      こうしたコードがセキュリティ攻撃面を広げていないか懸念される
    • Garry は単なる開発者ではなく YC の CEO だ
      LOC を気にしているのではなく、AI宣伝用の投稿 をしているのだ
    • 本当の指標は 価値 − コスト だ
      AI は開発・運用コストを下げるが、セキュリティや法的リスクのような 隠れたコスト を増やす
      AI 礼賛派は前者ばかり強調する
    • 20万 LOC を読んで悪いアイデアだと証明している暇はない
      それは vibe coder が証明すべきことだ
      LOC で自慢するのはやはり愚かだと思う
    • 「価値創出」という言葉自体が危険かもしれない
      化石燃料ベースの成長のように、短期的な価値が長期的なコストをもたらすこともある

  • 最近いくつかの PR を見ていて、LLM が誤った解決策 を出すのをよく目にする
    たとえば既存の JSON パーサーがあるのに、自前でパーサーを実装するようなことだ
    人間なら「これは非効率すぎる」と感じるはずだが、LLM には怠け心がないので 間違った方向に熱心に進んでしまう

    • また、プロジェクト内の重複関数をまったく認識しない
      formatTimestamp のような関数が3つもあることを、grep を1回かければ分かるのに 無視する

  • LLM が 怠惰ではない という話には共感する
    ただし、これが恒久的な問題なのか、次のモデルアップグレードや CICD パイプライン で解決されるのかは分からない
    私は機能完成後に「バグやリファクタリングすべき部分がないか確認せよ」というプロンプトを与えるが、
    将来的には自動で 最近のコミットを分析して単純化提案 をする段階が出てくるかもしれない

    • ただし「X を探せ」と言うと、LLM は常に何かを見つけてしまう
      そのため 終了条件の定義 が難しいという問題がある
    • 結局のところ、問題はツールの本質ではなく 使い方の限界 にある
      「追加しろ」とだけ言えば必ず追加し、「減らせ」と言えば LOC を減らす
      大きな作業を任せてレビューを省略すれば、コードスロップ がたまりやすい

  • LLM は単純なコンソール出力プログラムの代わりに フル SPA を作る傾向がある
    また spec.md ファイルを簡潔に保てない
    「この文書を更新して周辺の内容を単純化しろ」と言うと、むしろもっと複雑にしてしまう
    結局、読みやすい文書にするには 人間が自分で要約 しなければならない
    LLM の出力を編集するのは苦痛で、理解を保つには自分で書くしかない

  • LLM と vibe coder たちに、ソフトウェア開発の古典的な教訓を教えるべき時だ
    Negative 2000 Lines of Code の話のように、コードを減らすことこそ本当の進歩 であることが多い

  • こういうリーダーシップと一緒に働けたらどんなにいいだろうと思う
    本当に 理解力のあるリーダー と働けるのは大きな幸運だ