コードを書く時間が短くなると、変更してから結果を確かめるまでの待ち時間が、開発時間に占める割合を増す。LLMによる開発でも、生成速度だけでなく、ビルド、起動、状態の再現、検証までを含めた一回の修正にかかる時間で開発環境を評価したい。
Vivien Henz は Common Lisp の利点として、動いている環境で関数を更新し、結果をすぐ試せることを挙げている。この主張から残したいのは特定の言語が最良だという結論よりも、生成が速くなるほど検証までの待ち時間を短くする価値が増すという考えだ。
https://www.vivienhenz.com/common-lisp
Common Lisp の仕様は、コンパイル時と実行時を区別しながら、同じ Lisp イメージ内で実行時コンパイラを利用する仕組みを定めている。コンパイルが不要なのではなく、変更を試すために環境全体を作り直す負担を減らせる点が、この議論に関係する。
https://www.lispworks.com/documentation/HyperSpec/Body/03_ba.htm
ただし、結果が早く返ることと、正しい結果を判定できることは別だ。何を確かめるかが曖昧なままでは、短い周期で同じ誤りを繰り返せるだけになる。評価を改善の運用周期として設計するときも、判定条件を定めたうえで、変更から検証までの時間を短くする必要がある。