会話型ソフトウェア開発について

大規模な言語モデルを活用してコードを生成することは、人生を変える一つの方法ですが、ソフトウェア開発プロセスについて彼らと対話することも同様に重要です。 Jon Udell は、大規模言語モデルがプログラマーにもたらす価値を探求し続けています。

Let's Talk: 会話型ソフトウェア開発からの翻訳。

非常に成功する AI ChatGPT インタラクションを開始するためのヒントを紹介します。

 PROMPT: I'll give you a test script and the output it is testing, and ask about strategies to improve the test, OK? Here's the script. #!/bin/bash set -eu list_tickets() { local output output=$($command $subcommand run list_tickets 2>&1) || { echo "Command failed with error: $output" exit 1 } echo "$output" } output=$(list_tickets) count=$(echo "$output" | jq -r '.tickets_list | fromjson | length') # Check if count is greater than 0 if [[ $count -gt 0 ]]; then echo "PASS: list_tickets count is greater than 0." else echo "FAIL: list_tickets count is 0 or less." fi

通行人の意見

プロンプトは、私が思い描いた bash スクリプトを意図的に簡略化したものです。元のヒントでもサンプル出力を提供するつもりでしたが、忘れてしまいました。振り返ってみると、出力を提供せず、ChatGPT が最初にスクリプト自体に集中できるようにした方がよかったかもしれません。その観察結果には次のようなものがあります。

 RESPONSE: While you've used set -eu to exit on any error or unset variable usage, consider using set -euo pipefail to also capture failures in any part of a pipeline.

これは、コーディング中に LLM から暗黙的に知識を獲得する方法の良い例です。私は以前から bash の strict モードについて多少の知識を持っていましたが、それは不完全でした。そこで、私たちは少し立ち止まってこのトピックについて検討し、知識を深め、デバッグには他の -o パラメータ、特に -x (xtrace) と -n (noexec) の使用を検討するようにメモしました。私たちはまだ実際の課題に取り組み始めたばかりですが、このちょっとした回り道自体に価値があります。

JSONについて話しましょう

