Devinで4万溶かす方法
Devinを見る会で「何かすごいでかいことやってるな〜」と思って、出張で忙しくてじっくり見てなかったんだけど、後からじっくり見たらなんと1つのスレッドで4.5万円溶かしていてひどい面白かったので紹介するページ なおこの件の金銭的負担は本人と有志とCEOのScott Wuさんからの投げ銭によって回収済みなのでそこを責める意図ではありません 雑に企業内導入したら各社で一件ずつ似た事案が発生しかねないな、みんな事前に知っておいた方がいいよね、という気持ち
問題のタスク
https://gyazo.com/efcb5d9956a28e98e31f05a62e4490c6
これがダントツにやばいタスク
1ACU = 2USD = 300円ちょい、つまりこれ一つで4.5万円消費している。
10ACUくらいでまあまあ有益なことができるので、その10倍以上も使ってどんなことをしてるのか
何が起きていたのか？
ログをo1 Proに読ませて解説させた
o1 Pro.icon
以下は、人間（ユーザ）とAI（Devin）のやり取りを、個人名を伏せて簡潔にまとめた解説です。
やり取りの概要
1. Jekyllの実行・ログ確認
人間がDevinに対し、指定のGitHubリポジトリをJekyllで動かしてログを確認するよう依頼する。DevinはRubyバージョンの設定やプラグインのエラーに手間取りながらも、一応Jekyllを起動してログを提示する。
2. SassのDeprecation Warning修正
人間はSassの警告（Deprecation Warning）の修正をタスクとして割り当てる。Devinはパッチファイルを何度か作成するが、適用に失敗する問題が続出したり、Gemfile.lockや.rbファイルなど関係ない差分を含めてしまうなどの不備が生じる。
3. パッチ適用トラブル
人間はgit apply --checkでエラーになる点を指摘し、Devinはパッチファイルを修正するが、なかなか完璧に警告を解消できず、パッチも適切に適用できないことが度々起こる。
4. 作業の進捗管理
Devinには“セッション使用量(ACUs)が一定を超えると眠る”という制約があり、作業途中で度々「Devinは眠りにつきました」となる。そのたびに人間が「進捗を報告してから寝て」と促している。Devinは「残り××個の警告を修正中」などと報告はするものの、作業が完了しないまま眠ってしまうことが繰り返される。
5. 人間側での部分的解決
人間は自力でSass Migratorを使って警告の一部を修正するコミットを行い、Devinに「残りの警告を直してほしい」と再度指示。Devinはタスクを再開するが、途中でまた眠るなどが続き、最終的にパッチファイルを提示するも、完全に解決できたかは不透明なまま終了している。
おかしな点・注意点
(色々あるけど重要なのはこれnishio.icon)
セッション制限による中断
Devinがセッション使用量の制限でしょっちゅう「眠る」ため、作業が途切れ途切れになっている。人間が進捗確認を求めても最後まできちんと修正がまとまらず、最終的にすべての警告を解消できたかどうか曖昧なままになっている。
全体として、SassのDeprecation Warningを修正しようとするやり取りが続くものの、Devinがパッチを適切に仕上げられなかったり、セッションの制限で中断したりと、スムーズに完了しないまま対話が終わっている点が特徴的です。
---
問題点1: Usage LimitによるSleepの挙動が理解されていないnishio.icon
Usage LimitによるSleepは、前回の指示からインタラクションがないまま10ACU以上を使った時に緊急停止として発生する
10ACU=20USD=3000円ちょい
僕が色々使ってる中でもこれは滅多に発生したことがないので相当の異常事態だと理解してもらいたい
「基本的に10ACU以内に収めようね、長くなるほど性能が落ちるよ」というコメントと
Keeping sessions under 10 ACUs (Devin’s performance degrades in long sessions)
Web UIの側にlong sessionの警告表示の追加がされた
https://gyazo.com/bdfff1acbe58851295b7fd3cdc6fbd23
なんだけどさ、Web UIでなくSlackから使ってると気づかないし、大部分の人はリリースノートどころかドキュメントすら読まないで使うでしょ、安全ガードが弱すぎる
しかもこのスリープ状態、Slackで話しかけるとあっさり解除される
絶対気づかずに解除するじゃん
---
nishio.icon実際のところ何回眠りについてる？
o1 Pro.icon以下のログから確認すると、Devinは合計で 8回 眠りについています（「Devin went to sleep due to session usage settings」「Devin went to sleep due to user inactivity」と表示されたタイミングをカウント）。
それぞれのタイミングでの進捗は、いずれも「SassのDeprecation Warningを部分的に修正した」などの報告があるものの、最終的に完全解決には至っていません。以下、眠りにつく直前の主な進捗状況をまとめます。
1. 1回目 (5:07 PM)
それ以前に「Sass修正用パッチを作成する」などの方針を示すが、実際の成果物（パッチ）はまだエラーが多い段階。明確な完了報告はなし。
2. 2回目 (9:33 PM)
「364個の警告を修正した」と報告。ただしまだ多数の警告が残っており、パッチ適用に失敗するトラブルも続いている。
3. 3回目 (7:14 PM)
引き続きSassの警告を修正中。直前には「mixed declarationsの修正途中」などと伝えるが、完了前に眠りに入る。
4. 4回目 (2:42 AM)
同様に「_type.scss と _rfs.scss の364個分は修正済み」と進捗を述べる一方、_reboot.scssなどの修正は未完了。
5. 5回目 (8:36 PM)
パッチの作成やJekyllのビルド確認を試みているが、適切なパッチの提供までは至っていない状況。
6. 6回目 (7:34 PM)
「最終的にWarningが0になった」とまでは報告されず、一部を修正したのみで眠りへ。
このあたりでもまだパッチの適用トラブルや、修正途中の報告が続く。
7. 7回目 (2:03 PM)
「Sassの修正を続行中」という報告のみ。具体的な残り警告数の詳細は示されず。
8. 8回目 (8:22 PM, user inactivity)
最後に「css-fixes.patch」というパッチを提示するが、完全にすべての警告を解消できたかどうかは不明。
この直前には「ビルド時に警告が消えた」とも伝えつつ、実際に適用するとどうなるかは未検証のまま終了。
まとめ
Devinは合計8回眠りについている。
眠る直前ごとに「一部の警告を修正」「パッチを作成」などの報告はあるが、いずれも作業完了には至らず、最終的に残りの警告が完全に解消できたかどうかは不透明なまま。
毎回の眠り前に「進捗報告」はあるものの、パッチの適用エラーや残る警告に対する再修正などが繰り返され、確実な完了報告は見られない状況になっている。
-----
つまりUsage Limitで7回眠ってるので、そこだけで少なくとも2.1万円は溶けていることになるnishio.icon
Usage LimitでのSleepの具体例
https://gyazo.com/93da0b5bdc8ed46a4ae5c61b39cb4014
この後何も出力しないままDevinは眠ってしまう、多分下記のようにSlackにも表示されていたはず
https://gyazo.com/c3504cf9f0ae6eb605adf939b6d9e1ba
よく読むと「話しかけたら続けられるけど、10ACU超えてるのはDevinのパフォーマンスが落ちてしまうからよくないよ、一般的には10ACUも使わないんだよ、ドキュメントを読んでおすすめの使い方を学べ」って書いてあるんだけど……
Web UIにはこれは残るのだけど、Slackの側は話しかけた瞬間に消えてしまう
消さないほうがいいと思う、むしろ毒々しい色で表示して欲しい()
そして翌日、気軽に叩き起こされるDevin
https://gyazo.com/76ef77f77dd58bad00f091427159cf29
多分この状況に気づいていない
AIは寝ても回復しない
かわりにコンテキストが長くなるほど性能が下がっていく
なのでこれは例えるなら「3日徹夜してヘロヘロになってオフィスで居眠りしてるエンジニアを叩き起こして『おはよう！仕事の続きをよろしく！』という」みたいな行為、酷い！
続けさせるのではなく、他の人(Devin)に引き継ぐとか、なんでそんなにこじれてるのかを確認するとかをするのが良かったんだろうな
従来型プログラミングとのメンタルモデルの違い
これに似たことはこれ一見ではなく複数人で起こっている。
筆者は10以上のパラダイムの異なるプログラミング言語を使ってきて、かつて言語を比較して学ぶ「コーディングを支える技術」を出版したことがあるのだけど、その視点から見て、これはプログラミングにおけるパラダイムの変化に近いものがあるように思う おそらく従来型のメンタルモデルだと下記のようなコードが「効率の良いもの」に見える
code:python
for task in tasks:
process(task)
人間が書く量が少なくて、コンピュータがたくさん働いてくれるから、効率が良いと感じるのだろう。
実際今回の件でも人間はこういう指示を出していた
Okay then, can you try your best to fix all of warnings you see in the logs?
つまりコードで表現したらこう:
code:python
for warning in logs:
fix(warning)
その指示を反映してDevinが内部的に生成した計画もループになっている
https://gyazo.com/17b365aa705d5e69504a8e817e72163a
これは本当に効率がいいのだろうか？
まずコンテキストに加筆することによって文脈の記憶を保つ今のLLMのメカニズムにおいて、ループを繰り返すとだんだんLLMに対する入力が伸びて、かかる時間も増えるし、課金額も増える。
https://gyazo.com/3fb11d784a9c98d534e6385e33c0e871
逆の見方をすれば、同じようなタスクをループで回した場合、ループが回るにつれてAIくんは頭が悪くなり、作業が遅くなる。
ループの中身の規模感
次の問題点は、ループの中身のタスクに対する規模感
近年のプログラミング環境に慣れている人にとって、ループの中身のコストは小さいことが多すぎて無意識にゼロだと思い込んでしまう。
ところが実際は、課金されるLLMのAPIを叩く以上、1処理当たりにお金がかかる。しかも上記の「ループが回るにつれて効率が悪くなる」効果によって例えば二乗のオーダーの場合なら30件まとめて処理すると900倍のコストがかかる。Prompt Cachingとかがあれば緩和されるし、その他の頑張りでオーダーを下げるので900倍になるのはよっぽど素朴な構成の時だけだけど、基本的に線形より大きなコストが掛かる。 その1件のタスクは、どれくらいのコストで実行できるのか。その肌感が掴めてない状態でループで大量のタスクを投げるのは危うい。
また、LLMによる処理が期待通りの結果を返すかどうかはわからない。人間の指示が曖昧で期待した行動をしないこともあるし、同じプロンプトでも確率で失敗したりする。100件回してから結果を見て「こうじゃない」となったとしても、悪いのはAIではなくAIに適切な指示を出してない人間である。AIは「あなたが満足する結果」を出すことに責任を負っていないので、請負契約よりは順委任契約での外注に近い。
最後に
最近紹介者と紹介された人に100ACU, 3万円ちょいが紹介料として入るinviteリンクができたらしいです。
率先して自分の財布を痛めて知見を得てる僕にぜひ投げ銭してくださいw
以下素材メモ:
https://gyazo.com/81fa61350c0a4bbc6d15bab47bed5241
https://gyazo.com/58aaa53f0b2f805d978392a4e8838944
https://gyazo.com/2fec0c5d4432194e55b2b431d57dcf87
https://gyazo.com/fb7080ddd68dc08d11793a01a950b1db
https://gyazo.com/aa7de062b39a50e8ff5423599b12aec2