36 ポイント 投稿者 GN⁺ 2026-02-02 | 10件のコメント | WhatsAppで共有
  • LLMコーディングツールの登場により、数十年にわたって続いてきたソフトウェア開発の基本前提そのものが崩壊し、コードを書くことよりも問題を定義し構造を設計する能力が中核的なスキルになった
  • いまや開発の中心は、**「コードをうまく書く能力」ではなく、問題を想像し明確に説明する「語る力」**へと移りつつある
  • 整ったコード構造、よく整理されたREADMEやドキュメントは、もはや誠実さや熟練度の信頼シグナルではなく、むしろ完璧すぎるほどslopである可能性すら高まっている
  • AIが生成したコードと人間が書いたコードの外見上の区別が事実上不可能になり、品質よりも責任性・出所・人間性がコードの価値を分ける基準として浮上している
  • FOSSエコシステムを支えてきた協業と共有のインセンティブは弱まりつつあり、コードそのものよりも信頼、ガバナンス、キュレーション能力のほうが重要な資産になっている
  • これらのツールは熟練開発者にとっては強力な増幅器だが、初心者にとっては**基礎理解を築く機会を奪いかねない危険な魔人(genie)**にもなりうる

序論: Linus Torvaldsの格言とその転覆

> "Talk is cheap. Show me the code"

  • 2000年のLinus Torvaldsのこの言葉は、実際にコードを書いて証明しない限り、言葉には価値がないという姿勢を象徴していた
  • 当時は、どれほど明確な開発計画があっても、複雑なプログラムを実装すること自体が膨大な労力と時間、反復的な退屈さを必要としていた
  • 真のボトルネックは技術ではなく人間の限界だった。すなわち、認知的帯域、個人の時間とエネルギー、そして大規模システム全体を頭の中に保ったままコードを一行ずつ書き下していかなければならない生物学的コストである
  • その結果、ほとんどのアイデアは**「いつかやってみたいウィッシュリスト」に積まれたまま**、実際に試されることすらなく消えていった

25年後: LLMがすべてを覆す

  • 2025年、Linus Torvaldsは自身の趣味プロジェクトにAI生成コードをマージし、「自分が手で直接書いたものより良いか? もちろんだ」と述べた
  • 数十年にわたってソフトウェアを作ってきた開発者の視点から、筆者は私たちが知っていた形のソフトウェア開発はすでに終わったと断言する
  • ダイヤルアップからギガビットへ、BasicからNode.jsへ、SourceForgeからGitHubへと続く数多くの転換期を自ら経験してきた世代として、今回の変化が一時的な流行ではなく質的断絶であることを明確に認識している

コード品質評価基準の崩壊

  • 以前はFOSSプロジェクトを評価する際、プロジェクトの年齢、コミット頻度、コード構造の一貫性、READMEやドキュメントの品質などが重要な判断基準として機能していた
  • 簡潔なコメントとよく整理されたドキュメントは、開発者の思慮深さや他の開発者への配慮を示すシグナルとして受け取られていた
  • しかしLLMが完成度の高いドキュメントページ、過剰なほど詳細なREADME、整ったUI、整理されたパターンやコメントを一度に生成できるようになり、こうしたシグナルはもはや有効ではなくなった
  • その結果、そのリポジトリが非技術者がバイブコーディングで作ったものなのか、あるいは熟練開発者が設計した成果物なのかを、見た目だけで区別するのは難しくなった
  • むしろ完璧すぎて見えるほど、低労力の一発生成物である可能性を疑うべきという逆説的な状況が生まれている
  • 専門家レベルの綿密なレビューと分析がなければ、wheatとslopを見分けることがますます難しくなっている
  • これにより、コードそのものよりも誰が作ったのか、なぜ作ったのか、どのような履歴を持つ主体なのか、ガバナンスや維持計画があるのかといった出所(provenance)が、より重要な判断要素として浮上している

