AI時代における開発について
- 前提 - 2026/10/12 時点における自分なりの生成AIに対する考え方を記録
生成AIに対して否定的な自分だったが、そもそも底辺エンジニアの自分がAIに勝てるわけもなく頑なに「自分でやる！！」という考え自体が危険だと感じてきたことがきっかけ。
そもそも自分の力でコーディングする以前に要件を理解できていなければ、無駄な時間を費やしさらに生成AIよりも圧倒的に少ないコードしか組めない。
それなら、AIの効率的な使用方法を考えライブラリやフレームワークのようにAIを扱えばいいやと考えるようになった。
機能改修時における生成AI
# 概要
あなたは、○○ における ○○ リファクタリングのレビュー担当です。
コードを修正する前に以下調査と内容の整理をお願いします
# リファクタリング要件
- ここにリファクタリング要件
# 調査と整理
1. 現在の処理フローと各関数の役割
2. 今回の要件で修正が必要な個所
3. 変更により影響を受ける可能性がある機能やメソッド
4. リファクタリングに伴い必要な正常系・異常系・境界値のテストケース
5. 改修方法の候補と各影響リスク
6. 人間同士で確認すべき事項
# 制約
1. 既存コードにおいて事実と推測を混合させない
2. 影響範囲の根拠となるファイルやコードを提示する
3. 不必要なリファクタリングは提案しない
4. 許可なしにコードの変更を行わない
コードレビュー前セルフチェック
- リファクタリング箇所の理由が自分の口で説明できる
- 変更した処理が何を経由して呼び出されるか説明できる
- 変更前後における振る舞いの違いを説明できる
- 既存機能への影響範囲を説明できる
- 別の実装方法を採用しなかった理由を説明できる
GitHub プルリク依頼 テンプレ
# 概要
従来はデータ取得失敗時にも前回値をメトリクスとして公開していましたが、
監視側で最新値と誤認する可能性があるため、取得失敗時の公開方法を変更しました
# 変更内容
- メトリクス取得処理にエラーハンドリングを追加
- 取得失敗時に前回値を更新しないよう修正
- 取得成功・失敗を判別するステータスメトリクスを追加
- 上記の変更に対応する単体テストを追加
# 影響範囲
- XXXXXX
# テスト・動作確認
- [x] 正常取得時に正しいメトリクスが公開される
- [x] 取得失敗時にステータスメトリクスが失敗状態になる
- [x] 取得失敗後の復旧時に正常な値へ更新される
- [x] 既存単体テストがすべて成功する
# レビュー時の確認事項
- エラー発生時のメトリクス公開方法が監視要件に適しているか
- 既存の監視ルールへの影響に見落としがないか