🌐
Devinとのやり取りにSlackを使わなくなった
またもやDevinの話です。前回までの記事はこちら。
TL;DR
- ✅ Slack の通知や履歴が雑然としてSlack上でのDevinとのセッション体験が悪くなってきた。
- ✅ Slack の 4,000 字メッセージ制限がボトルネックになり、人間が長いコードブロックを共有しづらい。メッセージ分割でシンタックスハイライトが切れ、可読性が落ちる。
- ✅ Devin 公式 Web UI + GitHub(PR) コメントだけで十分ワークフローが回るようになった。
- ✅ “チャット” から “依頼 & レビュー” へ思考パターンが変わったので、アウトプットのイメージが付きやすく、タスク分割が楽になった。
- ❌ めちゃくちゃ疲れる。
1. そもそもなぜ Slack で始めたのか
運用初期では、Devin との対話を Slack 経由で行っていました。理由はシンプルで、
- UI 学習コストが 0 – みんな毎日開いている Slack に Devin がいてくれれば、導入ハードルがない。
- スレッドでトピックを分けられる – 人間同士の議論と同じようにでセッションを管理できる。
ところが、しばらく使ったところで次のような限界が見えてきました。
- 文字数制限 — 人間が貼り付けたい長いコードブロックや設定ファイルが 4,000 文字制限に阻まれ、メッセージを分割するとハイライトが途切れて読みにくい。
-
検索性の低下 — 1 つのチャンネルにセッションが溜まり PR レビューコメントまで流れてくると、
cmd+Kでも目的の発話を探しにくい。 - スレッドの深掘り地獄 — Devin が生成する長文ログがスレッドで入れ子になることで、ちょっと前のやりとりを確認したいときにスクロールが大変。
結論 : やりたいことがチャットの枠に収まらなくなり、“普段のコミュニケーションツール” と “開発用AIエージェント” を同じ箱に押し込むのは限界でした。
2. どのようにやり取りするようになったのか
2.1 Devin Web UI (web app)
- Devin の Chat + VSCode + ブラウザ が 1 タブにまとまっている。
- セッションの切替が容易。
- プロンプト履歴はセッション単位で自動保存され、期限も今のところ無し。
2.2 GitHub PR コメント
- Devin は自分の PR に付いたコメントを自動で拾って返信、作業を行ってくれる。
- 人間→AI→人間 の往復を GitHub だけ で完結でき、レビュー文化に溶け込みやすい。
3. 感じたメリット
| 観点 | Slack | Devin Web UI + GitHub |
|---|---|---|
| コード閲覧 | コードブロックのみ | VSCode で直接閲覧 & 編集 |
| PR 連携 | Bot を自作 | 標準機能で双方向 |
| コンテキスト制限 | 端っこが勝手に省略される | Devin のセッション length を超えない限りフル |
☑️ タスク分割が自然と細かく
Slack では「相談フェーズ」→「ひとまずやってみて」→「また相談」が 1 スレッドに混在していました。Web UI にして 1 セッション=1 タスク が視覚化されると、自然に粒度を意識 するようになり PR サイズも小さく安定するようになりました。
☑️ セッションの切替が容易になり、複数のDevinを同時に動かしやすくなった
気にならない人は気にならない部分であるとは思いますが、私はSlackのスレッドからのDevinへのアクセスだとどうしても人間とのやり取りが目に入り、Devinセッションを切り替える際のコンテキストスイッチが重くなりがちでした。
（当たり前ですが）Devinのセッションだけが表示されているUI上で作業を行うことで、セッション間の行き来が劇的に楽になりました。
4. まとめ
- Slack ありき でスタートしたものの、ワークフローが成熟すると Devin ネイティブ UI と GitHub だけでいい感じに完結する ことが分かりました。
- セッションを切り替えながら同時に複数のDevinを動かしていくと、脳の普段使っていない部分が刺激されるのか めちゃくちゃ疲れます が、これも筋トレ(脳トレ？)だと思い仕事に取り組んでいきます。
Discussion