Slop を作るな — Ara Khan (Cline) が示す AI エージェント成熟度の 4 段階 (AI Engineer Code Summit 2026)

AI Engineer Code Summit 2026 / 約 19 分

アラ・カーン / Ara Khan · 08:43 「Slop を作るな、頼むから。神に誓って、頼む。スループットは出せる、トークンも超高速で吐ける。でも本物のエンジニアとして学んだ一番の教訓は、アーキテクチャと設計を考える時間に投資する価値があるということ」

AI Engineer Code Summit 2026 (NYC、 Anthropic 主催、 2026 年 4 月下旬開催) における登壇。約 19 分。講師はアラ・カーン (Ara Khan、 Cline の創業エンジニア)。 Cline は VS Code 拡張として展開される coding agent (旧名 Claude Dev) で、 OSS かつ frontier model agnostic な設計が特徴。

Ara Khan が冒頭で持ち出す問題定義は「集団 psychosis」。周囲を見渡せば、ロボットの群れが軽やかにタスクを片付けているように見える、一方で自分は中央でフリーズしている。「15 体のエージェントを ripping させて vibing するべきか、それとも農民みたいに全行コードを読むべきか」 — FOMO がパニック発作に変わる現場が、そのまま AI Engineer Code Summit の会場に持ち込まれた。講演の狙いは「いったん深呼吸して、構造として整理し直そう」という減速の提案。

Khan の整理は 4 段階のエージェント成熟度モデル。 (1) 動くかどうかを確かめる段階 = framework を使う、 (2) 本気で取り組む段階 = state machine として自前で書く、 (3) UX の段階 = Kanban を form factor として採用する、 (4) スケールの段階 = cloud に出す。開発者が自分の必要に応じて上下にスライドして使うラフな heuristic として提示される。

4 段階のうち、 1 段目と 2 段目の境界線

Level 1 は framework の利用 — Langchain、 Langgraph 等。 Khan は「私は Cline で働いていて、エージェント体験を全部自分で書く立場だから framework アドバイスの最良の人選ではない」と前置きしつつ、 PMF を探す段階では framework が有効と認める。「メールを集約したい」程度のタスクなら、どの framework でも 30 分で wipe code できる。

Level 2 への境界は「本番に持っていく」瞬間に引かれる。「本気で何かを作りたいと思ったとき、 customizability も modularity も futuristicness も、 framework の中には見つからない」と Khan は断言する。「同意しない人が多いことは知っている、そしてその人たちは間違っている」 — 控えめさを脱ぎ捨てた論争的な提言。

自前で書くときの 5 つのルール

Level 2 = 自分でエージェントを書く段階で、 Khan は 5 つのルールを提示する。これが講演の中核。

(1) すべてのエージェントを state machine として考える

「 state machine は学部 2 年生のトピック」と Khan は軽くいなしつつ、これを最重要のメンタルモデルとして提示する。「どんなエージェントも結局は条件付きの while ループ。 Cursor だろうが Claude Code だろうが、数個の条件と数個の終了状態を持つ while ループに過ぎない」。

具体例として、ユーザーがファイル数本を読ませる指示を出した場合 — 上部の user task 状態から始まり、 read 状態に遷移し、 read tool が action として実行され、完了を認識して completion tool を呼んで task complete に到達する。単純な図ではあるが、これを 8 分でも 10 分でも、場合によっては数時間連続で回せる。「設計時に状態遷移を頭の中で描けるかどうか」が、後段の保守性を決める。

(2) 何かを足すたびにエージェントを悪化させるリスクを背負う

「これは最も苦い教訓だった」と Khan が語る原則。巨大な system prompt、大量の edge case 処理、凝った if-else logic — それらが frontier model のパフォーマンスを下げる。「frontier model は自分の仕事が極めて上手いので、指示が少ない方がパフォーマンスが上がる」。

象徴的な事例として、 codex リポジトリの GPT-5 用 prompt と GPT-5.3 用 prompt のサイズ比較を挙げる — 後者は前者の 1/3。新しいモデルは性能が上がりすぎて、長い system prompt は「sensory overload」となり、むしろ判断を狂わせる。道を譲って、モデルに任せる方が良い。 Khan の率いる Cline 自身も「全体を最初から書き直した、古いバージョンの junk が積もりすぎていたから」と言う。「Claude Code は少なくとも 7 回はゼロから書き直されたはず」という業界観測も差し挟まれる。

(3) エージェントを pseudo-RL pipeline の一部として組む