努力の価値の変化

  • 以前は、熟練した開発者が意味のある結果を生む高品質な10,000行のコードを作るためには、長時間の集中と反復的な改善プロセスを経る必要があった
  • コード行数そのものは品質の尺度ではないが、よく磨き込まれた10,000行のコードは、時間、集中力、忍耐、専門性、そして一定水準のプロジェクト管理能力が投入されたことを意味していた
  • LLMはこうした成果物をわずか数秒で生成でき、テスト、システム設定、デプロイに至る技術的ワークフロー全体を処理できる
  • 人間の専門性と判断があわせて介在すれば、成果物は十分に実用可能な高品質に達しうる
  • 個人的にも、数週間あるいは数か月かかっていた作業を数日、ときには数時間で終えた経験を何度もしている
  • AGENT.mdや複雑なマルチエージェント・オーケストレーションなしに、単純なLLMエージェントCLIだけでこうした圧縮は可能だった
  • ソフトウェアの成果物を得るために払っていた生理的・認知的・感情的コストは桁違いに減少した
  • こうして確保された時間と認知的余裕は、エンジニアリング思考、アーキテクチャ設計、議論、実験、想像力の拡張へと再投資される
  • **「プログラミングは90%が思考で、10%がタイピングだ」**という古い言い回しは、もはや比喩ではなく現実になった

Slopの定義とコードの価値

  • コードを一行も書いたことのない人でさえ数秒で産業規模のコードを生み出せる状況で、コードという成果物そのものの価値とは何だろうか?
  • 「AIコードではなく純粋な人間のコードだけを求める」という主張は、現実を考えれば皮肉に近い冗談でしかない
    • CrowdStrike IT障害(2024)、Boeing 737 MAXの運航停止、英国郵便局スキャンダル、インドの大規模データ侵害、Equifaxのデータ流出など、人間が書いたコードによる重大事故の事例はすでに十分に存在する
  • 世界中で人間が毎日書いているコードの相当部分は、品質面で境界線上にある
  • ソフトウェア開発は依然として、客観的な成熟段階に達した専門学問とは言いがたい分野である
    • 医師や土木技師には厳格な教育と免許、実務結果への責任が求められるが、ソフトウェア開発には類似の制度がほとんどない
  • 今日の社会は、雑に設計され、適当に継ぎはぎされ、過度に膨らんだコードシステムの上で動いている
  • 感情に訴える言い方をするなら、AIが作るslopは少なくとも形式は整っており、ドキュメントはよく整理され、構文的一貫性を備えていることが多いとも言える
  • インターネットを埋め尽くす魂のないLLM生成文やメッセージを読むことは、文字どおり扁桃体ニューロンの活性化を無駄にするようなものだという認識が広がっている
  • 人間の創作過程、そこに含まれる完全さと欠陥が失われれば、言語・文学・芸術・音楽は本質的に楽しめない対象になる
  • 努力なしに無限に、即座に生成できるものは、人間にとって価値判断を与えることが極めて難しい対象になる

コードは芸術とは異なる

  • コードは本質的に常に目的のための手段であり、それ自体が目的だったことはない
  • 最終利用者はコードを読まないし、読む必要もなく、コードそのものに関心も持たない
  • ポータルの裏側で動く何百ものシステムがどの言語、フレームワーク、アーキテクチャで実装されているかは、ユーザーにとって意味を持たない
  • コードは徹底して隠された存在であり、ユーザーはUXを通じてコードが生み出した結果と効果だけを体験する
  • 機能的に同一のAIコードがslopかどうかを分ける基準は、責任(accountability)の構造と人間性(humanness)の介在の有無である
  • オープンソースのリポジトリに人が直接書いて投稿したPRは、コード品質とは無関係に、そこに注がれた人間の時間と労力を前提とした共感と価値を自然に与えられる
  • 逆にLLMが生成したPRは、品質と無関係に最初の反応が「slop!」になりがちだが、これはその中に込められた人間の努力を即座に測れないからである
  • それと同時に、そのコードを読んで検証しなければならない負担は、作成コストに比べて不均衡に、幾何級数的に増大する
  • 結局それは、努力なしに生成された無限の変形の一つにすぎず、意味ある出所や文脈を持たない
  • この地点で、私たちの現実はますます**Borgesが描いた「バベルの図書館」**に近づいていく

