はじめに
七尾百合子さん、お誕生日 78日目 おめでとうございます！ nikkieです。
TSKaigiの発表資料きっかけでここ数日考えていることです。
目次
まとめ
- 前提：AIにコーディングの運転席を譲った
- AIにとっては静的解析ツールのスピードが超重要（TSKaigi発表）
- TSKaigi発表をPythonで真似るため、Ruff + ast-grep の探究を始めた（が模索中）
TSKaigi 2025「AI Coding Agent Enablement in TypeScript」
#tskaigi のこちらの資料、めちゃめちゃ興味深かったです。
— nikkie(にっきー) / にっP (@ftnext) 2025年5月24日
TypeScriptは私馴染みが薄いんですが、arXivの論文数本出てきてそこら辺の話はTypeScriptよりも分かるので面白かったですし、TS以外にも当てはまりそうな戦略だと思いました。
UbieのVP of Technologyの方なのか〜 https://t.co/2TigfHgCxe
コーディングエージェントになるべく自律的に判断させるというトーク。
その方法の1つが静的解析
手順は3ステップ
- 気になった出力にフィードバック
- 詰める 「今の指摘を2度と繰り返さないようにESLintのカスタムルールを書いて」
- できあがり
この資料で一番印象的だったのは、高速にコーディングするエージェントにとって、静的解析ツールのスピードは大きなボトルネックになるということ
Ruffを使わざるをえないな
私たちは（個々人が望む望まざるにかかわらず）コーディングの運転席をAIに譲り渡したと私は考えています。
その前提からすると、この発表はTypeScriptに限らず、他の言語でも読み替えられる（むしろ読み替えていったほうがいい）と思いました。
Pythonの場合、コーディングエージェントのボトルネックとならない速い静的解析ツールは
- Ruff（リンター）
- ty（型チェッカ）
というAstral社製のOSSになるかなと思います
ここで私の中にはAstralに対する感情的なしこりがあります。
高速なツールを作るんだったら、互換性を保ったインターフェースで作ってよ（Faster Cpythonのように）
Ruffはflake8の代替としてもてはやされていますが、flake8にあるプラグインがRuffには（まだ）ありません。
プラグインサポートの点でflake8とは互換ではないという点で、Ruffにフルベットできずにいます。
ただコーディングエージェントが運転席に座る以上、Ruffが第1候補になるとも思います。
OpenAIのdeep researchを使って、Ruffのプラグインについて調査しました。
その結果、Ruffにないプラグインを他のツールで補完する方法を知りました。
ast-grep
ast-grepはRuffを補完するツールの1つとしてdeep researchから知りました。
期待して触ったのですが、私が試した一例ではOpenAI・Google・Anthropicのreasoningモデルはいずれもast-grepが書けませんでした。
発表のTypeScriptのESLintのようにはいかないようです。
(Ruff + ast-grep) x コーディングエージェントの方向性は模索中です。
deep researchはast-grep以外にもRuffを補完するツールを挙げていました。
- pylint
- flake8
これらから試したほうが、TSKaigi発表をPythonで真似るには早そうです
