ハクソク

世界を動かす技術を、日本語で。

AIはより多くのエンジニアリングの規律を求めている。少なくともではない。

2026年6月17日原文(charitydotwtf.substack.com)

概要

  • 本文はAIコード生成の進化と、それがソフトウェア開発にもたらすパラダイムシフトについて論じる内容
  • 2025年以降、AIによるコード生成が実用レベルに達し、開発現場の常識が大きく変化した経緯を解説
  • コードの「耐久資産」から「キャッシュ」への価値転換、そして評価・仕様理解の重要性を強調
  • Phoenix ArchitecturesやImmutable Infrastructureなど、現代的な開発思想の引用と考察
  • 今後のAI活用や、仕様化・評価手法の進化可能性についても展望

AIコード生成とソフトウェア開発の転換点

  • 2025年以降、AI生成コードの品質が大幅に向上し、 Opus 4.5 の登場で実用性が決定的に
  • AI Enthusiasts は進化の速さを予見していたが、現場の多くは懐疑的だった現実
  • Agentic harnesses や tool use、 function calling などの技術進展でAIの汎用性が拡大
  • コード生成の経済性 が一変し、「コード＝貴重な資産」から「使い捨て可能なキャッシュ」へ価値転換
  • 再生成が容易 になることで、従来の「編集による蓄積」から「置換によるリセット」へ設計思想がシフト

コードレビューとAI時代の誤解

  • 筆者の意図は「コードレビュー廃止」ではなく、 AI時代の新たな評価基準 の模索
  • AIコードはバグやエッジケースが残るが、解決される領域も急拡大
  • 「信じられるまで待つ」姿勢は、指数関数的変化の中では通用しない ことを強調
  • SRE（Site Reliability Engineering） 視点からは「本番環境こそが真実」の信念
  • 「テストは本番で」 という考え方の再評価

Phoenix Architecturesと「置換」の思想

  • Chad Fowler の「Phoenix Architectures」や「Relocating Rigor」などの思想に共感
  • Immutable Infrastructure や Stateless Services、 Blue-green Deployments の共通前提：「稼働中のものは直さず、置き換える」
  • AIはこの置換思想をアプリケーションコードレベルにまで拡張
  • 「The Deletion Test」 ：システムの実装全削除を想定し、「何が本当に必要か」を評価
    • 実は「コードそのもの」ではなく、「評価・仕様の明確化」が本質的課題
  • コードが唯一の知識の保管場所であることの危うさ を指摘

コードの役割変化とアーキテクチャの未来

  • コードは「耐久資産」から「キャッシュ」へ ：現状を表現する一時的なアウトプット
  • 再生成が容易な時代 には、コードの内容よりも「評価基準」や「仕様理解」が重要
  • アーキテクチャや仕様を議論・合意し、そこからコードを生成する未来像 の提示
  • 仕様（spec）の定義と評価手法の進化 が今後の鍵
  • QAや運用（Operations）分野の知見 を活かした新しい開発パラダイムへの期待

今後の展望と課題

  • AI生成コードの普及で、従来の開発・保守コストが大幅に低減
  • 「評価・仕様化」の難しさ が依然として最大の壁
  • AI活用には、評価基準やインターフェースの明確化が不可欠
  • 新しいツールやプロセスの発展 により、より柔軟で再生成可能なソフトウェア開発環境の実現が期待される

Hackerたちの意見

この記事はあんまり楽しめなかったな。文章自体は悪くないし、各段落もそれなりに良かったけど、全体としてはなんかダラダラしてて、言ってることが無意味に感じた。言葉はたくさん使ってるのに、実際に言いたいことはほとんどなかった気がする。

└