ここで戻ってサンプル出力を示します。

 PROMPT: “tickets_list”: “[{\”associates_rdb\”:null,\”association_type\”:null,\”cc_email\”:{\”cc_emails\”:[],\”fwd_emails\”:[],\”reply_cc\”:[],\”tkt_cc\”:[]},\”created_at\”:\”2023-10-12T12:15:00+01:00\”,\”custom_field\”:{\”cf_reference_number_2939992\”:null},\”datetime_tc01\”:null,\”datetime_tc02\”:null,\”datetime_tc03\”:null,\”deleted\”:false,\”delta\”:true,\”description\”:\”world\”,\”description_html\”:\”\\u003cdiv\\u003eworld\\u003c/div\\u003e\”,\”dirty\”:0,\”display_id\”:17,\”due_by\”:\”2023-10-16T22:00:00+01:00\”,\”email_config_id\”:153000020300,\”frDueBy\”:\”2023-10-12T22:00:00+01:00\”,\”fr_escalated\”:true,\”group_id\”:null,\”id\”:153002218563,\”int_tc01\”:null,\”int_tc02\”:null,\”int_tc03\”:null,\”int_tc04\”:null,\”int_tc05\”:null,\”internal_agent_id\”:null,\”internal_group_id\”:null,\”isescalated\”:false,\”json_tc01\”:null,\”long_tc01\”:null,\”long_tc02\”:null,\”long_tc03\”:null,\”long_tc04\”:null,\”long_tc05\”:null,\”nr_due_by\”:null,\”nr_escalated\”:false,\”nr_reminded\”:false,\”owner_id\”:null,\”parent_ticket_id\”:null,\”priority\”:1,\”priority_name\”:\”Low\”,\”product_id\”:153000018092,\”requester_id\”:153002362554,\”requester_name\”:\”Jon Udell\”,\”requester_status_name\”:\”Open\”,\”responder_id\”:null,\”responder_name\”:\”No Agent\”,\”sl_escalation_level\”:null,\”sl_manual_dueby\”:null,\”sl_merge_parent_ticket\”:null,\”sl_product_id\”:null,\”sl_skill_id\”:null,\”sl_sla_policy_id\”:null,\”sla_state\”:0,\”source\”:2,\”source_name\”:\”Portal\”,\”spam\”:false,\”st_survey_rating\”:null,\”status\”:2,\”status_name\”:\”Open\”,\”subject\”:\”hello\”,\”ticket_type\”:null,\”to_email\”:null,\”to_emails\”:null,\”trained\”:false,\”updated_at\”:\”2023-10-12T22:05:04+01:00\”,\”urgent\”:false},{\”associates_rdb\”:null,\”association_type\”:null,\”cc_email\”:{\”bcc_emails\”:[],\”cc_emails\”:[],\”fwd_emails\”:[],\”reply_cc\”:[],\”tkt_cc\”:[]},\”created_at\”:\”2023-10-12T04:41:12+01:00\”,\”custom_field\”:{\”cf_reference_number_2939992\”:null},\”datetime_tc01\”:null,\”datetime_tc02\”:null,\”datetime_tc03\”:null,\”deleted\”:false,\”delta\”:true,\”description\”:\”Hello there, Our Report metrics over the last week is at zero and can't be correct? Are you facing any issues?\”,\”description_html\”:\”Hello there, Our Report metrics over the last week is at zero and can't be correct? Are you facing any issues?\”,\”dirty\”:0,\”display_id\”:6,\”due_by\”:\”2023-10-16T22:00:00+01:00\”,\”email_config_id\”:153000020300,\”frDueBy\”:\”2023-10-12T22:00:00+01:00\”,\”fr_escalated\”:false,\”group_id\”:153000077019,\”id\”:153002214584,\”int_tc01\”:null,\”int_tc02\”:null,\”int_tc03\”:null,\”int_tc04\”:null,\”int_tc05\”:null,\”internal_agent_id\”:null,\”internal_group_id\”:null,\”isescalated\”:false,\”json_tc01\”:null,\”long_tc01\”:null,\”long_tc02\”:null,\”long_tc03\”:null,\”long_tc04\”:null,\”long_tc05\”:null,\”nr_due_by\”:null,\”nr_escalated\”:false,\”nr_reminded\”:false,\”owner_id\”:null,\”parent_ticket_id\”:null,\”priority\”:1,\”priority_name\”:\”Low\”,\”product_id\”:153000018092,\”requester_id\”:153002465401,\”requester_name\”:\”Adam Doe\”,\”requester_status_name\”:\”Open\”,\”responder_id\”:null,\”responder_name\”:\”No Agent\”,\”sl_escalation_level\”:null,\”sl_manual_dueby\”:null,\”sl_merge_parent_ticket\”:null,\”sl_product_id\”:null,\”sl_skill_id\”:null,\”sl_sla_policy_id\”:null,\”sla_state\”:0,\”source\”:1,\”source_name\”:\”Email\”,\”spam\”:false,\”st_survey_rating\”:null,\”status\”:2,\”status_name\”:\”Open\”,\”subject\”:\”Issues with reports\”,\”ticket_type\”:\”Bug\”,\”to_email\”:null,\”to_emails\”:null,\”trained\”:false,\”updated_at\”:\”2023-10-12T04:41:13+01:00\”,\”urgent\”:false}]” }

別のシナリオでは、この JSON 出力のフォーマットを最適化するために時間を費やす可能性があります。しかし、LLM はコンパイラやインタープリタと同様に、その点を気にしません。さらに良いことに、従来の JSON フォーマッタがパニックを起こすような構文も許容します。上記の例をレガシーフォーマッタに貼り付けると、2 つの問題が発生します。まず、中括弧がないと有効な JSON ではありません。 2 番目に、tickets_list の値は JSON の文字列化された表現であるため、JSON オブジェクトではなく文字列になります。驚くべきことに、LLM はあなたの意図を「理解」し、適切に応答します。

 RESPONSE:

 { "tickets_list": [ { "associates_rdb": null, "association_type": null, "cc_email": { "cc_emails": [], "fwd_emails": [], "reply_cc": [], "tkt_cc": [] }, "created_at": "2023-10-12T12:15:00+01:00", "custom_field": { "cf_reference_number_2939992": null }, ... } ] }

