まずは自分で最後までビジネスロジックを書き切ってから、AIにレファクタリングの提案や改善を依頼しましょう。

青写真がない中、考えながら作ってる状態に感じました。

ざっくりでいいので言語化できるようになると変わりそうです。

が、まずは同僚がどう使っているか見せてもらうのはどうでしょう？

ジュニアメンバーが半日geminiとやりとりしてワカランとアラートあげてきたやつを、私がgeminiとやりとりしたら数回やりとりしただけで解決みたいなことがあって、メンバーのプロンプト見ると曖昧性の高いプロンプト、重要だと捉えるポイントが違ったり、論理的におかしいみたいなところに気づいてなかったりしてました。

エントリーポイントに実装のない空関数でビジネスロジックを記載し、各関数には doc string を記載した上で依頼を投げるような形にしていますね。

こうするとロジックの整合性の責務は人間側に残りますし、比較的安心して使えてます。

書いてもらうスコープを小さくすることが大事かなと思います。

大量のコードは、AIであろうとシニアエンジニアが書いたものであろうと、レビューするのは大変ですからね...

ここから好みですが、例えば特定の大きな機能を作る場合は、いくつもの小さな機能(関数)を書くことになると思いますが、小さな関数単位まで小さくすると、理解しながらかけて良いかなと言う感じがしております。

9割くらい書いてもらっていて、自分ではほとんど書いていません

的外れなコメントだったらすみませんが、利用しているAIのアップデートはしていますか？

もししていなければぜひ試してみてください

数ヶ月前と比べたら最近は細かく伝えなくても推測して対応してくれるように感じます

スコープが大きめのものだと他の方が仰っているような進め方や、最初に対応方針の壁打ちをすると確度が高くなると思います

AIと思うから失敗に及び腰になっているんだと思います。

特性は違いますが、今の生成AIは今日の朝入社した新人のようなものです。

新人に指示するように、

「この既存実装をまず読んで、他の人の書き方を参考にしつつ、今回のイシューはこれで、これが受け入れ条件だから、まあこんな感じでTDDで実装してみて。」

と実装させて、大体粗があるので、

「このコードはここの既存実装を読むとどう？」とか「これはイシューに書いてないよね」とか言う感じです。

大体大丈夫そうになったら、review機能をまわしつつ、自分でもしっかり細かく人のPRとしてレビューします。これでほぼいつも通りの、PRができるはずです。

上記は新人に対するコミュニケーションとほぼ同じだと思います。

生成AIが人と違うのは、初手からTDDでゴリゴリ実装できることと、指摘があればそ大きな手戻りでも即修正していけることです。要するに、短時間で高速に失敗可能です。

生成AIだと思わず、横に座っている人だと思って接してみてください。知識は無限にあるので、引き出せれば驚くほど効果がありますよ。

注意⚠️ 大量のレビューをさばけるようなレビューにおいてのハードスキルはとても必要になりますが。

> いろいろある業務知識をコンテキストとして伝えなければいけないのと、

これは必要なことですが、毎回promptで指示する必要はなく、Coding Agentが起動時に読み込むドキュメント(CLAUDE.mdやAGENTS.md)に一度書けば済むはずです。

タスクの指示も、タスク管理ツールのMCPがあればこのチケットの仕様実装して、で済むこともありますし、なくてもコピペである程度指示を効率化できます。

> 最終的なコードの品質責任を実装者である自分が負うことに変わりはないので、自分がクリアに見通しを立てられることしかAIに頼めず、それは自分で書くのと変わらないのでは？自分に技術力がなければAIに何も頼めないのでは

これはその通りだと思います。

プロダクションで使えるコードを書く鍵は実装前にplan modeでどこまで指示者の意図を汲ませることができるか、だと思います。

なので自分がまず実装イメージを持てること(AIと壁打ちしてもいいと思います)、それを伝えられることが重要かなと。

自分では実装できないものを指示しても、まぐれでちゃんと動く高品質なコードが出てくることがあっても再現性は低いと思います。

技術力がなければAIにまともに指示できない、というのもその通りかと。

また、plan modeで修正する方が書かせてから修正するより軽快でかなり効率的です。

(少なくとも現在は、の話です)

自分で書くのと変わらないか、でいうと、それは否だと思います。

実装させている間に他のタスクを並行して進められることで、生産性は倍くらいにはなるのではと思います。