AIはエンジニアリング規律を減らすのではなく、むしろより強く要求する
(charitydotwtf.substack.com)- AIによるコード生成の品質向上はコードレビューを捨ててよいという合図ではなく、コードが安価かつ高速に再生成される環境で 検証と運用の規律 をより強く求めることを意味する
- 2025年末の Opus 4.5 以降、AIは少なくとも一般的なパターンにおいて、中堅ソフトウェアエンジニアに近い品質のコードを、より速くより安く作れるようになり、agentic harness・ツール利用・function calling・MCPがこの転換を支えている
- コード生産コストがほぼゼロに近づくにつれ、コード行は大切に保存すべき資産ではなく、現在の理解を物質化した 再生成可能なキャッシュ に近いものになる
- immutable infrastructureが稼働中のサーバーを修理せず置き換える発想をもたらしたように、AI時代のアプリケーションコードでも変更そのものより 振る舞いの検証、characterization test、capture/replay、トラフィック分割、可観測性が重要になる
- 非決定的なシステムは、人間が品質ゲートとして踏ん張るやり方よりも、trace、production eval、短いフィードバックループといった エンジニアリング規律 を要求し、AIはソフトウェアが依然として技術者と規律を必要とするという事実を消し去らない
2025年に覆ったコード生産の経済性
- 2025年の大半において、AI生成コードは「slop」であり、今後もそうだろうという立場は合理的で主流の判断だった
- 2025年11月の Opus 4.5 以降、AIは少なくとも一般的なパターンでは、中堅ソフトウェアエンジニアに近い品質のコードを、はるかに速く安く生成できるようになった
- Opus 4.5は単一の原因というより ティッピングポイント に近い
- agentic harnessは、LLMをツールとともにループへ組み込むコード構造である
- こうしたハーネスは2025年半ばに現実的な形となり、その前兆は2024年末までさかのぼる
- tool use、function calling、MCPが2025年を通じて積み上がり、年末には汎用的な使いやすさへとつながった
- 最初の変化に対して「見れば信じる」という懐疑は許容できたが、同じ速度の変化が再び現れている状況では、同じ態度を維持するのは難しい
コードは貴重な資産から再生成可能な生成物へと変わる
- 2025年に起きた核心的な変化は コード生産の経済性 が逆転したことだった
- コードを生成することが難しく、時間がかかり、高価だった状態から、事実上即座に可能で安価な状態へ移った
- コード行は再利用して手厚く扱う対象から、捨てて作り直せる対象へと移行する
- ソフトウェアエンジニアリングチームの真の成果物を共有された理解とみなす見方もある
- その理解は人の頭の中にキャッシュのように保存され、GitHubのコミットや本番デプロイとしてディスクに書き出される
- しかし人間の記憶は忘れやすく、反復に鈍り、小さな細部を見落としやすい
- 頭の中のモデルは、ユーザーが実際に出会う世界と継続的にずれていく
- SREの観点では、優れたソフトウェアチームの真の成果物は 本番環境 にある
- “Only prod is prod”
- 本番環境は開発後の場所ではなく、開発の一段階として扱われるべきである
Phoenix Architectureとimmutable infrastructureの類似性
- Honeycombは2025年8月にAI mandateを出し、devtools企業として最新技術の難しい問題に取り組むべきだと判断した
- Chad Fowlerの Phoenix Architectures は、AIコード時代をimmutable infrastructureと結びつける
- Chad Fowlerは2013年に「immutable infrastructure」という言葉を作った人物である
- Relocating Rigor は、Martin FowlerがThoughtworks meetupの要約で言及した文章である
- The Death and Rebirth of Programming の要点は、動いているものを修理するのではなく置き換えよ、という原則にある
- immutable infrastructure、stateless services、containers、blue-green deployments、infrastructure as codeは、いずれも同じ前提を共有している
- AIはこの前提をインフラからアプリケーションコードへ拡張する
- 書き直しコストが下がるほど、その場での修正は危険になり、mutationはエントロピーを積み増し、replacementはそれをリセットする
- The Deletion Test は、実装全体を削除すると想像させる
- 削除が怖い理由は、コード自体よりも、必要な振る舞い、許容できない失敗、常に守るべき不変条件、新しいバージョンの正しさを判断する基準を知らないからである
- 忘れられていたエッジケースを修正したバグが何だったのか分からないことも、同じ問題である
- これはコードの問題ではなく 評価の問題 である
- コードが知識の唯一の居場所であるとき、コードは貴重になる
- かつてはコードを作る労働がボトルネックだったため、コードを永続的な資産のように扱うのは合理的だった
- 再生成が容易になると、コードは今は有用でも古くなれば捨てられる 理解の物質化されたビュー のように機能する
サーバーを再生成するようにコードも再生成できるべきだ
- 手作業で育てた server pets から immutable infrastructure の cattle へ移行した経験は、mutabilityが理解の敵だという教訓を残した
- 稼働中の成果物をその場で修正するとdriftが生じる
- driftはシステムの保守を難しくする
- Honeycombは毎週火曜にcronで最古のKafkaノードを落とす
- このやり方によって、ブートストラップとバランシングのプロセスが繰り返し可能だという確信を持てる
- データは再生成可能であり、重要な約束は別の場所にある
- コードを同じように再生成できないなら、そのコードを十分に理解していないという合図である
- どんな約束をしたのか分からない
- どんな依存関係が壊れるのか分からない
- 多くは実際に壊してみて初めて分かる
- 長く苦しい migration、rewrite、legacy codeの置き換え、strangler fig は、コード行があまりに多くの責任を背負っていた事例である
- コードには開発者の意図、ユーザーの期待、暗黙的・明示的な振る舞い、過去のバグの痕跡が一緒に束ねられていた
レビュー対象はコード行だけではない
- コード行を維持し変更するコストが大きかったため、他の成果物は十分に発達できなかった
- アーキテクチャがどう変わるのかを理解し議論するための成果物が不足している
- アーキテクチャ自体もコードからぼんやり推測されることが多い
- 理想的な方向は、アーキテクチャ図を議論して合意したうえで、その変更からコードを再生成する方式に近い
- すべてのコードが人間の理解を迂回し、AIが仕様どおりに生成するようになると断言はできない
- 可能性全体は spec が何であるか、あるいは何になり得るかにかかっている
- 痛みを伴うデータベース migration を経験した人なら、ユーザー期待を再生可能かつ自動化可能な形で抽出・形式化する難しさを知っているはずだ
- ツールはまだ存在しないが、関連するアイデアはすでにある
- 運用やQAから来た behavioral test、characterization test、capture/replay、traffic splitter がそれに当たる
- これらの手法は、何が正しいべきかを定義するというより、実際に何が起きているかを観察しエンコードすることに近い
- 良い意味での observability もここに含まれる
人間は検証用の品質ゲートには向いていない
- 本番環境の非決定的なコードは、以前からやるべきだったことを強制する
- traceの計測
- productionでのtestとeval
- 本番環境を開発後ではなく開発段階として扱うやり方
- 人間の脳は 検証 に向いていない
- 反復的で些細な差異を確認し続ける作業では機械より弱い
- 人間の役割を品質ゲート能力だけに置くと、ソフトウェア品質は脆くなる
- 人間は創造性、ひらめき、論理的飛躍などでは長く役割を保てるが、validationで機械に勝つ主体として置くのは難しい
AI時代の結論は規律の回帰
- この2年間のAI言説が多くのエンジニアにとって奇妙で不安だった理由は、一部のAI支持者の声が、ソフトウェアはもはやエンジニアリングの問題ではないと言っているように見えたからである
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacobは、ソフトウェア職の大きな変化を予想する人物として語られている
- 2025年がvibe codingの年だったなら、2026年は 規律への回帰 のように見える
- AIが中堅ソフトウェアエンジニア並みにコード行を生成できるようになったことで、可能な未来の範囲は不安定なほど広がった
- 頭の中の知識は、システムにエンコードされるまではAIが利用できない
- 速く短いフィードバックループで働くソフトウェアチームは非常に少ない
- 割合は5%程度、確実に10%未満とされる
- AIツールはこのやり方を以前よりも身近にできるかもしれない
- エンジニアリング規律なしにAIだけで巨大な投資対効果が生まれる状況は、近い将来の懸念ではない
- 多くのチームが試すだろうが、価値あるものはdisposabilityではなくdurabilityによって支えられる
- ユーザーは毎日Slackにログインするたびに、ボタンやメニューが微妙に変わることを望んでいない
- 金融取引が大半の場合にしか完了しないことも望んでいない
- determinismは消えない
- AIは魔法ではなく、ソフトウェアは依然としてエンジニアリングである
- 技術はtechnologistを必要とする
- 今後レビューすべき成果物は、コード行だけでなく、別種のエンジニアリング成果物へと広がっていく
1件のコメント
Hacker Newsの意見
今では、誰がシステムを理解してAIを効果的に使っているのか、誰が何も分かっていないままLLMのコピペだけをばらまいているのかを見分けるのが、はるかに難しくなった
2025年以前は、成果が低い人やただ居座っているだけの人は貢献が少ないので比較的見えやすかったが、今ではすべてのエンジニアがもっともらしい形式のPR、コードレビュー、技術設計文書などを大量に生み出している
CレベルがAIを最大限使えと強く圧力をかけている影響も大きいし、各エンジニアの立場から見ても、できるだけ多く生み出すほうが有利なゲーム理論的な対応でもある
もっともらしく見える文書とコードに完全に埋もれつつあり、その量を処理するためにまたAIに頼ることになる
この時代の反動は、規模の面で特に際立つ奇妙な形の技術的負債になる気がする
LLMは大量に作って何かを付け足すのが好きだが、本当に有能なエンジニアは、より少ないコードとより少ない可動部品で、より大きなビジネス成果を出す
「プロセスを自動化するためにAIを使いたいが、プロセス文書が完全ではないのでAIが助けてくれるといい」という話をよく聞く
無から結果を作り出すことはできないと説明しても、AIに関する議論は結局いつも同じ方向に戻っていく
そのAI自動化に投入する文書を作る解決策までAIを使おうという話になり、AIで文書を作り、AIで要約して入れ、AIが説明するウロボロスのようだ
コードも同じで、AIで数千行を作り、またAIでそれを説明することになるだろう
最近はLLMのおかげで、貢献量だけ見れば勤勉そうに見せるのがあまりにも簡単だ
違いは、今では無能な人が、慎重で経験豊富なエンジニアより文字通り何桁も多いアウトプットを生み出せてしまうことだ
PRは完璧な関門ではないが、今あるほとんど唯一の関門の一つであり、誰が努力していて誰がそうでないかはかなり明白だ
面接段階のアルゴリズム問題が、システム知識を持っているふりをする人たちを完全にふるい落としてくれるはずだから、そうだろう?
「それはコードの問題ではなく評価の問題だ」「コードが貴重になるのは、知識がコードの中にしか存在しないときだ」という意見に共感する
一日中AIが書いたコードを読むのは苦痛で、人間が最も有能であるべき瞬間に脳を溶かすようなひどいやり方だ
手作業のプログラミングには、コードを読み、書き、コンパイルが通るか実行できるか望んだ動作をするまで修正するという、生産的で満足感のあるフィードバックループがある
AIコードはその半分を代わりにやってくれるだけでなく、最後の「カチッ」とはまる瞬間も感動が薄い。その瞬間にたどり着くために、どこかで少しごまかしたのではないかと確信が持てないからだ
AI生成コードをプログラミングの唯一の持続的な成果物にするのは、この業界の袋小路だ
Charityが興味深い作業空間として指し示し、正しく捨てるべきだと言うのは、アーキテクチャ図と仕様書だ
私の推測では、それは人間が自分で書くプロンプト、Markdownの計画、誘導文により近い
人間として自分で作り出したものに集中してこそ、「AIが自分の指示に従ったか」という中核ループの土台になり、コードレビューでもより高いレバレッジになる
PRに到達するころには、Claudeに十分な入力を与えてコードを再生成できるはずなのに、現在の業界のデフォルトはそのセッションを全部捨ててコードだけをデプロイすることだ。これは逆だ
大きなコードの塊は人間には事実上レビュー不可能なのに、LLMが絡むと多くの人がその事実を忘れているように見える
毎日ものすごいコードの山がレビューしろと送られてきて、本当にうんざりする
それでもAIのほうがまだましだと感じるのは、ルールを書いておけば少なくとも従う傾向があるからだ
オフショア開発者のかなりの部分は、同じミスを毎日繰り返す
うちの会社はもっと良いオフショア開発者を採用すべきなのかもしれない
以前はコーディングを通じて作っていたシステムに関するメンタルモデルの一部を、今はコードレビューに依存して形成している
システムの詳細を理解して記憶することがより難しくなっているが、自分で「生成した」情報のほうが、読んだだけの情報よりよく記憶されることを考えれば驚くことではない
教育学から得た教訓をコードレビューの拡張に適用していて、この話に響くなら話してみたい
当面の間に合わせとしては、Claudeにセッション要約をコミットメッセージの一部として書かせることはできるだろうが、もっと構造化され高レベルなツールがあるのか知りたい
よく設計された計画に沿った検証可能なコードが欲しいなら、実質的には疑似コードを書いてAIに翻訳させる必要がある
それなら、そもそもなぜAIにコードを書かせるのかという疑問が湧く
個人的には、自分で計画し、書き、デバッグするほうが楽しい。そこがそもそもプログラミングを好きになった部分でもある
最近このことを本当によく考えている。
ソフトウェア開発についての自分の直感のかなりの部分は、25年間にわたって「あるコードを書くのにどれくらい時間がかかるか」に積み上がった経験に基づいている。
全体を壊しはしないが、誰かが踏むと少し厄介になるエッジケースの検証を追加するか迷うとき、コードに数時間余計にかかるなら見送ることもある。
でも、プロンプト1つで済むなら、なぜやらないだろうか？
新機能を理解しやすくするには専用のAPIエクスプローラーがあるとよいが、以前なら投資を正当化できなかったはずだ。
ところがCodexで10分でできるなら話は変わるし、実際そうだった: https://tools.simonwillison.net/datasette-extras-explorer#ur... リリースノートからもリンクされている https://docs.datasette.io/en/latest/changelog.html#extra-sup...
さらに大きな規模では、以前ならまったく検討しなかったプロジェクトもある。カスタムSQLite
SELECTクエリのパースライブラリは必要だったとしても、1週間以上かけるほどではなかった。しかし今では可能になった: https://github.com/simonw/sqlite-ast
コード行をより速く生み出せることに価値があると言うと、人はひどく怒ったり見下したりする。
もちろん、「コード行数」で成果を測るのは愚かだ。
しかし、価値を届ける検証済みのコード行数を測るのは愚かではなく、今ではそれをより速くできる。
Googleに価値があるのは、データを吸い上げて広告収益を生み、その収益に対して支出が小さいからだ。
あの大量の「賭け」は？ 面白いね、それでどうなった？
工学のための工学は経済に何の価値もなく、つまり無意味だ。
誰も聞きたがらない冷徹な真実は、ある時点の経済の中に存在できるものは限られており、価値があって経済的に持続可能なものだけが生き残る、ということだ。
気にしない人も多いが、気にする人もいる。
この記事は良かったし、他のコメントの多くはそうではないように見えたので、自分の考えを書いてみる。
新しいコードベースに入るとき、どうすればできるだけ早く役に立つ貢献者になれるか？ 自分はまず、人と人が書いたドキュメントを読む。
このシステムがもともと解決しようとしていた問題は何か、当初の設計は何だったのか、最大の問題は何か、いま誰が使っているのかを確認する。
これが分かると、なぜそういう形で作られたのか推測できるので、コードを読むのがずっと楽になる。
このブログ記事も人気を集めていた: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Charity は、非常に古い問題を見て、新しい技術が何らかの新しい解決策につながるだろうと期待しているように見える。
現世代のツールが AI ソフトウェア開発の物語の終着点だとは思っていないはずだ。
設計ドキュメントを Claude code に放り込んで立ち去ればいい、という話でもない。設計ドキュメントも完全ではないので、オンボーディングでは人と話し、古いチケットや事後分析も読む必要がある。
本番環境では、インフラがなぜ現在の状態になったのか分かりにくいのを嫌うので、いまは Infrastructure as Code をやっている。
コードベースも同じく、「なぜ現在の状態になったのか分かりにくい」のが基本状態であり、これは “Programming as Theory Building” 以前から観察されていた問題だ。
だからインフラと同じように、ソフトウェア開発も「コードがなぜ現在の状態になったのか」をもっと明確にするツール中心へ変わっていくだろうと期待しているように見える。
新しいコードベースに入るときにまず人と人が書いたドキュメントを見る、というやり方はその通りだが、多くのエンジニアリングチームにはそういうドキュメントがまったくない。
意思決定はあるエンジニアの頭の中や保存されないチャットで行われ、仕様は整理中に削除されたチケットの数行のメモだったり、追跡ツールの変更とともに消えたりする。
コードベースや機能の地図もなく、ADR もなく、可観測性も最小限だ。
残るのはコードだけなので、コードを読んで何が起きているのかを突き止め、特定の領域に最近コミットしたエンジニアに、なぜそうしたのか覚えているか聞くしかない。
誰かが変更を入れると、まったく無関係だと思っていたコードベースの反対側が壊れることすらある。
AI により多くの規律が必要なのは確かだが、理論上その規律は、優れたエンジニアになること自体よりずっと簡単に学べるはずだ。
20年前に優れたスケーラブルな C コードを書くには、天才であるか、その技術そのものに身を捧げる必要があった。
ASan、LSan、UBSan、TSan、GDB のような数多くのツールを手のひらのように知っている必要があり、DWARF ファイルを自分で読まなければならないなら、さらにひどかった。
短期間で習得するのは現実的に難しく、同時にシステム設計も学ばなければならなかったが、これはほとんど直交する別の能力だった。
いまは、使っている言語やフレームワークの危険ポイントを知り、LLM にそれをテストするよう指示し、十分にテストできているか確認するためのインフラを持ち、実際のテストと実装を読めばよい。
Rust を読んで理解することは、Rust 開発中に出てくる魔法のようなエラーをデバッグすることよりずっと簡単だ。
あるシナリオで Loom テスト が必要だと見抜き、実際に書かれているか検出するツールを作るのも簡単だ。
C や Zig を使い続けるにしても、それぞれのツールを個別に習得するより、いつ使うべきかを知って検出するほうがはるかに簡単だ。
SQL を読むのは難しくなく、ビジネス職のほぼ半分でもできる。Python はそれより少し難しい程度で、Rust も 50ページほどの読解ガイドを見れば理解できる。試行錯誤に10年費やすコストに比べれば、非常に小さな代償だ。
「LLM は未知の仕方で動く」から「だからより多くの規律が必要だ」を経て「すべて大丈夫だ」に至る道筋は、明確ではない。
すべて大丈夫だという点には同意するが、その思考過程が明瞭な経路だとは思わない。
実際に動くものにしようという意志があり、何が失敗の原因になるのかを少し時間をかけて理解しようとする人なら、LLM を使ってとてつもないことを成し遂げられる。
LLM は複雑なものを作るコストをほとんど無料に近づけるので、むしろ状況をはるかに複雑にするだろう。
工学は常に、規律と、動くようにすることに関わる仕事だったが、以前は価値ある存在になるために前提となる技術の束が必要だった。
その大半は今や消え、以前よりずっと簡単になった。
規律は依然として必要だが、火の中で10年転げ回るのに比べれば、規律は安いと思う。
ついさっき、この約200行の PR のレビューに1週間使った: https://github.com/ncruces/wasm2go/pull/37
熟練ユーザーが提出したもので、おそらく最先端の LLM にも聞いていた可能性が高い。
それでも何かがおかしい感じがした。理解できなかったし、理解できないままマージするつもりもなかった。
将来問題を引き起こす形で間違っているのではないかとも疑っていた。
そこで4つのやり方でレビューした: 理解して改善する、より良いアルゴリズムでやる、upstream で問題を直して回避する、自分の頭に合う形でゼロから書き直す。
答えは2番目か3番目だろうと予想していたが、2番目は正しい答えではあったものの、それを使うにはプロジェクトを最初からやり直す必要があり、3番目は本当にうまくいってほしかったが駄目だった。
結局、1番目と4番目を混ぜることになり、まだ完全な確信はないが、いまは問題と解決策を理解している。
自分のアプローチのほうが良いと思うのは当然だ。
それでも両方ともコメントを取り除いたうえで LLM にレビューさせた。
LLM は元の PR のほうが明らかに優れていると答え、自分がなぜそうではないかを説明すると、自分が正しいと答えた。
コメントを入れて試すと、LLM たちは自分のほうが良いと言う。自分が実際の問題を見つけたからだ。
だが、それが自分のほうが良いと言うのは、自分がそう言うように 誘導したから なのかどうかは分からない。
読んでみると、「すべてのモデルは間違っている」という格言を忘れているように思える
これは「現実的な」「シミュレーション」RPGを好む人たちがよく陥る誤りでもある
ある対象を十分に包括的にモデリングすれば、そのモデルはもはや対象そのものになってしまう
実在する場所のあらゆる細部を含む位置モデルを作るには、1:1スケールのモデルが必要で、それは結局その場所の複製である
システム機能の100%を信頼性高く再現できるほど十分な計画、つまりモデルへのプロンプトは、おそらくそのシステムのソースコードそのものになる
ITとプログラミングのかなりの部分は、よく理解された断片をつなぎ合わせる作業にすぎないのではないかとよく思っていた
8年前には、LLVMをはるかに単純なシステムで置き換え、手作業の最適化を単純なAI「オプティマイザ」で置き換えられないかと考えた
単純にコンパイルされたコードを「最適化された」コードへ変換するよう訓練すればよいと思っていたが、当時のコンセンサスは、AIシステムが実用に足るほど信頼性高く正しいコードを作るのは難しいというものだった
AIがそうした低レベルコードさえ置き換えられないなら、高レベルの問題は当然もっと先の話であるはずだ
ところが人々は高レベルの問題にAIを使っている
私の仮説では、現代のデジタルエンジニアリングの多くはプラグアンドプレイなのだ
2023年以前には、HNで誰もがコード行数を減らすことを最も強力なシニア指標として持ち上げていたのを覚えている
ただ、LLMによるコード行数の洪水に逆らって泳ぎ切るには流れが強すぎる
それに、LLMが良いコードを書けるというこの記事の前提にも同意しない
動くコードは書くが、デモゴルゴンが書いたように見えて、見ていると少し気分が悪くなる
悪いのだが、人間が絶対に書かないやり方で悪い
新人開発者が書いたスパゲティコードを読むときとは別種の不快感で、腹のどこかでCthulhuの卵が孵化するような嫌悪感だ
前にいた会社では、あるシニアが入社してからマネージャーになるまでコードを削除することしかしていなかったのを覚えている
この記事は読んでいて楽しくなかった
文そのものや各段落は悪くなかったが、全体としては散漫で、あえて言えば無意味だった
言葉は本当に多かったが、実際に語っていることはあまりにも少なく見えた
たとえば、2025年にコード生産の経済学がひっくり返ったという表現は正確ではない
以前は製造工程が3Dプリンティングのように厳密な加算型だったとして、今はCNCフライス加工のような減算型が補完されたのに近い
求められる「形」はほとんど変わっておらず、特定の許容差を気にするなら人間の労力も変わっていない
市場が要求する程度に応じて、依然として製品を大事にし、再利用し、手入れし、キュレーションしなければならない
「コード行はレビューするのに理想的な成果物ではない」という言葉にも同意しない
ここで「理想的」とはどういう意味なのか？
子どものころ、どの試験でも「解き方を示せ」がルールだった
その理由は、明日出荷する製品だけでなく、次の世代のメンタルモデルと思考過程を改善しようとしているからだ
言葉遣いが本当に追いにくく、記事の要点も目立たなかった
こういう記事を見ると、ソフトウェアエンジニアの仕事がなくなるという話がいっそう疑わしく思えてくる
2026年のソフトウェアエンジニアの仕事は2020年とも違うし、1990年とは言うまでもなく違うのに、なぜ2026年の仕事がそのまま維持されるか、全部なくなるかのどちらかだという偽の二分法を信じなければならないのか？
ずっと昔にGoogleで働いていたとき、すべてのコードをレビューするという考え方は新鮮だった
その前のMSでは、コードはCDに焼かれて箱に入るようなものだったので、プロジェクト終盤のリスクが高い時点まで大半はレビューされなかった
2000年から2004年の間にソフトウェアエンジニアが時間を使う方法は急激に変わり、共有理解を増やし協業を促進したので、より良くなったと思う
AIがコードを書き、人間がレビューにより多くの時間を使うなら、悪いことばかりではないかもしれない
しかしAIコードが十分に良くなれば、徹底的なレビューは任意のものと見なされるようになるだろう
そうなればソフトウェアエンジニアの仕事は以前とは大きく変わり、コードを大量に書くこともレビューに多くの時間を使うこともなくなる
IDEはドードー鳥のように姿を消すかもしれない
焦点は、AIコーディングチームが課題から逸れないようにするための目標設定とテスト設定へ移るかもしれない
プロジェクトがどこへ向かうのかをよく理解しているソフトウェアエンジニアが、アーキテクチャにより多くの時間を使うようになるかもしれない。目標地点が妥当に変わるたびにAIにあれこれ書き直してほしくはないだろうからだ
探索にもより多くの時間を使えるかもしれない。あるやり方で作り、別のやり方で作り、さらに別のやり方で作って比較し、異なるアプローチから新しいアイデアを生み出すといった具合だ
誰よりも優れた予測を持っているわけではないが、役割が消えるという見方には強く反対し、これまで何度もそうだったように進化するという見方に賛成する。ただし、今ほど速かったことはなかったかもしれない
「コードを恒久的なものとして扱ってきたのは、コードを生産する労働がボトルネックだったからだ」という言い方は正しくないと思う
コードを恒久的なものと見なしてきたのは、コードを真実の源泉として見ていたからだ
コンピュータは文書を実行せず、コードを実行する
要件文書がコードと矛盾するなら、デフォルトでは要件文書のほうが間違っていると見なされていた
コードを仕様から切り離すことはできない。コードこそが仕様だからだ