ソフトウェアエンジニアリングの幻滅、再び

約6年前、僕は「ソフトウェアエンジニアリングの幻滅」というタイトルの記事を読んだ。

飛行機や建築をソフトウェア開発と比較するのはあまり適切ではないと僕は思っている。なぜなら、一方は滅多に変更されないプロセスであり、ソフトウェア開発は継続的な反復（イテレーション）を前提として開発されるものだからだ。両者の特性は異なり、同列に扱うのは難しい。これは、家を建てている途中で「ハウルの動く城」の機能を追加して家自体が動けるようにしてくれ、と要求しないのと同じだ。

AIが登場してから、当初（2023年）は「大したことない、日常的な開発を代替するには程遠い」と思っていたところから、2025年にはすでにAIによる開発補助に慣れ、自動補完は欠かせない機能となり、今ではコードのほぼ90%以上がAIによって直接生成されるようになった。ソフトウェアエンジニアリングの幻滅は、別の形で再び押し寄せてきている。

以前はエンジニア自身が酷いコードを書いていたが、今ではAIが「一見動きそうだが誰も本当には理解していないコード」を大量に吐き出すようになった。

AIが登場した現在のソフトウェア開発では、大まかに2つの派閥に分けることができる。片方は、コーディングはすべてAIに任せるべきであり、保守性や可読性、拡張性などを気にする必要はなく、人間は意図や方向性の確認だけを担当すればいいと考える派。もう片方は、こうした「AI Slop（AIが垂れ流すゴミ）」には何の価値もないと考える派だ。

@yusukebe Yusuke Wada (@yusukebe) on X まじでPRの意味がなくなるな 低品質のPR PR取り込んでもらいたいだけの人のコミットを入れたくない CI回すのが怖い コードならメンテナが書ける

このツイートの主は Hono の作者だ（もし未だにExpressを使っているなら、ぜひHonoを試してみてほしい）。彼は最近、明らかにAIが生成した低品質なPull Requestを数多く受け取ってしまい、非常に頭を悩ませているというツイートをいくつか投稿していた。

僕たちは今、LLMの登場とLLMの成熟の間にある、この混乱期の中にいる。

LLMモデルが安定して成熟する時代はいつか必ず訪れる。モデルの進化はソフトウェア開発のあり方を根本から変えるだろうが、それがいつになるのかは分からない。特異点（シンギュラリティ）がまだ訪れていない今のうちは、流れに身を任せるしかないのだろう。

苦痛と興奮の狭間で

僕は一方で、これからのAIの発展に大いに期待している。モデルの能力がますます向上し、強力になっていけば、現在人間が介入する必要のある多くのことは必然的に少しずつ代替されていくだろう。

コード自体の品質にせよ、AIが生み出すコードの品質にせよ、あるいは作品をより良くするためにかける手間にせよ、参入障壁はますます低くなっていく。

だが、最近起きたいくつかの出来事によって、僕は少なからず苦痛も感じている。プロジェクト内やコミュニティにおいて、AIが書いたものを一切レビューせずにそのまま提出する人をよく見かけるようになったからだ。

これは、彼らが読み手の気持ちを考えていないことを意味している。コードにせよ、ドキュメントにせよ、時には何かを議論する際にも、Geminiとの会話履歴をそのまま貼り付けてくる相手さえいる。僕が思うに、最低限の基準として、まずは自分自身の考えを持ち、AIを通じてそれを確認したり補強したりした上で提示すべきだ。そして、まずは自分自身で一次的な整理を行うこと。それこそが読み手に対する敬意だと僕は思っている。

Simonが Anti-patterns: things to avoid という記事で言及しているように、AIを使って何千行ものコードを生成し、自分で確認もせずにPRを出すというのは、「このコードが使えるかどうかを検証する」作業をレビュアーに押し付けているのと同じだ。

レビュアーだって自分でAIに書かせることができるのに、一体君は何を貢献したというのか？

責任あるPRとは、本来こういうもののはずだ。自分で検証したからこそ、そのコードが正常に動くという確信を持っていること。レビュアーが開いた瞬間に閉じたくならないよう、変更範囲が十分に小さいこと。そして、なぜこの変更を行うのかという十分なコンテキストがPRの説明に書かれていること——決して、AIに生成させた、一見プロフェッショナルに見えるが自分でも読んでいないような説明文を載せることではない。 AIによってコードを生成することがあまりにも簡単になったからこそ、逆に自分自身が手をかけたことを能動的に証明する必要があるのだ。

手動テストの記録や、実装の選択に関する説明、あるいはスクリーンショットを1枚添えること。これらはすべてレビュアーに対して、「僕はちゃんと読みました。これはあなたに押し付けるゴミではありません」と伝えるためのものだ。

センス

もう一つ僕を苦しめているのは、センスと経験に関わる部分だ。

プログラミングを長く続けていると、自然といくつかのアンチパターンを嗅ぎ分けられるようになる。この書き方でも今は動くけれど遅かれ早かれ問題が起きる、といったことが直感的に分かるし、修正自体はほんの数行で済むことも多い。