第 3 のルールは少し meta 的。エージェント開発に CLI を必ず付ける、という指針。「 pseudo-RL pipeline と私が呼ぶもの」 — エージェントを CLI で build/test 可能にしておくと、他の coding agent がそれを操作できるようになる。

ここで Khan が描く構図は印象的。「昔は人間が AI を導いていた、今は AI が人間を導く時代に向かっている」。だから人間は、 AI が扱いやすい形でエージェントを設計する必要がある — AGENTS.md を正しく書く、 skill を整える、 CI/CD を構築する。これらが揃えば、長時間動作する別エージェントを並列スレッドで走らせて、自分のエージェントを改修・テスト・end-to-end 確認まで任せられる。ここに到達するためには、まず自分のエージェントが build/test しやすい構造でなければならない。「再帰的だが、そこが要点」。

(4) Slop を作るな

ルール 4 は講演タイトルそのもの。「神に誓って、頼むから slop を作らないでくれ」。 Khan の言う slop とは、トークンを大量に流して何となく動くものを並べること。アーキテクチャと設計に時間を投資せず、別のモデルにコードを ripping させて済ませる姿勢。「我々が学んだのは、少なくともアーキテクチャは人間が thoughtful に決めるべき、ということ」。エージェントと対話しながら設計するのは構わない、ただし時間をかけて state machine を頭で描くこと。「他のモデルに rip させて終わり、にしない」。

(5) Frontier lab は開発者を lock down したがる

最も論争的なルール。 frontier lab の API は、切り替えのコストを上げて顧客を抱え込もうとする — Khan のテーゼ。

具体例は新世代モデルの reasoning trace 。 Opus 4.6、 Gemini 3.1 Pro、 5.3 Codex といった新モデルは、内部の reasoning trace を cache + test-time compute loop の一部に組み込む。多ターン会話では、 reasoning trace を「正確に期待される format で」送り返さないとパフォーマンスが degrade する — しかも degrade したことは表面上分からない。

「多くの人が新モデルの巨大な性能向上を取り逃している、単純に API を正確な形で使っていないせいで」。 OpenRouter のような中継経路を挙げる意見もあるが、 Khan の見立てでは「それだけでは不十分」。異なる frontier lab の API を切り替えて使うなら、「自分が API を本当に正しく使えているか、慎重に検証する」必要がある。互換性の幻想を信じてはいけない、というのが提言の輪郭。

Kanban テーゼ — 推論 bound 時代の UX 形式

Level 3 の form factor = UX の問題に Khan が当てる解は Kanban 。「2026/03/26 に私は Kanban を使うべきだとツイートした、そして 10 時間前に Claude Code が同じものを出してきた。だから私は正しかったはず」 — 自虐とも自信ともつかない口調で、講演の核心テーゼが提示される。

なぜ Kanban なのか。 Khan の論理はシンプル。エージェントを使う開発者は常に「推論 bound」 — 1 体の Codex や Opus が 8〜10 分回し続けている間、人間は doom scroll するか別のエージェントを起動するしかない。並列で 2〜3 体を同時に走らせれば、同じソースを mutate する衝突が発生する。だから state を isolate し、推論を並列で走らせるための form factor が要る。

Kanban カラムは「エンジニアリングマネージャーとしての一覧」を提供する。自分は manager、各エージェントは IC (individual contributor)。タスクの進行状況を見出しレベルで把握できる、「A と B が終わったら C」という flow も組める。単に綺麗な UI ではなく、推論並列時代のオフィスの間取り図。講演後の Q&A では「在チケット内での plan の往復」をどう扱うかが議論され、 Khan は「会話を経て brother, you can go on your own と言える瞬間に pull out して別のタスクへ」という運用を示した。

Cloud agents — スケールを引き受ける最終段

Level 4 は cloud。 8,000 人規模の会社で全員が個別マシンに複雑な環境を構築する jank を強いるのは無理がある — Khan の見立て。「一度大変な仕事をしたら、すべて cloud に乗せろ」。 cloud agent には 3 つの直接的な利点がある: (a) 並列化、 (b) 各エージェント専用のマシン、 (c) ローカル依存からの解放。

Khan 自身の使い方は具体的。「スマホから cloud agent に 15〜20 分のタスクを送る」 — 例えば「この VS Code 拡張をビルドして、ここでログインして、 settings をクリックしてテーマを切り替えて、ターミナルでテストして」という UX QA タスクを丸ごと投げる。 cloud agent は実際にクリックを実行し、機能しなければ反復する。 1 タスク 50〜60 分に達することもある。これを並列で大量に送って、ラップトップに戻ってきたら PR が並んでいる、という運用が成立する。

