誰もがAIを持っていても、会社が依然として何も学べないとき
(robert-glaser.de)- 従業員個人のAIによる生産性向上は、自動的に組織レベルの学習にはつながらず、実際の発見が個人からチーム、さらに組織能力へと移る経路が中核的な課題となる
- AI導入の複雑な中間段階では、Copilot、ChatGPT Enterprise、Claude、Gemini、Cursorのようなツールの利用は広く浸透しているが、チームごとに活用の深さが異なり、一部の学習は隠れているため比較や展開が難しい
- 既存の変革管理の手法であるコミュニティ、チャンピオンネットワーク、デモ、アンケート、ダッシュボードでは、実務の中で生じるAI活用の文脈・失敗・検証・人の介入を十分に捉えにくい
- エージェント型エンジニアリングは反復コストを下げ、意図からプロトタイプや評価までを素早く進められるようにするが、組織のScrum・スプリント・引き継ぎ手順は依然として、反復は希少だという前提にとどまりうる
- 組織にはAgent Operations、Loop Intelligence、Agent Capabilitiesが同時に必要であり、従業員監視ではなく、実際の業務ループを理解して再利用可能な能力とより速い学習へ戻すフィードバック・ハーネスが重要である
組織が学べないAI導入の複雑な中間段階
- Ethan Mollickの
Leadership, Lab, and Crowdという観点では、個人のAIによる生産性向上は自動的に組織レベルの成果にはならない- 従業員はより速く書き、より多くを分析し、自動化し、「サイボーグ」のように働けるようになっても、会社はほとんど何も学べないことがある
- GitHub Copilot、ChatGPT Enterprise、Claude、Gemini、Cursorのようなツールはすでに社内に入り込み、公式の教育資料よりはるか先を行く人が各チームにいる
- 経営陣はライセンス使用量、プロンプト数、アンケート、社内PoC、ステアリングコミッティー向け資料を見ることはできても、実際の学習がどこで起きているかはよく見えない
- 会社によっては、AIがそのままIT部門に渡されたあと、それ以上進展しないこともある
- AI導入の複雑な中間段階は、AI利用が広く浸透している一方で不均一であり、一部は隠れていて、比較しにくく、なおかつまだ組織学習と結びついていない状態から始まる
- 導入の単位はもはや組織全体でも、場合によってはチームですらなく、実際の業務の中のループへと変わる
全員がCopilotを持った後に起きること
- AI導入の第1段階は、既存のエンタープライズ・ロールアウトのように見え、比較的なじみやすい
- ライセンスを購入し、許容される利用範囲を定め、教育を行い、チャンピオンネットワークを作り、Teamsチャネルでユースケースを共有させる
- こうしたチャネルは一時的には活発でも、やがて善意だけが積み上がった社内倉庫のようになることがある
- 第2段階では、同じ会社の中でもAIの使い方が大きく分岐する
- Copilotをオートコンプリート程度にしか使わないチームもある
- 別のチームはClaude Codeを、テスト、レビュー、継続的な調整とともに密なループで回している
- プロダクト担当者がFigmaの画面を作る代わりに、実際のソフトウェアをプロトタイピングする
- シニアエンジニアが根本原因分析をエージェントに任せ、1時間以内に有効な解決策を得て、AIなしでは2週間かかった作業を短縮する
- ジュニアが洗練されたコードを作れても、どのようなアーキテクチャ上の前提がシステムに入り込んだのか分からないことがある
- サポートチームは、反復するチケットを静かにワークフロー自動化へ置き換え、Center of Excellenceが把握できていない実際の痛点を知っている
- Mollickの枠組みでは、リーダーシップは方向性と許可を定め、Crowdは実際の業務を行うことでユースケースを発見し、Labはその発見を共有可能な実践、ツール、ベンチマーク、新しいシステムへと変える
- 中核的な難しさは、発見が個人からチームへ、チームから組織能力へと実際にどう移動するのかにある
従来の変革管理の手法は遅すぎる
- 多くの会社は、既存の変革管理の仕組みでAI導入に対処しようとする
- 実践コミュニティ、ランチセッション、チャンピオンネットワーク、イネーブルメント資料、オフィスアワー、月次デモ、アンケート、ダッシュボードなどが使われる
- まだ実験の許可そのものが必要な組織では、こうした方法も役に立つ
- しかし、本当に興味深いAI活用は、次のコミュニティミーティングを待たず、実務の最中に生まれる
- コードレビュー、営業提案書、リサーチ作業、プロダクトのプロトタイプ、運用障害、テスト戦略、コンプライアンスに関する問いの中で現れる
- 特定のプロダクトコンポーネントの種類では、「ダークファクトリー」に近いパターンが作られることがある
- 意図を書く
- エージェントに緩いループを回させる
- 十分なバックプレッシャーをかけて軌道を保つ
- 強いシナリオで結果を評価する
- 意図を磨き、反復的に高品質な結果を得る
- 有用だった学習は、ベストプラクティスのスライドにまとめられた時点で鋭さを失いやすい
- 実際の価値を生んだのは、省かれた文脈、失敗したテスト、奇妙なAPIの挙動、エージェントがとんでもない方向へ逸れたときに人が引き戻した摩擦だったからである
- elastic loopという観点では、AIとの協業は単一のモードではない
- 密で同期的な共同運転から、より緩く非同期的な委任まで広がっている
- 重要な問いは「人々がAIを使っているか」ではなく、チームがどの大きさのループを使うべきか、どこに抵抗が必要か、どの成果物がループの後にも残るべきか、その成果物がどう組織学習になるのか、である
- これはツールの利用量やトークン数を数えるよりはるかに難しい問いだ
Scrumは高価な反復を前提に作られている
- 現代のソフトウェアプロセスの多くは、人間による反復が高価だったために存在している
- スプリント計画、見積もり、スタンドアップ、ユーザーストーリー、チケット整理、引き継ぎ、調整とリスク低減のための儀式がこれに含まれる
- 1回の反復に数日または数週間かかるなら、無駄な反復を防ぐ構造が必要だった
- エージェント型エンジニアリングは、反復の経済性を変える
- より多くの選択肢を実際に作ってみられるようにする
- 意図からプロトタイプ、評価までをより速く進められるようにする
- プロダクト担当者が動くソフトウェアをより早い段階で見られるようにする
- エンジニアが意思決定前により多くの仮説を試せるようにする
- デリバリーそのものを魔法のように簡単にするわけではないが、制約を実装から意図、検証、判断、フィードバックの側へ移す
- 多くの組織は20年間自らをアジャイルと呼んできたが、アジャイルが取り除こうとした組織的反射を維持している
- AIは実際の俊敏性をより現実的なものにするが、システムは依然として2週間スプリントの約束、引き継ぎ文書、反復は希少だという前提を持つ手順を要求する
- ループは、組織がそのループから学んだことを消化する速度より速く動きうる
AI利用料は組織により良い問いを強いる
- AI利用は、より明確に計量される可能性が高い
- 現在の「全員にアクセス権があり、コストはそれほど気にしない」というエンタープライズの空気は長く続かないかもしれない
- モデルルーティング、トークン予算、従量課金、推論コスト、どの作業にどのモデルを許可するかのガバナンスは、より明示的なものへ変わっていく
- 重要な問いは、抽象的にトークンコストを下げることではない
- ソフトウェアデリバリーで重要なのがキーストローク数の最小化ではなかったのと同じだ
- より良い問いは「そのトークンを使ったことで何が変わったのか」である
- プルリクエスト数を数えるようなやり方は避けるべきだ
- どのループがより速く閉じたのか
- どの意思決定が改善されたのか
- どの根本原因分析がより鋭くなったのか
- どのレビューがより多くの問題を発見したのか
- どのチームが再利用可能なパターンを学んだのか
- どのプロダクトアイデアが、プロトタイプによって弱点が露わになり、より早く廃棄されたのか
- AIはどこで学習を生み、どこで単により多くの成果物を生んだだけだったのか
- 「トークン当たり成果物」は、古い測定反射が新しい服を着た形にすぎない
- もっと重要なのはトークン当たり学習に近いものだ
欠けているフィードバック経路としてのLoop Intelligence
- AI導入の複雑な中間段階で、会社には3つの能力が必要である
-
Agent Operations
- どのエージェントやAIツールが動いているのか、どのシステムに触れられるのか、どのデータを見られるのかを管理する
- どの行動に承認が必要か、アイデンティティ、監査、権限、ランタイム可視性がどこにあるかも含まれる
- エージェント型の作業は最終的に実システムに触れるため、統制の側面が重要である
-
Loop Intelligence
- どのAI支援または完全エージェント型のループが実際の学習を生むのかを把握する
- どのループが開いたままなのか、どのループが衰退しているのか、エージェントがどこでレバレッジを生み、どこで枝葉に広がっているのかを見る
- どのチームがテスト、文脈、直感の不足によって密な監督に縛られているのか、どのチームがより緩い委任の準備ができているのかを判断する
-
Agent Capabilities
- 有用な能力を組織全体に展開するが、巨大な3つのエージェントですべての仕事ができるとは想定しない
- AIは、単一のアプリケーションカテゴリというより、流動的な基盤技術のように動き始める
- 「HRエージェント」「エンジニアリングエージェント」「営業エージェント」を1つずつエンタープライズ動物園に置くやり方にはうまく適合しない
- 能力は、実際に仕事が行われる場所へ流れていかなければならない
- 従業員ハーネス
- バックグラウンドエージェント
- プロダクトチーム
- プラットフォームサービス
- ローカルスキル
- MCPサーバー
- 評価スイート
- ランブック
- 例
- ドメイン別手順
プラットフォームの問いとフィードバック・ハーネス
- プラットフォームのレベルで重要なのは、有用な能力の所有と移動の仕方という問いである
- あるチームで見つかった有用なエージェントスキルが、死んだテンプレートにならずに別のチームへ渡る方法が必要だ
- 開発者のハーネス、プロダクト担当者のハーネス、サポートチームのバックグラウンドエージェント、コンプライアンスワークフローは、それぞれ異なる形で強化される必要がある
- ある能力はチームの近くにあるべきで、ある能力はプラットフォーム層にあるべきであり、またある能力はローカルな文脈そのものが核心なので一般化すべきではない
- 3つの能力のうち1つだけでは、すぐにおかしくなる
- Agent OperationsだけでLoop Intelligenceがなければ、統制官僚主義になる
- Loop IntelligenceだけでAgent Capabilitiesがなければ、有用なパターンを見つけても再び業務へ戻せない分析レイヤーになる
- Agent CapabilitiesだけでOperationsとLoop Intelligenceがなければ、ブランディングが少し良くなっただけのツール乱立になる
- 統制の経路、学習の経路、能力の経路は、どこかで合流しなければならない
- 内部的には、これをフィードバック・ハーネスと呼べる
- 顧客が買うのは洗練されたメカニズムではなく、自信、より良い意思決定、より速い学習、より少ない無駄、より安全な委任である
- 顧客にとってより有用な概念はLoop Intelligence Hubかもしれない
- フィードバック・ハーネスは、実際の業務ループを聴くための装置である
- タスク、プロンプト、仕様、レビュー、シナリオ、採用・却下された仮説、運用シグナル、手戻り、人の意思決定と介入を見る
- 人を監視するためではなく、ループを理解するためのものだ
- 最初のバージョンが巨大なプラットフォームである必要はない
- いくつかの実際のワークフローを選び、意図、エージェント作業、検証、人の意思決定がすでに痕跡を残している地点を計測し、ループがなぜ成功または失敗したのかを理解できるだけの定性的フィードバックを集め、それを反復的な学習成果物へ変えればよい
- Loop Intelligence Hubは、シグナルを組織が行動できる形へ変換する
- イネーブルメント・バックログ
- 能力レーダー
- 投資ブリーフ
- ガバナンスのギャップ
- 再利用可能なワークフロー
- 教育ニーズ
- 評価の優先順位
- どこにでも当てはまるダッシュボードではなく、関連性に合わせた出力が必要だ
- 興味深い成果物はダッシュボードそのものではなく、その背後の意思決定である
- より多く委任する前に、より良いバックプレッシャーが必要なチームもある
- 一部のプロダクトグループは、狭いコンポーネント種別に対して反復可能なダークファクトリーパターンを持っている
- あるコンプライアンスワークフローには、ガバナンスが適用されたツール境界が必要だ
- あるスキルは5つのチームが誤って再発明したため、プラットフォームへ移すべきだ
- ハーネスは収集し、ハブは組織の意思決定を助け、能力レイヤーは学習を再び業務へ戻す
従業員監視になったら失敗する
- この構造が従業員の点数付けに変われば、全体が崩れる
- 従業員が、組織が自分のAI利用量を十分かどうか測っていると信じれば、シグナルを操作する
- すべての実験が生産性への期待値になると信じれば、実験を隠す
- 最良のワークフローがすぐに新たな標準業務量になると信じれば、それを非公開にする
- 会社は、可視的な遵守と不可視の学習という最悪の導入形態を手にすることになる
- 有用な問いは「誰が十分にAIを使っているか」ではない
- AIはどこで、組織が学べる形で仕事を変えたのか
- どのループがより健全になったのか
- どのチームが、より多く委任する前により良いバックプレッシャーを必要としているのか
- プロトタイプが実際のソフトウェアになりつつあるなら、どのプロダクトチームに別の環境が必要なのか
- ポリシーは必要だが、ガバナンスも学習と同様、利用を通じてしか現実のものにならない
- エージェントが運用に近い作業に触れるとき
- プロダクト担当者が仕様を書く代わりにプロトタイプを作るとき
- 開発者が根本原因分析を委任するとき
- トークン支出が大きくなり、経営陣が答えを求めるとき
- 組織は、自分たちが学習システムを作ったのか、それとも単に大量のライセンスを買っただけなのかを知ることになる
複雑な中間段階は耐え忍ぶための段階ではない
- AI導入の第1段階は、アクセス権に関するものだった
- 誰がツールを受け取るのか、誰が許可を得るのか、誰が契約交渉をするのか、調達チケットなしで最新モデルを試せるのかが重要だった
- この段階は依然として重要だが、長く差別化要因にはならない
- 最前線の知能へのアクセスは借りられても、運用統制と組織学習は同じようには借りられない
- 次の優位性は学習速度である
- 誰が実際のパターンをより速く見つけるのか
- 誰が発見を個人からチームへ、チームから組織能力へ移すのか
- 誰がエージェント型ループにバックプレッシャーを入れて、エージェントが拡散しないようにするのか
- 誰が、全員向けではない巨大なエンタープライズエージェントにせず、有用なエージェント能力を展開するのか
- 誰が、AIを既存の儀式に付け足すのではなく、エージェント型エンジニアリングによってアジャイルを現実に近づけるのか
- 確立済みの導入プレイブックを待っていては、この変化を理解しにくい
- ベンダー、コンサルタント、AI研究所からの最終回答を待つのではなく、実際の業務を計測し、泥臭い学習を共有し、他者に弱点を突かせ、公開の場で反復すべきである
1件のコメント
Hacker Newsの意見
大企業環境では、AI導入は開発チームの外にほとんど広がっておらず、開発者だけがGitHub Copilotを使える
コードがコミットから本番デプロイに至るまで6〜12か月かかり、もともと開発速度はボトルネックではなかった
時間がかかるのは、インフラのプロビジョニング、テスト、承認、変更管理、デプロイ日程のような手続きであり、AIは開発後のボトルネックをさらに悪化させ、変更がリリース列車の前に積み上がるようにしてしまう
大企業がトークンコストの投資対効果を確保するには、ソフトウェアをもっと速くデプロイする方法を学ばなければならず、デプロイされていないコードは資産ではなく負債である
ソフトウェア開発が非効率なのは確かだが、核心はコードを書くことではなく、どんなコードを書くべきかを突き止める調査と設計であり、この部分は十分に考慮されていない
Microsoftが「コードを50%速く!」と叫ぶと、経営陣は「製品も50%速く、金も50%速く」と受け取る
投資対効果を求め始めた瞬間に破滅しかねず、今はみなが測定を避けているだけだ
いずれ投資家は「200万ドル使ったのだから純利益400万ドルを出せ」と求めるだろうが、そんな結果は出にくい
CopilotとClaudeは、古い組織知、文書化されていない特殊な解決策、将来の活用可能性といった本当のボトルネックを解決しない
コードは本当の製品でも本当の仕事でもなく、健全なコードベースでは設計と調査プロセスのほとんど無料の産物に近い
「購買チームが検索を使いづらい」を実用的なチケットに磨き上げた時点で、Reactの検索フィルターコンポーネントは事実上すでに決まっており、コーディングは10分で済む形式的な手順に近い
Copilotがそれを5分に短縮しても、その前に費やした6時間の会議と通話を考えれば大して印象的ではない
栄養やカロリーも、あるところまでは有益だが、その後はリターンが減り、やがて悪影響が出る
完璧な比喩ではないが、より多く生み出すことがむしろより少ない価値しか生まない、という思考モデルをつかむのに役立つ
顧客から、文書は完全で詳細だが圧倒的すぎるというフィードバックを受け、結局、要点を伝える短いbullet pointがいくつかある方が、5ページの文書より良いと分かった
[0] https://en.wikipedia.org/wiki/Theory_of_constraints
[1] https://www.goodreads.com/book/show/113934.The_Goal
[2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
財務チームから、Copilot、Cursor、Claudeで財務計画用アプリをバイブコーディングしてよいかと聞かれ、「CFOがLovableを試して確信したので、我々にアプリをバイブコーディングしろと言った」という理由まで持ち出してきた
経営陣が「CFOがそう言った」と聞くだけで固まるのを知っていて、その論理を前面に出したわけだ
最後には「適切なデータセキュリティと保守性を備えたバイブコーディングアプリが企業財務領域に存在しうるか確認する必要がある」というもっともらしい包装まで付けていた
これが年商200億ドル超の会社から出てきたreasoningだという点がさらに驚きだ
私のような平凡なエンジニアにとって、会社でAIを使うことに実質的な利点はない
会社は我々をじわじわ煮ており、HNのエリート層である投資家、役員、有名人、最上位エンジニアたちは「どうしてイノベーションに反対できるんだ」と言うだろう
AI/LLMはTCP/IP、Linux、Postgresのような形のイノベーションではない
Claude、Codex、Gemini、Grokのようなものは利益のために存在し、生産性を最後の一滴まで搾り取り、もう不要になれば解雇できるようにするための道具だ
AIが良いものなら、オープンソースモデルを使って個人プロジェクトで使う方がよい
AIはコードを大量にばらまけるが、実際に何が起きているのかを理解するエンジニアは依然として必要であり、それが常にボトルネックだった
ジュニア職は消えるかもしれないが、シニアエンジニアはしばらく大丈夫そうだ
私ももともと反骨的なので苦労して学んだ教訓だが、雇われている以上、経営陣が望むことをやるために雇われている
抵抗するなら、彼らが気付かないか気にしないことを祈るしかなく、大きな変化を起こすのは難しい
SCOが崩壊しながら業界に何をしたか覚えているか分からない
企業が内部の機密情報であるコード、プロセス、顧客要件、社内政治、リーダーシップの構想を、スタートアップや信用しがたい大企業の手に渡している部分がいまだに理解できない
Microsoftもかつては秘密保持契約と取引の濫用で有名だった
LLM巨大企業が企業資料で学習しないはずがなく、しないと嘘をつかないはずもないと思う
彼らが崩れ始めたら、このゴールドラッシュは長く醜い尻尾を引くかもしれない
実際に解雇されるのは、こうした技術を導入しない側であり、そのように振る舞えば自ら解雇対象の範囲に入ることになる
今日のCoinbaseの事例を見ても、未来を受け入れない人々を整理している
彼らは進歩を助けず、前に押し進めもせず、そうする人々を引き留めるからだ
この記事はmessy middleを正確に突いている
自分の責任や仕事がかかっている開発者には、このような知能ループを作る動機がほとんどない
経営陣がどれだけ丁寧に頼んできても、自分の生産性向上を会社全体に無料で利他的に共有するつもりはない
便利なツールなら共有するかもしれないが、AIの扱い方やエージェントの設定方法を学ぶノウハウは、共有に対する評価がないなら自分だけで持っていた方がよい
うちの会社は導入拡大のために「今週のプロンプト」賞やランチセッションを作り、こうした流れを開発するチームまである
しかし、実際の金銭的報酬や雇用の安定なしに知識を広めるリスクとコストは、全面的に開発者に降りかかる
今のAIがここまでになるずっと前から、仕事を楽にし、自動化スクリプトを書きやすくするために個人CLIを作っていた
同僚たちはそのツールを見て共有してくれと言ったが、外交的に表現した答えは拒否だった
共有するとサポート負担が生じ、みんなが私と同じだけ生産的に働けるようになって自分の優位性が消える負のリターンが生まれる
しかもリーダーシップは私の創意工夫を資産として認めないので、雇用の安定も増えない
近い将来どうせ解雇されるかもしれないのに、善意で会社を助けるつもりはない
今の市場で開発者が仕事を心配しているなら、個人ワークフローは営業秘密のように扱うべきだ
この例はAIに限ったことではないが、AIワークフローにもそのまま当てはまる
労働者優位の市場では、そうした知識を組織と共有するのが時には楽しかったが、雇用主優位の市場では、私の個人的な工夫にアクセスしたいなら金を払うべきだ
職場を家族だとは思わないが、自分の墓穴を掘っているのではないかと心配せずに、お互い仕事をうまくやって共有できたらいいのにと思う
ほとんどの人は仕事をするために賃金をもらっており、勤務時間中は当然雇用主のために働くべきだ
実際、他人が思いつけないほど大したものはほとんどない
私の経験では、プロンプトや技術を共有しても使う人はあまりおらず、あまりに基本的すぎてすでに各自が自分版を持っていた
AI以前に誰かがxyzに興味がなかったなら、銀の皿に載せて持っていっても、AI以後に突然興味を持つことはない
退屈な作業はほとんど消え、いくつかの問題は投げておけば処理され、1日1〜4時間が戻ってくる
その人が合理的にその時間を使って、さらに多くの仕事を探しに行くだろうか? 自分の会社であるか、特別な動機があるのでない限り、その可能性は低い
引退して3年になるシステムアナリストとして、若い同僚たちが気の毒に感じられる
2023年にチームの中で比較的早くAIを使い、元の作者がずっと前に去り、コメントや文書をほとんど残していないPerlベースのレガシーコードを解きほぐした
そのコードは重要な業務を担っており、AIが窮地から救い出してくれたので、皆この新技術に感嘆した
しかし次第に、これは自分が使えるツールというより、自分に対して加えられる何かのように見えてきた
誰もこんなものを頼んではいなかった
すべてを即座に処理するという名目で、ひらめきや思考がいつから価値を下げられ、無価値なものになったのか分からず、仕事から魂が失われた
AIそれ自体は、それほど有用ではない
エージェントは忘れたりミスしたりすることが十分に多く、すべての作業を確認しなければならず、結果として生産性がむしろ下がることすらある
真価を発揮するのは、AIを別のツールを作るためのツールとして扱う時だ
たとえば、作業が一定の品質に達するまで進み続けるよう強制するツールを作らせたり、出力に対してコンプライアンス検査を走らせて、どこを直すべきか教えさせたりする
そうして初めて、その作業を信頼できる
今のほとんどの役割とワークフローは、与えられたツールを扱って特定の仕事を成し遂げる構造で設計されており、そのような体制ではAIは周辺からしか入り込めない
良い記事で、組織が仕事を定義するやり方が変わるという部分が特に目を引いた
以前のモデルでは、成果やOKRは職務分野、肩書き、役割ごとの期待値に結びついていた
AI時代には、その境界が崩れ始める
より深い問題は心理的・組織的なもので、人々は「これは自分の仕事だ」と「これは自分の責任ではない」の間の線を絶えず交渉することになる
そこで核心的な導入問題が生じる。AI上級ユーザーとして目立って認められることの利点は何か?
自分がより速く、より上手く、より多機能にまたがって働けると知られたなら、会社が承認・報酬・キャリア成長の明確な仕組みを作らない限り、なぜそれを明らかにする必要があるのか?
エージェントたちがその境界をまたぐ世界では、かなり厄介になるかもしれない
エージェントの群れを率いるAIエンジニアが、すべてを継続運用する責任まで負うのか? かなり疑わしいが、見守るしかない
そうした新しい職業に引かれた誰かが、会社固有の文脈に関する助言を数週間分、より新しいアプローチと結びつければ、結局その人は取り除かれるドメイン専門家の役割に置かれることになる
「去年Anthropicに払った200万ユーロの投資対効果はどこにある?」への答えは、CEOオフィスに掛かっているYouTube風のプラチナトークン盾だ
「去年Anthropicに払った200万ユーロの投資対効果はどこにある?」という問いに潜む前提バイアスは本当にばかげている
問題は、生成AIが目に見える投資対効果を生み出せないことだ
なのに「解決策」は、開発組織全体をその技術中心に再配置し、新しいツールを発明しろという話になる
こうした記事の本当の目的は、表向きに扱っている内容ではなく、その議論が土台にしている前提の正当化にある
今この分野で働くのは本当にひどい
私が勤める会社では、上司たちが開発者でない人まで全員にAIを使わせている
本当に辞めて別の分野で働きたいが、私の住む場所では初任給で家賃を払えず、年齢も上がってきている
AIの約束をドットコムブームと比較すると理解の助けになり、似ている点も多い
ただしインターネットは企業の立場から見るともっと単純な概念だった
基本的には、人々が自分のコンピュータで物を買えるようになったという意味だった
AIの約束とは何か? 物事についての推論を近似できるということか?
これは実際にはるかに難しい実装パズルだ
コーディング作業以外では、まだ実質的な何かを見たことがない気がする