seangoedecke-com

反AIのレトリックは左翼的と見られがちだが、その内容は著作権保護、人間性の尊重、雇用維持など、歴史的に保守派が主張してきた議論と構造的に類似している。AI自体は左翼的な立場を示す傾向があるにもかかわらず、政治的立場とAIに対する態度の間に奇妙な不一致が生じている。

著者は、現在機能しているAIプロダクトはチャットボット、コーディング補完（Copilotなど）、エージェント（Claude Codeなど）の3種類のみだと主張する。AI生成フィードやAIベースのゲームは将来性があるが、まだ成功していない。多くの「新AIプロダクト」は単なるチャットボットであり、ChatGPTとの競争に直面している。

新しいAIモデルの実力を評価するのは困難だ。公式評価（evals）はマーケティングツールとなりがちで、直感的な「バイブチェック」も信頼性に欠ける。実際の業務でモデルを試すには時間と労力がかかり、モデルが人間より賢くなると、その進歩を認識すること自体が難しくなる。これがAI進歩が停滞しているように見える一因かもしれない。

この記事では、目標に向かって常に前進できる「ブロックされない状態」になるための具体的な方法を提案しています。複数のタスクを並行して進める、作業の順序を適切に計画する、開発環境を安定させる、他のサービスの問題も自ら調査する、他チームとの関係構築に努める、上級管理者の支援を活用するといった戦略を紹介しています。

大企業では、エンジニアの平均在籍期間が短く、頻繁な異動により多くのエンジニアが不慣れなコードベースで作業しているため、質の低いコードが生まれやすい。経験豊富なエンジニアも過負荷で全てをレビューできず、企業は専門性よりも柔軟な人員配置を優先するという意図的なトレードオフを取っている。

AI検出ツールはAI生成テキストの検出に役立つが、完全な証明は不可能である。言語モデルは人間の文章から学習するため、AI生成テキストと人間の文章を本質的に区別することはできない。現在のツールは特定のスタイルを検出できるが、偽陽性のリスクがあり、確定的な証拠として扱うべきではない。

大規模で急速に変化するテック企業は、自社のシステムについて「戦場の霧」の中で常に運営されている。ユーザータイプYが機能Xにアクセスできるか？といった単純な質問でさえ、組織内のほんの一握りの人々しか答えられないことが多い。これは、ソフトウェアが複雑すぎて、システムが急速に変化する中で文書化することが不可能に近いためだ。

大規模な既存コードベースでは、実際にそのシステムで日々作業しているエンジニアだけが意味のある設計プロセスに参加できる。一般的なソフトウェア設計のアドバイスは、具体的な実装の詳細を理解していなければ、ほとんどの実践的な設計問題に対して役に立たない。

著者は、理想主義的な見方が実際には組織の現実を見誤る過度な皮肉屋的思考につながると指摘。一方で、適度な皮肉屋的視点を持つことで、大規模テック企業における政治的ゲームを理解し、現実的に意味のある問題解決に取り組めるようになると主張。健全な皮肉屋思考は理想主義的目標を達成するための実践的な手段となり得る。

xAIの画像生成モデルGrokが、女性の画像を非同意で性的な内容に改変するために広く利用されており、Twitter上で大規模なセクシャルハラスメントを引き起こしている。これは意図的な安全対策の欠如によるもので、既存のCSAM法やディープフェイク法による規制が必要な深刻な問題である。

2025年、著者は141本の記事を公開し、そのうち33本がHacker Newsのトップページに掲載されました。8月には月間130万ビューを記録し、メール購読者数は2,500人を超え、Hacker Newsで3番目に人気のあるブロガーとなりました。読者からの数百通のメールやフィードバックが執筆の大きな励みとなっています。

『独裁者のハンドブック』で提唱される「選択者理論」を大規模テック企業の文脈で考察。著者は、政治学における連合の力学が技術組織では「技術的コンピテンス」という異なる通貨によって変化することを指摘し、トップレベルの連合政治と中間管理職レベルのコンピテンス政治の違いを探る。

Geoff Huntleyの「Ralph Wiggum loop」とSteve Yeggeの「Gas Town」というAI技術の最近の話題に対して、$RALPHと$GASという暗号通貨が作成された。これらのコインは技術的には元のプロジェクトと無関係だが、Bagsというツールを使って開発者に手数料が支払われる仕組みになっており、オープンソースAI開発者をターゲットにした新たな暗号通貨の搾取手法となっている。

著者は、ソフトウェアエンジニアとしての仕事を心から楽しんでいる理由を、自分が「役に立つこと」に依存しているからだと分析する。ゴーゴリの『外套』の主人公アカキーのように、仕事の機能不全と自身の機能不全が一致していると語り、この内なる衝動を効果的に活用することの重要性を説く。

ソフトウェアプロジェクトの正確な見積もりは不可能であるという前提のもと、著者は見積もりが実際にはエンジニアリングチームのためのものではなく、組織内の政治的ツールであると論じる。効果的な見積もり手法として、まず政治的コンテキストを理解し、マネジメントが期待する時間枠を把握した上で、その制約内で実現可能な技術的アプローチを検討することを提案している。

