西側は物を作る方法を忘れ、今やコードのことも忘れつつある
(techtrenches.dev)- 防衛産業の生産能力の崩壊は、退職した熟練人材と失われた工程知識の断絶によって、戦時需要が生じても生産を迅速に立て直せないことを示している
- Stinger、155mm砲弾、Fogbankの復元事例は、コスト最適化と単一障害点が平時の効率を高めた一方で、サプライチェーンの余力と復旧速度を大きく弱めたことを示している
- ソフトウェアも、より安価な代替手段に依存して人材パイプラインを弱体化させる方向へ進んでおり、AI導入後はジュニア採用の縮小とreview bottleneckの拡大が同時に進んでいる
- 熟練は金だけで短期間に作れるものではなく、防衛産業でもソフトウェアでも、知識と熟練の蓄積には何年もの現場経験とレビュー能力が必要である
- ジュニアが形成期の失敗やデバッグを経験できなければ、暗黙知が蓄積されず、将来的にseniorエンジニアやinstitutional knowledgeが不足するリスクが高まる
防衛産業の生産能力崩壊とソフトウェア人員削減の平行線
- RaytheonはStinger生産再開のために70代のエンジニアを呼び戻し、古い紙の図面と倉庫に残っていた試験装置を手がかりに工程を復元しなければならなかった
- Pentagonが20年間新しいStingerを調達しなかった後、ウクライナ戦争で需要が急増したが、生産ラインは閉鎖されており、電子部品とseekerは生産終了状態で、2022年5月の発注分も引き渡しは2026年の予定だった
- 戦争開始から10か月で13年分のStinger生産量が消費されるほど需要は膨らみ、すでに失われた生産知識と人材の空白がボトルネックとして浮上した
- 単なる予算の問題ではなく、退職した熟練人材が抜けた後に後継人材が続かなかった構造そのものが中核的な障害として作用している
砲弾増産の失敗が露呈させたサプライチェーンの脆弱性
-
100万発の約束と実際の生産能力
- EUは2023年3月、12か月以内にウクライナへ砲弾100万発を供給すると約束したが、欧州の年間生産能力は23万発程度で、ウクライナは1日5,000〜7,000発を消費していた
- 期限までに欧州が納入できたのは約半分にとどまり、9か国11メディアの調査では、実際の生産能力はEUの公式主張の約3分の1水準と集計された
- 100万発の達成時期は2024年12月へずれ込み、当初の約束より9か月遅れた
-
複数のボトルネックが同時に重なった構造
- Franceは2007年に国内の推進薬生産を停止して以降、17年間止まったままだった
- 欧州の主要なTNT生産拠点はPolandの1か所のみで、Germanyの備蓄弾薬は2日分にすぎなかった
- DenmarkのNammo工場は2020年に閉鎖された後、ゼロから再稼働しなければならなかった
- 欧州の防衛産業は少量の高価なカスタム製品に最適化されており、大量生産や危機対応を前提に設計されていなかった
-
米国も同様の弱点を抱える
- 米国もScrantonの1工場、Iowaの爆薬充填施設1か所に依存しており、1986年以降は国内TNT生産が途絶えていた
- 何十億ドルも投じた後でも、生産量は目標の半分にも届かなかった
コスト最適化が生んだ単一障害点
- 1993年、Pentagonは防衛大手CEOたちに統合しなければ淘汰されるというメッセージを投げ、その後51社あった主要防衛企業は5社に減った
- 戦術ミサイルの供給業者は13社から3社へ、造船企業は8社から2社へ減少し、労働力は320万人から110万人へと65%減少した
- 弾薬サプライチェーンの各所にsingle point of failureが生まれ、155mm砲弾の弾体製造はCaliforniaのCoachellaにある1社へ集中していた
- 推進装薬もCanadaの単一施設に依存しており、最低コスト中心の最適化は平時の効率を高めた一方で、需要急増に対応する余力をほとんど残さなかった
知識が失われると復旧も遅れる
-
Fogbank復元の失敗
- Fogbankは核弾頭に使われる機密物質で、1975年から1989年まで生産された後、施設は閉鎖された
- 2000年、寿命延長プログラムのため再生産を試みたが、生産ノウハウを持つ人員の大半は退職・死亡・離職しており、記録もほとんど残っていなかった
- GAO関連内容によれば、追加で6,900万ドルと数年にわたるリバースエンジニアリングを費やして、ようやく生産可能なFogbankを再確保できた
-
文書にない暗黙知が決定的だった
- 新たに作られたFogbankは純度が高すぎ、元のバッチに含まれていた意図しない不純物が実際の機能に重要だったことが後になって判明した
- その情報はどの文書にもなく、元の生産に携わった作業者だけが知っていたが、彼らはすでに退職していた
- 自分たちで作った物質すら再現できなかった理由は、知識が人の中にしか残っていなかったからである
ソフトウェアも同じ経路をたどっている
-
安くて速い代替手段が人材パイプラインを弱める
- 何十年もかけて築いた能力をより安い代替手段に置き換え、人間の人材パイプラインを弱体化させた後、危機の際に削った能力が再び必要になるというパターンが、防衛産業とソフトウェアで重なっている
- 防衛産業におけるその代替手段がpeace dividendだったとすれば、ソフトウェアではAIがその位置を占めている
- 既存の人材パイプラインの崩壊と理解力の危機はすでに表面化しており、防衛産業の事例はその再建期間がどれほど長いかも示している
-
再建には金より時間が必要
- 主要な防衛産業の増産は、単純なシステムでも3〜5年、複雑なシステムでは5〜10年を要した
- Stingerは発注から納入まで最低30か月、Javelinは生産量を2倍弱に増やすだけで4年半、155mm砲弾は50億ドルを投じても4年目でなお目標未達だった
- Franceも推進薬生産の再開まで17年を要し、制約は資金より知識と熟練にあった
- RAND研究は、潜水艦設計技術の10%はPhD取得後でも現場で10年の経験を必要とするとし、防衛産業の熟練職も見習いに2〜4年、監督能力まで含めると5〜8年が必要だった
-
ソフトウェアの成長曲線も圧縮できない
- ジュニア開発者が安定したmid-levelに達するまで3〜5年、seniorまで5〜8年、principalやarchitectまでは10年以上かかる
- この時間は金を多く投じても短縮できず、AIでも圧縮しにくいように見える
AI導入後のボトルネックと熟練の弱体化
-
生産速度よりレビューのボトルネックが大きくなる
- METRのランダム化比較試験では、熟練開発者がAIコーディングツールを使うと、実際のオープンソース作業はむしろ19%長くかかった
- 開始前にはAIで24%速くなると予想されていたが、実際の結果との差は43ポイントに達した
- 後続実験では、AIなしで働くなら参加しないと答えた開発者の割合も少なくなく、AIのない作業へ戻ることを想像するのも容易ではなさそうだった
-
採用縮小と大学登録者数の減少
- Salesforceは、2025年にソフトウェアエンジニアの追加採用を行わないとした
- LeadDevの調査では、エンジニアリングリーダーの54%がAI copilotsは長期的にジュニア採用を減らすと見ていた
- CRA調査では、大学のコンピューティング系学科の62%が今年の登録者減少を報告した
-
コードレビューが中核的制約へ移る
- AIはコードを高速に生成するが、人間のレビューは遅く進むため、review bottleneckが生じる
- これに対応して、AIがAIのコードをレビューしないようにしつつ、pull requestテンプレートに変更内容、変更理由、変更の種類、変更前後のスクリーンショットを必須で入れる運用へ変わっている
- プロジェクトごとの専任レビュアーを追加し、モデルが見落とした部分をより多くの目で見つけようとする方式も使われている
これから不足する能力
-
技術だけでは足りない環境へ変わる
- もはや技術的専門性だけでは不十分で、責任を負い、トレードオフを説明し、機械が自信満々に出してくる誤った提案を退けられる判断力とリーダーシップがあわせて必要になる
- 最近の採用では応募者2,253人のうち2,069人が不採用となり、採用されたのは4人だけで、転換率は0.18%だった
- 技術力に加えてAIの誤りを見抜く判断力を持つ人材が市場にほとんどいない現実が露わになっている
-
文書化だけでは知識継承は終わらない
- Site Books、SDDs、RVSレポート、完全なカバレッジを備えたboilerplateモジュールに至るまで、幅広く文書化が進められている
- 現時点ではそれらの文書を読む人々がエンジニアリングの専門性を持っているから機能しているが、その専門性が失われたときにも同じ形で維持されるかは不確かだ
- 2031年のモデル性能は予測できず、AIが十分に良くなって問題を減らすのかどうかも確実ではない
-
危機は予告なく訪れ、seniorはすぐには育たない
- 2022年に欧州で全面戦争が起きると予想していなかったのと同じように、危機は予定表に合わせてやって来ない
- 5〜10年後には、システム全体を理解し、午前2時に分散障害をデバッグし、コードベースの外側にあるinstitutional knowledgeまで背負えるseniorエンジニアが必要になる
- しかし、そのような人材は今まさに育成されておらず、学ぶべきジュニアは採用されないか、あるいはDoD資金の研究が呼ぶAI-mediated competenceを積み上げている
- AIにプロンプトを投げる能力は残っても、AIの間違いを指摘する能力は育たないかもしれない
コードにとってのFogbankになりうる危険
- ジュニアがデバッグや形成期の失敗を飛ばすと暗黙知が蓄積されず、現在世代のエンジニアが退職するとき、その知識はAIへ移転されない
- その結果、知識は単純に消失しうるのであり、これはFogbankで起きたことと同じ構造につながっている
- ウクライナ戦争は、防衛産業の最適化の失敗が現実のコストとなって跳ね返る瞬間であり、Stinger、Javelin、Fogbank、そして生産できなかった100万発の砲弾がその代償を示している
- ソフトウェアエンジニアリングも同じ最適化に賭けており、AIが十分に優れていればこの賭けは当たるかもしれないが、そうでなければ同じ請求書が回ってくる可能性がある
1件のコメント
Hacker Newsの意見
本当の問題は AIそのもの ではない
即時の利益を生まないとして、人や組織から余裕を奪っておきながら、後で必要になったときにもその知識が残っていると信じる経営のやり方が問題だ
短期的なコスト削減はジュニア採用を減らし、熟練エンジニアが教える余裕も奪って、暗黙知の継承を断ち切ってしまう
結局残るのは文書と自動化だけだが、文書は現場経験ではなく、自動化は判断力の代わりにはならない
実際にシステムを扱ってきた人が抜けると、暗黙知は組織から消え、生産性も結局は落ちる
今のAIも同じパターンで売られていて、多くの領域で必要とされているのは生産性向上より 人員削減 に近く見える
GEが四半期業績と株主利益の最大化に執着して長期的な能力を空洞化させたのと似た考え方が、また見えている
実際のエンジニアリングから遠い意思決定者たちは、ツールやプロセスや文書で暗黙知を代替できると信じているが、そうではない
人と学習パイプラインをなくせば、その知識は組織の中に残らず消えていく
実験、修理、衝撃吸収のための余裕がまったくなく、最近壊れるシステムの90%は短期的な衝撃を受け止めるslackがないせいだと思う
スタートアップのプロジェクトは最初から何かを作り続けなければならないので、機能を増やすこと自体が価値になるが、Visa、Salesforce、LinkedInのような会社は、すでに製品も機能も資源も十分に持っていることが多い
こうした会社はしばしば、write more softwareというハンマーに合う釘を無理やり探している状態になる
ウィッシュリストやA/Bテストの仕組みがたくさんあるように見えても、本当にソフトウェアをさらに作るほど儲かる機会が明確なら、すでにやっていた可能性が高い
実際の成長と新たな需要はこうした場所の外側から多く生まれ、ソフトウェアを作れない、あるいは買ってこられない会社のほうがむしろ機会をつかめることもある
そして核心は fungibility だ
人的資本は簡単に詰め替えられるモノではなく生きた存在であり、人材と技術のパイプラインは一度途切れるとそのまま消えうる
AIコーディングの危険も、既存の人的資本を食いつぶすだけで、未来のための人的資本を新たに作れない点にある
私が担当しているシステム知識のかなりの部分は 文書化 できるし、その文書だけで新しい人が引き継ぐことも理論上は可能だ
ただ問題は、必要な文書量が途方もなく多いことだ
小さなシステムですら、びっしり埋まった A4数万ページ は現実的だと思う
新しい担当者はその膨大な文書をほとんど丸暗記するほど理解しなければならず、会社はそうした文書作成コストや新しい人材の学習コストに金を使いたがらない
私の経験ではそれでうまくいかないのであって、原理的に絶対不可能だからではない
私たちは他人と 会話する理由 を少しずつなくしている
AIに質問した瞬間、本来なら同僚としていたはずの人間的なやり取りがひとつ消えることになる
これはコーディングだけの問題ではなく、ポケットの中に常に ChatGPT があるとき、どんな社会的相互作用が置き換えられるのかを考えさせられる
人間は本質的に社会的な存在なのに、私たちは社会化をできる限り最適化して消し去ろうとしている
私自身も昔のように店に電話するより Doordash を好むので、この流れと無縁ではない
理想的な世界なら、企業は中短期の利益を、政府は長期の利益を、個人は人生全体を最適化すべきだ
企業がslackを削ってきつく回すなら、政府は規制によってその余裕と人材流入を維持し、国家の能力を守るべきだ
ところが西側では、ロビー団体とMBAが企業を振り回し、政府まで 金だけを最適化 する方向へ引っ張っているように見える
コーディング補助なしで毎日コードを書くのは、そうすることで細かいことまで含めた 手でやる感覚 を忘れないと信じているからだ
AIを使わない最大の理由は、画面の前にいるとき、できるだけ何にも 依存したくない からだ
もちろん文書や本やStack Overflowのようなものは別だ
身の回りでは些細な日常作業まで全部AIに頼る人をよく見るが、それは思考に注ぐ努力が極端に減るということで、かなり恐ろしく感じる
その精神的な努力を明け渡すのは小さなことではない
私にとってそれを手放す瞬間、依存したゾンビになるような感覚があり、知識はほとんど毎日繰り返す試行錯誤から生まれると思っている
技術は常に人を押し流し操れることを示してきたし、AI依存は企業が人間の最も繊細な能力である 考え、好奇心を持つ力 にまで踏み込む最終形のように見える
ほとんどの時間を混乱と苛立ちの中で過ごし、7時間近く問題と格闘した末に作業を終えた
だが、その難しさ自体が衝撃で、使っていなかったせいで自分の脳が少し腐ったのではないかと心配になるほどだった
そこで、もともと新しい問題を解くときはいつもそれくらい苦労していたことを思い出した
初めて見る問題と向き合う感覚は本来そのくらい難しいもので、自分がその感覚に慣れていなくなっていただけだった
難しさに慣れるとそれが普通に感じられ、逆に難しさのない状態に慣れると、再び直面したとき圧倒的で奇妙に感じられる
だから 不快さと難しさ に耐える能力は、必ず守るべき筋肉だと思う
それが実際に問題だったのは新しい職場へ移る際、文法チェックや自動補完のない環境で面接用コードを書かなければならなかったときくらいで、そのため事前にそういう環境で練習した
実務では文法の自動補完に依存しても大きな問題になったことはなく、重要なのは 言語の中核概念 とランタイムの理解だった
たとえばNode.jsのevent loopがどう動くか、非同期・イベント駆動プログラムをどう書くかのほうが重要だった
この6か月でデプロイしたコードのうち、自分で1行でも読んだものがほとんどないと言っていいくらいだ
だが、その働き方のほうがずっと疲れる
手でコードを書いていたときは、問題解決の過程がパズルのようで、解き終えると 満足のループ とドーパミンの報酬があった
今は一日の大半、パズルを解く人ではなく QA担当者 のように感じられ、それがひどく消耗する
AIが難しい問題を代わりに解いてくれても、LLMスロットマシン が与える満足感は、自分で解いたときよりずっと弱い
残りの2日はコーディング補助を使わず、作業が終わったあとにレビューだけ任せる
このやり方はメンタルヘルスの維持にもよく、実力の切れ味も保ってくれると思う
かなり得意だった言語でも、機械的な部分はすぐ曖昧になる
だから LLM支援作業 は自分の脳に漂白剤を注ぐような感じになりそうだ
使えば使うほど自分には悪いだろうと、自分で感じられる
必要なものを構造化し、問題解決する能力はまだ大丈夫だが、実際の nuts and bolts はすぐ蒸発してしまう
金は制約ではなかった。知識が制約だった という一文は皮肉に聞こえる
当の文章自体があまりにも AIが書いたような文体 で読みにくいからだ
不自然でぶつ切りの流れに、LLM特有の言い回しが満ちている
文章力も結局は衰える技能だ
言語の流暢さのためにAIを使うのは理解できるが、生成された文章よりはむしろ AI翻訳 のほうがましだと感じる
自分で書くほどの関心もないなら、こちらもわざわざ読む理由があまりない
私にはコードと散文は本質的にそれほど違って見えない
どちらもキーワード、文法、構文、意味のある組み合わせでできている
AIが作った文章が意味不明だったり読みにくかったりするなら、同じ論理で AIが作ったコード も読みにくく信頼しにくいはずだ
こういう二重基準はそろそろやめてほしい
むしろHNでしばしば皆が良いものとして流してしまう AI雑文 よりずっと良かった
だから、人々がLLM特有だと感じる特徴の一部は、実際には人間が先に使っていた文体が再び人間の手で反復されているだけかもしれない
ウェブ検索の上位でAIが作った文章を日に何本も見かけてすぐ閉じることはあるが、この文章はそういう類とはかなり違って見えた
会社が開発者の キャリア水準 を正しく見極められるとはあまり思えない
junior、mid、senior、leadといった区分は見かけにすぎず、実際には複数の軸にまたがる連続体で、流行技術によって歪められやすい
厳密に言えば、会社に雇われていなくてもsenior級の開発者になることはありうると思う
結局のところ核心は、自分で学び作ろうとする意志と投じた時間だ
最近の会社が本当に欲しているのは開発力よりも、壊れた組織構造 と拙いコミュニケーション・予算構造をどうにか迂回した経験のように見える
それがseniorを意味するのか、ただ政治に長けているという意味なのかは分からない
ソフトウェアが失敗して錯覚がはがれるとき、こうしたパターンは特によく現れる
問題を渡されたら必要なことを自分で学び、分からない部分を掘り下げ、意味のある結果を繰り返し出し、必要な人とコミュニケーションし、進捗を共有し、チームと助け合い、不足部分も先回りして埋める人が一方だ
残りはただの残りだ
キャリア初期の数年でだいたいどちらかは見えてきて、後者を前者に変えるのはほとんど不可能だ
だから30年経験の senior でも後者かもしれないし、卒業したばかりの人でも前者かもしれない
もちろん政治力、対人能力、はったりに非常に長けていて、管理層の目には前者に見えるが実際には後者という人もいる
だがそれはもはやソフトウェアを作る能力の話ではない
また前者に属していても低く評価されたり昇進できなかったりすることはあり、実際のキャリア成功との相関はそれほど大きくない
自分でどんなラベルでも貼ることはできるが、少し妙なことだ
フリーランサーはポートフォリオで、学術系のコンピュータ科学者は論文で、OSS貢献者は貢献量と影響力で評価される
いずれの場合も、結局は学習と構築に注いだ努力に比例する
ただし、雇用の有無にかかわらず、専門性は本だけで学べることによって決まるわけではない
ステークホルダー管理 や解決策の発表のようなものは、読んで身につけるのが難しく、実際の練習とフィードバックが必要だ
seniorエンジニアとは単にコードがうまい人ではなく、SDLC全体で自律的に貢献し、他人も助けられる人であり、そうした能力はアマチュアのプロジェクトより プロ環境 のほうがはるかに育てやすい
そこにはたいてい社会的・組織的スキルが必要で、不満でも世界はそういうふうに回っている
同時に、私はこういうことをできるだけ知りたくもない
誰かのために自分の頭の中身を削って合わせたいとは思わないし、こういう種類の問題の中で働くのは純粋に苦痛だ
雇われていない外科医がsenior surgeonになれるかという話に近い
数年にわたり実際に職業としてやった経験なしでseniorになるのは難しく、この分野では 経験がすべて に近い
本だけでは必要な理解を身体化できず、人間は読んだり見たりするだけでは十分に内面化できない
実際にやってこそ本当の学びが生まれる
事実や手法は本で学べても、ミシュランレストランの本を読んだからといってすぐ Michelin Chef になれるわけではない
AIコード生成器 はトロールみたいだ
自信たっぷりにもっともらしいが一部は間違った内容を出してきて、結局は人間がその誤りを見つけなければならない
これは面白くもないし flow もない
私は他人が作ったミスを直すのが好きで、とくに LLMに勝つ感じ が好きだ
従来の没入状態よりむしろ、LLMを執拗に監視しながらのほうが長く集中できた
そこには論理がなく パターンの反復 があるだけなのに、賢いはずのエンジニアたちがなぜそれに引っかかるのか理解できない
この文章自体もかなり明確に AIの助け を受けているように見えるのが、少し皮肉だ
AI支援そのものを批判しているわけではないが、文章の主題と並べてみると考えさせられる
人々は文章を「磨く」ために使っているつもりだが、実際には使わなかったほうが読みやすかった可能性が高い
最近とくに気になるのは、読点の代わりに句点を乱発するような文だ
My people lived the other side of this equation. Not the factory floor. The receiving end.重みを出したい意図なのだろうが、不要なところにまでそう書くので、アクション映画の予告編の台詞を読んでいる感じが残る
倫理的にAI利用そのものが問題だとは思わないが、LLM文体 があまりにも鼻についた
そのうえ、人々がテキストに不要な分量やfillerを足し続けるのに使っているので、今ではそうした文章を何ページもかき分けて進まなければならない
さらに悪いのは、その文章が少なくとも人間の新しい洞察に支えられているのか、それとも単に write me something about X というプロンプトで全部生成しただけなのかを、簡単に見分ける方法がないことだ
現状の水準では、後者なら読む価値はほとんどないと見なしても無理はない
私には、同性愛を非難していた聖職者が男性売春婦とベッドにいるところを見つかったような感じだ
コカインをやっていたかどうかは任意だが、いずれにせよ後味は悪い
このテキストには、よく言われる露骨なAIの痕跡はあまりなく、私にはLLM特有に見えるのは短く断定的な文の構造くらいだ
だが、そうした文体は Hemingway 以降の英語圏ではかなり権威ある書き方でもあった
昔はAIではなく 東欧のリモート契約開発チーム のほうが安い代替手段と見なされていたのではないかと思う
そもそも人数が足りてもいない
それに、ここ 東経15度より東 でも結局みんな一緒に解雇された
実際の計画は、AI関連でなければ全般的に あまりやらない に近かった気がするし、みんな誰が先に解雇を始めるか様子見していただけのように見えた
私は6か月間パートタイムで働いたが、意思決定者たちは長期的にはそのほうが良いとはっきり言っていた
解雇よりはましだが、ああいう生活を続けることはできなかった
倹約家ではあるが、あそこまでは無理だった
彼らは本当に金を使いたがらず、とくに アメリカ人と健康保険 にはなおさら金を使いたがらない
こうしてアメリカ企業がアメリカ人を仕事から押し出す急速な軌道に乗っているのに、ほとんど歯止めがないのが奇妙に感じられる
ヨーロッパ人として東欧の開発者ももちろん見たが、私が一緒に働いたすべての会社にいたわけではなかった
一方でインド人材は常にいた
品質面ではいつも似た話で、詳しくは言わないが、受け入れる準備がある人なら私が何を言おうとしているかはすでに分かると思う
80年代末に初めて受けた Formal verification in software の授業から、2000年代初頭に私が去る前、新入生に任せていた Programming in Java の授業までを振り返ると、学問的厳密さが崖のように崩れ、その跡を 就職への最適化 が埋めたように感じる
昔の教育は考える方法に近かったのに、後になると高給の仕事を得る方法へと変わった
企業が新入社員をこれ以上訓練したくなくなったからだ
研修生の給与も、教える側のコストも、どちらも金がかかるので、そのコストを 学位要件 として大学や学生、政府側へ押しつけた
就職条件として研修費を従業員に払わせたら詐欺くさいと言いながら、当の degree millシステム はあまりに簡単に受け入れられているのが不思議だ
人間は完璧ではない
ロシアの侵攻の数日前に ウクライナ へ行ったとき、キーウでの旅行やホテルは非常に安く、現地の人に侵攻の可能性を尋ねても皆 起きない と言っていた
ロシアはいつも攻撃的なことを言うだけで実際にはやらない、という反応だった
準備は十分でなく、その結果、数日で領土の20%を失った
オーストリアに戻った後、自分が会った人たちの一部は死んだかもしれないという思いがずっと残った
その後 Dubai と Saudi Arabia でも起業家かつエンジニアとして、ドローンがインフラを攻撃したらどうするのかと聞いたが、ロシア戦争とイランの最初の攻撃を見ていれば、そうした攻撃は十分予想できたはずだ
ところがまたしても 起きない という答えを聞いた
きちんと準備していなかったせいで数百億ドルを失い、数年間で数億ドルだけ使っていれば防げたはずだと思う
結局のところ問題はAIではなく 人間 だ
準備がなければ、今ごろキーウにはロシア側の代弁者が座っていただろうと思う
最初の2週間を持ちこたえたからこそ長期戦に移れたし、ドンバス戦争もすでに 8年 続いていた
ウクライナの人々が相手はロシアではないという錯覚の中にいたとは考えにくい
よく見ると、その契約を取る必要のある友人がいたり、相手が攻め込めば家族が即座に死ぬといった恐怖を売っていたりする
あなたは誰かが 絶対に起きない と言い、実際には起きた事例を二つ持ってきただけだ
同じことを言って、実際に何も起きなかった無数のケースはどうするのかと聞きたくなる
宝くじを買う何百万人に私が「当たらない」と言えば、ほぼ全員に対して正しい予測になる
一人が当たったからといって私の予測が間違っていたわけではなく、それは単なる reporting bias かもしれない
皆が プーチン がそこまで愚かだと確信していたわけではないが、ウクライナ軍は万一に備えて防衛線、備蓄、防衛戦術の準備で非常に忙しかった
日が経つほど Peter Naur の programming as theory building がますます重要に思えてくる
リンク: https://gwern.net/doc/cs/algorithm/1985-naur.pdf
強く薦めたい読み物だ