FOSSの未来

  • FOSSはおそらく人類が生み出した最も偉大な公共財の一つである
  • FOSSの出発点には、ソフトウェアが極めて高価で、少数の専門家だけが作れた時代的前提があった
  • 世界でごく少数の人しかソフトウェアを作れず、残りはその成果物を使う側にとどまるしかなかった
  • いまや、どれほどニッチな要求であっても、専門家なら自分の必要に正確に合った小規模ライブラリをすばやく作り出せる環境になった
  • さらに、ある程度賢ければ誰でも個人用途に必要な小さなツールをバイブコーディングで自作して使う時代が到来している
  • StackOverflowで起きた変化が、速度は遅くともソフトウェア全体でも同様に進行中である
  • これは、FOSSの協業と共有を支えてきた人間的動機、社会的条件、参加インセンティブの核心を正面から揺さぶる変化に見える
  • 前例のない規模で押し寄せるFOSSプロジェクトのカンブリア爆発的な大増殖を考えれば
  • 最終的に生き残り繁栄する高品質なFOSSプロジェクトでは、コードそのものよりも専門家によるガバナンス、キュレーション、信頼の構造のほうが重要な資産になる可能性が高い

木ばかり見て森を見ない両極端

  • 構文ハイライトやIDE、各種ツールがなかった時代でも、人間はすでに驚くべき水準のソフトウェアを作っていた
  • 逆に、あらゆるツールと資源が溢れる今でもひどいソフトウェアは作られ続けている
  • 表現力に優れ、品質に関心を持つ有能な開発者は、LLMであれ他のツールであれ、自分なりの方法で活用して良い結果を出す
  • 一方、問題を説明できず品質にも無関心な開発者は、LLMを使うかどうかに関係なく悪い成果物を生み出す
  • 極端な「エージェント的」バイブコーディングの信奉者も、LLMを全面否定する人たちも、結局は森を見ずに木にばかり執着している
  • 経験と専門性、思考力と表現力を備えた人が、適切なトレードオフを選んで望む結果を得る実用的な中間地点は確かに存在する
  • バイブコーディングは、非技術者が初めてソフトウェアに触れ、実験し、楽しみながら能力を伸ばせる重要な入口でもある
  • しかしバイブコーディングを盲信する人々は、人間が何らかの成果物を真剣に受け止めるようにする核心的要素、すなわち**有限性(finitude)**を見落としている
  • その結果、自らもおべっかを使うエージェントが生み出したslopの海の中で道を見失いやすい、巨大なボルヘス的図書館を積み上げつつある
  • 努力なしに無限に生成され、意味ある出所を持たない成果物は、価値を与えることも、真剣に受け止めることも極めて難しい
  • 人間は本質的に、無限の供給、とりわけ選択肢の無限にうまく対処できない存在である
  • 一方でLLM懐疑論者は、しばしば**不信の論証(argument from incredulity)**を超えられない
  • 個人的に気に入らない、望む結果が得られない、期待が外れた、あるいは単に飽きたという理由で技術そのものを否定する
  • しかしそれは、同じツールを効果的に活用し、正反対の体験をしている相当数の人々が存在するという事実の前では説得力を失う
  • 誇大宣伝と熱狂、強欲に押し進められた愚かで有害な実装が現実に存在し、重大な懸念の対象であることは確かだ
  • AIビジネスのバブルはおそらく歴史上最大級のバブルの一つになる可能性がある
  • それでもなお、FOSS AI技術の拡散は明らかに希望的な兆候である
  • 悪質な行為者や数字遊び、とんでもない実装をこれらの技術が持つ根本的・物理的能力と同一視するのは不合理である

