10月21日、Latent Spaceが「AI for the Fortune 2000: How Tenex Builds an AI-Native SDLC」と題した記事を公開した。エンタープライズ向けにAIネイティブな開発プロセスを構築するTenexの組織設計・技術スタック・報酬モデルの実態を詳報した内容で、成果報酬型エンジニアリングという新興の業界トレンドを考えるうえでも示唆に富む。

「時間ではなく成果に払う」を75人規模で動かす

Tenexは、エンジニアの報酬を稼働時間ではなくストーリーポイント（完了したタスクの難易度・規模を数値化したアジャイル開発の指標）に連動させるというモデルで知られるAI開発会社だ。創業から18ヶ月で75名規模に成長し、顧客の50%はFortune 2000企業（米国売上上位2000社）、残り50%は年商1億〜5億ドル規模のミッドマーケット企業という構成になっている。

当初「AIを活用したdev shop（受託開発会社）」として出発したTenexだが、大企業顧客が増えるにつれて「AIエンジニアリングの外注」だけでなく「AI変革そのものの支援」を求める声が強くなったという。顧客企業のSDLC（Software Development Life Cycle：要件定義から設計・実装・テスト・運用までの開発ライフサイクル全体）にAIを組み込む支援へと、事業の重心がシフトしている。

懸念されていた「ストーリーポイントを水増しする」「粗悪なコードを大量に出荷する」といった問題は、実際にはほとんど発生していないとAlex Lieberman氏は語る。その理由はAIストラテジストの存在だ。顧客のリテンションと成長に報酬が連動するAIストラテジストが、エンジニアとは利害が対立する形でインセンティブ設計されており、価値のない作業への歯止めになっている。

一方で表面化した課題が別にある。コーディング以外の時間——アーキテクチャ設計、顧客ミーティング、問題定義——をどう評価するかだ。特に最近はモデルの能力向上に伴い、エンジニアがコードを直接書く時間は減り、「顧客の文脈をモデルが使える形に整える」作業の比重が増している。成果報酬モデルは、こうした「出荷物に直結しない作業」も包含できるよう進化させる必要が出てきた。

なお、成果報酬型のエンジニアリング組織というアプローチはTenexに限った話ではなく、近年の業界トレンドとして注目が集まっている。動画生成AIのPika、コーディングエージェントのAugment Code、AIコーディング支援のMagicといったプレイヤーも、それぞれの文脈でAIと人間の協働・成果ベースの開発モデルを模索しており、Tenexのケースはその中でも組織設計まで踏み込んだ先行事例として位置づけられる。

MetaHarness：コードと「なぜそう作ったか」を一緒にGit管理する

成果報酬モデルと並んでTenexの組織的競争力を支えているのが、独自開発の内製ツール群だ。その中核を成すMetaHarnessは、AIエージェントが長期タスクに戻ってきたとき「何が作られたか」だけでなく「なぜそう決めたか」を読めるようにする仕組みだ。

具体的には、計画・意思決定・受け入れ条件といったドキュメント群を、コードと並べてGitにチェックインする。エージェントはコードベースだけでなく、設計判断の経緯も参照できる。Linear（エンジニアリングチーム向けプロジェクト管理ツール）、GitHub、クライアント向けアップデートへのビューも統合されている。

出典: Tenex, Building an AI-Native SDLC

ポイントは「エージェントにコードを速く書かせる」ことと「周辺作業を機械可読にする」ことを区別している点だ。Tenex自身も認めているが、このレベルの構造化は小規模チームや単発プロジェクトにはオーバーキルになりうる。スケールする組織でAIエージェントを継続的に動かすことを前提とした設計であり、MetaHarnessはその文脈で初めて意味をなすツールだ。

組織モデルと内製ツールの両輪が整ったうえで、記事はさらに二つの論点——「既存SaaSはAIエージェントで代替できるか」「垂直特化AIは汎用モデルに飲み込まれるか」——へと議論を広げていく。

$43,000/年のSaaSをAIエージェントで置き換えられるか

記事中では、Latent Spaceが行った実験「Kill My SaaS」も取り上げられている。年間43,000ドルの見積もりが出たカンファレンス登壇者管理ツールを、AIエージェントで置き換えることを参加者に競わせた企画で、72件の応募があった。

興味深いのは結果の乖離だ。人間の審査員が選んだ優勝チームは、AIによる評価ランキングでは19位だった。「シナリオリストを満たすかどうか」と「人が実際に使いたいと思うか」は別の評価軸であることが浮き彫りになった。

Alex氏の反論も的確だ。大企業ほど既存システムの入れ替えはコストとリスクが大きく、小規模ツールであっても「誰かが保守し続けなければならない」という現実がある。これに対してLatent Spaceサイドの反論は「コスト削減だけが目的ではない。ベンダーのリリースサイクルを待たずに数分でイテレーションできる点に価値がある」というものだ。

この実験が示すのは、「置き換えられるか否か」という二項対立ではなく、「誰が保守コストを引き受けるか」「評価軸を誰が設定するか」という問いのほうが本質的だという点だ。エンタープライズ文脈でTenexが直面する現場の実感とも通底している。

垂直特化AIはいつ汎用モデルに飲み込まれるか

Alex氏はバーティカルAI（特定業界向けAI製品）に対して懐疑的な立場だ。エンタープライズが「自社専用の解」を求める以上、ソフトウェアのマージンでスケールさせるのは構造的に難しい、というのが論拠だ。

一方で反例として挙がるのがHarvey（法律特化）やOpenEvidence（医療特化）だ。ドメイン固有データ、専用インターフェース、既存ワークフローとの統合は、基盤モデルが共通化されても意味を持ち続けうる。比較対象として挙げられるのがBloombergターミナルで、「データ自体は他でも取れるが、データ・ワークフロー・コミュニケーション・習慣が一体になっている」点が競合優位の源泉とされる。

CJ Hess氏はより鋭い切り口を提示する。「エージェントがタスクを実行する」こと自体を主機能とする製品と、「そのタスクを取り巻くワークフロー全体を改善する」ツールは区別すべきだ、という視点だ。前者はエージェントの汎用化で代替される可能性が高く、後者は「人が実際に仕事をする場所」として定着しやすい。この区別は、MetaHarnessの設計思想とも対応している——Tenexが内製ツールでコードの高速生成ではなくワークフロー全体の構造化を優先しているのは、同じ問いへの一つの回答といえる。

詳細はAI for the Fortune 2000: How Tenex Builds an AI-Native SDLCを参照していただきたい。