はてなブックマーク

レビュー精度：対象PRへの指摘のうち、正しかった指摘割合の平均 再現率：Devinの良い指摘を再現した割合 レビュー内容の精度やコストから、予想以上にDevinのレビュー精度を上回っていることがわかります。 また、レビューの速度についても、Devinと同等 / ほとんどの場合、Devinよりも高速でした。（ローカル環境がそのまま使えるため、環境セットアップの時間が省略されているのもポイントですね） 定量その2 サイクルタイム レビュー精度という数値のみを追いかけてしまうと、「指摘は鋭いがレスポンスが遅い」といった数値ハック・局所最適に陥るリスクがあります。 開発フロー全体の健全性 を測るために、2 つ目の軸としてサイクルタイム という健康指標を導入しています。これから組織で展開する際に、精度にのみ注目し他を見落とすことがないよう、合わせて指標を追っていきます。 計測には technuma

この記事はCursor (with Gemini 2.5 Pro) に「読んでいて楽しくドキドキするように書いてください」とお願いして書いてもらった文章に、少しだけ手を加えたものです。そのためやや誇張された表現になっていますが、技術的な内容は事実に基づいています。 突然鳴り響いた警報 「おかしい。これはどう見てもおかしい」 ある朝、AWS BillingのCost Anomaly Detection機能から届いた通知を見て、私の顔から血の気が引きました。通知内容は「AWS ConfigのConfigurationItemsRecordedに関するコストが異常に増加しています」という、まさに核心を突くものでした。dev環境のコストグラフを見ると、AWS Config料金が突如として跳ね上がっていたのです。 before: Config料金は多くて$15/day、基本は$10未満/day af

チューニング チューニングにあたっては、大きく以下の3点を重視しました。また、これらを管理するための「プロンプト」と「Knowledge」の使い分けも工夫しています（後述します）。 レビュー時のお作法を守らせる（AIは細かい作業に分解することが苦手な場合が多いため、ファイル単位でのチェックや処理の追い方といった手順をインプットしています） Railsアプリケーションにおける理想的な設計パターンをレビュー時に定着させる グロービス特有のドメイン知識・運用ルールを活用させる これらの観点で情報整理を行うことにより、「一般的に望ましい設計や実装方法」だけでなく、「自社特有の事情を反映した指摘」を自然に提示できるようになります。 また、知識の初期構築に多くの時間を割くことなく、実際に使いながらDevinにフィードバックを行い徐々に精度を高めていけるため、最初は小さく始めることを意識しました。 Kn

はじめに 前回は Cursor の Project Rules 活用と改善 という記事を書かせていただきました。 今回は、私自身が普段実施している、より具体に迫った Cursor の活用方法をお伝えしようと思います。 私と私のチームのメンバーの一部が活用し始めた手法であり、すべてのPJでワークする確証はないため、ネタ枠の気持ちでお読みいただけると嬉しいです。 また、私が一から考案したものというよりは、X や Cursor の Forum で議論されていた内容を、抽象化し、実践に落としたものです。(※参考文献を参照) 私の関わっている中規模程度のプロジェクトにおいても、とりわけバックエンド開発（Rails + GraphQL）においては、今回の手法を使い、8~9割ほどのコードは Cursor で生成されたものを使うことができています。 手法の一つとして、参考になる部分があれば幸いです。 Cu

ちなみに来月は利用量がかなり増えそうな見込みがすでに立っており、Devinの上限を超えそうな状況に頭を抱えています。 定性面について（AIサマリー） おすすめの使い方 おすすめの使い方についてアンケート結果をAIサマリー丸っとかけた結果について以下に共有したいと思います。最初はSlackから呼び出す使い方が多かったですが、レビューに組み込むであったりPOやQAのみなさんが使い始めてから活用事例としては多く出てきた印象があります。 1. コードレビュー・PR関連の活用 DevinはコードレビューやPR作成で特に役立つとの意見が多く見られました。 「コードレビューでは特に効果を発揮している印象です。小規模なリファクタはスムーズに行えるため、かなりありがたいですね…！」 「PRレビューでは非常に有用だと感じています。確認すべき観点を knowledge に蓄積することで、確認漏れや同じミスを防げ

この記事はなに？ この記事では、現時点でのAIツールで確実に恩恵を受けるためには、 スコープを小さくすることで確実性を上げることが重要であるという考え方を紹介します。 扱わないもの ツールの機能説明、チャレンジングなハック的アプローチのAIに自由に編集・参照させている memories.md ファイルや大きなタスクの context を自然言語でまとめておく issues.md ファイルや.cursor/rulesをAIに自動で修正してもらうなど AI要約 丸投げせず、小さく刻むのがカギ！ 💡 3つのポイント 1️⃣ プロンプトを工夫 - 明確に指示するが、手間をかけすぎない！ 2️⃣ .cursor/rules でルールを設定 - 一貫性を保つ✨ 3️⃣ タスクを小さく分割 - 実装計画 → テスト → 実装 の3ステップ！ ツールの進化を見つつ、最適な使い方を模索しよう💡 自己紹介

1. Project Rules とは Cursor の Project Rules（v0.45~） は、Cursor Chat/Composer での対話において、必要なコンテキストを与えるための機能です Cursor > General > Project Rules から設定できます。 これまで、Cursor では Rules for AI, .cursorrules といったカスタムルールを用いて、プロンプトのコンテキストを与えていました。 Project Rules は、これらのカスタムルールに加え、より具体的かつ個別にコンテキストを与えることができる機能です。 もちろん、Rules for AI や .cursorrules を併用することも可能です。 各ルールの特徴 Rules for AI Cursor のアプリケーション自体に設定するカスタムルールです。 Cursor で

3行で できるだけ「文字列指定」ではなく「キー指定」を使いましょう where句にてテーブル名を指定するのは極力避けましょう activerecord-pretty-comparator gem を使うことで、文字列指定を使わざるを得なかった > もキー指定で書けます はじめに この記事では where('ends_at > ?', Time.current) のような書き方を「文字列指定」、 where(starts_at: ...Time.current) のような書き方を「キー指定」と呼びます 株式会社グロービスのslackにかみぽさんにJOINいただいており、不定期にRailsの困りごとを 壁打ち/相談 させていただいています この記事に出てくるコードは、実際のプロダクトコードをベースにしつつ問題を再現する最小のケースとして書いてみました Kaigi on RailsにCFP出した