- 最近、大規模言語モデル(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の内部構造変更作業を設計文書だけで再現
- こうした経験を通じて、AIがプログラミングの本質を変えつつあることを確認した
AIと開発者の関係
- AIがコードを書いても、開発者の役割はなくならない
- 重要なのは問題を定義し、AIが生成したコードをレビュー・調整する能力
- AIは協力者(partner) として開発生産性を最大化する
- AI企業の収益性、株価、CEOの発言などは長期的には重要ではない
- プログラミングの本質的変化は後戻りできない段階にある
- 本人は、自分が書いたコードがLLMの学習に使われたことを前向きに評価している
- これを知識とシステムの民主化の過程と見ている
- オープンソースが1990年代にそうだったように、AIも小規模チームの競争力強化に寄与すると見ている
AI技術の民主化と中央集権化への懸念
- 現在は中国などで公開モデルが登場し、一定水準の民主化が進んでいる
- クローズドな研究所の先行モデルと比べても性能差は大きくない
- しかし、このバランスが恒久的とは限らない
- AI技術が少数企業に集中する可能性について懸念がある
- 大規模ニューラルネットワークは本質的に驚くべき性能を発揮しており、特定企業だけが独占できるような「魔法」は存在しない
社会的影響と対応
- AIによって雇用減少が起こる可能性への懸念はある
- 企業が人員を減らすのか、より多くのプロジェクトを進めるのかは不確実
- 一部産業では人間が完全に代替されるリスクもある
- そのため政府の役割が重要
- 失業者を支援し、変化に対応できる政策が必要
- 解雇が増えるほど政治的圧力が強まり、社会的保護を求める方向へ進むだろうと見ている
開発者への助言
- AIを拒否したり回避したりすることはキャリアの助けにならない
- 新しいツールを自分で試し、長期間使ってみることが必要
- 短期テストで結論を出さず、数週間単位の実験とともに継続して試すべき
- AIを通じて自分の能力を拡張する方法を探すべき
- コーディングの本質は「書くこと」ではなく何かを作る楽しさであり、AIを活用すればより多く、より良く作れる
5件のコメント
思っているほど、コードで解決できる問題は現実には多くありません。コードはかなり多くの問題を解決できますが、ほとんどの問題はコードやモニターの外側にあります。
頑なな不信と同じくらい、絶対的な盲信も間違っていると思います。
適切に長所と短所をよく考慮して使うことが重要で、ただやみくもにFOMOの空気を作り出すのはAI企業の商法だと思います。
Hacker Newsの意見
夜通しコードを書いて、プロジェクトが動くのを見ていたあの情熱は、「何かを作る喜び」だった。
その火種の形は人それぞれだ。ある人は「コンピュータを自分の思いどおりに操る」感覚から、またある人は「他人の問題を解決する」ことから、さらに別の人は「感情を呼び起こす何かを作る」ことから動機を得る。
自分の場合、最初は他人のWebサイトを壊したくてプログラミングを始めたが、作って共有する過程のほうが楽しくなった。だから他人のフィードバックを聞くことが自分の火種になった。
結局、プログラマーごとに理由は違い、ある人にとってはLLMが楽しさを増やすが、ある人にとっては核となる楽しさを奪う存在になる。
antirezの文章には全面的に同意する。AIは開発者に大きな利点をもたらしており、今はインターネット以降で最大の技術革命のただ中にいる。
ただし彼はAIの欠点や反AI的な見方の理由を分析していない。社会的影響、とくにソフトウェアエンジニアリングの未来への懸念に触れていない点は惜しい。
「AI列車に乗らないと取り残される」という言い方が理解できない。まだ自分の仕事にはあまり役立っていないので、ツールが十分よくなったときに始めても遅くないと思う。
「反AIブーム」という表現は、あまりに単純化しすぎた見方だ。技術的にはまだ粗いが、有用性は明らかであり、消えることはないだろう。
ただしビジネス面では収益モデルが不明瞭だ。技術は残るだろうが、これを基盤にしたスタートアップの崩壊は予想される。
5年後もAIはより多く使われているだろうが、今存在するAI企業の大半は消えている気がする。
「AIがプログラミングを永遠に変える」vs「ただ自分の頭で考えろ」という終わりのない論争がある。自分は後者を好む。AIの利点を語るだけでは問題は解決しない。
「最新のLLMが中規模プロジェクトをほぼ単独で完成させる」という話は誇張だ。ドメイン知識のある人が具体的な仕様を与えれば生産性は大きく上がるが、成果物の品質は依然としてユーザーの知識水準を反映する。
良いトラクターを与えても、農家の腕が重要だという比喩が的確だ。
開発ツールがますます抽象化されるほど、開発者の影響力と報酬はむしろ大きくなってきた。LLMもその延長線上にある。
抽象化は仕事を簡単にするが、その分より多くの仕事を可能にし、新たな複雑さも生む。結局、信頼と影響力が重要になる。だからCEOは従業員よりはるかに高い報酬を得るのだ。
LLMは開発者の力と影響力をさらに大きくするだろう。
結局、昔のように「上に上がるか(out)、消えるか」の時代がまた来るだろう。人を扱う技術とビジネス感覚を身につけなければ、次第に無意味な存在になるリスクがある。
「Look ma, no hands」式のAI過信に陥ってはいけない。
Antirez + LLM + CFOの組み合わせなら、数億ドル規模のRedis企業を作れるかもしれないが、それは彼がRedisを完璧に理解しているからだ。
もしPostgresのような見慣れないコードベースなら、同じ成果を出すのは難しく、ほとんどの開発者はそうした未知の環境で働いている。
結局、LLMの本当の価値はドメインエキスパートにあり、組織がAIを正しく活用するには従業員教育と学習への投資が必須だ。
このように検証の仕組みをうまく整えれば、未知の分野でも成果を出せる。結局必要なのは、直感、批判的思考、科学的な思考法だ。
「LLMが自分のコードを学習した事実がうれしい」という言葉には同意しない。
自分はそうではない。むしろソフトウェア品質は低下しているし、LLMがより良いコードを作るとは思わない。
「AIを拒んでも世界を止めることはできない」という言葉には共感する。
自分も友人たちに「実際に使ってから判断しろ」と助言している。5分触って結論を出すのではなく、数週間実験してみろと言っている。
今のメディアの大半は、クリックのための否定的な物語を売っている。正確に判断するには、自分で使ってみるしかない。
そして今は、肯定的なシグナルをもっと注意深く見るべきだ。「これでこういうことをやってみた」という事例のほうが、「まだこれはできない」という話よりはるかに価値がある。
まだAIを使わずに、AIはゴミみたいなコードしか生まないと言っている開発者がかなり多いみたいですね。不思議です……
一方で、問題点を指摘する声も無視してはいけないと思います。少しの批判でさえ、ただの非難のようなものとして片づけられてしまうこともかなり多いと感じます。