メタプロンプトを活用したDevin AIによる開発革命：PRマージ率9割以上を実現する高品質issue設計術
はじめに ソフトウェア開発の現場では、タスク管理とコード実装の間に常に「翻訳」の問題が存在しています。優れた開発者は明確な仕様から効率的にコードを生み出せますが、そもそも仕様自体が曖昧であれば、どれほど優秀なエンジニアでも迷走してしまいます。これはAIコーディングアシスタントであるDevinも例外ではありません。 本稿で紹介する手法は、メタプロンプト技術を活用した高品質なissue設計によって、Devinを使用したPRのマージ率を個人的観測平均の約50%から9割以上へと飛躍的に向上させることに成功した実践的アプローチです。適切なコンテキスト管理と構造化された要件定義により、AIとの協働効率を最大化する方法を解説します。 Cognition社が発表したバージョン2.1以降のDevinでは、このような課題に対して革新的なアプローチを導入しています。特に注目すべきは、LinearやJiraなどの
Devinのドキュメント和訳してみた【Creating Playbooks】編｜TOZUKA
Devinのドキュメントを和訳していきます！ 他のページも随時和訳していくのでお待ち下さい！ 和訳したページ👇️ 組織で再利用可能なプロンプトのライブラリを構築する プレイブックとはプレイブックは、繰り返し行うタスクのために、簡単に共有・再利用できる指示書です。 プレイブックは、繰り返し行うタスクのためのカスタムシステムプロンプトのようなものです。例えば、同じサードパーティライブラリをアプリケーションの異なる部分に統合する必要がある場合、プレイブックが役立ちます。 プレイブックは簡単に共有・再利用できるため、誰かがDevinで成功すれば、他の人も同じように成功しやすくなります！ ベストプラクティス、スタイルガイド、その他のプロジェクト固有の指示は、ナレッジを使用してDevinと共有することをお勧めします。どちらの方法がニーズに合っているかを理解するため、プレイブックを作成する前にナレッジ
ウチのDevinと会社のDevinのセキュリティ意識が違いすぎる - Devin観察日記｜Daiki Teramoto
今日は、僕が所属している株式会社HelpfeelにDevinを導入した時の話です。 そう、導入したんです、会社に。 昨年末からCTOに「Devinいいですよ」と言い続けたり、社内Devinルールを整備したり、プライバシーポリシーを精査したり、稟議を書いたり…といった地道な準備を進め、ついに契約することができました。 今は試用期間中のような位置付けで、一部のメンバーが、セキュリティ的に問題ないと判断した業務でのみDevinを利用し、その成果をもとに継続可否を議論していく予定です。 CTOと僕がDevinに熱を上げている様子はこちらのポッドキャストでもお聴きいただけますので、ぜひご視聴ください。 Spotify↓ 育ちの違い？会社の仕事をDevinに投げてみたところ、初めはとても賢かったのですが、なんというか、うちのDevinとは少し違う振る舞いが見られました。 GitHub Actionsか
Devinを開発チームと全社で使うには【主に使う機能とその運用について深掘り】 - クロスマート Tech Blog
はじめに 本記事では書かないこと（前提とする知識） 本記事で書くこと 対象読者 Devinがメンションされ出した組織に向けて Devinがあなたと同じだけの開発知識を得るために Devin Knowlege Playbooks Devinがあなたをどのようにサポートするか Devin Machine Devin Wiki Devin Search Interactive Planning Interactive Browser Jira Integration 開発組織で使いこなすために Devinに与えている権限 Devinへの仕事の頼み方 非エンジニアメンバーがDevinの恩恵を受けることができる未来のために 頼んでみたらSlackからDevin Searchを使えるようにしてくれた 社内のAIツール開発メンバーと協力し、Bizメンバーから容易に質問出来る環境を構築中 おわりに はじめ
Devinと3ヶ月協働して個人のアウトプットを1.5倍にした実践3ステップ - Findy Tech Blog
こんにちは、ファインディでソフトウェアエンジニアをしているnipe0324です。 先日、AWSさんのCoding Agent at Loft #2 〜 AI コーディング活用事例 Night - 効果的な組織導入と実践〜 (第2回目)で登壇させていただき、登壇内容を記事として書き起こしました。 この記事では、Devinと協働して「個人のアウトプットを1.5倍にした実践3ステップ」をご紹介します。 Devinと協働して個人のアウトプットは1.5倍に増加 2025年5月末時点では、Copilot Coding Agent、Codex、Jules などのリリースが続々とされており、自律型のコーディングエージェントが盛り上がってきています。 Devinに特化せず他のコーディングエージェントでも使える内容になっていますので、自律型のコーディングエージェントの利活用に興味ある方はご一読くださいませ。
Devin AIを育てるための効果的なTipsと2025年の最速AIコーディングのあり方
最近、Devin AIを契約したので、はじめて使う人や決済するか悩んでる人向けのTipsを書こうと思います。 契約する前は海外の悪評が目立っていたのでどうかな？と思っていたんですが、Ubieの鹿野さんの記事に触発されて、まずは試してみないとわからないかと思い決済しました。（円安で8万1千円ほどのでしたが、まぁマネージャーレイヤーだとありかなと思います。） いまは使い方に慣れてきて、毎日お話しています。継続してもいいかな？とも思っており、以下の点に気をつけて使っています。ほぼリモートエンジニアと仕事するときと一緒ですね。シェアしていきます。 段階的なオンボーディング 小さなタスクから始める 成功体験を積み重ねる 明確な振る舞いの指示 プロジェクト固有の規約を説明 期待する成果物の形式を具体的に示す *ちなみに、DevinのOSS版と言われるOpen Hands（旧Open Devin）も使っ
DevinのKnowledgeで共通ルールを整備する
前書き noteの記事投稿以降、Devinを利用した開発を続けています。 Devinと働く中で、いくつか気になる点が出てきました。 日本語での応答に固定するのが手間 GitHub上にDevinの作業ブランチが多数作成されてしまう 指示した箇所以外のプロジェクト全体を確認してからタスクに取り組んでほしい 等 これらの課題を解決し、出力をより安定させるために、DevinのKnowledgeを整備しました。 DevinのKnowledgeとは DevinのKnowledgeとは、Devinがあらゆるセッションで参照できる指示やアドバイスの集まりであり、組織・プロジェクトのコンテキストをDevinに教えるためのものです。 Knowledgeは、コードベースレベル（タスクレベルではない）のコンテキストを共有するのに最適な方法であり、例えば、コードの規約、デプロイのワークフロー、PRの命名規則、テスト
DevinのPlaybookとKnowledge、どう使い分ける？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Devinの能力を最大限に引き出すためには、PlaybookとKnowledgeという2つの重要な機能を理解し、使い分けることが不可欠です。 「毎回同じような指示を出すのが面倒...」 「プロジェクト固有のルールをDevinに覚えてほしい...」 こんな風に感じたことはありませんか？ 本記事では、Devinをまるで優秀な新メンバーのように育てるための「Playbook」と「Knowledge」の機能について解説し、その効果的な使い分けを具体的な利用シーンと共にまとめます。 Playbookとは？ - タスク自動化のための「レシ
Devinにドキュメントを生成してもらう実験 - Mitsuyuki.Shiiba
Devinにお願いしてソースコードからドキュメントを生成してもらえると面白そうなので実験してみた。Devin Wiki や Deep Wiki もあるんだけど、それとは別に自分で指示を出してコントロールできるのもいいかなという気持ち。 どうせ作るなら自分がドキュメントを読みたいやつがいいなぁと思って、ecspresso が好きだから、ecspressoのソースコードからドキュメントを生成してみることにした。 軽い気持ちでやってみたら、思ってたより苦戦した。すごくいい感じにできたわけじゃないので「この記事をめちゃ信じる！」んじゃなくて「へー、ちょっと参考にしとこっか」くらいが良いと思う。 勢いで書かないと書き終わらなさそうだったので、勢いでざーっと書いた。ので長い。 できあがったもの できあがったものを最初に書いておく。わりと気に入ってる。ただ、生成するたびに色々変わるので、雰囲気で参照する
外部仕様書の確認を Slack ワークフローに組み込むことで、 Devin くんにサポートしてもらってみた - KAKEHASHI Tech Blog
カケハシの AI 在庫管理でソフトウェアエンジニアをしている鳥海 (@toripeeeeee) です。こちらの記事は 生成AI研究会 での取り組み記事になります。 カケハシでは、エンジニア個々のコーディング支援に留まらず、AI技術を活用して開発プロセス全体の生産性と品質を向上させることを組織的な目標としています。そこで今回は、こちらの記事で紹介した Slack のワークフローに Devin を用いて開発プロセスにAIを載せることで、リリース前の外部仕様書のチェックをAIにサポートしてもらう取り組みにトライしましたので、ご紹介したいと思います。 なぜ外部仕様書のレビューが重要なのか そもそも外部仕様書って何？ ここで「外部仕様書」と呼んでいるのは、開発するシステムが外部からどのように見えるか、どのように動作するかを定義し、まとめています。具体的には、以下のような情報が含まれています。 機能の
新入社員のDevinと過ごす日々 - Repro Tech Blog
皆様こんにちは。Boosterの杉浦です。 Repro ではここのところ、各種 AI を活用して生産性を上げられないか、色々模索しているところです。 Devin も複数のチームで実験的に導入をはじめ、現状3か月ほどになりました。 Booster チームでは主に既存レポジトリのコードの改善、機能追加の目的で試しており、以下のような感触です。 人間のジュニアプログラマと比較して十分役に立ち、高速かつ大量に作業を行える プレーンテキストのドキュメントやリソースがすでにあるかが非常に重要 開発 - ビルド - テストのパイプラインが手元の VM/Docker ですべて完結するように整備されていると、作業のスピードもクオリティも上がる 実機が要る、などの場合は現実的に頼めることがあまりない ローカルでテストが回せないと途端にやり取りの手間が激増する テスト環境の整備自体を頼むこともできる 頼む側は、
Devindabot: Devinで実現するライブラリの脆弱性自動対応システム - freee Developers Hub
freee PSIRT( Product Security Incident Response Team ) のhikaeです。freeeでも自律型AI AgentのDevin*1を雇用しています。 今回はPSIRTの業務の一つである Dependabot対応におけるDevinの活用事例（Devindabot）… ライブラリの脆弱性対策にAIを活用して、開発ライフサイクル全体にいい影響が出た話 をご紹介します。 Dependabot対応 ... ライブラリの脆弱性対策 ライブラリアップデートの辛さ フローを見直し負担を下げる DependabotがPull Requestを作る流れ 1. GitHub Advisory Database · GitHub に脆弱性情報が追加される 2. Dependabotがリポジトリごとの依存グラフを定期的に更新する。もし脆弱性による影響がある場合はアラ
ZennチームにもDevinがジョインしました。そしてAIコーディング時代におけるエンジニアの役割について
@dyoshikawaです。 先月、社長にお願いしてZennチームに試験的にDevinを導入することができました。 導入して約1ヶ月ほど経ったので、Devin含むAIコーディングエージェントの活用や課題、そして生成AI時代におけるエンジニアの役割について思うところを書いてみようと思います。 Devinとは 自律性の高いAIコーディングエージェントです。Cognition社（Devin開発元）いわく「最初のAIソフトウェアエンジニア」。 AIモデルが独立した動作環境（Linuxサーバ）、コーディングエディタ（VSCode。拡張機能も入れられる）、ブラウザを持っており、それらを自由に操作する権限を与えられていることが新規性だと思っています。 かなり話題になっており、Zennにも毎日のようにDevinに関する記事が執筆されています。 Devinに懐疑的な見方もある （特に海外の一部ユーザーの間な
Devinにライブラリバージョンアップのリスク評価をやらせたらめっちゃよかった！
株式会社tacomsではAIツールの導入が積極的に進められており、Devinもそのひとつです。 tacomsでは以下のようなクイックスタートガイドラインが整備され、積極利用中です！ 今回はライブラリバージョンアップのリスク評価をDevinにしたところ、非常に精度がよかったのでご紹介させていただきます！ ライブラリバージョンアップのリスク評価とは 使っているフレームワークやライブラリなどのバージョンアップを行う際、破壊的変更が含まれていた場合、その機能に依存している機能で障害が発生する可能性があります。 ユニットテストを充実させている場合この変更に気づきやすくなりますが、ユニットテストでは十分にカバーできるかと言うとそうでもなかったりするところもあると思います。 そのためライブラリのバージョンを上げる際は、どのような変更が含まれるか確認しリスク評価をする必要があります。 ただこれはとても大変
Devinにコードレビューをさせ、コード品質と開発速度を同時に高める話
チューニング チューニングにあたっては、大きく以下の3点を重視しました。また、これらを管理するための「プロンプト」と「Knowledge」の使い分けも工夫しています（後述します）。 レビュー時のお作法を守らせる（AIは細かい作業に分解することが苦手な場合が多いため、ファイル単位でのチェックや処理の追い方といった手順をインプットしています） Railsアプリケーションにおける理想的な設計パターンをレビュー時に定着させる グロービス特有のドメイン知識・運用ルールを活用させる これらの観点で情報整理を行うことにより、「一般的に望ましい設計や実装方法」だけでなく、「自社特有の事情を反映した指摘」を自然に提示できるようになります。 また、知識の初期構築に多くの時間を割くことなく、実際に使いながらDevinにフィードバックを行い徐々に精度を高めていけるため、最初は小さく始めることを意識しました。 Kn
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