人間的コスト

  • 経験豊富な開発者やエンジニアの視点から見れば、こうしたAI技術は非常に強力で効果的な補助手段として機能する
  • しかし、業界に足を踏み入れたばかりの初期段階の学習者やジュニアにとっては、まったく別の問題が生じる
  • 基礎が不足し、システムやソフトウェア開発プロセスについての内在的で微妙な理解が形成されていない状態なら、この技術は**信頼できず危険な魔人(genie)**に近い
  • コードを求めればコードを出し、変更を頼めば即座に修正してくれるというやり方は、一見すると便利である
  • しかしやがて利用者は、動作原理を理解できないコードベースに閉じ込められ、問題解決のために魔人に頼り続けるようになる
  • この依存が繰り返されると、基礎的で根本的な能力が自然に形成される学習環境そのものが失われ、認知的退化にまでつながる危険がある
  • その結果、意味のあるシニアへと成長する機会を得られないジュニア世代全体が現れる可能性が指摘される
  • 真の懸念は、slopが何であり何でないのかを客観的に見分ける専門性を習得する機会が、学習者世代から失われることにある
  • さらに深刻なのは、これらのツールを巧みに使う熟練者でさえ、ジュニアを基礎的なやり方でメンタリングし訓練する動機を失う可能性があることだ
  • これはソフトウェア開発を超えて、人間が主体性と意思決定をブラックボックスに全面委任する方向へ進む危険を内包している

結論: いまやTalkはコードより価値がある

  • 手で直接開発してきた開発者にとっても、いまやコードを読み、批判的に評価する能力のほうが、構文を覚えて一行ずつタイプする能力より重要になっている
  • もちろん後者も依然として重要な技能であり、効果的にコードを読む能力は結局その土台の上に形成される
  • それにもかかわらず、日常的なソフトウェア開発ワークフローそのものはすでに完全に覆っている
  • うまく語れる熟練開発者、すなわち想像し、説明し、問題を定義し、アーキテクチャを設計しエンジニアリングできる人は、そうでない人に比べてこれまでになく不均衡に大きな優位を持つ
  • 特定の言語、文法、フレームワークに関する知識は、もはや主要なボトルネックではない
  • かつて開発者を縛っていた生理的・物理的制約も、もはや決定的な障害としては機能しない
  • 大規模なコードを即座に作り出す機械は、いまやコモディティ化したツールとなり、誰でもpip installレベルでアクセスできる
  • 別途の専門訓練や、新しい言語やフレームワークを学ぶ必要も事実上なくなりつつある
  • 求められるのは、古典的な批判的思考力、基礎的な人間的能力、そしてこの機械を扱うための最低限の運用能力だけである
  • その結果、既存のソフトウェア開発方法論と役割分担――WaterfallとAgile、開発者とテスター、シニアとジュニア――は根本的な変化を経験している
  • 伝統的な境界は、想像を絶する速さで、圧縮され、曖昧になった反復的な「エージェント的」ループへと統合されつつある
  • それに伴い、ソフトウェア開発を取り巻く人、組織、公共コミュニティのダイナミクスと、共有・協業を支えていた人間的インセンティブも急速に変化している
    • curlのバグバウンティ終了、ZulipのAI利用ガイドライン導入、Ghosttyの明示的AIポリシーなどの事例がそれを示している
  • 歴史上初めて、良いtalkは良いコードよりも幾何級数的に大きな価値を持つ要素になった
  • この変化がもたらす波及効果は重大であり、同時に非常に破壊的である

10件のコメント

 
orange 2026-02-03

「コードを一行も書いたことがない人ですら、数秒で産業規模のコードを作り出せる状況」
-> すがいでマンションを建てたら、それが産業規模なんですか?

 
goathead 2026-02-02

トーバルズのあの言葉が好きだったのですが……時代は完全に変わりましたね

 
kuthia 2026-02-03

「学習環境そのものが消えていくこと」に深く共感します。知識へのアクセスコストがゼロに近い世界で、教育はいまどのような形になっていくのでしょうか?

 
tested 2026-02-03

