Zenn
Closed7

Devin sandbox

Devin
shin_t_o_shin_t_o_

Devin試行錯誤記録

有り難いことに会社で契約してもらったので使ってみている
メモ社内ドキュメントに後ほどまとめるためのもの

機能まとめ

Knowledge

登録： 会話中にDevin側から提案
更新： 登録時に内容編集 / 「Knowledge」メニューから登録や編集
利用： 登録後の会話

  • セッション中頻繁に「この知識を保存するか？」を聞かれる
    • 同じことを聞かれたくない場合は保存
    • 修正してから保存も可能（「このリポジトリに対してのみ」等）
  • 以後似たような工程を経るときに過去の知識として参照してくれる
    • しばしば無視される　参照度合いはまちまち

Playbooks

登録： 作業開始前に事前に登録
更新： 「Playbooks」メニューから登録や編集
利用： 新規セッション開始時に「テンプレ」として参照

  • テンプレ化して保存したいフローを文字化
    • claspによるGASの編集フロー（登録済）
    • GCPへのデプロイとか
    • GAS + VPNのフローとか
  • チーム内の共有に良い
    • うまくまとめればメンバー間の知識差分をいい感じに補完してくれる
    • 「作業始めるまでのセットアップがめんどい」系の儀式を覚えさせ代わりにやってもらう

登録： Devinと特定のリポジトリを紐づけたとき
更新： そのリポジトリに更新があったとき（自動）
利用： プロジェクトに対して質問したい／問い合わせたいとき

  • 読み込んだリポジトリをRAG = 参考文献として、自然言語で色々問い合わせが可能
  • エンジニア以外の人がそのサービス／アプリの仕様を（エンジニアではなく）Devinに問い合わせる、という運用も実例あり

Devin Wiki

登録： Devinと特定のリポジトリを紐づけたとき
更新： そのリポジトリに更新があったとき（自動）
利用： 「Devin Wiki」ページから常時閲覧可能

  • 読み込んだリポジトリに対して自動更新型のWikiを作成する
    • 変更に追随してインデックスを張り直してくれるっぽい
  • 現実的には「人間記載のドキュメント（実装背景や社内ナレッジなど）」「DevinによるWiki」の併用になる？という事例あり
shin_t_o_shin_t_o_

初期設定系

  • 指示可能場所
    • Slackから @Devin で開始
    • 招待済Googleアカウント経由でDevinログイン、セッション開始
    • VSCodeでアカウント連携後にVSCode内からセッション開始
  • 引き継ぎ可能場所
    • Devin GUI / VSCode は履歴が読み込み可能 = 作成済みセッションの読み込みが可能
    • slackは履歴が読み込めない = 投稿時点で新規セッション扱い、スレッド内が同一セッション扱い
      • 便利だがWeb GUIと独立しているので、チーム利用ならあんまり使い勝手良くない？

運用系

  • （アラートでも出るが）10ACU越えた辺りから精度下がる
    • 派生したPR, issueはセッションを変えて行ったほうが良い
    • 単一のタスクでも膨れたらSnapshot作成して引き継いだほうが良い
  • ムーブを指定する
    • 「設計モード」と「実装モード」を明確に区別させた方が良い
      • 望まぬ箇所でコード出力、望まぬ箇所で検討のみを行う、というケースが減る
  • 不明点を先に確認させる
    • LLM全般に言えること
    • LLM = 予測モデル、なので知識の欠損があれば予測しようとする = 嘘に繋がる
      • 「嘘をつかないで下さい」のような○○するな系よりも「不明点があったら確認して」のほうが守られやすい、らしい

権限系

  • 「別セッション」参照権限なし
    • 【要調査】何かやり方ある？
      -> スナップショット機能良さそう？
  • GitHub編集権限周り
    • Issue作成やPR作成は可能
    • SubIssue作成権限はない
    • Project編集権限はない
  • BitBucket連携
    • ベータ版として利用可能らしいがCSに連絡する必要あり 気付いたら対応してた
shin_t_o_shin_t_o_

プロジェクト区分に応じた始め方

新規プロジェクト作成時

  • Devinがそのままでは作業開始できない & 今後テンプレ化しそうなフローならKnowledge + Playbooksに登録しておくのが良い
    • ex) GASプロジェクトの設定やデプロイ方法など

