「Lispの呪い」とは、プログラミングにおける歴史的な現象を指します。Lisp言語の極めて高い能力と柔軟性により、開発者は独自のソリューションを非常に容易に作成することができ、その結果、共有ライブラリを回避することが頻繁に起こりました。他者の特定の抽象化や「思考の枠組み」を学ぶよりも、独自の解決策を書き上げる方が速かったため、Lispのエコシステムには他の言語に見られるような中央集権的なフレームワークが不足することが多々ありました。この孤立は、再利用可能なコンポーネントの不足を招きました。開発者はプライベートな環境で「車輪の再発明」をすることを好んだため、結果として第三者が理解したりメンテナンスしたりすることが困難なコードが生成されることが多かったのです。
Tim Zöllerは、大規模言語モデル（LLM）が現在、Javaのような主流のエコシステムにこの「呪い」をもたらしていると主張しています。LLMによって、わずか数個のプロンプトから機能的なコードを生成することがより安く、より速く行えるようになるにつれ、確立されたライブラリのドキュメントを調査したり、インターフェースを学習したりする動機が薄れていきます。もし開発者がわずか数ドルのトークン費用で20分以内にカスタムモジュールを生成できるのであれば、特定のAPIやバージョニングを理解する必要がある、コミュニティでテストされた安定したライブラリを統合する際の摩擦は、大きな障壁となります。この変化は、ソフトウェアが共同での問題解決を通じて構築されるのではなく、孤立して構築される、より個人主義的な開発モデルへとつながる可能性があります。
この傾向は、オープンソースモデルに対して二重の脅威をもたらします。第一に、ライブラリの使用減少はメンテナンス担当者へのフィードバックループを減少させ、既存プロジェクトの維持を困難にします。第二に、新しいライブラリの創出が停滞する可能性があります。オープンソースの「難しい部分」であるモジュール化、ホスティングインフラ、および後方互換性の維持は、開発者が自身の即時的なニーズに正確に合わせた使い捨て可能なローカルモジュールを簡単に生成できる場合、魅力が低下してしまいます。一部の開発者は、LLMによって既存のライブラリを統合することが実際に容易になると主張していますが、他の人々は、AIが生成したコードによって個々の人間の貢献を区別したり評価したりすることが困難になる「ゴミの海（sea of slop）」について警告しています。このトレードオフは、成熟したソフトウェアエコシステムが提供する安定性と集合的な知識を犠牲にして、極端なカスタマイズとスピードへと向かう動きを意味しています。