LLMの世界でプログラミングを楽しむ方法

LLMの世界でプログラミングを楽しむ方法 未分類 turion 2026年9月18日 9:56am 1 AIによる燃え尽き症候群に向かっていますか？ プログラミングスキルがほとんどなく、品質への意欲もなく、巨大なClaudeアカウントを持つ誰かに仕事を奪われることを恐れていますか？ プロジェクトのコード品質、あるいは「自分の」コードの品質に失望していますか？ これはあなたのためです。 大手テック企業が運営する最先端LLMには、重大で正当な倫理的懸念がありますが、これらはすでに長々と議論されており、私はそれを認識し、同意しています。この記事はそれらに関するものではありません。どうか私をLLM推進のテックブロと間違えないでください。また：私の文章がLLM生成だと誤解されることがあるので、これは100%人間が書いたもので、AIの助けは一切借りていないことをお伝えします。 魂の巨大な機械 ショーン・マクマレンによるこのタイトルの素晴らしい本があり、ティーンエイジャーの頃に楽しみました。一見すると、それは私たちの状況とは正反対の状況を描いています。人間が個々のコンポーネントである巨大なコンピューターで、計算ユニットを形成するために協力しています。一方で、LLM自体は実際のコンピューター上で動作し、（スーパー）人間のように振る舞います。しかし、よく見ると、物語と現実はそれほどかけ離れていません。ソフトウェア製造における私たちの役割は、俳優から機械の歯車へと徐々に格下げされています。仕様駆動のディストピアとは、単に仕様が手渡され、それをLLMに叩き込み、テクノーフェーダルな領主がより少ないトークンを配布することを決定したためにトークンが尽きて泣くことです。 Haskellプログラマーとして、私はHaskellを書くことを楽しんでいます。はい、仕事で作成する製品は大好きですし、私のオープンソースライブラリでできることも好きですが、この言語で自分の考えを表現するプロセス自体が本当に好きです。これはほとんどの皆さんにも当てはまると思いますが、他の多くの言語ではそうではないでしょう。これが、異なるプログラミング言語の愛好家がLLM支援の未来が明るいか暗いかについて異なる意見を持つ理由の一部を説明しています。 コードを生成すると、その楽しみの多くが危険にさらされます。だから、やらない方がいいかもしれません。 私は（少なくとも楽しい部分の）Haskellプログラムを書き続けたいと思っており、生成されたコードを（あまり）読み、レビューする必要がないようにしたいです。同時に、私の脳をゆっくりと燃え尽きさせない、良い用途にそのトークンを使いたいと思っています。私は、LLMとの生産性を適度に向上させながら、プログラミングの楽しみを維持する方法を示したいと思っています。単にLLMに依存しないという選択肢もあります。その場合、あなたはすでに自分のやり方を知っているでしょう。しかし、そうしたくない理由があるかもしれません。例えば、実際に生産性の向上をもたらす必要がある場合、あるいはチーム、会社、業界全体がLLMの採用を積極的に進めている中で、取り残されたくない場合です。 コードを書き続ける コードベースを所有し続けたいなら、コードを書き続ける必要があります。すべてを生成させてしまうと、コーディングエージェントだけが繁栄できるLLMの荒野になってしまいます。だから、コードを書き続けるべきです。そうでなければ、あなたのコードベースは最終的に失われます。 コードを書き続けるもう一つの理由は、良いプログラマーであり続けることです。スキルは練習しないと失われます。そしてここでは、コーディング作業をやめてエージェントに任せる敷居が非常に低いため、リスクは特に高くなります。数週間コーディングせず、すべてをエージェントに任せると、自分でコーディングに戻るのが困難になることに気づくでしょう。 LLMは宣伝されているよりも、人間が読みやすい良いコードを生成するのがはるかに苦手です。それらは、後で自分たち自身が排他的に作業するコードを生成することにはある程度適しています。しかし、あなたはすでに、どこかにバグが含まれているはずの完全に生成されたファイルを見て、人間としてのあなたの能力ではそれを見つけることができないという絶望を経験したことがあるでしょう。なぜなら、その状況はあまりにも異質だからです。 では、エージェントにコーディングを任せるのではなく、生産性向上をどのように実現できるのでしょうか？ エージェントに、それ以外のほとんどの作業を任せることで。特に、あなたにとって面倒な退屈な作業です。理想的には、正しく行うのがそれほど難しくなく、チェックしやすいタスクです。 計画 コンピューターの最も初期の歴史から、それらは常に会計ツールとして使用されてきました。LLMもそのように使用してください。とりわけ、それは、フォーマルなインターフェースの代わりに自然言語でアドレスできる会計ツールです。ドメインエキスパート間の巨大な会話を、実行可能なToDoに変換します。何かをテストし、テスト結果を書き留め、それを欠陥を修正するための計画に整理させます。ToDoツール、あるいはフロントマター付きのMarkdownファイルのようなものを使用して、計画項目を適切に追跡させます。 LLMは巨大なコンテキストを持つことができますが、それでもコンテキストがいっぱいすぎると、情報を静かに失う可能性があります。しかし、重要な決定はさせないでください。あなたに尋ねさせます。質問が理解できない場合は、関連するコンテキストを提供しないLLMのせい（または、あなたが疲れて休憩が必要な場合）です。同じ問題に何度も戻ってくる場合は、画面から一歩離れて自分で考えてみてください。そして、何をしたいのかが明確になったら戻ってきてください。 調査 エージェントに調査タスクを与えるとき、それがクエリを実行して「考えている」のを見るのは魅力的です。別のプロジェクトで別のエージェントを起動したり、コーヒーを淹れに行ったりします。これら3つのうち、コーヒーを淹れるのが最善の選択肢です。 より良い選択肢は、昔ながらの検索エンジンを使って自分で並行して調査することです。エージェントが知るであろうすべてのことを、少なくとも大まかに知っておいてください。単に調査させて、その結果を事実として受け入れ、そこから計画を立てないでください。これは、恥ずかしい技術的負債につながります。 エージェントに調査させるポイントは、関連知識をすべて提示させることでも、あなたができるよりも良い決定を下させることでもありません。ポイントは、あなたが「私にそれをグーグルさせて」という状態にならないことです。あなたがモデル化しているドメインを、エージェントと同じくらい、理想的にはそれ以上に理解している必要があります。 エージェントに、使用したリソースへのリンクとともに、調査結果をどこかに書き留めさせます。後で戻ってきて奇妙な提案をされたときに、調査結果とどのリソースがそれを言っているのか尋ねてください。50％の確率で、エージェントは自分の間違いを発見するでしょう。残りの50％では、それを読んで、自分で良い決定を下せるようになります。 あなたはコーダーです これがゲームチェンジャーです。典型的なコーディングハーネスは、「まず計画し、それからエージェントにコーディングさせる」という誘惑に駆り立てます。拒否してください。一緒に計画しますが、その後はあなたがコードを書きます。 LLMにコードベースを調査させ、現在のToDoを知らせ、編集する必要があるすべての場所を提示させ、潜在的な落とし穴に言及させ、関連する背景調査を思い出させます。 私はこのワークフローで作業しており、それは非常に楽しいです。以前よりも仕事を楽しんでいます。 時にはLLM以前よりも楽しんでいます。 常に明確なToDoがあり、全体的な計画を心配する必要がなく、集中できます。計画がしっかりしているため、ToDoはすぐに完了します。それはアジャイルのようですが、すべての面倒なプロセスはありません。 エージェントをあなたの働き方に合わせます。逆ではありません。 あなたは経験豊富なプログラマーで、すでに自分の働き方を最もよく知っているかもしれません。あなたがそれほど楽しんでいない付随的な作業をすべてエージェントに任せます。 このワークフローにはいくつかの利点があります。 - あなたは自分が楽しんでいることをし続けます。プログラミングが好きなら、それをしてください。 - コードベースがどのような状態にあるかを常に把握しています。自分の気分でコーディングしたセッションから奇妙な生成されたものに驚いたことはありますか？LLMのゴミを書き直す必要がありましたか？セッションのどこにいるかを見失いましたか？この方法なら、二度とそうする必要はありません。 - 悪い計画を早期に発見します。エージェントコーダーは、あなたがすぐに悪いアイデアだと認識するもので延々と進むかもしれません。 - スキルを磨き続けます。明らかに。 あなたは良いプログラマーであり続けるか、さらに改善していくでしょう。 コーディングエージェントが有用なまれなケース クリーンアップ、小さなタスク、ルーチンワーク、低リスクのリファクタリングに最適です。 コードにFIXMEを残しました（ま