コードは負債であり、資産ではありません。技術部門の上司はこれを理解していません。彼らはAIがプログラマーの1万倍のコードを生み出すから素晴らしいと思っていますが、それは単に1万倍のリスクを生み出しているだけだということです。 1/

このスレッドのエッセイ形式のバージョンを読んだり共有したりしたい場合は、私の監視なし、広告なし、トラッカーなしのブログにリンクがあります。 2/

AIは、私たちがハイテク社会の壁に埋め込んでいるアスベストそのものです: コードは負債です。コードの*能力*は資産です。 3/

テックショップの目標は、そのコードを維持するコストよりも多くの収益を生み出す能力を持つコードを持つことです。 4/

長い間、企業はコードの実行コストが時間とともに低くなるという誤った信念を育んできました。つまり、コードのバグを見つけて修正する初期の試運転期間を経れば、コードは意味のあるメンテナンスを必要としなくなるのです。 5/

結局のところ、コードは可動部品のない機械であり、摩耗しません。すら摩耗しません。 これはポール・メイソンの2015年の著書『ポストキャピタリズム』の主張であり、この本は著しく時代遅れをとっています(ただし、メイソン自身の政治的信頼性ほどではないかもしれません)。 6/

コードは労働を必要としない無限に再現可能な機械ではありません。むしろ、良好な状態を維持するためにますます困難な対策を要し、最終的には「摩耗」(つまり、上から下までのリファクタリングが必要になる)という意味で、脆い機械です。 7/

なぜコードがリスクであるのかを理解するには、「コードを書く」と「ソフトウェアエンジニアリング」の違いを理解する必要があります。 「コードを書く」ことは、非常に有用で楽しく、没入感のある娯楽です。 8/

これは複雑なタスクを離散的なステップに分解し、コンピュータが確実に実行できるように正確に記述し、コードがCPUのリソース(例えばRAMやプロセッササイクル)に課す負荷を最小限に抑える巧妙な方法を見つけてパフォーマンスを最適化することを指します。 9/

一方、「ソフトウェアエンジニアリング」は「コードを書く」ことを包含しつつも、コードが属する*システム*の長期的な運用に焦点を当てた分野です。 10/

ソフトウェア工学は、システムが受け取るデータを生成する上流プロセスに関心を持っています。システムが処理された情報を発信する下流プロセスに関わる。 11/

これは、同じ上流プロセスからデータを受信したり、同じ下流プロセスにデータを送信している隣接システムに関わっています。 12/

「コードを書く」とは、*よく動く*コードを作ることです。「ソフトウェアエンジニアリング」とは、うまく失敗するコードを作ることです。それは、管理を依頼される第三者にも機能が理解できる、可読可能なコードを作ることです。 13/

これらの第三者は、システムの崩壊を防ぐために、下流、上流、または隣接するプロセスの適応を求められることがあります。 14/

問題は、どんな非自明なコードも外部世界と相互作用しなければならず、外部世界は静的ではなく*動的*であるということです。外の世界はソフトウェア開発者の仮定を*常に*打ち破り、そのたびにソフトウェアは修正される必要があります。 16/

Y2Kを覚えていますか?あの日は、完璧に機能するコードが、完璧に機能するハードウェア上で動いていたものが、コードが変わったからではなく、*時間が進む*ために止まる日だった。 17/

Y2038問題までは12年先です。32ビットのUnixも計算可能な秒数が尽きて動作しなくなるからです。 18/

「世界」の存在は避けられない要因であり、ソフトウェアを摩耗させ、しばしば莫大な費用を伴う再構築を必要とします。コードが動作する時間が長ければ長いほど、「世界」に遭遇する可能性が高くなります。 20/

デバイスが物理的な位置を報告するために使うコードを例に挙げましょう。もともとは請求など、どのキャリアやプロバイダーのネットワークを使っているか、ローミングしているかどうかを判断するために使われていました。 21/

その後、モバイルデバイスはこのコードを使って位置を特定し、ナビゲーションアプリで順番の案内を提供しました。その後、このコードは再び再利用され、私たちが失くしたデバイスを見つける手助けをしました。 22/

