本動画は、ソフトウェアアーキテクチャの劣化が優秀なエンジニアの存在にもかかわらず不可避である理由を、人間の認知的制約という観点から分析している。従来AIはアーキテクチャに不向きとされてきたが、実際には人間が構造的に苦手とする「大規模な一貫性維持」や「全体と部分の同時把握」においてAIが優位性を持つ可能性を提示する。Verselのパフォーマンス最適化の事例を通じて、個別の合理的な判断が積み重なって生じるシステム全体の問題、つまりエントロピーの増大を防ぐには、人間の限られたワーキングメモリではなくAIの広大なコンテキストウィンドウが有効であることを論じる。一方で、新規パターンの創造やビジネス判断といった領域では依然として人間の判断力が不可欠であり、両者の認知的強みを理解した上での相補的な協働関係の構築が2026年以降の組織にとって重要な課題であると結論づけている。
AIはアーキテクチャにおいて人間より優れているかもしれない
AIはソフトウェアアーキテクチャにおいて人間より優れているかもしれません。AIがより賢いからではなく、人間が構造的に、優れた大規模技術アーキテクチャが必要とする種類の警戒心を持つことができないからです。これは非常に強い主張であり、私たちが通常教えられてきたことすべてに反するものです。
ここ数年の従来の常識では、AIは技術アーキテクチャが苦手だとされてきました。なぜならアーキテクチャには全体論的思考、創造的判断、長年蓄積された知恵が必要だからです。アーキテクチャは人間のエンジニアリングにおける最後の砦の一つとされ、経験と直感が最も重要な領域だと考えられてきました。
しかし、私が繰り返し気づいていることがあります。エンジニアが自分たちのアーキテクチャの失敗について説明するとき、例えば数ヶ月かけて劣化したパフォーマンスや、静かに壊れたキャッシング層、誰もが最善を尽くしたにもかかわらず蓄積し続けた技術的負債について語るとき、根本原因はほぼ決して悪いアーキテクチャ判断ではないのです。
ほとんどの場合、それは失われたコンテキストなんです。問題を防ぐために必要な情報は存在していました。ただ、あまりにも多くのファイル、あまりにも多くの人々、あまりにも多くの時間の瞬間に分散していたのです。単一の人間の心がそれらすべてを一度に保持することはできませんでした。
アーキテクチャが劣化する構造的理由
元のアーキテクチャは多くの場合問題ありません。エンジニアは有能です。コードレビューは通常徹底的に行われています。しかし、初期設計と本番環境への機能出荷という日々の現実の間のどこかで、システムは劣化していきます。個々の変更はすべて理にかなっていて、すべてがレビューを通過します。それでも全体として、誰も予見できなかった混乱を私たちは生み出してしまうのです。
これはアーキテクチャの失敗として書かれたコモンズの悲劇のようなものです。劇的な崩壊ではありません。ゆっくりとした腐敗のように感じられます。そしてそれは人々が悪いエンジニアだという意味ではありません。人間の認知的制約の下で活動している優秀なエンジニアでも、この状況に陥る可能性があるのです。
そこで私は挑発的な質問をしたいと思いました。もしかしたら、私たちはこれらすべてについて逆に考えてきたのではないでしょうか。アーキテクチャ作業の特定の側面において、AIが単に適切であるだけでなく、構造的に人間より優れているとしたらどうでしょうか。知能のためではなく、注意力の持続時間、記憶、そして単一行の変更を評価しながらコードベース全体を心に保持する能力のためです。
そして、より大きなコンテキストウィンドウと検索可能なコンテキストを得るにつれて、AIエージェントにとってそれはより実現可能な心的モデルになっていきます。これはAIがアーキテクトを置き換えるという論争ではありません。アーキテクトにはご覧のとおり重要な役割がまだあります。これは実際には、アーキテクチャの基礎となる主要原則から逆算して、人間とAIの認知的優位性が実際にどこにあるのかを理解し、それが2026年以降、AIが私たちと協働してソフトウェアを構築する方法にとって何を意味するのかを考える試みなのです。
エントロピー問題としてのパフォーマンス低下
私と一緒に踏み込んでみましょう。まず、最近エンジニアリング界で話題になっている記事から始めましょう。Verselでパフォーマンス最適化の仕事に約7年間携わり、パフォーマンスに焦点を当てた約400のプルリクエストをオープンしてきたDingという人物がいます。私たちがそれを知っているのは、彼がそれについて書いたからです。
彼が提出したものの約10件に1件で、私が関わってきたすべての大規模エンジニアリング組織で見てきた問題が彼にとって明確になっています。彼の論点は、パフォーマンス問題は技術的問題ではなく、実際にはエントロピー問題だというものです。そしてこれは深い洞察だと思います。
議論はこう進みます。どんなに経験豊富なエンジニアでも、頭の中に保持できる量には限りがあります。現代のコードベースは指数関数的に成長します。依存関係、ステートマシン、非同期フロー、キャッシング層。コードベースは個々の人が追跡できる速度よりも速く成長します。これはAIの時代においてさらに真実です。
エンジニアは機能間で焦点を移します。コンテキストは薄れていきます。AIの時代にはさらに速く薄れるでしょう。そしてチームが拡大すると、知識は分散され希薄化されます。彼の表現は頭に残ります。
彼はこう書きました。「一つのレンガを置きながら、大聖堂の設計を頭の中に保持することはできない」。これは本当に真実だと思います。そしてAIエージェントがあらゆる場所でそのレンガを置いている世界を想像するなら、これはさらに真実となるでしょう。
パターンの反復と構造的制約
ここで興味深くなります。同じ間違いが異なる組織やコードベース全体で繰り返し現れ続けています。今はより高速なフレームワークがあります。より優れたコンパイラがあります。よりスマートなリンターがあります。AIエージェントがあります。しかしエントロピーはパッチを当てられる技術的問題ではありません。それは人間の認知アーキテクチャと現代のソフトウェアシステムの規模との間のミスマッチから生じるシステム的な問題なのです。
私たちはこう自分に言い聞かせます。エンジニアが注意を払えば、エンジニアがより良いコードを書けば、アプリケーションは単に機能するだろうと。しかし善意は拡張しません。エンジニアが不注意だからではありません。システムが劣化を許しているからです。
エントロピーは悪意によって勝利するのでもなく、無能によって勝利するのでもなく、誰もシステム的問題に加算されると見なかった局所的に合理的な決定の蓄積によって勝利するのです。
本番環境からの具体例
本番コードベースからの例でこれを具体的にしましょう。例1、抽象化がコストを隠す。ユーザーがウェブサイト上のポップアップをクリックしたときを検出するためにグローバルクリックリスナーを追加する、完璧にクリーンに見える再利用可能なポップアップフックがあります。これは合理的な実装ですが、抽象化が重要な何かを隠しています。
すべての単一のインスタンスがグローバルリスナーを追加するのです。したがって、アプリケーション全体に100のポップアップインスタンスがある場合、そして複雑なウェブサイトではそうなりますが、それはウェブサイトのどこかでのすべてのクリックで発火する100のコールバックということになります。
技術的な修正は簡単です。単にリスナーを重複排除すればいいのです。しかし本当の問題はシステム的です。コードベースの中にこのパターンが広がることを防ぐものは何もありません。次回、フックを再利用するエンジニアは、ユーザーが本番環境での動作の遅さについて不満を言うまで、コストを知る方法がないのです。より良い決定をするために必要な情報は存在しています。ただ決定が行われる時点では見えないのです。
例2、壊れやすい抽象化。エンジニアがオブジェクトパラメータを追加してキャッシュされた関数を拡張するとしましょう。合理的な変更です。パラメータを追加すれば、機能を拡張できます。コードはコンパイルされ、テストは通過し、すべてが良好に見えます。
しかし、すべての呼び出しが新しいオブジェクト参照を作成することになり、それはキャッシュが決してヒットしないことを意味します。完全に静かに壊れているのです。これを正しく行うための技術的知識はドキュメントに存在しています。システム的問題は、そのドキュメントを強制するものが何もないということです。型安全性は役に立ちません。リンターでは捕捉されません。キャッシュは静かに機能を停止するだけで、数ヶ月後に誰かがアプリをプロファイリングするまで誰も気づきません。
例3、抽象化が不透明になる、または透けて見えにくくなるとしましょう。注文を処理する関数にクーポンチェックが追加されるとします。エンジニアは局所的な問題を解決しています。私はクーポンサポートを追加しなければなりません。プロダクトマネージャーがそう言いました。そこで彼らはクーポン検証のためのawaitを追加します。合理的に見えますが、その関数は1000行の長さです。複数の人によって構築されています。
クーポンチェックは今やその下のすべてをブロックし、順次実行可能だった操作が並列実行できたはずのウォーターフォールを作り出しています。チェックを追加しているエンジニアは、チェックアウトにおけるグローバルな非同期フローについて考えていません。そのフローを見ることができないのです。なぜならそれはもうそこで働いていない人々によって書かれた数百または数千行のコードに分散しているからです。
最適化は技術的には可能です。しかし機会を見るために必要な情報は、パフォーマンスへの影響を理解しながらチェックアウトの関数全体を頭の中に保持できる場合にのみ存在します。そして人間組織の働き方とコードが構築され分散される方法のため、そしてこれはAIの時代においてさらに当てはまりますが、誰もそのすべてをそこに保持することはできないのです。
例4、証明のない最適化。エンジニアがプロパティアクセスをラッピングする条件をメモ化します。彼らはメモ化が高価な作業を最適化すると学びましたが、特定のプロパティを読み取ることは瞬時です。そこで彼らはメモ化クロージャを作成します。依存関係を追跡し、すべてのレンダリングで比較することは、実際にはそれらを単に読み取るよりも高価です。
例4、証明のない最適化。エンジニアがコードの一部にパフォーマンス最適化を適用します。彼らはメモ化と呼ばれるこの技術が、再計算する代わりに結果を記憶することで処理を高速化すると学びました。それは素晴らしい直感ですが、彼らが最適化している操作はすでに瞬時でした。
2足す2が4であることを記憶するために複雑なキャッシングシステムをインストールするようなものです。システムのオーバーヘッドが今や元の計算を行うよりも長くかかります。エンジニアはベストプラクティスを適用し、それが必要かどうかを決してチェックしませんでした。そしてシステムは書類上では良く見えたのでそれを許可しました。
これらはエッジケースではありません。大規模ソフトウェアの通常の失敗モードです。個々の決定はそれぞれ擁護可能であり、各エンジニアは有能でした。失敗は個人が橋渡しできなかったコンテキストギャップから生じたのです。
人間の認知的制約とAIの優位性
今、AIとアーキテクチャの議論において過小評価されていると思うフレームを紹介したいと思います。私たち人間には根本的な認知的制約があります。ワーキングメモリです。ここでの研究は非常に確立されています。私たちは頭の中に4から7のチャンクの情報を保持できます。これはトレーニングの問題ではありません。経験で克服できるものではありません。構造的な限界なのです。
これはアーキテクチャにとって非常に重要です。なぜなら優れたアーキテクチャ推論は複数の懸念事項を同時に保持する必要があるからです。パフォーマンスへの影響、セキュリティ考慮事項、保守性、コードベースにおける既存のパターン、他のチームへの下流効果。適度に複雑なアーキテクチャの決定でさえ、12の関連する考慮事項を含むかもしれません。私たちはそれらを一度にすべて頭の中に保持することはできません。
そして私たちは抽象化を使って循環し、メンタルモデルを構築し、どう考えるかを理解する傾向があります。そして私たちは実際にそれが非常に得意です。優れたアーキテクトは複雑なシステムを非常に非常によく理解するために単純化し抽象化を構築します。問題は、私たちが皆、それを行うために自分の心のハードウェアに依存しているということです。私たちは皆それを等しく得意というわけではありません。
そして頭の中で行う場合、抽象化はそれほど遠くまで拡張しません。人間がコードをレビューするとき、彼らはローカルな変更にズームインするか、ズームアウトするかできますが、両方を同じ忠実度で行うことは困難です。これがコードレビューがバグを捕捉することはあってもアーキテクチャの退化を見逃すことが多い理由です。
大きくズームアウトしてみましょう。ビジネスの規模で何が起こるかを見てください。大規模なエンジニアリングチームは本質的に分散認知システムです。個々のエンジニアはシステム全体の知識の断片を保持しています。コミュニケーションのオーバーヘッドはチームサイズとともに二次的に増加し、エンジニア間のコンテキスト転送は非常に損失が多いのです。
そして制度的知識は人々が去ると劣化し、本質的に劣化します。なぜその奇妙なキャッシングパターンが存在するのかを知っていたエンジニアは、ずっと前に別の会社に移りました。そしてドキュメントは、もし存在していたとしても、古くなっています。
これは非常に予測可能な失敗モードを作り出します。単一のエンジニアが見ることができなかったアーキテクチャの退化です。なぜならそれらを見るには、認知システム全体に分散していた情報を統合する必要があったからです。
コンテキストウィンドウとAIの能力
factory.aiの研究は、これを人間組織のためのコンテキストウィンドウ問題としてフレーム化しています。典型的なエンタープライズモノレポは数千のファイルと数百万行のコードにまたがります。そのコードのアーキテクチャについて良い決定を下すために必要なコンテキストには、コードがどのように構築されたかという歴史的コンテキスト、チームの慣習は何かといった協働的コンテキスト、そして環境的コンテキストも含まれます。
デプロイメントの制約は何か。人間はこれらすべてを頭の中に保持することはできません。私たちは必然的に不完全ですが、有用な抽象化であることを期待するメンタルモデルを構築することで対処しています。
ここでAIシステムが実際に何であるかについて注意深く考える必要があります。機械ができることとできないことについての直感に頼るのではなく、十分なコンテキストでデプロイされた現代の大規模言語モデルが実際に何ができるかを真剣に見るべきです。なぜなら彼らは人間とは非常に異なる認知アーキテクチャを持っているからです。
彼らは同じワーキングメモリ制約を持っていません。彼らは20万トークンのコンテキストウィンドウ、おそらく15万語を、その入力長全体にわたって絶えず相互参照を可能にする注意の形式で保持できます。一部のモデルは今や100万トークン以上の使用可能なコンテキストウィンドウをサポートしています。
これは人間的な意味での知能ではありません。それは何か異なるものです。非常に大きなコンテキストウィンドウ全体にわたる包括的なパターンマッチングと、疲労や忘却なしに一貫したルールを適用する能力です。
これがエントロピー問題にとって何を意味するかを見てみましょう。私が先ほど説明した例、グローバルリスナーを追加するフック、静かに壊れるキャッシュ、これらはすべて、局所的な変更を行う人間がグローバルな影響を見ることができないケースです。
コンテキスト内に、または要求に応じて取得可能な形で、コードベース全体を持つAIシステムは同じ制約を持っていません。フックパターンが何百回もインスタンス化されているかどうかをチェックできます。キャッシュ使用の参照品質への影響をトレースできます。関数全体にわたって非同期フローを分析できます。メモ化されている操作が実際に高価かどうかをチェックできます。
さらに重要なことに、締め切りのプレッシャーなしに、専門知識の検証なしに、エンジニアがチームを変えるときに知識がドアから出て行くことなしに、その週の47番目のプルリクエストをレビューする認知的疲労なしに、これを毎回一貫して行うことができるのです。
Verselチームの取り組み
Verselチームはこれに基づいて行動を始めています。彼らは10年以上のReactとNext.jsの最適化知識を構造化されたリポジトリに蒸留しています。重大なものから段階的なものまで、影響によって順序付けられた8つのカテゴリにわたる40以上のルールです。重大とはウォーターフォールの排除です。段階的な例は高度な技術パターンでしょう。
そのリポジトリはAIエージェントによってクエリ可能であるように特別に設計されています。エージェントがコードをレビューするとき、それらのパターンを参照できます。違反を見つけたとき、理論的根拠を説明し、修正を示すことができます。
観察は私が他の組織全体で見てきたことと一致しています。ほとんどのパフォーマンス作業は、スタックの低すぎる場所から始まるために失敗します。リクエストウォーターフォールが0.5秒以上の待機時間を追加する場合、呼び出しがどれほど最適化されていても関係ありません。300キロバイトの余分なJavaScriptを出荷する場合、ループからマイクロ秒を削ることは関係ありません。最適化がスタックで実際にどのように機能するかを理解していなければ、基本的に上り坂で戦っているのです。
AIは一貫した優先順位付けを強制でき、技術システムでレバレッジがどのように機能するか、そしてより速いページロードのようなより大きな目標がシステムを構築する方法についての技術ルールのセット内で実際にどのように達成できるかについて、人々に思い出させることに疲れることはありません。
AIの構造的優位性を詳細に分析する
これらのカテゴリをより正確に列挙させてください。具体性が役立つと思うからです。第一に、AIは大規模で一貫したルールを適用できるときに構造的優位性を持ちます。人間は10個に与えるのと同じ注意で1万のファイルを一連の原則に対してチェックすることはしません。
AIではそれは真実ではありません。AIはすべてのファイルに同一の精査を適用できます。そしてこれは、一貫したエラー処理パターンを確保すること、すべてのAPIエンドポイントが規約に従っているかをチェックすることなどにとって重要です。
AIはグローバルローカル推論、大聖堂とレンガの問題において構造的優位性を持っています。AIは行ごとの変更を調べながら同時にアーキテクチャドキュメントを参照し、私たちの脳がうまくできない方法で両方のレベルの抽象化を同時に維持できます。
これは周辺視野のようなものです。森と木を同時に見るようなものです。人間のレビュアーはそれをしません。彼らはズームインするかズームアウトするかです。そしてAIは同じパスで両方を行うことができます。
時間と空間を超えたパターン検出。バージョン履歴とフルコードベースへのアクセスを持つAIシステムは、組織の経験全体にまたがるパターンを識別できます。たとえば、このキャッシュパターンはこのコードベースで以前に3回誤用されていました。このタイプのウォーターフォールは導入され、後で修正されました。人間はその程度の制度的記憶を維持できません。システムがそれを表面化するように構築されていれば、AIはできます。そしてそれは大きな問題です。それは人間のための問題です。
AIは必要な瞬間に教えることができます。これはおそらく最も過小評価されている利点です。誰かがシステムにウォーターフォールを書いたとき、優れたシステムはそれをアーキテクチャの欠陥としてフラグを立てるだけではありません。なぜそれが問題なのかを説明し、チェックアウトでページロードの問題を引き起こさないように並列化する方法を示すことができます。
彼らがキャッシュを壊したとき、ジュニアエンジニアが理解できる方法で参照等価性の問題を説明できます。この教育はワークフローに組み込まれ、現在であるかどうかわからない、そして確実にオンボーディングでカバーされる以上のものである既存の知識に依存することはありません。
AIには疲れを知らない警戒心があります。締め切りのプレッシャーの下にある人間は、私たちは単に物事をスキップします。人間は機能間でコンテキストスイッチします。何番目かのPRをレビューしている人間はそれほど鋭くないでしょう。人間は疲れてイライラしているときに物事を見逃します。
これが私が思うに業界が内面化の瀬戸際にある大きな洞察です。AIが単に役立つだけでなく、人間の認知に対して構造的に優れているアーキテクチャ推論の特定のカテゴリがあります。タスク要件が人間の認知的制約を超えているためです。
AIがより賢いからではありません。タスクが大規模でのパターンマッチングであり、人間はそのために作られていないからです。
AIが依然として不足している領域
では、AIはどこでまだ不足しているのでしょうか。ここで私たちはまだ微妙さが必要です。AIの利点を明らかにする同じ推論が、その限界を露わにします。そしてこれらの制限は一時的なギャップではありません。それらはAIシステムの構造的特徴なのです。
新規のアーキテクチャ決定。AIシステムは根本的に既存のコードとドキュメントで調整されています。彼らはコードが確立されたパターンから逸脱するときを識別することに秀でています。彼らは新しいパターンを発明することは得意ではありません。そしてあなたはアンドレ・カルパシーのような最先端のエンジニアが、真新しいものをコーディングするためにAIを使用できないことについて話すときにそれを見ます。
AIの支援は、おそらく関連する以前の例から推論することに制限されることがよくあります。そして以前の例がない場合、それは困難になります。
ビジネスコンテキストとトレードオフ。アーキテクチャは技術的に最適なものについてだけではありません。それは開発速度、保守性、一貫性、柔軟性をめぐる競合する懸念事項間のトレードオフについてです。これらのトレードオフは文脈的であり、組織的制約、市場圧力に結びついています。
AIはパターンが技術的負債を作り出すことをあなたに伝えることができますが、それが正しい呼びかけかどうかを伝えることはできません。
システム間統合。現代のアーキテクチャは、しばしば異なるチームによって所有される複数のシステムを含み、統合ポイントはAIがアクセスできる単一のソースに完全に文書化されていないことがよくあります。このサービスが異なるケイデンスで出荷するXチームによって維持されていることを知っているエンジニアは、コード分析が提供できない組織的コンテキストを持っています。
私たちは以前にこの統合を試み、ブラックフライデー中に問題を引き起こしたことを覚えている人は、おそらくAIにアクセスできない歴史的コンテキストを持っています。
十分に良いことについての判断。アーキテクチャには、いつ最適化を止めるべきかを知ることが含まれます。6ヶ月かかる技術的に優れたソリューションは、今出荷される適切なソリューションよりも必ずしも優れているわけではありません。完璧にクリーンなアーキテクチャは、紙上にのみ存在する場合は役に立ちません。この種の判断には、賭け金とリスクを理解する必要があり、人間は非常に非常に得意なままです。
既存の決定の背後にある理由。コードベースは考古学的な遺物です。それらはもはや存在しない制約の下で行われた決定を含んでいます。AIはコードが何をするかを見ることができます。なぜその決定がその方法で行われたのかを推論できないことがよくあり、荷重を支える決定と歴史的偶然を区別できません。人間にはできません。
AI支援開発システムの実践的展開
では、これらすべては、AI支援開発システムを実際にどのようにデプロイするかについて考える方法にとって何を意味するのでしょうか。第一に、価値提案は具体的であることを認識してください。AIがアーキテクチャ問題において優れている場所と優れていない場所の詳細に立ち入るために時間を費やしてきました。なぜなら、これらの会話でAIを有用なツールとして位置づけたいのであれば、私たちは具体的でなければならないと思うからです。
AIを汎用オラクルとして位置づけようとすれば、あまり遠くには行けません。
第二に、AIがそれらを強制する前にパターンが存在しなければなりません。そして私はVerselが何年ものパフォーマンス最適化経験を構造化されたルールに蒸留するために時間を費やしていることに注目します。彼らはAIがコードベースからそれらのルールを導き出すことに単に依存しているわけではありません。なぜなら彼らはそれらが一貫して適用されていないことを知っているからです。これらの原則をAIとともに生きるには準備作業とコミットメントが必要です。
第三に、コンテキスト問題は難しい課題です。100万トークンのコンテキストウィンドウがあっても、エンタープライズコードベースはそれより10倍または100倍大きい可能性があります。したがって、特定の決定のために適切なコンテキストを表面化するために必要な足場は些細なものではありません。
セマンティック検索、プログレッシブディスクロージャー、おそらくRAG、おそらくそうではない、おそらく構造化されたリポジトリ概要が必要です。このようなシステムを準備するためのエンジニアリング努力の多くはここに行くでしょう。モデルインテリジェンスはますます商品化されています。コンテキストエンジニアリングが差別化要因です。
factory.aiやaugmentのような企業は、モデル能力を最大限に活用するために適切なタイミングで適切なコンテキストを表面化する必要があるという考えを中心に製品全体を構築しています。
そのようなシステムにおいても人間の判断は依然として置き換え不可能であることを改めて指摘したいと思います。新規の決定、ビジネスコンテキスト、システム間統合。AIはパターンマッチングを処理できます。そのように設定すれば、AIは一貫性の強制を処理できます。人間はまだ、私たちが得意とすることをするために、必要な判断を伴う決定を下すために関与する必要があります。
私たちの目標は単に、人間がとにかくエントロピーに負けるはずだったアーキテクチャの部分にAIを配置することです。
第五に最後に、これすべての組織的意味合いは本当に興味深いものです。AIがアーキテクチャパターンを一貫して強制できるなら、それは誰のパターンなのでしょうか。ルールセットをどのように統治しますか。時間とともにそれらをどのように進化させますか。異なるアーキテクチャ基準を持つチーム間の意見の相違をどう処理しますか。それらはしばしば表面下に書かれてきました。それらは暗黙の意見の相違でした。
AIがシステムのエントロピーを減らすためにアーキテクチャ原則を大規模に強制することにどう役立つかについての会話は、伝統的に戦う必要がなかったチームに、彼らの原則が単に別々のままでいられたために、より大きな会話をさせることになるでしょう。そして私はそれが、私たちが乗り越えなければならない新しい組織的人間のアラインメントの領域になると思います。
AIと人間の相補性の理解
私が組織で繰り返し見ているパターンは、私たちが間違った質問をし続けているということです。AIはどこで自律的かつ独立して開発を推進できるのかを尋ね続けています。おそらくAIはアーキテクチャから完全に締め出されるべきだ、などです。
私はAIと技術開発についてより具体的な質問をすべきだと思います。その良い例は、人間として私たちがこれらの空間で一貫した弱点を持っていることに気づくので、技術アーキテクチャのどの側面に対してAIを当てることができるかということです。
それには多くの微妙さが必要ですよね。AIが大規模でコンテキストを維持することにおいて構造的に優れており、人間が不確実性の下での判断において構造的に優れていることを理解するには、多くの思慮深さが必要です。そしてそれをこれらのシステムのどこに適用するかを考えなければなりません。
これは置き換えについての話ではありません。これは相補性についての話であり、その相補性を大規模で正しく行うことについて、そしてそれが種としての私たちの実際の認知的強みを理解し、私たちの実際の制限を理解し、私たちの弱点に対処することで私たちを強化するAIシステムを設計することを必要とする方法についてです。
そして私はそれを明らかにしています。私は今日ここでその物語を語っています。なぜなら私は、この種の会話、この質の思考が、エンジニアだけでなく2026年の複数の異なる部門で必要だと信じているからです。私たちはこのレベルで、プロダクト、マーケティング、カスタマーサクセスで考える必要があります。私たちはどこに認知的盲点を持っているのか。AIはそれらをどこで修正できるのか。人間はまだどこで役割を果たすのか。それが2026年の問題です。
そして私たちがアーキテクチャとAIがどのように機能するかについていくつかの怠惰な仮定をしてきた領域に少し掘り下げることは、会話がどれほど豊かになり得るかを示していると思います。
ソフトウェアアーキテクチャの未来は人間対AIではありません。それは人間が常に負けるはずだったエントロピーのようなものでAIが私たちを助けている一方で、人間がAIが単に触れることができない創造的で文脈的な仕事に集中することです。
その区別を理解し、それを本当に深く実装することは、組織が怠惰な仮定をして苦労するのではなく、AIの時代に実際に繁栄するのを助けます。
私たちの脳をオンにして、このレベルで問題を考え抜くことの代わりになるものはありません。そしてそれはエンジニアだけではありません。私はここで技術的な深みに飛び込んだことを知っていますが、2026年にAIと人間の間の効果的なパートナーシップを構築するために、誰もが自分のシステムがどのように機能するかについてこのレベルで考えなければならないのです。
コメント