これは非常に些細なことですが、ワークフローに影響を与え、高度な機能のために確保しておくべき認知リソースを無駄にする可能性があります。この時点で、私は説明可能性テストと呼んでいるものも実行します。LLM は、1) コード スニペットを中括弧で囲む必要があること、2) ネストされた値を解析する必要があることを説明していますか?結果は次のとおりです。

これは私にとって興味深いことでした。なぜなら、Copilot Chat が OpenAI を使用し、Cody が Anthropic を使用していることは知っていたものの、必ずしも明らかではなかったからです。それぞれのチャット インターフェイスには、基盤となる LLM から取得される応答とは異なる応答を行うためのプロンプトが強化されています。しかし、この場合、ツールはそれぞれのインターフェースと一貫して動作するようです。

テスト戦略について話し合いましょう

ChatGPT の set -euo pipefail に関する観察は、私たちが検討できる多くの方向性の 1 つにすぎませんが、私は会話を目の前のタスク、つまり元のヒントに含めたテスト スクリプトの改良に戻しました。このスクリプトは Freshdesk チケット システムの出力をテストします。単純なテストでは、テスト対象のツールが Freshdesk の API を呼び出して 0 個を超えるチケットを返すことができるかどうかをチェックするだけです。より良いテストとはどのようなものでしょうか? ChatGPT の推奨事項には、優先度とステータスが期待値と一致していること、空の値または長いリストを含むチケットが適切に処理されていること、すべての日付フィールドが存在し、有効な日付が含まれていることを確認することが含まれます。

私は最後のアプローチを選択し、ChatGPT はそれに応じてテスト スクリプトを変更しました。これには、日付に一致する正規表現を記述し、各チケットの日付フィールドのセットをループして、その正規表現を適用する必要があります。これは複雑すぎると感じたので、1 つの日付フィールド created_at のみをチェックするようにスコープを制限するように依頼しました。これでもまだ複雑すぎるように感じるので、ループを削除し、単一のチケットの有効期限をチェックするだけのテストに簡略化します。それから次の話題に移りました。

テストスイートにテストを展開する方法について議論しましょう

テストする必要があるユースケースは次のとおりです。

• Freshdesk チケットの一覧
• 新しいFreshdeskチケットを作成する
• Freshdeskチケットを削除する
• 特定の Freshdesk チケットの詳細を取得する
• Freshdeskチケットの更新
• Freshdeskチケットにメモを追加する

私は bash 関数をほとんど使用しませんが、ここでは役に立つかもしれないと思ったので、6 つのテスト ケースに対応する 6 つの関数に bash スクリプトを構造化した返信を見て嬉しく思いました。 「良さそうですね」と私は言いました。「最初のテストを含めて、このように構成された完全なビルドをください。」

この時点で、私の横で見ていた同僚は、LLM では「お願いします」や「ありがとう」を使うと良い結果が得られるのではないかと考えました。これは私にはわかりません！ただ気持ちいいからやるだけ。これは危険な擬人化ですか？多分。しかし、たとえ彼らが人間でなかったとしても、私のアシスタントをいじめることに何のメリットもないと思います。

その後、同じ同僚がテーブルからテストを実行するための代替戦略について質問しました。私たちはこう尋ねました:

 PROMPT: We are wondering if it would be better to have a data structure for these tests instead of a set of loose functions, what do you think are the pros and cons?

回答では、利点 (保守性、再利用性、並列実行、一貫したログ記録、明確さ) と欠点 (追加のオーバーヘッド、複雑さ、移行時間、学習曲線) が挙げられました。最後に、次の要約で終わります。

 RESPONSE: Given that your test suite might grow or change over time, adopting a structured approach earlier can be beneficial. However, it's essential to weigh the initial time investment against the long-term benefits. If you think your test suite will remain relatively small and static, the current loose function setup might suffice. But if you anticipate growth or frequent changes, the structured approach will pay off in the long run.