現実には、ほとんどの採用でJavaなどの言語について常に「実務経験N年以上」が求められる

 
allinux 2026-02-02

「話すこと」と「書くこと」は別物です。
実際には、「話すこと」よりも「書くこと」をうまくやるべきなのかもしれません。

 
pencil6962 2026-02-02

🐎🐎🐎🐎🐎

 
skageektp 2026-02-03

キミノアイバがズキュンドキュン〜

 
koreacglee 2026-02-02

ほんの数年前までは、会社の同僚や開発者の集まりなどに行くと、実力はないのに口先だけ達者な(最新トレンド技術やキーワードへの無思考なアーリーアダプター的執着、せいぜいフレームワークやライブラリの使用経験があるだけで、基礎的なものさえ自分で作ったことがない……)エンジニアたちを「舌プログラマー」と見下したりしていたのに……今や「舌プログラマー」が開発者の現実になってしまいましたね。ああ、隔世の感だ。

 
GN⁺ 2026-02-02
Hacker Newsの意見
  • 今日、CodexにRedux向けの単体テストを書いてもらった
    最初はそれなりに良さそうに見えたのでそのまま流したが、後で自分でテストを追加しようとして見直すと、「これは何だ?」と思う箇所が何十個もあった
    動きはするが、ひどい出来だった。単純なコードなのにこのレベルだった
    AIを使うたびに似たような経験をする — 見た目はそれっぽいが、拡張しようとすると惨事レベルで、結局は自分が全部整理することになる
    「コードは安い」という言葉の問題は、生成は安いが保守は高くつくという点だ
    1日に何千行も生成するのは、クレジットカードで借金を積み上げるようなものだ。無料だと思っていたら後で請求書が来る

    • 私もずっと「1行のコードも負債」と言ってきた。私たちの仕事はその負債を最小化することだが、最近はその原則がほとんど消えたように感じる
    • 私はReduxの主要メンテナだ。どんなコードが生成されたのか本当に気になる
      私たちが直接影響を与えられるかは分からないが、何が起きたのか見てみたい
      ちなみにReduxのテスト方針は公式ドキュメントにまとまっている
    • 「Redux向けの単体テストを書いてくれ」というのは、「犬を描いてくれ」レベルの曖昧な依頼だ
      まずテスト手法を整理し、それに基づいてモデルに依頼すべきだ
      AIは明示されていない部分を勝手に仮定するので注意が必要だ
      根本的にテストが重要だ。AIコードを勘で判断せず、テストで検証すべきだ
      コードの価値はテストの水準に比例する。「LGTM」的に雑に流すのは、目を閉じてバイクを運転するようなものだ
    • 今の時点では、LLMにテストを書かせるのは危険なことが多い
      うまくいく場合もあるが、完全にひどい場合もある
      たとえば正しいユースケースを与えたのにコードが間違っていて、テストが失敗するとAIがテストを書き直してしまった
      つまり、自分基準で成功を定義してしまう危険がある
      以前、Claudeインスタンスを2つ立ち上げて、片方にテスト、もう片方に実装を担当させたことがあるが、設定があまりに面倒だった
    • コード生成はもともと安く感じられていた
      だからこそ、この技術がチームに強制導入される理由の一つだと思う
      クラウド移行と同じで、本当のコストは後から見えてくる。ただ今回はもっと早いだろう
  • 自動車組み立ての比喩で言えば、
    ただ仕様どおりに部品を組み立てる人は、ロボットアームに代替されるのではと心配して当然だ
    しかし設計を試行し、プロトタイプを作り、ロボットアームをプログラムする人は、自動化への不安は小さい
    多くの反論は「AIがその後者の役割も自動化する」というものだが、実際には前者の仕事を後者だと勘違いしている場合が多いと思う

    • LLMを使うソフトウェアエンジニアは一般ユーザーよりはるかに強力だ
      デバッグも、方向転換も、具体的な指示もできるからだ
      一般ユーザーは「これ動きません、直してください」を繰り返すだけだ
      だから仕事の形は変わるだろうが、職業そのものが消えるわけではない
    • 私の仕事は、お金を持っている人たちに私が不可欠だと信じさせることだ
      AIがそれを真似できるなら、私を代替できるかもしれない
      競争の少ない経済なら、「それっぽい模倣」だけでも十分だ
    • 問題は自動化されるかどうかより、CEOが気にしないこと
      ひどいAIの成果物でも、収益とイグジットさえ保証されるなら十分なのだ
      世界はいつだって「分散したゴミ」を許容してきた。Windowsを見れば分かる
    • 私も以前は「後者のタイプ」だと自負していたが、最近は自分の仕事のかなりの部分が誤分類されていたようだ
      実際には自動化可能な部分が多く、これまで自分の自尊心が過大評価されていたのかもしれない
    • あなたが言っているのは伝統的な決定論的自動化
      しかし今日のLLMははるかに汎用的で、どのクラスの仕事でも担える
      ロボットアームに「今年の車のデザインを改善しろ」と言えば止まるだろうが、AIなら意見を出せる
      アイデア → 設計 → 制作 → テスト → 評価までAIが全工程を実行できるなら、
      これは過去の技術とは本質的に異なる革新
  • 「コードを手で書く時代は終わった」というのは大げさだ
    こうした誇張は、人々の専門性を揺さぶり、FOMOをあおるための手口だ
    怯えずに、自分の判断を信じるべきだ

    • どんな技術にも表現のニッチは残る
      ただし、技術が実践の仕方を変えるのは事実だ
      結局重要なのは、性能、コスト、納期、品質のバランスを取る能力だ
  • 「エンジニアリングは終わった」という主張にはいつも反発があるが、
    私が見る限り、大規模製品ではコードを書く作業は全体の10〜20%程度にすぎない
    残りは設計、実験、分析、コミュニケーションなどで、LLMがそこを代替するのは難しい
    むしろ協業と調整はさらに複雑になり、LLMがそれを悪化させることも多い
    だからAIは代替物ではなくツールとして見るのが正しい

    • 実は筆者と完全に反対の立場ではないのかもしれない
      彼らも「数十年続いた開発のやり方が終わった」と言ったのであって、エンジニアリングが終わったとは言っていない
      コード記述が10〜20%なら、残りの「会話」がより重要になったという意味だ
    • 「Code is cheap」の本当の意味は、エンジニアリングの本質がより重要になったということだ
      Linusの言葉どおり、「コードが意図どおりに動くことを示せ」だ
      LLMで数行書くのは簡単でも、安全に修正するのは依然として難しい
      HoneycombのLiz Fong-Jonesもこうしたミスをしたことがあるらしい
    • 実際、コーディングは全体の10%以下だという点に同意する
      企業がLLMのROIを追跡するにつれて、現実に気づくだろう
      今はGartnerのハイプ・サイクルの頂点にいて、まもなく幻滅の谷に下っていく気がする
    • 私も似た経験をした
      Claudeのおかげで素早くリファクタリングしていたが、ある時点で完全に止まった
      理由は、自分が何を望んでいるのか分かっていなかったから
      データモデルが明確でない状態で「続きを書いて」とやると、とてもひどい結果になる
    • Software Engineering at Google』にもあるように、
      プログラミングは短期的な活動だが、ソフトウェアエンジニアリングは長期的なプロセス
      AIは前者を速くするが、後者を置き換えることはできない
  • 「明確な開発計画と実装ノウハウ」という前提は現実的ではない
    プログラミング自体がそのまま計画行為であり、言語は優れた思考の道具だ
    だからLLMを見る視点が分かれる — 言語を思考の道具と見る人と、単なる実行ツールと見る人だ
    前者はプログラミングそのものの価値を見ており、後者はコードを隠したがる
    結局は選択の問題だ。最初から概念モデルをきちんと立てるのか、それとも後でデバッグ地獄を見るのか
    今のツールは前者に合わせて作られていない。ツールのギャップが大きい

    • 多くの人はLLMを思考の道具として見ていて、プログラマはそこにコーディングツールとしての視点を加えている
      一部の人はその二つを組み合わせて新しいやり方で働いている
  • 「Talk is cheap」の本来の意味は、「話すのは簡単で価値がない」ということだ
    なのに「Code is cheap. Show me the talk.」は、それよりさらに無価値だと言っているようで、最初から不快だった
    実際に記事を読んでみると、その予想は当たっていた

    • タイトルにこだわりすぎだと思う。それはただのジョーク
      筆者はコードに無知ではない。オープンソース活動も活発だ
      要点は単純で、昔は良い設計をコードに落とし込むのが高価だったが、
      今は安くなったので、設計の質がより重要になったということだ
    • 実際、このフレーズはLinusの言葉、
      “Talk is cheap, show me the code”反転パロディ
    • 別の文脈では「話」のほうが重要かもしれない
      コードよりも開発者の頭の中のモデルが核心だからだ
      コードはそのモデルの副産物にすぎず、人間の解釈なしには意味を持たない
      こうした視点はLLMの使い方にも大きく影響する
  • 「何十年もやってきたやり方が終わった」という言葉には同意しづらい
    2005年、2015年、2025年の開発スタイルはそれぞれ違っていた
    変化は常にあり、「何十年も同じだった」という前提が間違っている

    • ただ、この20年間で中核のワークフローは大きく変わっていない
      ツールは進化したが、開発者の働き方は似ている
    • 昔のVisual Age for Javaの即時コンパイル機能を思い出すと、
      今のneovimは当時よりずっと強力だ
      この30年の漸進的な進歩は過小評価されがちだ
    • 1995年と2005年の差のほうがずっと大きかった
      当時は大半の情報を紙の本やリバースエンジニアリングから得ていた
  • 「Talk is even cheaper, still show me the code」のほうがしっくりくる
    AIは10倍の生産性を約束するが、実際にそんな結果はほとんど見たことがない
    AIのおかげで複雑さが耐えられる程度にはなったが、それでもReactアプリを書くのは苦痛
    非決定的なAPIを扱うのもつらい
    それでも、タイプミスやサンプル検索に時間を取られにくくなったのは利点だ
    だが、推論力不足と知識の限界のせいで、コーディングは依然として退屈だ

    • たとえばClaudeのターミナルプログラムはReactを60fpsでレンダリングしたあと、
      ANSI文字に変換してターミナルに上書きする —
      実際にはcursesで簡単にできることを複雑に実装しているわけだ
  • 「Code is cheap. Show me the talk.」のようなフレーズは、今やクリック誘導の釣り文句として乱用されている
    記事自体は悪くないが、新しさはない
    AIブームに乗っているのは企業だけでなく、ブロガーやインフルエンサーも同じだ
    AIに肯定的でも否定的でも、刺激的なタイトルを付ければHNやRedditでトレンドになる
    ちなみにこのフレーズの元ネタはこのツイートと、
    このミームページ

  • ついに誰かが極端論のあいだにある現実的な中間地帯をうまく表現した
    LLMは神でも災厄でもない。ツール
    OpenAI、Google、Microsoftのような企業によるレント抽出を批判しつつも、
    QwenやMistralのようなローカルモデルを活用できる
    クラウドLLMはセキュリティ上E2EEが不可能なので、企業環境には不向きだ
    しかしローカルLLMのおかげで、今では一人でもエンタープライズ級の作業が可能になった
    Mac Mini一台でデータベースクエリ、API統合、自動化までこなしている
    大規模組織でないなら、シニアのジェネラリスト一人がミドルクラス3人を置き換えられる
    もちろん、雇用縮小や著作権の問題などには今でも不満が多いが、
    ローカルLLMは私の中核ツールキットとして定着した

 
xfile284 2026-02-03

「信仰」をしている人たちに見せたい文章ですね