信頼が先、並列はその後：Lauren Tan の講演が語るメカニズム
Lauren Tan は X では @poteto、GitHub でも poteto だ。2026-09-21 に彼女はある投稿をした。元の投稿はこちら。投稿タイトルにある数字は 2,500 で、趣旨は「先月、2,500 本の PR を本番環境に出した」というものだ。この内容はもともと Cursor Compile London で話す予定だったが、のちに Grok @Bot Galaxy 向けのライブ配信に変わった。動画は約 38 分、2281 秒で、動画 id は 2101938030122868736。
口頭で語られた数字はこれとは違う。書き起こしは X の英語自動字幕によるもので、人手による校正は入っていない。字幕では、彼女は先月本番環境に約 2,000 本の pull request をマージしたと言っている。2,500 はあの投稿のタイトルだけのもの、約 2,000 はこの講演の自動字幕書き起こしだけのものだ。 両方の数字を残し、合算もしないし、一方を使ってもう一方を書き換えることもしない。
彼女の論点は狭い。スループットは信頼から生まれるのであって、agent を増やすことから生まれるのではない。ここでいう信頼とは、人が横にいないときでも agent が十分な品質の仕事を出してくることを指す。環境が整えば産出は上がり、個人やチームの「ソフトウェア工場」のようにも見えてくる。彼女はこの言葉を好まず、ミシュランの厨房にたとえるほうを選ぶ。流れ作業で複製するのではなく、最後に客席へ出すものには人が責任を持つ。agent が部品を引き受けた後に段取りすべきなのは、コンロの前に立つ人、道具、訓練、そして下ごしらえと調理の比率だ。講演の後半で、彼女は「ソフトウェア工場」という言葉に線を引いて消している。
自動字幕には聞き間違えた固有名詞がいくつもあり、本文ではそうした誤表記は使わない。アカウントは poteto、プラグインは PStack、フレームワークは Dune、プロダクトは Grok Bot、メモリ採取は heap snapshot、静的チェックは lint、レビューボットは Bugbot と表記する。
信頼がなければ、百の cloud agent はただのゴミを生む
講演の中で、彼女は起点を約半年前に置いている。Cursor に入ったばかりで、会社はまだ SpaceXAI に統合されていなかった。既製の agent skill（agent 向けに書かれた再利用可能なやり方）はなく、コードベースもプロダクトも彼女にとって新しかった。当時 Cursor は IDE の代わりになるもの、つまり新しい agents ウィンドウを作っていた。彼女が入る前から、このウィンドウには性能問題が山ほどあった。上司が彼女に助けを求めた理由は、Cursor に来る前に React チームにいたからだ。
性能の仕事なら経験があった。止められなかったのはマージの速度だ。pull request が壁のように次々と押し寄せ、アプリの性能が後退しているかどうかを判断できなかった。初期の時間はほとんど Chrome の開発者ツールに費やされた。パフォーマンスパネルを見て、trace を採り、heap snapshot を撮る。手作業すぎて自分でも嫌になった。すでに agent があるのに、なぜ人間がまだこのパネルの前に座っているのか。
そこで彼女は検証 skill を考え始めた。agent に自分でアプリを起動させ、自分で trace を採り、trace を読み解き、ホットスポットを見つけ、性能を引き上げさせる。この半年で自分の産出は上がったが、「月に約 2,000 本の PR」を目標にしたことは一度もないと彼女は言う。振り返ると、それらの skill、ツール、コードベースの変更はすべて同じ一点に積み上がっていた。信頼だ。当時のもっと率直な言い方はこうだった。自分がボトルネックになっている、エンジニアが知っていることをこの agent 群に渡さなければならない、そうすればすべてが自分のところで詰まることはなくなる。
公開されている経歴には、別途 2026 年 4 月に Cursor に入社したとある。講演の「約半年」もこの入社月も確認済みの資料から来ているが、本記事ではこれらを同じ一日に換算しないし、後述する「入社二日目に Cursor 3 を直していた」話をこの agents ウィンドウの話に混ぜることもしない。
彼女は始めた頃の働き方をこう描写する。同時に見ていられたのは 1 から 5 個の会話だけだった。どのチャットも見張っていなければならず、方向を絶えず修正する。人がいなければ、何も起きないか、agent が間違ったことをする。彼女はこの段階が一番抜け出しにくいと考えている。出口が見えないからだ。抜け出せないのは、agent が出してくるものをまだ信頼していないからだ。この段階でいきなり 100 個の sub-agent や cloud agent（クラウドで動かす agent）を立ち上げても、得られるのはゴミのような pull request、リグレッション、バグの山だ。誰も喜ばない。
だから問題は、あと何個開けるかではない。どうすれば見張るのをやめられるか、だ。
修正のたびに、まず最も強い層で受け止められるかを問う
agent を修正するとき、彼女は強いものから弱いものへ五つの層を並べる。この順序そのものが論点の一部だ。上の層ほど、ある一回の会話の中で agent や人がプロンプトの一節を読むのを覚えているかどうかに依存しなくなる。
モデルはコンテキストにすでにあるものを踏襲する。agent が読んだファイル、開いたファイルはコンテキストに入っている。agent は PR ごとに古いコードをリファクタリングしたりせず、そのまま続きを書く。だからリポジトリに残っている姿のほうが、チャットでの一回きりの修正よりも長持ちする。修正が会話の中だけにとどまれば、次のセッションからは見えない。修正が「この書き方はそもそも書けない」や「CI が落ちる」になれば、次のセッションも避けられない。
第一層はコードベースとアーキテクチャで、悪い書き方をカテゴリごと不可能にする。彼女はコードベースを agent の記憶とみなしている。既存のアンチパターンも記憶として扱われる。ちょっとした回避策や、その回避策を説明するコメントが、数日から数週間で事実上の標準的な書き方としてコピーされていく。彼女はこの拡散をウイルスにたとえ、庭に残しておくべきでない伸び方にもたとえる。コピーされてほしい状態は、次の agent にそのまま真似されても構わないと自分でも思える状態でなければならない。この層にはデータ構造ややり方の変更も含まれる。同じ間違いを毎回口頭で直すより、その間違いを書けないようにするほうがいい。チームが本当に、これからのコードの大半は agent が書くと信じているなら、これこそ最も投資に値するエンジニアリングであり、プロンプトを何本か書き足すことではない、と彼女は考えている。
第二層は静的解析で、lint、コンパイラ、CI だ。これらはリポジトリの中で強制できる制約だ。agent が同じ間違いを繰り返すなら lint を足せばいい。それでも、第一層に戻って間違いをカテゴリごと不可能にできればなお良い。技術的負債や悪いパターンを見たとき、彼女の最初の反応は lint を一本書くことだ。すぐに片付ける必要はない。まず止血して、それ以上広がらないようにし、それから時間をかけて agent に掃除させる。彼女は特定の linter や CI 製品の名前を挙げていない。この層にどこかのベンダーのツール名を補ってはいけない。
第三層はルール、Bugbot、skill だ。ここでは硬い制約から誘導に変わる。Bugbot のドキュメントはこちら。ルールや skill はたいてい使われるが、agent がルールを読み忘れることもあれば、agent を動かしている人がそれを無視することもある。だからこの層は重要だが、すでに強制されているものとして扱うことはできない。一度読み漏らせば、その制約はなかったのと同じだ。
第四層はスタイルガイドと人によるレビューだ。スタイルガイドがルールや Bugbot、skill に書き込まれていなければ、人がコードをレビューするときにしか効かない。人が一行ずつ読み、コメントを残すのを覚えていなければならない。PR の速度が上がれば、それは無理だ。彼女はスタイルガイドだけに頼ることを勧めない。人のレビューは何が欠けているかを見つけるのに向いており、そのうえで時間を上の層に投じるべきで、人のレビューそのものをスケールの手段とみなすべきではない。レビューコメントに同じ種類の指摘が繰り返し出てくるなら、それはまだ第四層にとどまっていて、アーキテクチャや lint、ルールに取り込まれていないということだ。
第五層は検証 skill だ。正しさは証明できるが、性能やコード品質を自動的に証明するわけではない。彼女にとっての正しさとは、その機能やそのコードが、やらせたかったことをやり遂げたかどうかだ。検証 skill は経験的な証拠を出せる。たとえば、ある経路が実際に最後まで通った、というように。その機能が速いかどうかも、コードがよく書けているかどうかも教えてはくれない。性能には別途メトリクスとテレメトリを採る必要がある。コード品質には別の種類の skill が要る。「動いた」と証明するだけでなく、エンジニアのやり方で仕事をするよう agent に教える skill だ。
スペクトルの反対側には形式手法がある。Lean や TLA+ を使えば、業務上の不変条件が常に成り立つか、アプリケーションが形式的に証明できる状態にあるかを検査できる。彼女自身はこの道を進んでいないと言う。形式手法は依然として難しく、依然として未解決の問題で、実際に検証 skill と組み合わせて使っている人はごく少ない。彼女の判断は、形式手法がなくても検証 skill でかなり遠くまで行ける、というものだ。これは境界線であって、「形式手法は役に立たない」という意味ではない。検証 skill が形式手法で証明すべき種類の不変条件までカバーしているとは、彼女は主張していない。
締めくくりとして、彼女は聴衆に修正の順序を覚えておくよう求めた。agent を追いかけて直している自分に気づいたら、最も効果的な一手を選ぶ。まずそのパターンをコードベース、アーキテクチャ、データ構造の上で不可能にする。できなければ静的解析を使う。そのうえでルール、Bugbot、skill を重ねる。品質寄りの skill には別に時間を割く必要がある。これらの層が積み重なって初めて、agent が自分で前に進めるだけの信頼が生まれる。これはコツではなく大量の仕事だと彼女は言う。人のレビューとスタイルガイドは欠けているところを見つけるため、検証 skill は正しさの証拠を得るためのものだ。どちらも第一層の代わりにしてはいけない。
Control Glass は社内の検証 skill にすぎない
Cursor に入り、agents ウィンドウの性能に取り組み始めたとき、彼女が最初に作った skill は Control Glass という名前だった。これは検証 skill だ。公開ページはない。 以下ではリンクを付けないし、照らし合わせて読める公開ドキュメントもない。リリース済みのプロダクトとして書いてはいけない。
これは agent にアプリの起動と trace の採取のやり方を教えるもので、Chrome DevTools Protocol を使う。構造は反復を経て初めて見えてきたもので、最初からこうだったわけではないと彼女は言う。検証 skill は二つの部分からなる。
一つは再現可能な CLI で、skill ディレクトリに置く。agent に毎回スクリプトをその場で書かせるのではない。セッションをまたぐとスクリプトはぶれ、同じ性能ラインでも違うものを測ってしまう。固定された CLI が、アプリの起動、trace と heap snapshot の収集、そして「コードが動いていて、性能ラインに達したか」の経験的証拠を担う。この部分はさまざまな使い方をカバーするために継続的な投資が必要で、一度デモして終わりではない。
もう一つを彼女は feature map と呼ぶ。リポジトリに書き込まれた機能の地図と考えればいい。名前は自分で付けたもので、サイトマップに近い発想だと言う。本質はディスクに書き残された記憶だ。アプリがどう動くか、どんな機能があるか、ユーザーがどうやってそこに辿り着くか、ショートカットキーは何か、どの DOM をクリックするか、各機能が何をするか。feature map はコードベースの skill ディレクトリに置かれ、一連の自動化によってメンテナンスされている。ここでの「自動化」は彼女がこの地図について述べた言い方であり、どこかの公開済みプロダクトの機能一覧として書いてはいけない。
どちらか一方だけでは足りない。社内の Slack にはとても曖昧な報告がよく来る。UI の一部を切り取った小さなスクリーンショットに、はてなマークが三つ。agent はアプリを起動できても、ユーザーがどこを指しているのかは推測するしかない。CLI に feature map が加わって初めて、agent はアプリを安定して操作し、trace を採り、社内外のユーザーの要望を読み解けるようになる。チームはすぐに、アプリを操作するこの種の検証 skill を、ずっとメンテナンスし続けるべき重要インフラとみなすようになったと彼女は言う。agent が自分の仕事を確かめられることは信頼のかなり実質的な部分であり、彼らはこの skill に多くの時間を費やした。
境界をはっきりさせておく。Control Glass が答えるのは「できたかどうか」と、性能サンプルが同じ方法で採れるかどうかだ。trace が採れることは、コード品質が合格していることを意味しないし、形式的な証明を済ませたことも意味しない。外部の人がインストールできるドキュメント付きのパッケージでもない。同種のものを作りたいなら、再現可能な CLI を自分で用意し、機能への辿り着き方を skill ディレクトリに書き込む必要がある。存在しない公開ページを探しに行くのではない。
Dune は近道を唯一の正しい道にする
Grok Bot のコードベースで、彼らは Dune と呼ぶクライアントフレームワークを作った。agent が書いても道を外れにくくするのが狙いだ。Dune には公開ページがない。 ドキュメントサイトのあるプロダクトとして書いてはいけないし、ここにもリンクは置かない。
直接のきっかけは Cursor の agents ウィンドウの性能問題で、やり方の多くはそこから持ち込まれた。彼女が定めた原則はこうだ。agent は近道が好きだ。ならば近道を正しい道にしてしまえばいい。そういうコードベースは人間にとっては煩わしく、できることとできないことがきつく縛られている。それがまさに agent に、特にコンテキストの少ない agent に向いていると彼女は考える。これからリポジトリに変更を出すのはエンジニアだけではない。デザイナー、プロダクト担当、CEO のように多忙でコンテキストの少ない人も、機能を作りに入ってくる。最初から正しくできるようになっていることのほうが、彼らがまずスタイルガイドを読み終えてくれると期待するより頼りになる。
コードベースは記憶であり、その逆も成り立つ。アンチパターンは勝手に育つ。彼女が目指すのは、人間が書くには窮屈なほど縛られていながら、一見無害なパターンさえ残らないほど約束事が強い状態だ。彼女が挙げた例はコメントだ。最初は agent がコメントを残すことが必ずしも悪いとは思っていなかった。人間もエッジケースや回避策の横に同僚へのメモを残す。ところが Cursor のコードベースで、agent がコメントを本当の問題を直さない言い訳にし、短期的な手当てでバグを取り繕うのを目にした。そこで Grok Bot 向けの Dune ではコメントを禁止し、この書き方がリポジトリ全体にコピーされるのを防いだ。コメントは「人に向けた説明」から「次の agent にとっての悪い手本」に変わっていたのだ。
彼女はこの役割に庭師という名前を付けた。リポジトリは庭のように望まないものを生やすので、広がる前に摘み取らなければならない。園芸のことは分からないと彼女は言い、比喩はそこで止まる。誰かが専任で、何がコードベースに入り込んでいるかを見ていなければならない。Dune の背後で彼女が強調するのは三つだ。既存の技術的負債は削除する。agent がコピーするからだ。奨励すべきパターンの大半には舗装された道を一本だけ残し、agent に推測させない。コードベース、CI、lint に十分な誘導を入れて、agent をその道へ追い込む。技術的負債や悪いパターンを見たら、反射的に lint を書く。まず止血し、それから agent に古いものを掃除させて、リポジトリを「コピーされても構わない」状態に保つ。
彼女は Dune の構成を一つずつ説明したわけではなく、Cursor の agent ウィンドウから学び、アーキテクチャの中で消した性能問題を一つだけ例に挙げた。Electron のメインプロセスで動くものは renderer に入ってはいけない。ウィンドウ側では、コードが誤って renderer にインポートされ、遅いコードが一緒に入り込んだことがあった。renderer は UI を滑らかに保つ必要があり、フレーム予算を超える長いタスクを抱えられない。毎秒 60 フレームならおよそ 16 ミリ秒、毎秒 120 フレームならおよそ 8 ミリ秒だ。仕事は分割しなければならず、一か所に積み上げてはいけない。Dune はインポートの依存グラフでこの境界を固定し、この種の誤インポートをカテゴリごと不可能にした。個々の例は重要ではないと彼女は言う。重要なのは、自分たちのフレームワークで、シニアエンジニアの経験をスタイルガイドやレビューコメントから取り出し、コードベースに書き込めることだ。するとコードベースは、agent に延長してほしい、すでに書き残された状態になる。次にやって来る agent は、古いコメントから回避策を学ぶのではなく、その状態を保ち続ける可能性が高くなる。
Grok Bot 側では、彼女はリポジトリを悪いコードがほとんど書けないところまで縛り込んでいる。コンテキストが少なく推論も強くない agent が入ってきても、まずまずのコードを書ける可能性がある。それは道が狭められたからであって、会話を増やしたからではない。
外側のループはツールをつなぐことであり、会社の頭脳を作ることではない
講演の後半で、彼女は Grok Bot と Cursor を別々の位置に置いた。Grok Bot が得意なのは、彼女の言う外側のループだ。さまざまなコネクタにつなぎ、情報を集約し、判断に使う。例として挙がったのは Slack、Datadog、Sentry、PlanetScale、そしてあなたが使っているサービスだ。これは例であって、固定の連携リストではない。 四つの名前を揃ったセットとして書いてはいけないし、彼女が言っていないツールを補ってもいけない。
こうしたつなぎ方を会社の頭脳（company brain）と呼ぶ人もいる。彼女は凝った版のそれを受け入れない。agent はもともとツールを使うのが得意なので、そこまで複雑にする必要はないと考えている。ツールを Grok Bot につなぎ、それに cloud agent を自動で起動させるのに、まず大がかりなインフラを作る必要はない。彼女は再び「ソフトウェア工場」を消し、Grok Bot を使って自分のためにあの厨房を作ればいいと言い直した。routine（購読や条件に応じてタスクを自動で起動する仕組み）を使えば、Slack のスレッドや Sentry のアラートを購読し、自動で作業を始められる。公開されている説明は Grok Bot の概要と、skill、routine、自動化にある。
これらは前述の層の上に積み重ねるもので、別のシステムを立ち上げるわけではない。コードベース、ルール、skill が先にあって初めて、Grok Bot は外側のループから来るイベントに反応し、cloud agent を起動できる。Cursor 側では、automations と TypeScript SDK を使ってさらに bot を作り、すでに敷いた agent インフラを再利用して、より複雑なタスクをこなすこともできる。配信では Cursor 上の自動化のスクリーンショットをいくつか見せた。バグ報告を自動で再現し、pull request を自動で開くものだ。彼女の言い方では、これらを積み重ねることでチーム全体の使える産出が増える。ここに独立した第三者による産出量の数字はない。スクリーンショットは彼女のデモであって、監査済みのレポートではない。
Cloud Agents と agents ウィンドウ は公開されているプロダクトの入口だ。これらは「信頼がないまま並列にする」問題を解決しない。外側のループがまだ縛られていないリポジトリの上で動けば、自動化はゴミの PR を増幅する。まず第一層から第三層を整え、それからアラートの購読や PR の自動作成を考える。
PStack は、彼女が誘導の層に置く種類のエンジニアリング playbook だ。講演では、今日はこのプラグインについて多くは話さないとわざわざ断っていた。これは彼女が作った Cursor プラグインで、一連の skill からなり、彼女自身がデバッグ、機能開発、プロトタイピングをするときのやり方から来ている。公開ページは Cursor のプラグインマーケットプレイス、ガイドはプラグインリポジトリ内の説明にある。入口は /poteto-mode だ。使い方としては、まず /setup-pstack でモデルを選び、それから /poteto-mode に入る。これは自分が Cursor で毎日使っている skill で、目指すのは少なく書いて正しく書くことであって、行数を積み上げることではないと彼女は言う。より経験のあるエンジニアは、この種の skill をチームのリポジトリにまとめ、agent に自分たちの望むやり方で書かせることができる。検証 skill にこうしたワークフローが加わって初めて、agent は正しくできたことを証明するだけでなく、品質に手が届く可能性が出てくる。性能の数字は依然として、あの再現可能なサンプリングの経路で採らなければならず、playbook の名前で得られるものではない。
agent を作る人が持ち帰れる順序と、彼女が言っていないこと
修正をどの層に置くかは、先月何本の PR をマージしたかより先に見る価値がある。人がまだ 1 から 5 個の会話にとどまっているうちは、並列化を進歩とみなさないほうがいい。同じ間違いをチャットの中でしか直していなければ、次のセッションでまた起きる。人のレビューで同じ種類の指摘が繰り返し出るなら、それはまだアーキテクチャ、lint、ルールになっていない。誘導の層はデフォルトで読み飛ばされると考えるべきで、唯一の関門にはできない。
彼女が言っていないことは、別に帳簿に残しておくべきだ。検証 skill が提供するのは正しさの経験的証拠だけで、性能指標の代わりにはならないし、Lean や TLA+ で証明すべき不変条件の代わりにもならない。彼女自身は形式手法の道を進んでいない。Control Glass にも Dune にも公開ページはなく、本記事はそれらにリンクを補わない。Slack、Datadog、Sentry、PlanetScale は例であって固定のリストではない。彼女は凝った会社の頭脳をまず作ることを主張していない。投稿タイトルの 2,500 と口頭の約 2,000 は出どころが違う。講演の中で彼女は、約 2,000 本の PR は自分が設定した目標ではないとはっきり述べている。百の cloud agent は信頼がないときの反例であって、推奨構成ではない。外側のループが産出を増やすのは、リポジトリがすでにコピーされる価値のある状態にあるときだけで、そうでなければゴミの PR を自動で増幅しているにすぎない。
この方法はどの確認済みの経歴から生まれたのか
公開資料で裏付けられる経路はこうだ。フロントエンドと型システムの出身で、Netflix ではコンテンツスタジオ向けのツールを作り、Meta では React のコンパイラを作り、いまは「agent に自分で検証させる」ことを Cursor と Grok Bot で実践している。所在地は本人が記載している南カリフォルニア。近況は LinkedIn を参照。旧サイト no.lol は Facebook 時代と Netflix 以前の紹介のままで、すでに古くなっており、現職として読んではいけない。
彼女は独学でキャリアを転じた。最初は UI デザインをしていて、やがて自分のデザインを動くインターフェースにするようになった。about.me には金融分野の学位があり、ロンドン・スクール・オブ・エコノミクスとモナッシュ大学で学んだとある。そのページは彼女がまだ Meta でエンジニアリングマネージャーをしていた頃のままだ。
2014 年から 2016 年のブログはほぼすべて Ember.js についてで、当時は DockYard にいた。GitHub アカウントは 2012 年からある。リポジトリの中で最も有名なのは hiring-without-whiteboards だ。
Netflix 時代はエンジニアリングマネージャーとして Studio UI を担当していた。企画の pitch から公開までを扱うコンテンツ制作ツールだ。それ以前には、オリジナル作品の編成を担う Studio Programming を率いていた。旧サイトには三つの講演が残っている。2018 年 RubyConf の Building the World’s Largest Studio、2019 年 TSConf の Just Use Any、2019 年 Netflix UI の Ambitious UIs for Pitch to Play だ。最後の講演の技術スタックは React、TypeScript、GraphQL だった。これらのページが示すのは当時どんなツールを作っていたかであって、現在の肩書きではない。
Meta には約六年在籍し、2026 年 3 月中旬に離れた。2026-04-07 の LinkedIn 投稿には、離れて約三週間と書かれている。React 組織での仕事として公開の紹介が挙げているのは、Server Components のプロトタイプ、Relay のコンパイラとランタイム、React 18、React Compiler、useEffectEvent、クロスプラットフォーム React で、のちには組織の AI 戦略にも関わった。React Conf 2021 の紹介ページには、当時彼女は React のエンジニアリングマネージャーで、マネジメントに移る前は Meta で Server Components のプロトタイプを率いていたとある。ページはこちら。
同じ LinkedIn の自己紹介によれば、彼女はのちに個人貢献者として React Compiler を書き直した。文単位の解析から、独自の制御フローグラフ（CFG）に基づく式単位の解析へ移行したという。SSA、hoisting、validation、eslint-plugin-react-compiler、実験的な compiler LSP に触れ、オープンソース化も担当したと書いている。この部分は本人の自己申告だ。そこにある高速化の数字は、本記事では独自に検証していない。 彼女は、Instagram Web、Threads、Quest Store、Facebook.com で導入した後、インタラクションが 2.5 倍速くなり、読み込みとナビゲーションが 12% 速くなり、メモリは増えなかったと書いている。React の CI を CircleCI から GitHub Actions に移し、より安く、50% 以上速くなったとも述べている。2.5 倍、12%、メモリ増なし、50% 以上は、いずれもこの LinkedIn の自己申告にしか出てこない数字で、この講演で語られたものでも、第三者による測定でもない。引用するときは必ず「本人がそう書いているだけで、独自には検証されていない」と添えなければならず、実証済みのプロダクト成果として書いてはいけない。
2026 年 4 月、彼女は Cursor に入った。彼女の投稿によれば、入社二日目にはもう Cursor 3 クライアントの性能を直していた。agent に自分でアプリを動かし、profile を取り、trace を採らせ、そのメトリクスをたどってメモリリークとレンダリングに対処した。講演のほうでは、agents ウィンドウでの Chrome 性能作業として、まず手作業でやり、それを検証 skill にまとめた話になっている。どちらも彼女自身の語りだ。本記事ではこれらを同じ一つの変更としてまとめないし、対応する PR 番号を補うこともしない。5 月に彼女は PStack をオープンソース化した。彼女の投稿によれば、その週にエンジニアリングチームはこれらの skill を約 1 万回使った。この 1 万回も彼女の言い分であり、独立した集計ではない。Cursor が SpaceXAI に統合された後、彼女の肩書きは Grok Bot at SpaceXAI になった。現在の公開プロフィールでは、SpaceXAI で Grok Bot と Cursor に携わりつつ、React Compiler のコアチームにも属している。
講演と噛み合うのは、同じ一つのことの両端だ。コンパイラと性能の出身であること、そして Cursor で手作業の trace や heap snapshot を検証 skill にまとめ、さらにコピーされるべきでないパターンをリポジトリの硬い制約に変えたこと。投稿の 2,500 も口頭の約 2,000 も、この道のりを歩き終えた後に書き留められた数字であって、方法そのものではない。講演の最後に彼女が残した連絡先は、X の poteto だ。