LLMでできることやライブラリの実験のために作ってみて学んだことが結構あったので、まとめてみようと思います
動機
claude codeを使っていて、ちゃんとハーネスやloop engineeringを用意すれば、自分が承認ボタンを押すだけのことが多くなりました。また誤字修正など、簡単なものは検証も簡単なので一瞬で終わります。そこでふと考えたのが、linearからチケットが切られた時点でPRを自動作成できれば、ここら辺を全部自動化できるのではと思いました。もちろん既存ツールを使えばできますが、勉強のために自分で実装しようと思いました。
構成
フロー
ライブラリ
| ライブラリ | 役割 |
|---|---|
| mastra | LLMのフロー制御 |
| chat.sdk | slack bot作成 |
| claude sdk | coding用 |
| langfuse | プロンプト評価 + 管理 |
| fly.io | デプロイ兼sandbox代わり |
| nestjs | バックエンド |
簡単に組みたかった + typescriptで統一したかったので、一番慣れてるmastraを使いました。特にmastraはnestjsとデフォルトで繋げるので, 管理なども楽でした。
特に役に立ったのではchat.sdkです。起動すればslackからのwebhookのend pointを自動で作ってくれますし、memory stateで簡易的にchatの履歴を保持してくれます。このおかげでプロトタイピングで、いちいちredisなどを挟まなくて良くなりました。
LLM周りの実装
障害の情報の深掘り
シンプルな構成で,triage agentがlinearのチケットを切る前に、十分な情報を起票者に聞き返します。特に、再現条件や期待する動作などです。
ここで、LLMが十分な情報が揃ったと判断した時点でフローが次へ進み,linearにチケットが切られます。
現在進行形でいじってるのですが、この聞き返しのプロンプトが曲者で、深掘りすぎたり、情報が揃わないと判断したら強制的に終了させたり、まだいじっています。最近jevが出たので、それを使おうかと思案中
coding
linearのチケットが切られたら、webhookで受け取ってcodingを開始させます。
対象のrepositoryを事前に指定しておき、LLMが自分の判断でrepoをpullしてfly.ioの環境でclaude sdkを使って非対話形式でcodingします。
ここで重要なのは、コーディングルールやテストの書き方はrepositoryのclaude.mdやskillを参照することです。
なので、品質を保つ責務はrepository側が持っています。
repostioryにplanドキュメントを指定してればそれを守ってくれる
無限にcodingされたり、各タスクの独立性を保ちかったので、以下のように設定できるようにしてます。
プロンプト管理とeval
コード書いてて、途中でpromptの管理が面倒になったのでlang fuseへ移行しました。
promptとテストを同時に管理できるので、相当楽になりました。
その他の話
LLMの責務
今回LLMはタスクの分解とlinearのチケットの内容を生成するだけで、直接linearを叩いてないです。理由は、linearのチケットの削除など誤動作が怖かったのと、失敗した場合にバグ調査を簡単にするためです。実際にagentの責務が非常にシンプルになったので、切り分けが楽になりました。
エラー
バイブコーディングしてましたが、エラーハンドリングが結構抜けていて、テストした時に苦労しました。特にエラーが全て 情報が集まりませんでしたで統一されており、ターン数の上限に達したのか、実行時エラーになったのかがslack上で判別できず、原因調査にいらない時間を使ってしまいました。
最後に
今後もちまちまと改善していきたいなと思います。
最近だとsandboxのe2bや判断特化のjevなどあるので、色々いじりがいがあるなと感じています。
それでは良きLLMライフを