私たちはまだラピッドプロトタイピング段階にあり、このテスト戦略に長期的な投資をする準備ができていないため、緩やかに機能させることにしました。しかし、私たちは全員、別のアプローチについて数分間検討することは価値があると感じました。

チケットIDを保持する方法について議論しましょう

次に記述するテストは、チケットを作成するためのテストです。 ChatGPT では、チケットの読み取り、更新、およびチケットへのコメント追加の機能をテストするために、他のテストで使用するためにチケットの ID を保存することを推奨しています。そして、ID をファイルに保存する関数を記述します。これにより、ファイルと変数間の保存のトレードオフを評価する必要があることが疑問に思いました。以下は、表形式で修正された回答の要約です (ChatGPT に感謝)。

そして、次のような結論を付け加えました。

 RESPONSE: If you're writing a single script, and the data doesn't need to persist beyond the script's execution, a variable might be simpler and faster.

ファイルベースの代替案については検討すらしていません。 ChatGPT がそのアプローチを採用したとき、私はさまざまなオプションのトレードオフを検討し、議論するようになりました。結局、LLM を使用する前とまったく同じことをしたので、この回り道は不要だったのでしょうか?私はそうは思わない。代替案を検討することは常に価値があります。この回り道にはほとんど時間がかかりませんでしたし、最終的に私がやったことは変わりませんでしたが、そのプロセスは価値があると感じました。

get_ticket 関数のテストを書いているときにも同様のやり取りがありました。取得したチケット ID が保存したものと一致するかどうかを確認するだけで十分ですか? ChatGPT は、効率性と徹底性の間に微妙な境界線を引き、より徹底した検査のオプションをリストし、基本的なスモーク テストでは効率性を優先することが理にかなっていることを示唆しています。繰り返しますが、より簡単なことを行う方法は既に知っているので、これによって何も変わることはありません。しかし、私たちが確かにスモークテストを行っていることはわかっていましたが、それを声に出して言うことは役に立ちました。

バッシュについて話しましょう

ここでは、結果を劇的に変える相互作用があります。テスト スイートに 3 番目のテストを追加しましたが、実行したのは最初の 2 つだけです。何が悪かったのでしょうか?デバッグのプロセスは LLM を使用する前と同じですが、ChatGPT はコードに print ステートメントをより速く挿入できるため、はるかに高速です。この力ずくの試行錯誤のアプローチを何度か試した後も、2 番目のテストに合格できませんでした。

そこで、「set -euo pipefail をオフにするのは意味があるだろうか?」という疑問が浮かびました。これを実行すると、スクリプトは完全に実行されました (つまり、6 つのテストがすべて実行されました)。ただし、成功するはずだった 2 番目のテストは失敗しました。その時、私は気づきました。私はこう尋ねました。「test_create_ticket から $TICKET_ID を返すべきですか?」 ChatGPT は、私が読んだことはあったが、遭遇したことのない動作を思い出させました。

 RESPONSE: In the context of bash scripts, when you return a number from a function, it's analogous to an exit code.

ああ、神様！それは正しい！この関数は、作成されたチケットの値をグローバル変数に設定し、厳密モードを有効なままにして早期終了を回避するために 0 を返す必要があります。それが最終的な突破口でした。その後、すべてが順調に進みました。

ラバーダックが話すとき

私は、この投稿シリーズの最初のテーマである「ゴム製のアヒルが話すとき」に何度も戻ってきます。声に出して考えることは常に役に立ちます。理想的には、人間のパートナーと一緒にこれを行うことができます。ゴム製のアヒルは代用品としては不十分ですが、何もないよりはましです。

LLM と話すことはこれらのオプションのいずれとも似ておらず、まったく別のものです。私たちは皆、それがどのように機能するかを理解しようとしています。 LLM にコードを書いてもらうと、魔法のようにコードが現れるのでしょうか?これは明らかに人生を変える出来事です。共同で書いたコードについて LLM に相談しますか?これも、あまり目立たないけれども、同様に人生を変えるほどの重大なことだと思います。