AIを使う人の課題
AIに任せた開発を、どう確かめて出荷するか
AIで実装を進める開発者、複数AIを使う運用者、検証ツールの作り手
公開PRに修正記録・全体効果は未確認
7〜10月の投稿・更新資料と、公表日が不明な運用記録。公開・更新・経験の時期を分けて示します。
編集確認：2026-10-23
関心が向いていること
AIへの分担や要望からの実装が進む一方、使い込む開発者は、レビューと実際の動作確認にも仕組みを作っています。
困っていること
実装を終えても、元の要件や故障時の振る舞いの確認が残ります。編集した範囲と関連テストがつながらず、確認が遅いという要望もあります。
試されている対処
別モデルのレビュー、実行probeとコード解析、人のプレビュー確認を組み合わせています。編集後と停止時のフックで関連テストにつなぐ案も提示されています。
結果として確認できたこと
DoltLiteの公開PRでは修正とテスト追加を確認。初期に実行できなかったnative経路にも保守者が検証を追加しています。関連テストのフック案は、導入後の結果が未確認です。
まだ分からないこと
見落とし率や確認全体の工数削減は分かりません。関連テスト案にはBash経由の変更漏れと再試行上限の課題があります。マージも全問題の解決を示しません。
対処と結果をもう少し詳しく
動かして失敗条件を確かめ、修正後も確認する
公開PRで修正・テスト追加を確認
実行probeとコード解析で回復処理を指摘。保守者が修正し、初期に実行できなかったnative経路にも故障注入テストを追加したと報告しています。
対象と限界：1つのPRの経過。製品全体の検出率や他方式との比較ではありません。
実装と別のモデルが、元の依頼に照らしてレビューする
作り手が実施・効果の比較は未確認
Orkaの後半集計では、初回レビュー111件中100件が修正要求。レビュー判断の件数で、コードの不良率ではありません。
対象と限界：同じ運用者の6案件・2026年9月28日〜10月10日。
要望からドラフトPRまでを自動化し、人が操作して判断する
本人が運用・成功率は未記載
Andrew Lisowskiは、AIの実装後に差分とプレビューを確認し、必要な修正を求めてからマージすると説明。
対象と限界：自作アプリの1実践。運用件数や工数削減は不明です。
編集した範囲を記録し、停止前に関連テストを回す
公開された対処案・導入結果は未確認
既存フック2つを使う案。Bash経由の変更検出と、無限再試行を防ぐ上限が残ります。
対象と限界：1件の機能要望への返信。例示の件数・秒数は測定結果ではありません。
読むときの注意
- 製品側の説明、運用者の自己申告、公開された修正記録は根拠の種類が異なります。
- 同じ実践のProduct Hunt・GitHub・SNS・記事を、別々の利用者や成功例として数えません。
次に確かめたいこと
同じ種類の変更で、確認時間、見逃した不具合、差し戻しと修正後の再発を継続して記録した資料を追います。
編集のまとまりを、関連テストと失敗の返却につなぐ
複数ファイルを直す開発では、全テストの実行が重く省略される一方、AIが単一のテストを推測して確認を済ませる、と相談者は説明しています。ファイルを編集するたびに検査すると、変更途中の状態を何度も試す問題もあります。返信者の案は、編集時に変更ファイルを蓄積し、応答終了時に関連テストをまとめて実行するものです。
成功時に一覧を消し、失敗時は結果をAIへ戻して修正につなげます。ただし、シェルやコード生成経由の変更はそのままでは記録されず、直せない失敗による無限再試行にも上限が必要だと説明しています。これは対処案で、相談者による導入・改善の報告は未確認です。掲載された秒数やテスト件数も利用例であり、実績値として扱いません。
考えるための問い
- 編集ツール以外のシェル操作・コード生成も含め、変更ファイルと確認対象を拾えているか。
- 関連テストで確認できない条件と、失敗を直せない場合の停止上限を、完了報告に残せるか。
利用者の要望と、返信者による既存フックの提案。確認質問は編集上の提案です。