だが問題は、今では多くの人がAIにコードを生成させてそのまま使うことに慣れてしまい、振り返って見直すことをあまりしなくなったことだ（僕自身でさえそうだ）。これによって悪循環が生まれている。AIは問題のあるコードをコンテキストとして読み込み、その後に生成されるコードもすべてその問題のある土台の上に構築されるため、利用者がまったく気づかないうちにどんどんおかしな方向へと進んでいってしまう。

具体例をいくつか挙げよう。

Reactの useEffect 内で setState を呼び出して不要な再レンダリングを引き起こしたり、あるいはアーキテクチャ上の決定として、CDNを使わずにファイルシステムから直接静的リソースを読み込んだりすることだ。

こうしたものはローカルでのテストでは何の問題もないし、ユーザーが少ない時も問題にならない。だが、トラフィックが増え、コードベースが肥大化し始めた時には、もはや数行書き直すだけで済むような話ではなくなっていることに気づくのだ。

そしてこれは、開発者が怠けてチェックしなかったからとは限らない。おそらくどこに問題があるのかすら分かっていないのだ。その落とし穴にハマった経験がないから、見えないのだ。しかし、こうした事柄はソフトウェアの品質に大きな影響を与える。その結果、品質を気にする人ほど苦しむことになる。Huliや龍哥も似たようなことを言っていた。

AI 時代寫程式，你是在學習還是在偷懶？ | 高見龍 AI 帶來的變革堪比當年從組合語言到高階語言的轉變，而最核心的挑戰在於從「確定性」轉變到「非確定性」。AI 會說謊、會瞎掰，但用得好能讓效率翻倍。本文探討 Vibe Coding 的陷阱、學習迴圈的重要性，以及初學者與資深工程師使用 AI 的策略差異。AI 是工具不是魔法，能讓你變強也能讓你變弱，關鍵不在於「要不要用 AI」，而在於「怎麼用 AI」 高見龍

AI 與鴨子，惰性與真實 - Huli 終於到了個我覺得適合來寫一篇文章，聊聊我對 AI 的感想的時機了。 前兩年都還太早，很多東西進步的速度太快，文章會跟不上。舉例來說，假設我 2023 年底寫了篇文章，可能會說 AI 看起來厲害但工作上幫不了太多忙。若是 2024 年底寫，會說 AI 工作上可以幫忙了，但一半的工作還是要自己來。而.. Huli

僕のセンスは「確かな基礎」の上に成り立っているとも言える。他の人のアウトプットが僕の考える基礎に達していないとき、それが僕の苦痛の種の一つになる。そして長く続けば、自分自身さえも影響を受けてしまうのだ。

僕は今も答えを探している

つい昨日、Claude Code で人的ミスによりSource Mapが流出し、ソースコードが容易に復元できる事態が発生した。Anthropicの年収数千万円超えのエンジニアでさえミスを犯す（原因はAIではないかもしれないが）。だとすれば、基礎を重視することや、セキュリティ問題、品質を気にすることすら、もう重要ではなくなってしまったのだろうか？

Coding is largely solved ——Boris Cherny

囲碁と野球

AlphaGoが10年前に世界最強の棋士である李世乭や柯潔を破って以来、現在ではAIに勝てる人間の棋士は一人もいない。囲碁はある意味ですでに「解決」された——だが、囲碁はそれによって消滅したわけではない。人々は今も碁を打ち、プロ棋士が存在し、素晴らしい一手に対して胸を熱くする人がいる。

野球もそうだ。客観的に見れば、グラウンドで9＋1人の人間がボールを投げ、打ち、塁を走ることは、この世界の営みに何の実質的な役にも立っていない。おそらくすべての競技スポーツがそうだろう。それでも人類は、こうした「役に立たない」ことを、極めて真剣に行うのだ。

おそらく、AIが大半の生産的なタスクを解決してしまった後、プログラミングもまた囲碁や野球に近い営みになっていくのかもしれない——君でなければならないから書くのではなく、そのプロセス自体に価値を感じているからこそコードを書くのだ。

次の一歩

流れに身を任せること。それがおそらく最善の答えなのだろう。技術的特異点（シンギュラリティ）が訪れる前に、僕が試してみたいことがまだいくつかある。

• 僕の中にあるセンスを、再現可能な基準として具現化すること
• アーキテクチャや技術選定を含む、ここ数年のソフトウェア開発の経験を共有すること
• 日本のソフトウェア開発に対するいくつかの所感

もう一点、最近深く感じていることがあるのだが、まだ明確な形にはなっていないので、進展があればまた共有したいと思う。

最後に、『ひゃくえむ。』の中で僕がとても気に入っている財津の言葉をシェアしたい：

不安は対処すべきではない。人生は常に失う可能性に満ちている。そこに命の醍醐味がある。 恐怖は不快ではない。安全は愉快ではない。不安とは君自身が君を試す時の感情だ。 栄光を前に対価を差し出さなきゃならない時、ちっぽけな細胞の寄せ集めの人生なんてくれてやればいい。

不安は対処すべきものではない。人生は常に失う可能性に満ちている。そこにこそ命の醍醐味がある。恐怖は不快なものではなく、安全も愉快なものではない。不安とは、自分自身が自分を試しているときに生じる感情だ。栄光を前にして代償を差し出さなければならないとき、ちっぽけな細胞の寄せ集めにすぎない人生なんてくれてやればいい。

君は何がしたい？