いやぁ、正直エージェントモード怖いです。AIがコードをばりばり書き換えていくんですよね？
自分で記述したコードが、がっつり修正されちゃったりするんですよね？うまく使いこなすコツとかありますか？
バイブコーディング、AIエージェントを利用したコーディングのTipsを紹介します。
プログラムのコーディングをする方なら、自分で書いたコードはロジックは理解できますが、エージェントコーディングになると
新しい記述法やエレガントなロジックをAIが勝手に実装するため、コードの細部は理解できなくなります。
また、記述されるコードの量も数倍に増えますので、コードの細部を理解するのは難しくなります。
細部のコードは理解できなくなっても、メソッドが何をするものかを理解することはできます。コード生成時に
メソッドやモジュールのドキュメント化、どういう構造で何を実行するのかの大枠をソースコードとは別にドキュメント化しておくことで、
細部の理解はできなくても、全体の動作は理解できる状態になります。
全てをドキュメント化しなくても、いつでもコードの内容をAIに説明してもらえますので、
重要な部分や基本動作をドキュメント化しておくだけでも十分役立ちます。
また、テストを増やして「テスト＝仕様」という考えに基づいて、inとoutをしっかり把握する方法も良いです。
AIエージェントにお願いしたら、どんどん修正を始めましたが、その修正方法が適切なのか判断がつかないです。
やりたいことに対して、どういう方針やロジックで実現するのか、採用した方針を適用する場合、プログラムのどの部分を修正するのかを事前に相談します。
提案された方針やロジックに対して、パフォーマンス面での指摘や、将来性などを鑑みて指摘を入れます。
議論の結果、AIの提案が変わる場合もありますし、新たな方針が出てくる場合もあります。
素直に、フラグ管理が怖い、以前挫折した方式だ、同期をきちんと取れるのか心配？など心理的な不安を伝えるのもありです。
相談結果をファイルに保存しておくことで、工程表の作成やコードの修正がスムーズに実施できます。
作業規模が大きい場合、修正を始めても本当に完成するのかが心配になります。
延々とビルドエラーが出続けたり、バグが出続けて手に負えなくなるなど心配です。
修正を始める前に、工程表を生成して全体の流れをドキュメント化します。
工程表の中で、心配な部分があれば、さらにブレークダウンした工程表を作成します。
作成した工程表をレビューして、懸念点や心配な部分を解消してから、工程表をもとにコード修正を始めます。
大量にコードを記述して、AIが得意げに出来上がりました。ビルドも通りました。と言っても、本当にそれが正しい動作をするのか怪しいと思ってします。
テストシナリオを準備して、テストを多めに用意します。テストコードもAIで生成します。
あれこれ、オーダーを出してプログラムをあちこち修正したのですが、何をどう直したのかがわからないです。
どう修正したのかをドキュメントとして残しておきます。コードの修正は差分で追えるため、修正理由や全体における修正の位置づけなどのドキュメントを残します。
AIエージェントでアプリを作成したのですが、バグが取れないです。どうすればよいですか?
アプリの作成にClaude Codeを利用している場合には、Codexに、Codexを利用していた場合は、Claude Codeにプログラムのバグ調査をするとうまく見つけられる場合があります。
最初の指示のロジックの筋が悪い場合には、バグが取り切れないことがあります。そもそもロジックが不安定であるといった根本原因が影響しています。 AIエージェントに普通に指示を出すと現状のロジックのままで、何とか頑張ろうとコードを修正する動作になります。
試行錯誤してうまくいかない場合は、そもそものロジックに問題がある可能性があるため、方針転換をして別のロジックを検討します。
別のロジック案がある場合は、そのロジックで再実装する旨の指示をすればよいです。
ロジックの想定が無い場合は、チャットツール等で、ゼロベースから相談してロジック決めをして、ロジックが決まってから、
コーディングツール(Claude Code, Codex)でプログラム作成の指示を出します。
正直生産性が上がるか疑問です。
行き当たりばったりではうまくいかないことが多いですが、方針を決め、計画やドキュメントを残しながら作業を進めれば、極めて効率よくプログラム作成ができます。
また、画面の見た目やビジュアルの指示は言語だけではどうしても伝わりにくいため、作成するアプリケーションの種類によっては、FigmaなどのUI作成ツールを活用する必要はあります。
