はじめに
ChatGPTを使ってコーディングするときにここは注意したほうがいいと感じたことをまとめます。
勢いで書いているので既出だったり、あたり前なこと書いてます。
ChatGPTを使ってますが、Github Cpilotなどもっと他にいいのがあると思うかもしれません。
調べずに簡単に無料で利用できたというのが選択理由です。
（Github Copilotの課金方法が複雑すぎて諦めた民です）
今の開発方法
ChatGPTで仕様書のレビューや議論、実装はGithub Copilotを使うのがよさそう。
仕様書や他のソースコードを理解してコーディングするのはGithub Copilotが強いです。
逆にプロジェクトのマネージメントはChatGPTを信頼しています。
といってもGithub Copilotが使えなくなったらChatGPTで作業しているので、
結果的にChatGPT頼りになっているのが現状。
結論
新人エンジニアとかプロジェクト参加したてのエンジニアとペアプログラミングしてるイメージ重要。
あとちゃんと生成されたものは読みましょう。
自分で書かない分、記憶から抜け落ちやすいです。
基本的には理想の開発フローであるほどより効果的でした。
- 仕様書を明確に作る
- 実装時にタスクを分割する
- モジュールを適切に分割する
何がゴールなのか、この場面では何を考えなきゃいけないのかを明確にする、がキーワードです。
ChatGPTと開発する
起きる問題
- 提示されるコードにばらつきが出る
- ソースコードの微修正やバグ修正のやり取りが長くなるとやり取りが無限ループする
- やりとりのページがどんどん重くなる
- 用語の認識に齟齬があると見当違いなコードが出てくる
- 関数など局所的な部分だけを伝えるとシステム全体として整合性が損なわれる
- パス指定で末尾に区切り文字を強制するのかなど
- 複数のモジュールが結合されていると精度が落ちる
原因
提示されるソースコードにばらつきが出るのは制約が少ないからです。
制約条件にはきりがないので、頑張って手で直しましょう。
一番の要因は知識差があるからです。
プロジェクトへの理解をどれだけ認識させられるかがカギです。
コードの精度に限界を感じるかもしれません。
もしかしたら、明確な仕様（想定する入力や応答など）を十分に伝えられていない可能性があります。
基本的なスタンス
プロジェクトに参加したてのプログラマとして接しましょう。
プロジェクト固有の用語もしりませんし、お作法もわかりません。
もし独自のモジュールを使ってほしいのならしっかりと情報を提供しましょう。
実際のやりとりの注意点
まず、明瞭で簡潔な日本語を書きましょう。
C++で実装していて、std::stringを使って文字検知をしているんだけど、特定パターンを検出する関数を作りたい。
↓
特定パターンが含まれている場合にtrueを返す関数を実装したい。
入力にはstd::stringを受け取るとする。
また、コードはC++で実装したコードを提示して。
- 文章は短く
- 定義をする
- 何を目的にするのか
- 何を示してほしいのか
- 前提には何があるのか（どんな制約があるのか）
- 現状、どのような状況か
個人的には一度テキストエディタで文章を整理してから聞いています。
また、やり取りを重ねるほど文脈をどんどん忘れていくので一つのプロンプトに全てを集約しましょう。
また話はちゃんと区切りましょう。
示してもらったコードで実装できた。
次のステップに進む。
＜以下省略＞
話しを打ち切ることでどのような情報が重要か整理させることができます。
たぶん、整理してくれているはず。
一つの目標に対して達成することを意識しましょう。
複数の目標を同時並行する場合、認識の齟齬が生まれやすいです。
上記のように明確な目標を設定して話を進めましょう。
プロジェクト機能を使おう
ファイルで前提知識を提供できる機能です。そういう認識で使ってます。
整理されていない情報を渡すのはやめましょう。
理想は仕様書を渡すことです。
仕様書は1ファイルにし、仕様書が分散しないようにしましょう。
人間と違い1ファイルが長くても読んでくれます。
（LLMも同時に理解できる量には限りがありますが）
仕様書の例
<template type="ui"/>
<section name="UI画面">
{やりとり}
入力
┌─────────────────────────────────┐
│ │ [送信]
└─────────────────────────────────┘
[保存] [読み込み] [リセット]
</section>
<section name="各項目説明">
<element name="やりとり">
<item indent="0">以下の要素が表示される</item>
<item indent="1">ユーザの入力</item>
<item indent="1">LLMの応答</item>
<item indent="1">RAGの応答</item>
</element>
<element name="入力">
<item indent="0">LLMに送信するテキストを入力する</item>
<item indent="0">改行はShift+Enterで行う</item>
</element>
<element name="送信">
<item indent="0">入力されたテキストをLLMに送信する</item>
<item indent="0">以下のいずれかの条件を満たす場合ボタンが無効化される</item>
<item indent="1">入力欄が空欄</item>
<item indent="1">LLMからの応答を待機中</item>
<item indent="1">RAGからの応答を待機中</item>
<item indent="1">やりとりの保存中</item>
</element>
<element name="保存">
<item indent="0">押下時にログの保存場所を聞く</item>
<item indent="0">やりとりの内容をxml形式で保存する</item>
<item indent="1">プロンプト: promptタグ</item>
<item indent="1">LLMの応答: responseタグ</item>
<item indent="1">RAGの応答: ragタグ</item>
<item indent="0">以下のいずれかの条件を満たす場合ボタンが無効化される</item>
<item indent="1">入力欄が空欄</item>
<item indent="1">LLMからの応答を待機中</item>
<item indent="1">RAGからの応答を待機中</item>
<item indent="1">やりとりの保存中</item>
</element>
<element name="読み込み">
<item indent="0">押下時にログの読み込み場所を聞く</item>
<item indent="0">保存されたxml形式のやりとりを読み込む</item>
<item indent="0">以下のいずれかの条件を満たす場合ボタンが無効化される</item>
<item indent="1">LLMからの応答を待機中</item>
<item indent="1">RAGからの応答を待機中</item>
<item indent="1">やりとりの保存中</item>
<item indent="0">ログのやり取りがRAGの対象となる</item>
<item indent="0">ログのやり取りは読み込み時にクリアされる</item>
</element>
<element name="リセット">
<item indent="0">やりとりを全てクリアする</item>
<item indent="0">以下のいずれかの条件を満たす場合ボタンが無効化される</item>
<item indent="1">LLMからの応答を待機中</item>
<item indent="1">RAGからの応答を待機中</item>
<item indent="1">やりとりの保存中</item>
</element>
</section>
やりとりを適切に削除しよう
不要になったやり取りは削除して、参考にしてほしい情報を絞りましょう。
バグ修正のやり取りは不要になったら削除したほうがいいです。
バグ報告をしたときの情報を参照されないとは限りません。
やりとりの削除は部分的に行えないので適切にチャットは分割しましょう。
読みやすい仕様書を書こう
誰でも理解できる文章を書きましょう。
以下はバッドケースです。
- 受け取り方が複数ある
- 矛盾している
- 明記されていない専門用語がある
- 未定義な部分がある
- 前提が書いていない
背景や経緯を知らない人が読んでも理解できるのが理想です。
委託をする際にブリーフィングがあったりしますが、その内容も重要なので仕様書に入れましょう。
最後に
使っていて感じたのは使いようだなと思いました。
思ったより人間らしいと思います。
理不尽な要望でも怒ったりはしませんが。
他に感じたのは情報の取捨選択や話の切り替わりに弱いです。
そもそも人間はどうやってるんでしょうかね？
このように人との違いはあれど、結局は人とのコミュニケーションと変わらないと感じています。
やっぱり自分の脳で思い描いていることをいかに伝えられるかが勝負ですね。