これは盗難機器の特定方法となり、紛失端末を見つけることとは大きく異なる用途となりました。紛失したデバイスを探す際には、悪意のある者が「失くしたデバイスを探す」機能を無効化している可能性に悩む必要はありません。 23/

これらの追加のユースケース(上流、下流、そして隣接)は、元のコードに存在し、以前のアプリケーションでは表面化しなかったバグを露呈させました。 24/

例えば、すべての位置情報サービスは、自分がどこにいるのか正確には分からない場合に何らかのデフォルトの動作を持っているはずです。 25/

もしかしたら一般的な解決策を持っているかもしれません。例えば、どのセルラーマストに接続されているか、あるいは正確な位置を特定した*最後の*場所を知っているかもしれません—あるいは完全に迷子になっている場合もあります。 26/

多くの場合、位置情報アプリはその場所の周りに丸を描き、その円の中央に位置情報を設定していました。 27/

円が直径数フィートしかないなら問題ありませんし、アプリがこの近似値をより正確な位置にすぐに置き換えてくれます。しかし、もしその場所が何マイルも広がっていて、その位置修正が*全く*改善しないとしたら? 28/

もし特定の場所がないIPアドレスの位置が「アメリカ本土の中心」として示され、その場所を知らないアプリがカンザス州の家だと報告したらどうでしょうか? 29/

そして私の町バーバンクでは、Googleの位置情報共有サービスがかつて、当時11歳だった娘(電話が届かなかった)が12マイル離れたロサンゼルス郡の未編入地域の高速道路のランプにいると教えてくれました。 32/

(彼女は近くの公園にいたが、範囲外で、アプリは最後に彼女を固定した地域の中心として彼女の位置を推定していた。) (ここ数時間は本当に大変だった。) 33/

基盤となるコード、つまりかつては無害だったデフォルトを使って未知の場所を改ざんするコードは、上流、下流、隣接するプロセスが常に変化しているため、*絶え間なく*更新される必要があります。 34/

そのコードが長く放置されるほど、元の動作はますます老朽化し、その上に重ねられたパッチはよりバロック的で粗雑、難読化されていきます。 35/

コードは資産ではなく、むしろ負債です。コンピュータシステムが稼働している期間が長ければ長いほど、それはより多くの技術債務を意味します。システムが重要であればあるほど、それを壊して完全にやり直すのは難しくなります。 36/

代わりに、その上に新たなコードの層が重なり、コードの層が接するところには、これらのシステムが完全に一致しないような挙動を示す亀裂が生じます。 37/

さらに悪いことに、2社が合併すると、継ぎ目のある亀裂のあるITシステムが壊れ合い、隣接する技術債務の源や上流・下流の亀裂が生じることです。 38/

だからこそ、巨大企業はランサムウェア攻撃に非常に脆弱なのです。互換性のないシステムが多数存在し、それらは様々なデジタルのシリーパテや紐、バリングワイヤーと互換性の模倣に誘導されています。 39/

防水性はなく、防水にはできません。ハッカーに倒されなくても、時には倒れて立ち上がれなくなることがあります。 40/

2022年のクリスマスウィークの間ずっとサウスウエスト航空のコンピューターがダウンし、何百万人もの旅行者が足止めされたことを覚えていますか? 41/

航空会社は特に問題で、早期にコンピュータ化してしまい、古いコンピュータをシャットダウンして新しいものに置き換えることができません。だから彼らのアプリはひどいんです。 42/

だからこそ、航空会社がカスタマーサービス担当者を解雇し、すべての用途にアプリを使うようフライヤーに義務付けたのはひどいことです。アプリ自体は機能しませんが。これらのアプリは絶対に使えません。 43/

ブリティッシュ・エアウェイズのアプリに「不明のエラーが発生しました」と40〜80%の確率で表示される理由は、単にITスタッフを全員解雇し、海外の低価格入札業者にアウトソースしたからではありません。 44/

確かにそうですが、BAの最初のコンピューターは電気機械式のバルブで動作し、それ以降はすべてアラン・チューリングの弟子の一人が自分の前歯で丸太をかじり取ったシステムと後方互換性がなければなりません。 45/

