/note/tech

Does code quality still matter?

要約:

■ 1. 問題提起

  • コード品質はまだ重要か:
    • 正直なところ分からないが、いずれ判明する
  • LLMによるコード生成の喧伝:
    • SNSのフィードやポッドキャストは、LLMがプログラマより速くコードを書くという話であふれている
    • 新規開発だけでなく、既存のコードベースについても同様に語られる
  • 人間が責任を持つ限り品質は重要:
    • LLMを人間が最終的に責任を負うコードの生成ツールとして使う限り、コードの品質は依然として重要
    • 人間がそのコードをレビューし、扱い、バグを修正する必要があるため
  • 人間がループから外れた場合の問い:
    • 人間が関与しなくなったとき何が起こるかが本当の論点

■ 2. 発端となったツイート

  • Tim Ottingerの問い:
    • LLMなしで人手でコードベースをYOLOすることを許したらどうなるか、それは悪い考えか
    • ではなぜLLMならそれが許されるのか、なぜエージェントのコードだけが免罪されるのか
  • 引き取り方:
    • Ottingerはやや別の妥当な論点を提示しているが、自分が数年考えてきた問いに十分近い
    • すなわち、将来LLMがすべてのコードを書くなら、コード品質は重要かという問い

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

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

■ 4. LLM向けプログラミング言語

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

■ 5. LLMにとっての技術的負債

  • 負債が生じない可能性:
    • LLaMeで書くLLMが技術的負債を溜めるかは分からない
    • 問題化しないなら、以降の議論は無意味であり、永久にYOLOし続ければよい
  • 負債が生じうる根拠:
    • 機械語ですら、コードの構造化には選択の余地がある
    • レジスタを再利用するか、演算に2つの異なるレジスタを使うかといった選択が存在する
  • LLaMeにおける構造の優劣:
    • LLaMeも代替的なコード構造を許すと仮定せざるを得ない
    • 一部の構造は変更が困難であり、一部はLLMの理解により多くの資源、おそらくトークンを要する
  • 構造がもたらす差:
    • 良く構造化されたLLaMeコードは、機能追加とバグ修正を速く安価にする
    • 悪く構造化されたLLaMeコードは、改善により多くの時間と費用を要する

■ 6. LLMは技術的負債を防げるか

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

■ 7. 加速

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

■ 8. 結論

  • 品質が問題となる理由の対比:
    • コード品質が人間のプログラマにとって重要なのは認知の制約による
    • LLMは人間と同じ制約は受けないが、独自の制約を持つ可能性がある
  • 機械側の制約と技術的負債:
    • そうした機械側の制約が技術的負債を生み、ソフトウェアの開発と改善においてLLMを遅くしうる
  • 3つの可能性:
    • 問題が一度も顕在化しない可能性がある
    • 一時的に現れた後に解決される可能性がある
    • 解決されないままとなる可能性がある
  • 人間が手出しできない事態:
    • 解決されない場合、人間には解けない問題を抱えることになる
    • 制約が人間の認知を大きく超え、原因究明の余地すら残らない
  • 思考実験からの示唆:
    • 人間の監督なしにLLMにソフトウェアを作らせることは、多くのAI楽観論者が語るより複雑になる