/note/tech

Does code quality still matter?

要約:

■ 1. 問題提起

  • コード品質の存続性:
    • 正直なところ答えは分からないが、いずれ判明する
    • LLMがプログラマーより速くコードを書くという話がSNSやポッドキャストに溢れている
      • グリーンフィールド開発だけでなく、既存のコードベースにおいても同様
  • 人間が責任を負う限りの品質:
    • LLMを人間が最終責任を負うコード生成の道具として使う限り、コードの品質は依然として重要
    • 人間がそのコードをレビューし、扱い、バグを修正する必要があるため
    • 問題は人間がループから外れた場合に何が起こるか
  • Tim Ottingerの問い:
    • LLMなしで人間が手書きでコードベースをYOLOすることを許すのかという問い
    • それが悪い考えだと言うなら、なぜLLMなら許されるのかという問い
      • なぜエージェントの書いたコードだけが見逃され、人間のコードは見逃されないのか
    • Ottingerの主張はやや別の論点だが、数年来考えてきた問いに十分近い
      • 将来LLMがすべてのコードを書くなら、コード品質は重要かという問い

■ 2. コード品質が重要な理由

  • YOLOの意味:
    • コード品質を顧みずにコードを書くこと
    • この慣行は率直に言って何十年も支配的であった
  • 技術的負債の帰結:
    • コードベースをYOLOさせる開発組織は、いずれ問題を抱えることになる
    • 技術的負債が蓄積し、ビジネス上の要求に迅速に応えられなくなる
  • コード品質とソフトウェア品質の区別:
    • コード品質はコードベースの内在的な性質
    • コードがどう構造化され、どれだけ読みやすく、どれだけ変更しやすいか
  • 人間の認知への還元:
    • これまでコード品質は究極的にはすべて人間の認知の問題に還元できた
    • それが著書 Code That Fits in Your Head の要点
    • 人間がコードを書き、人間がそれを編集してきたため

■ 3. LLM向け言語

  • 思考実験の前提:
    • 人間がもはやコードを書きも読みもしない未来を想定する
  • 人間の認知制約の無効化:
    • 人間がコードを扱わないなら、人間の認知に関わる制約はすべて無意味になる
    • 結果として長いメソッド、高い循環的複雑度、不可解な変数名、密結合が生じうる
  • 概念自体の消滅:
    • それらの概念が意味を成さなくなる可能性すらある
    • 長いメソッドという概念は、ソフトウェアがメソッドを持つ形で表現されていることを前提とする
    • 機械語にはメソッドが存在しない
  • 機械語生成の非現実性:
    • LLMが機械語を直接生成するとは現実的に考えていない
    • 機械語は可搬性を欠くため
  • LLaMeという仮想言語:
    • 想定する未来において、LLMが現在存在する言語に留まると考える理由はない
    • 機械語を除くすべてのプログラミング言語は、人間のプログラミングを容易にするために存在する
    • 誰もコードを見ないなら、LLMが消費・生成・操作するのに最適化された言語が生まれうる
    • 議論のため、そうした言語が1つだけ現れると仮定し、LLaMeと呼ぶ

■ 4. LLaMeの技術的負債

  • 負債発生の可能性:
    • 将来のLLMがLLaMeでコードを書くとき技術的負債を蓄積するかは分からない
    • 問題化しないのであれば、以降の議論は無意味になる
  • 構造選択の余地:
    • 技術的負債が依然として蓄積しうることは想定できる
    • 機械語ですらコードの構造化には選択の余地がある
      • レジスタを再利用するか、1つの演算に2つの異なるレジスタを使うか
  • 構造による差:
    • LLaMeも代替的なコード構造を許すと想定せざるを得ない
    • 一部の構造は他より変更しにくい
    • 一部の構造はLLMが理解するのにより多くの資源、すなわちトークンを要する
    • 構造の良いLLaMeコードは機能追加とバグ修正を速く安価にする
    • 構造の悪いLLaMeコードは改善により多くの時間と費用を要する

■ 5. 負債回避の知見不足

  • 良し悪しの未知:
    • 悪いLLaMeコードがどのようなものかは分からない
    • LLaMeがどのようなものかも、どのパターンやイディオムが有益かも分からない
  • 人間の経験の性質:
    • 人間は世代を超えて経験を蓄積し、何が有効で何が有効でないかを知っている
    • 蓄積された知見の例:
      • 長いメソッドを避ける
      • 記述的な名前を使う
      • 結合に注意する
    • しかしその経験はすべて人間の認知の制約と深く絡み合っている
  • 知見の転用不能:
    • LLMは人間の経験から学ぶことができない
    • 書籍、カンファレンス講演、ポッドキャスト、ブログ記事はすべて人間の問題を扱っている
    • それらがLLaMeの技術的負債回避に適用される見込みは薄い
    • LLMは自らの経験から学ぶほかない

■ 6. 学習の加速

  • 自己経験からの学習:
    • LLMが現在自らの経験から学んでいるかは分からないが、可能ではあると考える
    • LLMが他のLLM向けにインシデント報告や論考を書くことはありうる
  • 世代間の継承:
    • LLMは人間よりはるかに速くそれを行える
    • 前世代が学んだ経験で次世代のコーディングLLMを訓練することは可能と考える
    • 人間が同種の知識を吸収するよりはるかに速く進みうる
  • 一時的問題という見通し:
    • LLaMeの技術的負債は数年間問題になり、その後解決される可能性がある
    • LLMはコードをYOLOせず、適切なLLaMeのコーディング作法に従うようになる

■ 7. 結論

  • 制約の所在:
    • コード品質が人間のプログラマーにとって重要なのは認知の制約によるもの
    • LLMは人間と同じ制約は受けないが、独自の制約を持つ可能性がある
    • そうした機械側の制約が技術的負債を生み、開発と改善においてLLMを遅らせうる
  • 三つの可能性:
    • 問題が決して顕在化しない可能性がある
    • 問題がしばらく現れ、その後解決される可能性がある
    • 問題が解決されないままとなる可能性がある
  • 解決不能のリスク:
    • 問題が起きた場合、人間には解決できない問題を抱えることになりうる
    • 制約が人間の認知をはるかに超えており、原因究明の見込みがない
  • 思考実験の含意:
    • 人間の監督なしにLLMにソフトウェアを作らせることは、多くのAI楽観論者が語るよりも複雑になる