この文章にはあんまり考えが入ってない気がする。例えば、2025年に何が起こったかというと、コード生産の経済がひっくり返ったんだ。コードを生成するのがすごく難しくて、時間がかかって、高価だったのが、実質的に無料で瞬時にできるようになった。コードの行数は、大切にされて再利用され、手入れされ、慎重にキュレーションされていたのが、使い捨てで再生可能なものになった。これは一晩で起こったことだよ。「経済がひっくり返った」っていうより、以前は厳密に加算的だった製造プロセス（3Dプリントに似てる）に、今は減算的なプロセス（CNCフライスに似てる）が加わったって感じ。求められる「形」はあんまり変わってないし、人間の努力も変わってない（特定の公差を達成することを気にする限り）。市場が求める限り、やっぱり「大切にして、再利用して、手入れして、キュレーションする」必要があると思う。それと、「コードの行数はレビューするのに理想的なアーティファクトじゃない」っていうのには同意できない。「理想的」ってどういう意味？僕が育った頃は、「作業を見せる」っていうのが試験のルールだったよ。なんでかって言うと、次の世代のためにメンタルモデルや思考プロセスを改善するために働いてるからで、明日リリースする製品だけじゃないんだ。

└

楽しかったよ。人々は自分を楽しませるためにブログに投稿するんであって、必ずしも読者のためじゃないからね。

└

メタな話だけど、私は諦めた。言語がすごく難しくて、記事のポイントが私にはあまり伝わらなかった。シュラッグ。

└

「文章自体は良かったし、各段落も良かったけど、全体としては迷走してて、言ってしまえば無意味だった。言葉はたくさんあったのに、実際にはあまり言われていないように感じた。理由はわかると思う！」

└

イントロで記事が取り上げるべき明確な論点が提示されたと思ったんだけど、その後の文章はその点で勢いを失ってしまった。スキミングに切り替えたけど、結論を見つけられなかった。彼らが前の記事から読者が誤解したスタンスを説明していたのが、実際には彼らのスタンスだと思う。そうでなければ、なんでそんなに回りくどくなるの？

└

同じく、あの投稿の一般的なアイデアは好きなんだけど、構成と冗長さのせいで、他の人と共有したいとは思わなかった。

2023年以前は、ここHNでみんなが「コードの行数を減らすのが最強のシニアメトリックだ」って言ってたのを覚えてる。

└

簡素化はまだまだいいよね。僕がいた会社に入ったとき、あるシニアはコードを削除するのは彼がマネージャーになるまでだったって覚えてる！

└

機能を削除せずにコードの行数を減らすこと。

└

まだそうじゃない？それとも、かなりそうだよね。LLMの行数の洪水に対抗して水泳レースに勝つには、流れが強すぎる。でも、著者が軽々しく言ってることには同意できない部分もある。LLMが良いコードを書けるかどうかってこと。彼らは動くコードを書くけど、まるでデモゴルゴンが書いたみたいで、見るとちょっと気持ち悪くなる。悪いけど、人間が書くような悪さじゃない。新しい開発者が書いたスパゲッティコードを読むときの気持ち悪さとは違う。まるでクトゥルフの卵がどこかで孵化してるみたいな気持ち悪さ。

いい記事だった。著者が正しいかどうかは分からないけど、格言に何か変化が起きてる気がする。>「十分に詳細な仕様は実行可能なコードである。」ある意味、LLMが4GLや「十分に賢いコンパイラ」の夢を実現する手助けをすると思う。LLMは賢くはないけど、能力がある。特に翻訳や変換に関してはね。彼らが僕たちの作業の抽象化の地平線を動かすのを見える気がする。つまり、求められる論理やプロセスの厳格な高レベルの説明と品質テストのプロセスが、重要なキュレーションされたアーティファクトになり、生成されたGo/Rust/Java/Pythonなどのコードは偶発的で可変的になるってこと。システムの展開の一部として、常に書き直される運命にある。 [c] そうそう、素朴なC/C++を使って、RISC/EPICプラットフォームをフル活用した実行可能ファイルを作るやつらのことね。Intel Itaniumも参考にしてみて。

Hacker Newsで議論の続きを見る