コードは資産ではなく負債です(BAの新しいアプリは予定より数年遅れています)。 コードは負債です。マイケル・ブルームバーグをRISCチップで億万長者にしたブルームバーグ端末のサーバー。 46/

つまり、減少し続ける専門ハードウェアやデータセンターベンダーの使用、専門プログラマーへの支払い、そしてこれらのRISCシステムを世界のあまり珍しくない同等物と接続するための脆弱なコードチェーンを構築することに縛られているのです。コードは資産ではありません。 47/

AIはコードを書けますが、ソフトウェアエンジニアリングはできません。ソフトウェアエンジニアリングは*文脈*を考えることがすべてです。このシステムの前に何が来るのでしょうか?その後に何が起こるのでしょうか?その隣に何が置かれるのでしょうか?世界はどう変わるのでしょうか? 48/

ソフトウェアエンジニアリングは非常に広い「コンテキストウィンドウ」を必要とします。これはAIには持たない、そして持てないものです。AIのコンテキストウィンドウは狭く浅いです。AIのコンテキストウィンドウを線形に増加させるには、計算要求の*幾何学的*拡張が必要です: 49/

失敗の原因を考慮せずに動作するコードを書くことは、破滅のレシピです。これは大規模にテック債務を生み出す手段です。それは技術社会の壁にアスベストを掘り込むことです。 50/

上司はコードが資産ではなく負債であることを*知らない*。だからこそ、人間のプログラマーの1万倍もコードを出すチャットボットの話を黙らないのです。 51/

彼らは人間のプログラマーの1万倍の速度で*資産*を生産できる機械を見つけたと思っています。しかし、そうではありません。彼らは人間のプログラマーの1万倍の速度で*責任*を生み出せる機械を見つけました。 52/

保守性は、単に苦労して得た経験が落とし穴のどこにあるかを教えてくれるだけではありません。 53/

また、「フィンガースピッツェンゲフュール」という「指先の感覚」を育てることも必要で、これまで見たことのない落とし穴がどこに現れるかを合理的に推測できる感覚です。 54/

これはプロセス知識の一形態です。それは避けられないことです。トレーニングデータとして使える最大のコードコーパスにも潜在的ではありません: *いやあ*技術系の上司たちはこれを理解できないんだ。 55/

マイクロソフトを例に挙げましょう。今の彼らの大きな賭けは「エージェントAI」です。彼らはあなたのコンピュータにスパイウェアをインストールし、すべてのキーストローク、すべての通信、すべての画面をキャプチャしてマイクロソフトのクラウドに送信し、多数のチャットボットにアクセスさせようとしています。 56/

彼らは、コンピューターに「カーディフ行きの電車を予約して、昨年コーリーが言っていたホテルを見つけて、そこで部屋を予約してくれ」と指示すれば、それで対応できると言っています。 これは非常に実現不可能なアイデアです。 57/

これらのことをすべて行うことができるチャットボットは全くなく、これはマイクロソフトが自由に規定していることです。マイクロソフトはこれを1つのチャットボットで行うのではなく、数十のチャットボットに分割し、それぞれ最大95%の信頼性を目指しています。 58/

それ自体が全く信じがたいチャットボットの標準ですが、考えてみてください:確率は*掛け算*です。2つのプロセスが95%の信頼性で動作する場合、純信頼性は90.25%(0.95 × 0.95)となります。 59/

数十体の95%の精度を持つボットの中からタスクを分解すると、そのタスクが正しく完了する確率はゼロになります。 60/

一方、昨年12月、マイクロソフトの幹部がLinkedInにAIにマイクロソフトのコードを*全て*書き換える意向を投稿したことで問題に巻き込まれました。 63/

Microsoftのコードベースをリファクタリングするのは非常に理にかなっています。マイクロソフトはブリティッシュ・エアウェイズや他のレガシー企業と同様に、持続不可能なテック債務を表す非常に古いコードが多く存在します。 64/