Khan の予測する未来像は明快。「エージェントを扱う UX のほとんどは Kanban になり、エージェント実行の計算のほとんどは cloud で起きる」。 4 段階の framework は単に分類ではなく、「どの問題を解いているかで上下にスライドして使う」ヒューリスティクスとして提示される。まずは bare minimum の easy thing から、必要に応じて段階を上げる。

着眼点

「Frontier 3 社の UI スクリーンショット、区別できない」 (01:32)

講演の冒頭、 Khan は会場に 3 つの UI スクリーンショットを見せる。「factory、 codex、 cursor のうち、誰もどれがどれか当てられないと保証する」。自分にも区別がつかない、と Khan は言う。 frontier lab 3 社の coding agent UI が見分けがつかないほど収斂している現象 — これが「集団 psychosis」の物理的な現れ。 Khan の 4 段階モデルは、この差別化不能な平地に対する個人レベルの設計指針として提示される。業界全体が一つの平面に押し込められたとき、個別開発者がどう自分の地形を作り直すか — その視点が講演全体を貫いている。

「3 月のツイートから 10 時間前まで」 — 予言の時系列

Khan は Kanban テーゼを 2026/03/26 にツイートで主張し、講演の 10 時間前に Claude Code が同じ機能を追加した、と語る。これは単なる自慢話としてではなく、「業界の form factor 収斂が予測可能になっている」という現象として読むべき。 frontier model の指示低減 (codex の prompt 1/3 化)、 reasoning trace の format 固定化、 Kanban の標準化 — 個別の事象が同じ方向に進む同時多発の現実を、 Khan は予言者の口調で記述している。同型化する現実の中で「予測精度」自体が個人ブランドの差別化要因になる。

「Frontier lab は開発者を lock down したがる」という独立 OSS の立場

ルール 5 の reasoning trace 仕様差の話は、 frontier model agnostic を掲げる Cline / OpenRouter / OSS coding agent harness 全体の立場から自然に出てくる主張。 Vincent Koc (OpenCode コアコントリビューター) も同様に「harness 側で frontier の挙動差を吸収する」立場を取る。 frontier lab 側 (Anthropic / OpenAI / Google) は当然「自社モデルが最適に動くのは自社 API のみ」という関係を作る経済的動機を持ち、 OSS harness 側はそれに抵抗する。 reasoning trace 仕様の API 表面化は、この対立が「分かりやすい lock-in」から「分かりにくい性能差」へ移行する分水嶺。 Khan の警告は技術というより、業界構造の見取り図として読み解く必要がある。

動画の構成

(00:00) オープニング、集団 psychosis = エージェントの FOMO 問題
(01:32) Frontier 3 社の UI が区別不能、同型化の現実
(02:18) 4 段階の framework 提示 (framework / state machine / Kanban / cloud)
(03:04) Level 1 = framework、 PMF 探索段階の選択肢
(03:50) Framework の限界、本番化には customizability が足りない
(04:35) Level 2 = 自前実装の 5 ルール導入
(04:35) ルール (1) state machine としてエージェントを捉える
(06:08) ルール (2) 何かを足すたびに悪化リスクを背負う、 codex prompt 1/3 化の事例
(06:56) Cline / Claude Code の複数回ゼロから書き直し
(06:56) ルール (3) pseudo-RL pipeline、 CLI と AGENTS.md
(08:43) ルール (4) Slop を作るな、アーキテクチャに時間を投資
(09:34) ルール (5) Frontier lab の lock-down、 reasoning trace 仕様差
(10:27) API asymmetry、 OpenRouter だけでは不十分
(11:13) Level 3 = Kanban テーゼ、 03/26 のツイート紹介
(11:59) 推論 bound、並列実行と state 隔離の必要性
(12:50) 「3/26 にツイート、 10 時間前に Claude Code が同じものを出した」
(13:06) Level 4 = cloud agents の導入
(13:53) 並列化、専用マシン、ローカル依存からの解放
(14:38) スマホから 15〜20 分タスクを送る、 UX QA を丸ごと cloud に投げる
(15:24) 共有 setup として cloud の利点
(16:09) 4 段階のヒューリスティクスとしての使い方、締めくくり
(17:12) Q&A — Kanban 内での plan 往復、 review state への遷移

編集所見 — MEMEX における Khan の位置づけ

