Автор заметки сравнивает LLM-assisted coding с так называемым проклятием Lisp. В исходной формулировке гибкость Lisp позволяет разработчику легко создать собственное решение вместо поиска и изучения чужой библиотеки. В результате программисты дольше работают изолированно, заново изобретают типовые компоненты и реже формируют общие фреймворки. Написанный для узкой задачи код нередко сложнее документировать и понимать, поэтому следующий разработчик снова предпочитает собственную реализацию.
По наблюдению автора, в обсуждениях LLM всё чаще звучит похожий аргумент: сгенерировать функциональность будто бы дешевле и проще, чем разобраться в интерфейсе существующей библиотеки. Он рассматривает последствия такого подхода как мысленный эксперимент, специально отмечая, что не согласен с исходной посылкой. Зрелые библиотеки проверены большим числом разработчиков и CI-пайплайнов, а их поддержкой занимаются специалисты.
Если генерация действительно заменит использование готовых решений, первым эффектом станет сокращение аудитории open-source проектов. Пользователи будут реже сообщать о проблемах и давать maintainers обратную связь, поскольку смогут получить локальное решение за несколько prompts и небольшую плату за токены. Им также не придётся читать документацию или принимать во внимание чужие API-решения.
Второй эффект — замедление появления новых библиотек. Публикация кода требует не только рабочей реализации, но и структурирования, инфраструктуры, репозиториев артефактов, версионирования, обратной совместимости и постоянных обновлений. Если собственный сгенерированный модуль уже решает задачу, у автора меньше причин проходить весь этот путь и делиться результатом.
Эти процессы способны усиливать друг друга. Чем меньше библиотек интегрирует новые технологии в экосистему, тем чаще разработчики будут генерировать изолированные решения. Автор называет такой подход Not generated here по аналогии с Not invented here.
Он не утверждает, что LLM исчезнут или полностью уничтожат open source. Более вероятным ему кажется постепенный, частично случайный сценарий: совместной работы станет меньше, а разработка — более одиноким занятием. При этом лично он предпочитает проверенные абстракции сотням строк кода, созданным для одной локальной задачи.