9 ポイント 投稿者 GN⁺ 2026-01-12 | 5件のコメント | WhatsAppで共有
  • 最近、大規模言語モデル(LLM) は中規模プロジェクトをほぼ単独で完成できるほど進化しており、プログラミングのやり方が根本的に変わりつつある
  • コードを直接書く行為の必要性は減り、何を作るか、どう説明するかについて考える能力のほうが、より重要なスキルへと移りつつある
  • Redis創始者のAntirezは、Claude Codeを使ってUTF-8対応の追加、Redisテストのバグ修正、BERT埋め込み用Cライブラリの作成、Redis Streams内部構造の再現という4つの作業を数時間で実施
  • AIはソフトウェア開発の民主化を促進し、小規模チームでも大企業と競争できる環境を作りつつある
  • しかし、AI技術の中央集権化リスクや雇用減少の問題に対する社会的対応は必要であり、AIを避けるのではなく積極的に活用すべき

プログラミングの変化とLLMの役割

  • 最新のLLMは、十分なヒントを与えれば中規模プロジェクトをほぼ独力で完成させられる
    • 成功するかどうかは、プログラミングの種類と問題を明確に表現する能力によって左右される
    • システムプログラミングのようなテキストで表現可能な作業ほど効果が大きい
  • ほとんどのプロジェクトでは、直接コードを書くことは非効率であり、今は何を作るのか、どう作るのかを理解することのほうが重要
  • 筆者のAntirezはAIを使って次の4つの作業を行った
    • linenoiseライブラリにUTF-8対応を追加し、エミュレーション端末ベースのテストフレームワークを構築
      • 以前はテストコストに対して価値が低いとして断念していた作業を、AIで実現
    • Redisテストのタイミング・TCPデッドロック関連の断続的な失敗問題を解決
      — Claude Codeがプロセス状態を分析してバグを解決
    • BERT系埋め込みモデル推論用の純粋なCライブラリを5分で生成
      • PyTorchより15%遅いが同じ結果を提供。約700行規模のコード
      • GTE-smallモデル変換用のPythonツールを含む
    • Redis Streamsの内部構造変更作業を設計文書だけで再現
      • レビューと実行承認の時間を除けば約20分で完了
  • こうした経験を通じて、AIがプログラミングの本質を変えつつあることを確認した

AIと開発者の関係

  • AIがコードを書いても、開発者の役割はなくならない
    • 重要なのは問題を定義し、AIが生成したコードをレビュー・調整する能力
    • AIは協力者(partner) として開発生産性を最大化する
  • AI企業の収益性、株価、CEOの発言などは長期的には重要ではない
  • プログラミングの本質的変化は後戻りできない段階にある
  • 本人は、自分が書いたコードがLLMの学習に使われたことを前向きに評価している
    • これを知識とシステムの民主化の過程と見ている
    • オープンソースが1990年代にそうだったように、AIも小規模チームの競争力強化に寄与すると見ている

AI技術の民主化と中央集権化への懸念

  • 現在は中国などで公開モデルが登場し、一定水準の民主化が進んでいる
    • クローズドな研究所の先行モデルと比べても性能差は大きくない
  • しかし、このバランスが恒久的とは限らない
    • AI技術が少数企業に集中する可能性について懸念がある
  • 大規模ニューラルネットワークは本質的に驚くべき性能を発揮しており、特定企業だけが独占できるような「魔法」は存在しない

社会的影響と対応

  • AIによって雇用減少が起こる可能性への懸念はある
    • 企業が人員を減らすのか、より多くのプロジェクトを進めるのかは不確実
    • 一部産業では人間が完全に代替されるリスクもある
  • そのため政府の役割が重要
    • 失業者を支援し、変化に対応できる政策が必要
    • 解雇が増えるほど政治的圧力が強まり、社会的保護を求める方向へ進むだろうと見ている

開発者への助言

  • AIを拒否したり回避したりすることはキャリアの助けにならない
    • 新しいツールを自分で試し、長期間使ってみることが必要
    • 短期テストで結論を出さず、数週間単位の実験とともに継続して試すべき
  • AIを通じて自分の能力を拡張する方法を探すべき
  • コーディングの本質は「書くこと」ではなく何かを作る楽しさであり、AIを活用すればより多く、より良く作れる

5件のコメント

 
m00nlygreat 2026-01-12

思っているほど、コードで解決できる問題は現実には多くありません。コードはかなり多くの問題を解決できますが、ほとんどの問題はコードやモニターの外側にあります。

 
flaxinger 2026-01-14