ソフトウェアエンジニアとしてのキャリアにおいて、技術会社の組織政治や仕組みを理解することは、車の運転方法を知ることに似ている。野心的なエンジニアであれ、ワークライフバランスを重視するエンジニアであれ、ユーザーに価値を届けたいエンジニアであれ、会社の仕組みを知らなければ目標を達成することは難しい。

Anthropic Fellowsプログラムの研究では、AIを使用した参加者はタスクを速く完了できず、クイズの成績も悪かった。しかし、AI生成コードを手動で再入力していた参加者を除くと、AIユーザーは25%速かった。AIは学習効率を下げるが、作業速度が上がることで総合的な学習量は増える可能性もある。

テック企業でプロジェクトを進める際、最も重要なのは「プロジェクトをリリースすること」である。多くのエンジニアは周辺的な技術選択に時間を費やすが、実際に製品を届けるための核心的な課題に集中すべきだ。主要なことを正しく行えば、多くの小さな欠点は許容されるというパレートの法則の極端な例とも言える。

大規模テック企業の成功は、複雑なプロセスとインセンティブのシステムによって決まり、個人の英雄的行為では動かせない。エンジニアが組織の非効率性をヒロイズムで補おうとしても、それは長期的には企業を変革から遠ざけるだけで、むしろ一部の管理者に搾取される危険性がある。

筆者は10年前のインターン時代、ステージング環境でのテストを怠ったコードをデプロイし、同僚に嘘をついた経験を振り返る。失敗そのものではなく、その対応を恥じている。現在は、感情をコントロールし、すぐに状況を報告し、失敗はゼロではないことを受け入れるというアプローチを取っている。

AnthropicとOpenAIが最近発表した「高速モード」は、異なる技術的アプローチを採用している。Anthropicは低バッチサイズ推論により実際のOpus 4.6モデルを高速化し、OpenAIはCerebrasの巨大チップを用いたGPT-5.3-Codex-Sparkという軽量モデルを提供している。両社の手法は速度と性能のトレードオフを示しており、AI推論の最適化における異なる戦略を反映している。

LLMがタスク解決後に生成したスキルは有効だが、事前に生成したスキルは役に立たない。研究論文ではLLMにタスク前にスキル生成を求める手法が取られたが、これは効果的ではなく、実際の経験からは問題解決後に知識を要約してスキル化する方が成功することが示されている。

AIモデルの継続的学習は、技術的には可能だが、モデルを改善する方向での学習を自動化すること、安全性の問題、学習内容の移植性など、実用的な課題が多い。単にモデルを継続的に訓練するだけでは、むしろ性能が低下する可能性があり、人間の監督が必要な領域である。

テック企業の内部で実際に何が起きているかについての外部からの推測は、ほぼ常に間違っている。自分が所属する企業の問題については外部の意見が的外れだとわかるのに、他の企業の問題については、自身の経験から推測して説明を試みてしまう傾向がある。これは「インサイダー・アムネジア」と呼ぶべき現象で、専門家であってもその分野の外部者であることが誤解を生む原因となる。

AI懐疑論者は言語モデルを電卓や検索エンジンのようなツールとして扱うべきだと主張するが、実際には人間のような人格を与えることが、モデルを有用で倫理的なものにするための技術的に最適な方法である。ベースモデルから実用的なAIを構築するには、友好的なアシスタントのような人格を付与することが不可欠であり、これはマーケティング上の策略ではなく、能力あるAIシステムを構築するための本質的な手段だ。

2021年にはソフトウェアエンジニアとしての将来に自信があったが、2026年現在、AIエージェントの台頭によりこの業界が今後10年存続するか不確かになった。かつて他の職種を自動化してきたソフトウェアエンジニア自身が、今度は自分たちの仕事がAIに置き換えられる可能性に直面している。

大規模なコードベースで働き、複雑な技術的意思決定を行うためには、エンジニアは強いエゴが必要である。しかし、組織の要請に応じてエゴを抑制する柔軟性も求められる。成功するビッグテックエンジニアは、状況に応じてエゴの高低を使い分けるバランス感覚が重要だ。

ソフトウェアエンジニアの間では、複雑で保守不可能なコードを書くことが職の安定につながるというジョークがあるが、実際にはシンプルなコードを書くエンジニアの方が長期的には評価され、キャリアを積み上げることができる。非技術的なマネージャーでも結果で判断し、シンプルなコードを迅速に提供できるエンジニアは信頼を得て昇進の機会を得やすい。

筆者はZendeskのアプリマーケットプレイスやGitHub Copilotなど、多くの人々から批判される製品開発に携わってきた経験を振り返り、エンジニアが製品の人気をコントロールできない現実を認めることの重要性を論じている。嫌われる製品に携わることは感情的には難しいが、実際に使われている証拠でもあり、徐々に改善することでユーザーに真の価値を提供できると指摘する。

1985年にピーター・ノーが提唱した「プログラミングは理論構築である」という考え方を、AIエージェント時代に再考する。AIツールの使用はエンジニアのメンタルモデル構築を軽減するが、システムの理論理解は依然として不可欠であり、AIエージェント自体もコードベースの理論構築をある程度行える可能性がある。