MEMEX で Khan の講演を取り上げる理由は 3 つ。

(1) Tejas Kumar (IBM) の「harness 入門」や Anthropic Applied AI の long-running agent workshop が「frontier lab + 大企業 DevRel の視点」から harness を体系化したのに対し、 Khan は OSS coding agent 開発者の視点で同じ領域を再構築する。「framework は本番不向き、自前で state machine を書け」という Khan の主張は、 Tejas の「harness の 6 構成要素」と対立しているのではなく、 OSS 単独開発者にとって最も実装しやすい mental model として補完関係にある。

(2) Raindrop の Agent Observability 議論や Vincent Koc の Malleable Evals が示した「evals は live で進化させる」という方向と、 Khan の pseudo-RL pipeline 提言は同じ系譜にある。自分のエージェントを別のエージェントが build/test できる状態に保つ — これは「エージェントを書く人間」自身が「エージェントが扱える素材」に変身していくプロセス。 Karpathy の auto-research の延長線上で、評価系と開発系の境界が溶けていく現象として読める。

(3) Khan の 4 段階モデルは、 Namespace の Continuous Compute や Intercom の Claude Code 全社展開といった企業導入事例を、「成熟度の上下移動」として整理する枠組みを提供する。 Intercom が辿った道は L1 (framework 試行) → L2 (自前実装) → L4 (Claude Code 全社展開 = cloud agent 的運用) の経路として読み解ける。 Khan の framework は分類というより、個別組織の「現在地」と「次の一歩」を測る座標系として機能する。

出典

「Don't Build Slop: 4 Levels of AI Agent Maturity」 YouTube 検索 (AI Engineer 公式チャンネルでの動画 ID は別途確認予定)
Cline 公式
Cline GitHub

アラ・カーン

Ara Khan

Cline (旧 Claude Dev) 創業エンジニア / OSS coding agent 主要開発者

用語集

エージェント成熟度モデル (4 段階): Ara Khan が提示した枠組み。 (1) framework によるプロトタイプ、 (2) state machine による自前実装、 (3) Kanban による UX 統合、 (4) cloud agent によるスケール。開発者は自分の必要に応じて段階を上下にスライドして使うヒューリスティクスとして提示された。「分類」ではなく「座標系」として機能する設計。
pseudo-RL pipeline: Khan の造語。完全な強化学習ループではないが、それに準じる構造でエージェント開発を回す枠組み。自分が作っているエージェントに CLI を付け、別のコーディングエージェント (Claude Code、 Codex 等) がそれを build/test/修正できるようにしておく。これにより「長時間動く別エージェントが、並列スレッドで自分のエージェントを改修する」多層構造が成立する。
state machine モデル: Khan のルール 1。あらゆる AI エージェントを「条件付きの while ループ + 終了状態」として捉える視点。 Cursor / Claude Code / Cline どれも例外ではない。任意の時点で「今エージェントはどの状態にいるか」のメンタルモデルを持てると、設計と保守が圧倒的に楽になる。学部 2 年生の概念を agent 設計の中核に据え直す Khan の編集視点。
reasoning trace lock-in: Khan のルール 5 が指す現象。新世代 frontier model (Opus 4.6、 Gemini 3.1 Pro、 5.3 Codex) が出力する内部推論ログを次のターンで送り返す際、各 lab が要求する exact precise format が異なる。ずれると性能が degrade するが、表面的な error は出ないので気付きにくい。 OpenRouter 等の中継経路だけでは吸収しきれない、と Khan は警告する。「分かりやすい lock-in」から「分かりにくい性能差」への業界構造のシフト。
Kanban as agent UX: Khan の Level 3 テーゼ。推論 bound 時代 (1 体のエージェントが 8〜10 分動く) には、並列で複数体を走らせる必要があり、各エージェントの状態を見出しレベルで把握する form factor が要る。 Kanban カラム (To Do / In Progress / Review / Done) はこの用途に最適。開発者は「エンジニアリングマネージャー」、各エージェントは「IC」という関係を可視化する。 2026/03/26 の Khan のツイートから 10 時間前に Claude Code が同型機能を追加。
Cloud agent: Khan の Level 4。ローカル環境ではなく cloud 上にエージェントを置く運用形態。並列化、専用マシン割り当て、ローカル依存からの解放、 UX QA タスクの 50〜60 分単位の reliable な実行が可能。 Khan 自身はスマホから cloud agent に 15〜20 分タスクを送り、ラップトップに戻ってきたら PR が並んでいる、という運用を実践している。