HN 日本語サマリー

← 一覧へ戻る
プログラミング

LLM生成コードを手動で打ち直してコグニティブ・デットを防ぐ

Prevent cognitive debt by manually retyping LLM-generated code (ankursethi.com)

475 pointsby mpweiher384 コメント

要約

LLM(大規模言語モデル)が生成したコードをそのまま使用すると、コードの理解が追いつかず、コグニティブ・デット(認知的負債)が生じます。著者は、LLMにコードを生成させる際に、それをチャットに表示させ、自身で手動で打ち直すという非効率ながらも理解を深めるワークフローを提唱しています。この方法により、コードの品質を保ちつつ、自身の知識として定着させることができると述べています。

全文翻訳

4月に言ったこととは裏腹に、私は個人的なプロジェクトでコーディングアシスタントを使い続けています。 これらのアシスタントを使って、まるごと一つの機能を一度に生成させると、私は満足できず、方向性を見失ってしまいます。しかし、プロジェクトの退屈な部分を高速化するために使うのは楽しんでいます。 しかし、コーディングアシスタントを私のプロジェクトで自由に動かすことは、私に膨大なコグニティブ・デットを残します。 ウェブサイトにタグ付けを追加する方法を理解するためにDjangoのドキュメントを熟読するアイデアを嫌うかもしれませんが、それでも根本的にはそれがどのように機能するかを理解したいのです。 問題が退屈であるという理由だけで、その解決策の理解を完全に機械に委ねたいわけではありません。 もちろん、LLMが生成するコードのすべての行を確認することはできます。 それが2026年という呪われた年に、ほとんどの開発者に期待されていることです。 ロボットがPR(プルリクエスト)を作成し、人間がそれをレビューします。 それは素晴らしい新世界です。 しかし、私はAI生成のPRをレビューするのが好きではありません。 過度に防御的で、コメントが悪く、微妙に間違っている何百行ものコードを熟読するのは楽しくありません。 雇用主のためなら渋々やるかもしれませんが(そして、できるだけ早くその雇用主が元雇用主になるようにしながら)、自分の個人的なプロジェクトのためにそれをやるつもりは毛頭ありません。 個人的なプロジェクトは、何よりもまず楽しいものであるべきです。 個人的なプロジェクトに取り組む喜びは、結果からではなく、プロセスから生まれます。 では、少年は何をすべきでしょうか? どのようにして、自分の仕事と認知をスロップマシン(ゴミ処理機)に委ねることなく、退屈な仕事をLLMにオフロードできるでしょうか? 私は、非常に非効率的で、おそらく少し滑稽な解決策を思いつきました。 それは、コーディングアシスタントにチャットでコードを生成させ、その後、すべての編集を自分自身で手動で行うことです。 私は、私の個人的なプロジェクトのすべてのエージェントファイルに、これらの指示を入れています。 「このプロジェクトに入るコードのすべての行を理解したいです。 明示的に依頼されない限り、プロジェクトファイルを新規作成、編集、移動、名前変更、または削除しないでください。 代わりに、すべての提案された編集をチャットに表示してください。私が手動で入力できるように。」 「明示的に要求されない限り、プロジェクトファイルを変更したり、依存関係をインストールしたり、リポジトリの状態を変更したりするコマンドを実行しないでください。 代わりに、それらのコマンドをチャットに表示してください。私が手動で実行できるように。」 「私は経験豊富な開発者です。 明示的に依頼されない限り、構文、API、プログラミングの概念、または実装の詳細を説明しないでください。」 LLMをこのように使用すると、LLMを使用しない場合よりも速く作業できますが、それでも、機械に自分の代わりに考えてもらうことをいとわない人々よりも遅いです。 10倍速くなる代わりに、おそらく2倍速くなるだけです。 しかし、速度で失うものを、コードに対するより深い理解によって補っています。 LLMが生成したコードのすべての行をエディタに手動で入力する際に、それがどのように機能し、既存のコードベースにどのように適合するかについてのメンタルモデルを構築します。 APIやアルゴリズムを理解できない場合は、それを調べて停止したり、LLMに説明を求めたりできます。 自分でコードを入力することは、私をスローダウンさせます。これは、LLMが行った可能性のある幻覚や悪い設計上の選択を検出する可能性が高くなることを意味します。 作業を進めながらコードをクリーンアップし、再編成し、リファクタリングし、コメントを追加し、一般的に自分の好みに合わせて調整できます。 最も重要なことは、このワークフローにより、コードベースの空間的なマップを構築できることです。 コードベースのどこにどの機能が存在するかを知っています。 変更を行う必要がある場合は、どこを変更する必要があるかを正確に把握しています。 これは、プロジェクト内でより速く作業するのに役立つだけでなく、将来的にLLMをより良くプロンプトし、指示するのを容易にします。 10代の頃、コーディングを学んでいたとき、経験豊富なプログラマーはよく、コードをプロジェクトにコピー&ペーストしないように言われました。 本から学んでいる場合、すべての例をコンピューターにコピーして、実行できることを確認するように勧められました。 ブログ記事やフォーラムの回答から学んでいる場合、それをタイプアウトしてコードベースに適応させ、完全に理解するように勧められました。 LLM生成コードをコードベースに手動で入力することは、まったく同じ学習プロセスのように感じられます。 LLMと連携する最も効率的な方法ではないかもしれませんが、生産性よりも理解を重視しています。 私はこれを数ヶ月間行っており、うまくいっています。 できる限り、このワークフローを使い続けるつもりです。 私は、ソフトウェア業界が、私たちが非常に早く返済しなければならない、大量のコグニティブ・デットを抱え込んでいるのではないかと恐れています。 私たちのデジタルインフラストラクチャの大部分がどのように構築されているかを理解しなくなる時が来るでしょう。 私個人が業界全体の方向性を変えることはできないかもしれませんが、少なくとも私が世に送り出すソフトウェアを完全に理解していることを確認できます。 それ以外は専門職としての不正行為でしょう。