はじめに
In a前回の投稿,私の新しいツールの開発でAIを使用するについて、以下のように書きましたinclude-tidy(Tidy)を利用するLibclang, 以前使ったことのない図書館:
何が助けになったのかロットはAI（厳密にはLLM）を使用していた。具体的にはGoogleのGemini（クレード（Claude）に払う気力がないため、特に個人プロジェクトでお金を稼ぐつもりがないから）。後で自分の経験を説明するブログ記事を書くかもしれないが、簡単に申し上げるなら、AIは多くのドキュメントを読む必要がなくなったし、チュートリアルを読む必要もなく、メールリストやStack Overflowに質問を投稿して答えを待つ必要もなくなったということだ。
これは前述のフォローアップブログ記事です。AIを使用している間は、これから述べる内容はおそらく驚きではありません。TidyのためにAIを使用する前は、小さな機能や特殊なケースの質問をするためにだけ使用していました。TidyのためにAIを使用するのは、私のAIの「大きな」使用法の最初でした。
初めて私のブログや私に会う方であれば、「この人は誰で、なぜ私が彼の考えを気にするべきなのか？」と疑問に思うかもしれません。私は40年以上にわたり、趣味としても職業としてもコンピューターをいじってきました。。いくつかのプログラマー、特に古い世代のものは、AIに対してとても懐疑的で、「ステロイドを効かせたオートコレクト」と呼ばることが多い。それには技術的な真実の種が含まれているが、それでもなかなか感銘すべきものだ.
プロンプティング
「プロンプトエンジニアリング」という用語やそれに関連する「プロンプトエンジニア」という肩書きは、後者は「清掃エンジニア」のようなもので、非常に過大評価されていると思う（）。はでなければならず、詳細で具体的である必要があります—Stack Overflowで質問を提出する場合と同じです。
スタックオーバーフローとは異なり、以前に同じ質問がされたものやFAQを読んでいないことに対して非難されません。なぜそんなことをしたいのかと問い詰められることもありません。蔑ましい回答やコメントを受け取ることもありません。何も回答が得られないこともありません。数秒以内に回答が得られます。
それらの音がすべて素晴らしいと言っても、得られる答えは完全に間違っている可能性があります。数回、Geminiは存在しないAPI関数を使うべきと言いました。それに気づかせていただいた後、それは自分で正しいことをしたのですが。
また、得られる答えはしばしばあなたの正確な質問だけに基づいています。AIを使うことを考えると、サルの手__JHSNS_SEG_662d2407_31__のように考えるのが一番良いでしょう。 それによって、技術的にあなたのリクエストを満たすものだが、意図しない結果が生じる可能性があることを防ぐ必要があります。
例えば、GeminiにTidyを作成するために最初に提示したプロンプトはこちらです。
clangのAPIを使用して、CまたはC++のソースファイルが与えられた場合、そのファイル内のすべてのシンボル（マクロ、定数、関数、型、変数など）と、そのシンボルが宣言されたファイルと行番号を表示するプログラムを書く。特定できない場合は「unknown」と表示する。
そして、Libclangからいくつかのスクリーン分のCコードを出力する。#include、抽象構文木をパースし、それを反復処理するためにどのような関数を呼び出すか、Libclangを初期化しクリーンアップするための関数はどうすればいいか。確かに、Libclangのチュートリアルを読む準備はできたが、Geminiの回答は私がしたいことを的確に反映していた。
もちろん、生成したプログラムは全く完成していなかった。コマンドラインオプション、設定ファイル、エラー、色付き出力、あるいはCやC++のソースファイルを解析する際のあらゆる特異なケースを扱っていなかった。これらのことは今後数週間で具体化される予定だった。しかし、私は良いスタートを切れていた
日常的なタスク
AIを使うことの他の良い点は、日常的なコードをAIにやってもらえることだ。はすることができるが、コードが退屈なので面倒を避けたい。例えば、Tidyはコマンドライン引数を事前にスキャンし、-Xtidyで始まるものを探して、それをTidy固有のものとLibclangにそのまま渡すべきものに二つの配列に分ける必要がある。私のプロンプトはこちらだった：
、
argcとargvをmainは C プログラムにおいて、二種類のオプションがあります：(1)-Xtidyオプション、つまり-Xtidyで始まるオプション、および (2) 単なるオプション。「オプション」は短いオプションまたは長いオプションのいずれかです。私は
argcとargvを操作したいので、-Xtidyで始まるすべてのオプションは、別のtiny_argv配列に分離されます。tiny_argcはargvをすべての-Xtidyと直後に続くオプションから切り離します。
そして、それは 正しく行いました 数秒で、すべて私がコードを書いた場合、予期せぬ off-by-one エラーをデバッグする必要がありませんでした。
経験
経験豊かなプログラマーであれば、生成されたコードを眺めてすぐにそれが正しいかどうかを見分けることができます。だから経験豊かなプログラマーにとって、AIは非常に良い加速器です；もし経験の浅いプログラマー（プログラマーでさえない人）であれば、私はおそらくサルの手の指にもまかれています.
バグを見つける
別のこととして、特定の.cが終わった後には、あなたができることはあります。.cppファイルをアップロードし、「このコードにバグは見つかるか？」と尋ねます。そしてそれがします。もちろん、見つけたすべてのバグを知ることはできませんので、あなたはまだユニットテストや他のテストを書くべきです。
もちろん、私のものと同じように偽陽性を報告することもできます。c_chan プロジェクト。それは私の特定のミューテックスの使用が間違っていると思った。もちろん、それはミューテックスを人間のプログラマーを混乱させるかもしれない非典型的な使用方法だった。しかし、それも初期化されていない構造メンバーのいくつかの実際のバグを見つけたり、tv_nsec メンバーの timespec 構造体の が必要であることに気づいた。は0～999999999の範囲内である必要があるため、オーバーフローをチェックするコードを追加する必要があります。
AIが行かなかったこと
多くのコードベースと同様に、コードの大部分はコードベースの主な目的に関与していません。Tidyの場合：
- 18%だけが
#includeディレクティブのスキャンとシンボルをインクルードファイルにマッピングに関わっています。 - 26% はただの「ユーティリティ」コード（他のコードを書きやすくする小さな関数）です。
- 25% は設定ファイルのパースにだけ使われます（TOMLを構文解析し、意味解釈を行い、エラーをチェックし、正確な行と列でエラーメッセージを表示）。
- 15% は汎用的なデータ構造（動的配列、赤黒木）に使われます。
- 9% はコマンドラインのパースに使われます。
- 8% はテストに使われます。
AIを使っていましたサポートwith (not書き込むLibclangを使用してコードを作成するが、ユーティリティコードや設定ファイルではなく、コマンドラインでのみ少し（引数を分割するために）、テスト用ではない。
意味合い
このブログ記事の目的は、ソフトウェア開発におけるAIの印象を説明することだけです。me、コメントで私の考えるソフトウェア開発全体への意味合いについて聞かれるかもしれませんので、今すぐそれに答えるかもしれません
。確かにAIに関するハイパーはこれまであり、今後もたくさんあるでしょうが、私が言ったように、それは私にとても役立ちました は Tidy で。それはソフトウェア開発の変革者です。経験豊かなプログラマの手の中では、それは加速剤です。私はもう初心者でないプログラマなので、初心者プログラマにとっての AI の使用はどうかについては直接コメントできません。それはまた加速剤である可能性が高いですが、初心者（または非）プログラマはそれを見たときに間違ったコードやセキュリティを省略したコードを見つけることができません。間違いなく、より多くのデータ漏洩と訴訟が発生するでしょう。
確かにテクノロジー企業の大規模なリストラを聞いたことがあるだろう（そして不幸にも直接経験したこともあるだろう）。私がコメントしたように、確かに多くのリストラはあったが、私はAIがCEOたちが無能であると聞かれないように、そして会社が困っていると聞かれないように、替わりの責任者として使われていると考えている。リストラの理由は以前も同じだ
- 、会社が愚かなほど多くの人を雇ったのだ。
- 新しい製品やサービスが成功しなかった
- 会社は財政的な困難に陥っている
これらはすべてCEOが無能であると見せつけるものだ
その代わりにAIを非難することで、先進技術を同時に導入しつつも費用を削減することでCEOは賢明に見えるようになり、これらはウォール街によって報酬される—これがさらに解雇の理由である__JHSNS_SEG_662d2407_112__これに加えて、以下の解雇の理由を付け加える。無能なCEO:
- 実際にすべてのハypeを信じ、彼らはAIによって開発者を置き換えられることができると考えるかもしれません。
以下の状況を考えてみてください。あなたは大手ソフトウェア製品を販売し、多くの顧客を持つテクノロジー会社のCEOです。社員には100人の開発者がいます。平均して、毎月1つの新しい機能を追加し、10つのバグを修正しています。もっと多くの機能を追加し、多くのバグを修正したいですが、もっと開発者を雇う資金がないです。今、AIが登場し、あなたには2つの選択肢があります。
- 毎月1つの新しい機能を追加し、10つのバグを修正するが、より少ない開発者と費用で行う.
- AIを加速器として使用し、同じ数の開発者で毎月2つ、場合によっては3つの新しい機能を追加し、30つのバグを修正する.
正常なCEOが選択肢1を選ぶとは考えられない。「私たちは現在の開発ペースで満足しており、顧客もそうだ」と考えながら。選択肢2は既存の顧客をもっと満足させ、新しい顧客を引き付けることにも効果的だろう。確かに、この考えを支持する研究がある.
だから、もし解雇に直面しているなら、おそらく何か心の安らぎを得られるかもしれない(schadenfreude)がCEOが無能である可能性があるということ。
結論
AIは非常に残りそうだ。明らかに開発者の加速剤だ。もちろん、再編や買収、そして少数の破産が起こるだろう。なぜなら、少なくとも現在は、AIを運営することは資金を失う出血だから。AIを利益を得る別の問題です。Googleのような代替的な収益源（広告）を持つ大手企業は、AIを永続的に資金援助できます；Anthropicはたったの今や利益を得ていますこれまでにない初めて。彼らができるかどうかは不明。続ける利益を得る。今後数年でわかる。