会社として生成AIの利用には積極的で、モデルやagentを何種類も法人契約しており業務で遠慮なく活用できる環境なのですが、ほとんど使えていません。
テストを書いてもらうとかエラーの原因を尋ねたりといったスポット的な利用はしていますが、プロダクションコードを書いてもらうことにどうしても及び腰になってしまいます。
いろいろある業務知識をコンテキストとして伝えなければいけないのと、最終的なコードの品質責任を実装者である自分が負うことに変わりはないので、自分がクリアに見通しを立てられることしかAIに頼めず、それは自分で書くのと変わらないのでは？自分に技術力がなければAIに何も頼めないのでは？と悩んでいます。
ただAIをほぼ使っていないのは自分くらいで、毎月トークン予算を使い切っている同僚も何人もいるため、組織の活用体制というより個々人のAIへの向き合い方に違いがある感じがしています。
業務でAIを使っているエンジニアの皆様は、どういうときにAIにコードを書いてもらっているでしょうか？
まずは自分で最後までビジネスロジックを書き切ってから、AIにレファクタリングの提案や改善を依頼しましょう。
それが良さそうですね。生産性を上げるというよりも、コードの品質向上のためにAIを使う意識が必要かもしれません。
慣れてきたら少しずつAIには一部の業務作業が依頼できるようになると思います。AI丸投げは失敗するしかないので。
青写真がない中、考えながら作ってる状態に感じました。
ざっくりでいいので言語化できるようになると変わりそうです。
が、まずは同僚がどう使っているか見せてもらうのはどうでしょう？
ジュニアメンバーが半日geminiとやりとりしてワカランとアラートあげてきたやつを、私がgeminiとやりとりしたら数回やりとりしただけで解決みたいなことがあって、メンバーのプロンプト見ると曖昧性の高いプロンプト、重要だと捉えるポイントが違ったり、論理的におかしいみたいなところに気づいてなかったりしてました。
一昔前のGoogle検索が上手い人と下手な人みたいな話を思い出しました。プロンプトの書き方を学んでみると発見があるかもしれないですね。
ですです。
生成AIのレスポンスに対して違和感を感じることから始めるのも良さそうです。
コーディングするときもなんかこれ違う(でも理想的なコードはわからない)みたいな違和感感じることないですかね？
あの違和感って理解が深まる、審美眼、言語化のファーストステップだと思っています。
エントリーポイントに実装のない空関数でビジネスロジックを記載し、各関数には doc string を記載した上で依頼を投げるような形にしていますね。
こうするとロジックの整合性の責務は人間側に残りますし、比較的安心して使えてます。
ガワを整えてから投げるのは有用そうですね。ありがとうございます。
書いてもらうスコープを小さくすることが大事かなと思います。
大量のコードは、AIであろうとシニアエンジニアが書いたものであろうと、レビューするのは大変ですからね...
ここから好みですが、例えば特定の大きな機能を作る場合は、いくつもの小さな機能(関数)を書くことになると思いますが、小さな関数単位まで小さくすると、理解しながらかけて良いかなと言う感じがしております。
以前全部まとめて書いてもらったら、メンテ不能のコードが出てきたことがあります。スコープの分割は大事そうですね。
9割くらい書いてもらっていて、自分ではほとんど書いていません
的外れなコメントだったらすみませんが、利用しているAIのアップデートはしていますか？
もししていなければぜひ試してみてください
数ヶ月前と比べたら最近は細かく伝えなくても推測して対応してくれるように感じます
スコープが大きめのものだと他の方が仰っているような進め方や、最初に対応方針の壁打ちをすると確度が高くなると思います
数ヶ月でそこまで変わるんですね。手元のバージョンを確認してみます。
AIと思うから失敗に及び腰になっているんだと思います。
特性は違いますが、今の生成AIは今日の朝入社した新人のようなものです。
新人に指示するように、
「この既存実装をまず読んで、他の人の書き方を参考にしつつ、今回のイシューはこれで、これが受け入れ条件だから、まあこんな感じでTDDで実装してみて。」
と実装させて、大体粗があるので、
「このコードはここの既存実装を読むとどう？」とか「これはイシューに書いてないよね」とか言う感じです。
大体大丈夫そうになったら、review機能をまわしつつ、自分でもしっかり細かく人のPRとしてレビューします。これでほぼいつも通りの、PRができるはずです。
上記は新人に対するコミュニケーションとほぼ同じだと思います。
生成AIが人と違うのは、初手からTDDでゴリゴリ実装できることと、指摘があればそ大きな手戻りでも即修正していけることです。要するに、短時間で高速に失敗可能です。
生成AIだと思わず、横に座っている人だと思って接してみてください。知識は無限にあるので、引き出せれば驚くほど効果がありますよ。
注意⚠️ 大量のレビューをさばけるようなレビューにおいてのハードスキルはとても必要になりますが。
自分で実装するのとはまた別のスキルセットですね… なかなか後輩が入ってこなくて他人に依頼をする機会が少なかったのですが、AI相手であってもある種のコミュニケーションという意識を持った方が良さそうですね。
そうですね
ただ、結局何年もエンジニアをやっていると、ゴリゴリコードを書くICだとしてもだんだんとチームをリードするようなテックリードなどになっていくと思います。
そうなると自分がコードを書くよりも、設計やレビューをするのが半分以上の環境になっていくと思います。
そこまでくると生成AIと一緒に仕事をしているのとあまり変わらなくなってきます。
結局人間も、設計やインターフェースを明示しないと大きく手戻りするPRを出してきます。しかも人間は修正に対して抵抗感が強いので、初期の設計がより重要になります。
生成AIは一切文句を言わずにガバッと修正してくれるので、むしろしっかり設計すると人間よりもいいコードを書いてくれます。
要するに、エンジニアの手書きだろうが生成AIのコードだろうがPRになるとどちらでも関係ないので、いいPRが出てくるお膳立て（設計）と、それに対しての的確なレビュースキルが重要になってきますね。やはりこの点でも、今までとやるべきことは同じになります。
今後はおそらくこの傾向が加速していくので、AIが仕事を奪うのではないのですが、このようなテックリード的な動きができない人はドロップしていく未来になるのかなと個人的には考えています。
もちろんそれがいいのか悪いのかは別として。
重複コメントにより削除
> いろいろある業務知識をコンテキストとして伝えなければいけないのと、
これは必要なことですが、毎回promptで指示する必要はなく、Coding Agentが起動時に読み込むドキュメント(CLAUDE.mdやAGENTS.md)に一度書けば済むはずです。
タスクの指示も、タスク管理ツールのMCPがあればこのチケットの仕様実装して、で済むこともありますし、なくてもコピペである程度指示を効率化できます。
> 最終的なコードの品質責任を実装者である自分が負うことに変わりはないので、自分がクリアに見通しを立てられることしかAIに頼めず、それは自分で書くのと変わらないのでは？自分に技術力がなければAIに何も頼めないのでは
これはその通りだと思います。
プロダクションで使えるコードを書く鍵は実装前にplan modeでどこまで指示者の意図を汲ませることができるか、だと思います。
なので自分がまず実装イメージを持てること(AIと壁打ちしてもいいと思います)、それを伝えられることが重要かなと。
自分では実装できないものを指示しても、まぐれでちゃんと動く高品質なコードが出てくることがあっても再現性は低いと思います。
技術力がなければAIにまともに指示できない、というのもその通りかと。
また、plan modeで修正する方が書かせてから修正するより軽快でかなり効率的です。
(少なくとも現在は、の話です)
自分で書くのと変わらないか、でいうと、それは否だと思います。
実装させている間に他のタスクを並行して進められることで、生産性は倍くらいにはなるのではと思います。
MCPはまだ個人的にほとんど活用できていないですが、AIを開発プロセスに取り込む上では鍵になりそうですね。
plan modeは話は聞いていましたが使ったことがなかったです。今の自分にかなり役立ちそうなので、ぜひ試してみます。