Devin内の既存プロジェクト引き継ぎ

  • 「Devinが自律的に作業を進められる環境整備」への労力を惜しまない
    • ドキュメントの読み込み・更新・再作成
    • 要件定義を再度すり合わせ（50コミット程度の既存repoだったが2,3セッション使った）
  • Issueを作らせ優先度を確認して後は潰してもらう、など
  • 「前回のセッション参照」はsnapshotしかない？
    • sessionId参照不可だった
    • Devin APIを使っても属性情報しか取得できない
    • セッション終了時に都度スナップショット作るのもなんかなあ
      • 要件定義に使ったセッションのスナップショットを残し、以後関連作業はそのスナップショットから始めるのが現実的？（常にその作業の背景を参照できる状態）

Devin外の既存プロジェクト引き継ぎ

  • まずはプロジェクトをリポジトリに登録しDevinが読み込めるように
  • Devinが概要を把握できるようドキュメントを整備
    • かつ実装時にそれを参照するよう指示
  • 最低でもこれらが揃っていることが望ましい（個人的感覚）
    • 要件定義
    • 技術構成
    • 実装ゴール
      • 機能の追加、拡張
      • テストの追加
      • リファクタリング
      • …
    • ゴールを元にしたIssue群
  • Issueまで分割された状態で新規セッション ⇒ 「Issue #XX に取り組んで」「参考資料は…」から始められると手戻りが少ない
shin_t_o_shin_t_o_

迷走のトリガーとなりやすいもの

  • 10ACUを越えるやり取り
  • 会話への割り込み
    • 作業途中に割り込む（「その作業ストップ」など）と返答はするものの、作業が混在しがち
    • 更新したという報告／修正されていないPR などの混在状態になることがある
  • 「相談 OR 指示」を明示しても勝手に作業を始めがち
    • そして割り込むと停止報告をしながらPRを作成するとかいう事態に

方向修正どうするか問題

試行錯誤中 + 私見

  • 優先度高
    • 要件定義
    • CI/CD（lint, format, build, test）
    • テストの作成（以後自動化するにもサンプルは人間が作るべき？）
  • 優先度中
    • Issueの作成（要件定義が十分ならIssueを切るのは任せても良いか？）
    • リポジトリ内設定ファイルの作成（手札を最初に決めればそれが制約になる）

境界は人間が決めたほうが良い気がする

shin_t_o_shin_t_o_

失敗事例メモ

大きすぎる依頼は迷走しがち
Knowledgeに追記しても何度も無視する事象はどうしたら良いか

  • 修正によるPR乱立
    • Knowledgeにも追加済みなのに、何故か修正指示に対して別ブランチ／別PRを立てがち
  • CI頼みのPR
    • こちらもKnowledge追加済（まずはローカルで実行する）だが修正指示に対して「少し直したらすぐpush -> CI Failed -> 修正 -> …」のループに入りがち
  • テスト作成
    • 「要件 / 既存コード / 実装サンプル」くらいのインプットだと規模によっては迷走
      • APIを消費するテストを書いたり、「AIからのレスポンス文章」を一致テストさせようとしたり
  • カバレッジ向上
    • 依頼の動機が甘かったことが最大の敗因
      • 無限にCIに失敗して GitHub Actionsを消費
      • ファイルには XXX-minimal や XXX-minimal-final や XXX-final や XXX-final-clean が乱立
      • ブランチも -minimal だの -minimal-final だの出来上がる
    • 何のためにテストを実装するのか　目的に立ち返る
shin_t_o_shin_t_o_

行き詰まりメモ

他セッション参照どうする？

  • 現状参照元セッションで「スナップショット」を作成し、新規開始時に指定するしかない？
    • APIで取得できる他セッション情報に内容は含まれない
    • （当人は "セッションIDで取得できる" と言ってるがそんなことはなかった）
  • Claudeとかと同じでセッション最後に要約をまとめさせ、それを次回貼り付けるとか、、

ドキュメント参照どうする？

  • 基本的に定形フローはPlaybooksに乗せたい…が動的参照出来なそう
    • セッション途中で追加のPlaybooks名を指定しても参照してくれない
    • 最初から読み込むべきものはすべて指定するか、途中で内容をコピーして貼り付けるか
      • いけてなさすぎだけどほんとかこれ
  • 動的参照知識は基本的にKnowledge？そんなことある？
このスクラップは2ヶ月前にクローズされました