皆さんの中には、チャットボットがコード作成に非常に役立つと感じているソフトウェアエンジニアの方もいます。これはよくあるAIのパラドックスです。なぜAIを使う人によっては本当に役立つと感じる人もいれば、嫌う人もいるのでしょうか? 66/

AIを嫌う人は「AIが下手」なのでしょうか?AIファンが怠けていて、作品の質にこだわらないのでしょうか? 67/

両方がある程度はあるでしょうが、たとえ全員にAIの専門家として教え、自分の仕事に誇りを持っていない者をサンプルから除外しても、パラドックスは残ります。 68/

AIパラドックスの真の解決策は自動化理論と「ケンタウロス」と「逆ケンタウロス」の概念にあります。 69/

自動化理論において、「ケンタウロス」とは機械に助けられる人物のことです。「逆ケンタウロス」とは、機械を*助けるために徴兵された者*のことです。 70/

例えば、あなたがソフトウェアエンジニアで、AIを使ってルーチンコードを書き、その時間と経験を積み、Fingerspitzengefühlやプロセスの知識を活用して目的に合ったものに仕上げているとしましょう。 71/

AIを使うことが(自分で選んだ方法で、自分のペースで使うときに)役立つ理由は簡単に理解できます。 しかし、例えばあなたがソフトウェアエンジニアで、以前の10倍、100倍、あるいは10,000倍の料金でコードを書くよう命じられたとします。 72/

もしAIを使うしか方法がない場合、そのコードを人間が確認して世界との初接触で壊れないようにする方法が全くありません。あなたなら嫌いになるでしょう: 73/

(もしAIの責任を問われる責任者にされて、AIのミスを個人的に責められるなら、さらに嫌になるでしょう。) ソフトウェアエンジニアがAI生成コードが非常に役立つもう一つの方法は、そのコードが*孤立*している場合です。 74/

もし単一のプロジェクト、例えば一括りのファイルを別の形式に一度だけ変換するなら、下流や上流、隣接するプロセスの心配は不要です。そんなことはありません。 75/

あなたは一度だけ何かを書くだけで、他のシステムとやり取りすることはありません。大量のコーディングはこの種のユーティリティプロジェクトです。それは面倒で感謝されず、自動化されるのが適している。 76/

多くの個人プロジェクトはこのカテゴリーに当てはまりますが、もちろん、個人プロジェクトは定義上ケンタウロスのプロジェクトです。個人プロジェクトでAIを使うことを強制されることはありません。どのツールもいつどのように使うかは常にあなたの選択です。 77/

しかし、ソフトウェアエンジニアがAIで仕事をより良くできることがあるからといって、コードが資産ではなく負債であり、AIコードが大規模な負債生産を代表しているという事実は否定しません。 78/

技術的失業の物語には、新しい技術が新しい仕事を生み出す一方で、古い仕事を時代遅れにするという考えがあります。自動車によって職を失った鍛冶屋が一人いる一方で、整備士の仕事が待っているのです。 79/

AIバブルが膨張し始めてから数年の間に、私たちはこの話の多くのバージョンを耳にしてきました。AIは「プロンプトエンジニア」の仕事を生み出す、あるいはAIが世界を認識できないほど変えるまで存在しない仕事を生み出す、というものだ。 80/

私たちの意識がAIによって大きく変わっていないため、これらの新しい働き方を概念化する能力をまだ持っていないため、想像もできない空想的な職種の仕事を期待しないでください。 81/

しかし、もしAIが確実に何百万もの仕事を生み出してくれているなら、私からの提案があります:デジタルアスベスト除去です。 82/

AIコードは、人間のコーグラマーの1万倍の速さで書かれ、うまく機能するように設計され、しかし優雅に失敗しないよう設計されていますが、私たちが壁を埋め尽くしているデジタルアスベストのようなものです。私たちの子孫は何世代にもわたって壁からアスベストを掘り出し続けるでしょう。 83/

最も危険なAIの精神病、すなわち「コードを書くこと」と「ソフトウェアエンジニアリング」と同じだという幻覚的な信念のおかげで、壊してしまったものを修正する作業はたくさんあります。 84/

このままでいけば、アスベスト除去業者の世代が完全雇用されるでしょう。 85/