2026/04/13 4:44
怠惰と失われた危機の罠
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
テキストは、ラリー・ウォールのプログラミングにおける「怠け」、不満、そして大それた振る舞いの美徳が依然として不可欠であると論じつつ、特に未来の利用に最適化された単純かつ強力な抽象化を駆使する「怠け」においてはその重要性が高いと指摘しています。これに対して、大規模言語モデル（LLM）は危険に「徳ある怠け」を、「 Hustle Porn」と呼ばれる偽の勤勉で置き換えてしまいました。人間とは異なり、LLM は作業に対してコストを負担せず、時間制約も無視するため、自慢のためのメトリクスによってではなくエンジニアリングの厳密さによってではない、不要なコードの層を蓄積します。この転換は、「Camel Book」という歴史的智慧において、即時の出力量よりも使いやすさを重視する方針と対照付けられます。具体例として、LLM を用いて 1 日 37,000 行ものコードを書き上げたというブロプログラマの Garry Tan の自慢に対し、Gregorein の分析によって多数のテストハネスとゼロバイトのロゴが示されており、これは無制約な AI が肥大化したシステムを生成する様子を明らかにしています。もし無制約のままにされれば、LLM は「ゴミ」の層を積み重ねることで単純な設計ではなく技術的負債の形で未来の世代を脅かすことになります。しかし、業界の行方はエンジニアがこれらの AI モデルを徳ある怠けの方へ導けるかに依存しています。制約と Oxide ガイドラインに導かれ、LLM が複雑性を削減し、厳密な設計を促進して将来に向けてより単純かつ強力なソフトウェア抽象化をもたらすことを保証することが可能です。
Text to translate:
The text argues that while Larry Wall's programming virtues of laziness, impatience, and hubris remain essential—especially laziness, which drives simple, powerful abstractions optimized for future use—Large Language Models (LLMs) have dangerously displaced "virtuous laziness" with a form of false industry called "hustle porn." Unlike humans, LLMs incur no cost for work and ignore time constraints, causing them to accumulate unnecessary code layers driven by vanity metrics rather than engineering rigor. The summary contrasts this shift with historical wisdom found in the "Camel Book," which prioritizes ease of use over immediate output volume. Examples include broprogrammer Garry Tan bragging about writing thirty-seven thousand lines of code per day with LLMs, while Gregorein's analysis revealed multiple test harnesses and a zero-byte logo, illustrating how unchecked AI generates bloated systems. If left unconstrained, LLMs will threaten future generations with technical debt by building up "garbage" layers rather than simpler designs. However, the industry's trajectory depends on whether engineers can steer these AI models back toward serving virtuous laziness; guided by constraints and Oxide guidelines, we can ensure LLMs reduce complexity and promote rigorous design to yield simpler and more powerful software abstractions for the future.
本文
ラリー・ウォールは、技術者を何世代にもわたり親しまれる「駱駝の本」とも称される古典的名作『プログラミング・ペルル』で、プログラマーの三大美德として怠惰（レイズネス）、不耐性（イムペアティエンス）、傲慢（ハブリス）について有名な一文を残しました。
もし良質なソフトウェア設計について語るのであれば、その基盤となる「怠惰、不耐性、傲慢」という三つの徳について語る必要があります。我々は、より高次の抽象化——たとえ単なるループやサブルーチンであっても——を定義すべきなのに、カット＆ペーストを使うという罠にはまってしまってきました。確かに、一部の人は逆に、カット＆ペーストを使うべきかっただけに過ぎないのに、膨大な数の高次抽象化を定義しすぎることまで行っています。しかし一般的には、ほとんどの人々はむしろ「少ない」という方向ではなく、「多い」という方向に考え、より多くの抽象化を利用する必要があるのです。
これらの徳の中で、私は特に怠惰が最も深遠だと感じてきました。その皮肉混じりの自己軽蔑の中には、単に抽象化が必要なことだけでなく、その美学的な側面に対する考察さえも含まれているからです。怠惰は我々を、「もっとはるかに簡単に」「はるかに多くのことを」行えるよう、システムを可能な限り単純（しかしそれ以上はならない！）にするように動機付けます。ここにある目に見えないウィンク（ふざけた仕草のような笑み）は、怠けること自体に多大な努力が伴うという事実を暗示しています：ハモック・ドライブン開発（ハンモックからコードを書く作業を見ながらのんびりと行うこと）という一見した怠けに見える Programmer の取り組みの中で、我々は実際には頭の中で問題を何度も反芥しています。これらの抽象化を開発するという難しい知的作業を行うのは、部分的に将来の自分自身の時間を最適化するからです——たとえ現在の自分犠牲を払うとしてもです。この計算が正しければ、その結果は壮麗なものであり、その抽象化は我々自身だけでなく、我々の後世の人々をも支えるようになります。つまり、我々の怠惰はソフトウェアを書きやすくし、システムを組み立てやすくすることを目的としています——より多くの人々がより多くのソフトウェアを書くことを可能にします。理想的には、抽象化から利益を受ける人々が、その「怠惰の徳」を先送りし、新たな力を使って自らが開発した抽象化の上に働きかけるべきです。しかし過去 20 年でソフトウェア開発が広がり、プログラマーと自認しない人たちも含まれるようになっている結果、怠惰という徳は本来の意味を失いつつあります。さらに、現代の抽象化によって実現された非凡な生産性ゆえに、「虚構的な勤勉さ」への偏重が生じてしまいました。軽蔑的に言えば、これは「ブログラマー」の台頭であり、皮肉まじき怠惰とハモック・ドライブン開発という徳が、コードを圧倒するというパフォーマンスへの執着によって置き換えられてしまったのです。
この乾燥した乾草に雷が落ちました。LLM が登場しました。ソフトウェア制作に対する個人のスタンスは何であれ、LLM を使うことでその活動ははるかに大きな力をもって行えるようになるため、LLM がブログラマー層にとってアナボリック・ステロイドのように機能していることには驚きはありませんでした。新しい力を身に付け嬉々として、彼らはこれについて止まらなくなりました。例えば、著名なブログラマーであるガリー・タン氏は、LLM の使用に関して特によく耐え難い発言をしており、「一日に 37,000 行のコードを書くペース」（しかも「今でも加速中」）と自慢しています：
もし怠惰がプログラマーの徳であるなら、このようにソフトウェアを捉えることは明らかに罪です。そして、文献を斤単価で評価することと同じく、その誤謬は初歩的なプログラマーにとっても明らかです。タン氏がそのような熱狂的なエネルギーで構築していたアーティファクトについては、私はほぼ無視していました。しかし、ポーランド出身のソフトウェアエンジニアであるグレジイン氏がそれを分析し、結果は予言できると同時に滑稽かつ示唆的でした。彼の「ニュースレター・ブログもの」と呼ばれる一つのローディングには、複数のテストハネス（！）、ヘロー・ワールド・レイルズアプリ（？！）、密航したテキストエディタ、そして同じロゴの 8 つの変種——そのうちの一つはゼロバイト——が含まれていました。問題はそのような個々の課題自体ではありません（すべて修正可能なので！）。また、それらを生み出した方法論がソフトウェア工学の未来を表しているという信念についても、特に批判的なものではありません（ただし確かに煩わしいことは事実です！）。問題は、LLM は本質的に「怠惰」という徳を持たないことです。LLM にとっては労働にはコストがかかりません。LLM は自分の時間や誰かの時間を最適化する必要性を感じず、安易にゴミの山の上にさらにデータを積み重ねます。制御されないと、LLM はシステムを「より良く」するのではなく、「より大きく」してしまいます——おそらく歪んだ vanity metrics にアピールするかもしれませんが、それでは何かが失われます。
このように LLM は、人間の怠惰がどれほど重要かを浮き彫りにしています：有限な時間は我々に鋭利で明確な抽象化を開発することを迫ります。それは単に不機能的なものによる結果を無駄にするのを避けようとするからです。優れた工学は常に制約から生まれ、時間の制約によって我々が認めるべきシステムの認知負荷に限界をもたらします。これがシステムをより単純化する原動力です——その本質的な複雑さにもかかわらずです。私の講演『シンプルさの複雑さ』で詳述した通り、これは重大な課題であり、時間や負荷という制約の下に活動しない LLM が自主的にこれを遂行するとは期待できません。
もちろん、LLM 将来において重要な役割を果たすとは言いません：それはソフトウェア工学にとって画期的なツールです——しかし Oxide の『LLM 利用ガイドライン』で示されている通り、LLM は単なる道具です。我々は彼らを「非皮肉めいた（そして徳のない！）プログラマーの怠惰」という側面に取り組み、技術的負債といった棘の多い問題を克服する助けにしたり、工程学的厳密さを促進するために使うことができます——しかしそれは常に我々の自身の徳ある怠惰のためのものです：より単純で力強いシステムを生み出し、我々自身だけでなく、その後の世代のソフトウェアエンジニアにも奉仕させるためです。