頑なな不信と同じくらい、絶対的な盲信も間違っていると思います。
適切に長所と短所をよく考慮して使うことが重要で、ただやみくもにFOMOの空気を作り出すのはAI企業の商法だと思います。

 
GN⁺ 2026-01-12
Hacker Newsの意見
  • 夜通しコードを書いて、プロジェクトが動くのを見ていたあの情熱は、「何かを作る喜び」だった。
    その火種の形は人それぞれだ。ある人は「コンピュータを自分の思いどおりに操る」感覚から、またある人は「他人の問題を解決する」ことから、さらに別の人は「感情を呼び起こす何かを作る」ことから動機を得る。
    自分の場合、最初は他人のWebサイトを壊したくてプログラミングを始めたが、作って共有する過程のほうが楽しくなった。だから他人のフィードバックを聞くことが自分の火種になった。
    結局、プログラマーごとに理由は違い、ある人にとってはLLMが楽しさを増やすが、ある人にとっては核となる楽しさを奪う存在になる。

    • 自分にとっては、LLMでコーディングするとフロー状態に入れなくなる。トークンが出力されるのを待ちながらレビューして修正する過程がつらすぎる。自分でコードを一気に書き出しながら没頭するときの楽しさが消えてしまう。
    • 「文字を直接入力する行為そのものが好きなプログラマー」という話を聞いて、Richard Hammingの本に出てきたSymbolic Assembly Program(SAP) の逸話を思い出した。昔はアセンブリを書くことが「本物のプログラマー」の象徴で、自動化ツールを使うのは「臆病者のすること」だと見なされていたという話だ。
    • 最初は他人のサイトを壊そうとしていたのに、結局は創作の喜びを見つけたというのは、悪い意図から良い結果が生まれた素敵な例のように思える。
    • 自分のフィードでは、「AI礼賛」が「AI批判」を5対1で圧倒している。antirezやsimonwのような中道的な視点は少なく、本当に急進的な立場は「AIは一部の人に漸進的だが確実な純利益をもたらす道具だ」と信じる側だ。
    • 問題はコード生成ではなく保守だ。AIが作ったコードをそのままコミットしたなら、あとで人間が修正するのか? それともAIがバグを直してくれると信じるのか? 結局、クリーンアップは誰がやるのかという問題だ。
  • antirezの文章には全面的に同意する。AIは開発者に大きな利点をもたらしており、今はインターネット以降で最大の技術革命のただ中にいる。
    ただし彼はAIの欠点や反AI的な見方の理由を分析していない。社会的影響、とくにソフトウェアエンジニアリングの未来への懸念に触れていない点は惜しい。

    • ビジネスの観点から見れば、反AIの姿勢は自分の足を引っ張る行為だ。ほとんどの競争環境では、AIを活用して速度を上げることが企業の利益にかなう。今のうちにLLMを身につけておけば、次の変化にも適応しやすい。
    • 「難しい部分はない」と思う。反AIの論理は古びており、エージェント型コーディング(agentic coding) はすでに機能している。
  • 「AI列車に乗らないと取り残される」という言い方が理解できない。まだ自分の仕事にはあまり役立っていないので、ツールが十分よくなったときに始めても遅くないと思う。

    • どんな仕事ならAIの助けを受けられないのか気になる。API情報の検索、ビジネスロジック設計のレビュー、コードレビューなど、AIの活用範囲は非常に広い。AntirezもRedisのコードでAIを使ってバグを見つけている。
    • 「数週間で追いつける」という考えは錯覚だ。自分はChatGPTの公開以来、毎日LLMでコードを扱ってきたが、直感(intuition) を積み上げるのに数か月、数年かかる。今始めなければ取り残されるリスクは大きい。
    • 自分も以前はのんびり構えていたが、今は変化に素早く飛び込むのが賢明だと感じている。最近のツールは3年前とはまったく違い、マルチエージェント・オーケストレーションのような概念まで登場している。
    • 逆に、ツールとワークフローが絶えず変わる今は、「取り残される」心配はそれほど大きくない。安定するまでは大きな流れだけ把握しておくのが賢い。Palm PilotのGraffitiのようにすぐ消える技術にしがみつく必要はない。
    • AIツールに慣れろという話は、地平線効果(horizon effect) に陥っているように見える。技術はこれからも変わり続けるし、本当に必要なのはコミュニケーション能力だ。プロジェクトの核心を素早く明確に表現できる人が有利になる。
  • 「反AIブーム」という表現は、あまりに単純化しすぎた見方だ。技術的にはまだ粗いが、有用性は明らかであり、消えることはないだろう。
    ただしビジネス面では収益モデルが不明瞭だ。技術は残るだろうが、これを基盤にしたスタートアップの崩壊は予想される。
    5年後もAIはより多く使われているだろうが、今存在するAI企業の大半は消えている気がする。

    • 2000年代後半にも「インターネットで金を払う人はいない」と言われていた。企業が開発者には数十万ドルを使いながら、AIツールには数百ドルしか払おうとしないのは不均衡だ。
    • ブログ記事のタイトルは、単にAIブームを風刺した冗談だ。
    • YouTube、Instagram、WhatsAppの買収時にも「金の無駄だ」と言われたが、今では卓越した判断として評価されている。
    • それでもHNには、いまだに「LLMは役に立たないゴミ生成器だ」という不満が多い。わずか6か月前よりは減ったが、まだ存在する。
  • 「AIがプログラミングを永遠に変える」vs「ただ自分の頭で考えろ」という終わりのない論争がある。自分は後者を好む。AIの利点を語るだけでは問題は解決しない。

    • エンジニアの核心は、システムの理解と正確性だ。LLMが書いたコードを深くレビューしなければ、目標は達成できない。
    • 実際には戦争などない。インターネットが論争的な話だけを強調しているだけだ。ほとんどのユーザーはAIの利点を認識しつつも、思考とレビューが依然として必須だと分かっている。
    • 世の中に永遠の戦争はない。「とにかくXを使え」というアプローチは、結局は消えていく。
  • 「最新のLLMが中規模プロジェクトをほぼ単独で完成させる」という話は誇張だ。ドメイン知識のある人が具体的な仕様を与えれば生産性は大きく上がるが、成果物の品質は依然としてユーザーの知識水準を反映する。
    良いトラクターを与えても、農家の腕が重要だという比喩が的確だ。

    • 誰かが8000件以上のテストをコピペして、完全なHTMLパーサーを作った例がある。その程度のヒントがあれば可能だ。
    • 「大規模プロジェクト」の定義が曖昧だ。すでに無数のGitHubリポジトリがある領域と、未知の領域ではまったく違う。
    • もしこれが10年以上の経験者にしか効かないのだとしたら、むしろ反AIの主張のように聞こえる。AIは誰でも簡単に使えるという約束が核心だったのだから。
    • 自分もそう思う。LLMは生産性の倍率器にすぎず、入力の質によって結果は変わる。具体的な技術仕様で導けば、魔法のように機能する。
  • 開発ツールがますます抽象化されるほど、開発者の影響力と報酬はむしろ大きくなってきた。LLMもその延長線上にある。
    抽象化は仕事を簡単にするが、その分より多くの仕事を可能にし、新たな複雑さも生む。結局、信頼と影響力が重要になる。だからCEOは従業員よりはるかに高い報酬を得るのだ。
    LLMは開発者の力と影響力をさらに大きくするだろう。

    • ただし、LLMを「新人インターン」のように見る人もいる。つまり、自分で作る代わりに指示して管理する仕事へと変わる。経営陣がAIを称賛する理由もここにある。プログラミングを管理業務に変え、「プログラマー」という職種そのものを減らす方向だ。
      結局、昔のように「上に上がるか(out)、消えるか」の時代がまた来るだろう。人を扱う技術とビジネス感覚を身につけなければ、次第に無意味な存在になるリスクがある。
  • 「Look ma, no hands」式のAI過信に陥ってはいけない。
    Antirez + LLM + CFOの組み合わせなら、数億ドル規模のRedis企業を作れるかもしれないが、それは彼がRedisを完璧に理解しているからだ。
    もしPostgresのような見慣れないコードベースなら、同じ成果を出すのは難しく、ほとんどの開発者はそうした未知の環境で働いている。
    結局、LLMの本当の価値はドメインエキスパートにあり、組織がAIを正しく活用するには従業員教育と学習への投資が必須だ。

    • ブログ記事も同じ文脈だ。出力の質はヒントの質、つまりユーザーの理解水準にかかっている。
    • AIは結局、高度なオートコンプリートだ。望む結果を思い描き、正しい出力を見分けられなければならない。だからLLMで学ぶのは危険だ。検索エンジンなら良い資料を見分けられるが、LLMにはその判別シグナルが不足している。
    • LLMはコード作成だけでなく、理解のプロセスも助けると思う。「今や面白いのはコードを書くことではなく、何をどうするかを理解することだ」というantirezの言葉に共感する。
    • 多くの経営陣はAIで未来を予測しようとしているが、実際には現場のエンジニアが依然としてプロダクションコードを扱っている。
    • 「ドメインエキスパート」の意味も変わりつつある。自分はコンピュータビジョン分野の経験はなかったが、視覚的フィードバックループを通じて素早く学習した。テスト画像をLLMにアップロードして対話しながら問題を解決した。
      このように検証の仕組みをうまく整えれば、未知の分野でも成果を出せる。結局必要なのは、直感、批判的思考、科学的な思考法だ。
  • 「LLMが自分のコードを学習した事実がうれしい」という言葉には同意しない。
    自分はそうではない。むしろソフトウェア品質は低下しているし、LLMがより良いコードを作るとは思わない。

  • 「AIを拒んでも世界を止めることはできない」という言葉には共感する。
    自分も友人たちに「実際に使ってから判断しろ」と助言している。5分触って結論を出すのではなく、数週間実験してみろと言っている。
    今のメディアの大半は、クリックのための否定的な物語を売っている。正確に判断するには、自分で使ってみるしかない。
    そして今は、肯定的なシグナルをもっと注意深く見るべきだ。「これでこういうことをやってみた」という事例のほうが、「まだこれはできない」という話よりはるかに価値がある。

 
parkindani 2026-01-13

まだAIを使わずに、AIはゴミみたいなコードしか生まないと言っている開発者がかなり多いみたいですね。不思議です……

 
dbs0829 2026-01-13

一方で、問題点を指摘する声も無視してはいけないと思います。少しの批判でさえ、ただの非難のようなものとして片づけられてしまうこともかなり多いと感じます。