Devin は本当に“エンジニアの代わり”になれるのか？Hacobu の実践レビュー

ツール導入前の課題

事業の成長に対し、以下のような要因で開発速度が不足する可能性があることを懸念していた。

• 外部要因：　採用市場が激化しているため、人員確保がスムーズにいかない
• 内部要因：　事業の成長に合わせてコードの複雑性が高くなり、属人化や運用保守工数の増加等によって、結果的に開発スピードが鈍化する

どのような状態を目指していたか

• コードを AI が把握して、出した指示に対して「いい感じ」にコード実装を一貫して行う状態

改善したかった課題はどれくらい解決され、どのような成果が得られたか

• 課題①：人員確保がスムーズにいかない
  • 結果：　期待している水準とはならなかった
  • 理由：　Devin 一人でタスクを完走できないため
  • 継続課題：　Devin の特性を活かした開発フロー
• 課題②：　成長に伴い増加する運用保守工数の増加
  • 結果：　一次対応や実装計画作成等で一定の成果があった
  • 理由：　完全自立を諦めることで、0 -> 1 にかかる時間を短縮することができた。ログや具体的な事象、ルールなどがあると更に精度が利用可能な程度のものとなった。
  • 継続課題：　Devin 利用者による差異をなく扱えるように、プロセス構築が必要（再現性を出す）

• Devin とのコミュニケーション
  • 指示を守らないことも多々あり、特に「しないでほしいこと」の指示を正しく理解することに難があった印象
  • やりとりが長期化すると、先祖返りを起こすことも多々あり、更にコミュニケーションコストがかさんだ
• 人間にお願いする粒度のタスクだと、Devin 一人で完走できない
  • 既存の開発フローに乗せて、一人の自立できるエンジニアのようにタスクを依頼することができない
  • あくまでも「ジュニアエンジニア」として出来る範疇を具体的で適切な指示と共に渡す必要がある。