Саймон Уиллисон, разработчик и автор, регулярно пишущий о LLM и прикладных AI-инструментах, 14 сентября 2026 года опубликовал короткий комментарий к обсуждению на Lobste.rs о блог-постах, сильнее всего повлиявших на мышление инженеров. Это не анонс модели и не исследовательская работа, но для команд, которые строят продукты на базе LLM, список получился практичным: Уиллисон выбрал тексты о границах абстракций, техническом долге и переходах между инженерной и менеджерской ролью.
Оригинальный комментарий опубликован на сайте Уиллисона: https://simonwillison.net/2026/Sep/14/influences/. В нем он называет три материала: Joel Spolsky — “The Law of Leaky Abstractions”, Will Larson — “Migrations: the sole scalable fix to tech debt” и Charity Majors — “The Engineer/Manager Pendulum”.
Сигнал от Уиллисона: не список AI-инструментов, а инженерная оптика
Главная ценность этого короткого поста — не в самих ссылках как «обязательном чтении», а в том, какую оптику они предлагают для современной AI-разработки. LLM-продукты часто строятся поверх нескольких слоев: модельного API, фреймворка для агентов, векторной базы, пайплайна извлечения контекста, оркестрации задач, мониторинга, биллинга и интерфейса для пользователя. На демо такой стек выглядит цельно, но в эксплуатации сбои почти всегда проявляются на стыках.
Уиллисон пишет, что ранний текст Joel Spolsky подтолкнул его «всегда искать более глубокое понимание слоев под тем, где он работает», потому что абстракции могут протекать. Для читателей Comrad404 это особенно заметно в LLM-системах: библиотека может скрывать промпт, провайдер — детали токенизации, агентный фреймворк — порядок вызова инструментов, а облачная платформа — реальные задержки и лимиты.
«Дырявые абстракции» в AI-стеке
Эссе Joel Spolsky “The Law of Leaky Abstractions” вышло еще в 2002 году: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/. Его основной тезис прост: любая нетривиальная абстракция в какой-то момент начинает пропускать детали нижележащего уровня. Для классического программирования это касалось сетей, SQL, файловых систем и языков высокого уровня. Для LLM-разработки список стал шире.
Практический пример: команда использует готовый SDK для построения RAG-поиска и считает, что «поиск по документам» решен. Затем выясняется, что качество ответа зависит от чанкинга, метаданных, эмбеддингов, лимитов контекста, порядка вставки фрагментов и поведения конкретной модели при конфликтующих источниках. Абстракция «просто подключим базу знаний» начинает протекать.
То же относится к агентам. Фреймворк может обещать удобную схему «модель сама решит, какой инструмент вызвать», но в реальном продукте приходится разбираться с ретраями, идемпотентностью, правами доступа, трассировкой, стоимостью токенов и безопасностью действий. Поэтому совет Уиллисона — понимать нижние слои — звучит актуально именно сейчас, когда многие AI-продукты собираются из быстро меняющихся компонентов.
Миграции как нормальная часть разработки, а не катастрофа
Второй текст из списка — статья Will Larson “Migrations: the sole scalable fix to tech debt” 2018 года: https://lethain.com/migrations/. Уиллисон отмечает, что ему близка мысль Larson: миграции — замена сервиса, переход на другую базу данных, смена архитектурного подхода — не должны восприниматься как уникальные бедствия. Это обычная инженерная компетенция, которую нужно развивать.
Для AI-команд это почти неизбежный сценарий. За один год проект может пройти путь от одного LLM-провайдера к нескольким, от ручных промптов к шаблонам, от простой интеграции chat completion к инструментам, function calling, structured outputs или локальным моделям. При этом бизнес уже зависит от продукта, пользователи ждут стабильности, а накопленные промпты, eval-наборы и логи превращаются в инфраструктуру.
Если команда не умеет проводить миграции, она быстро застревает на первом выбранном стеке. Это влияет не только на стоимость, но и на качество: нельзя спокойно сравнить модели, обновить retrieval-пайплайн, заменить векторное хранилище или переработать агентный контур. В таком контексте статья Larson читается как аргумент за проектирование с учетом будущей замены компонентов: метрики до миграции, обратимые шаги, параллельные прогоны, понятные критерии отключения старой системы.
Карьерный маятник инженера и менеджера
Третий материал — “The Engineer/Manager Pendulum” Charity Majors: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/. Уиллисон пишет, что этот текст был для него «очень влиятельным»: он переживал, что переход из инженерного менеджмента обратно в роль индивидуального разработчика может повредить карьере. По его словам, Majors помогла ему иначе посмотреть на такие переходы: многие сильные специалисты несколько раз двигаются между менеджерской и инженерной траекторией, становясь лучше на обеих сторонах.
Для AI-рынка этот тезис тоже не абстрактен. Командам, которые внедряют LLM в продукт, часто нужны люди на стыке: они должны понимать код, ограничения моделей, продуктовую ценность, риски безопасности, бюджет токенов и организационные процессы. Инженер, который видел менеджерскую сторону, может лучше сформулировать миграционный план или объяснить, почему «быстро заменить модель» недостаточно. Менеджер с недавним инженерным опытом обычно точнее оценивает риски демо, которое еще не готово к production.
Важно, что речь не о романтизации постоянных карьерных скачков. Скорее, это напоминание: в быстро меняющейся области вроде AI опыт на разных уровнях системы — техническом и организационном — может быть преимуществом, а не признаком «неопределившейся» карьеры.
Как использовать этот список в работе с LLM-проектами
Короткий пост Уиллисона не доказывает, что именно эти три статьи обязательны для всех AI-инженеров. Это личный список влияний, опубликованный как комментарий к обсуждению. Но его можно использовать как практический чек-лист для команды.
Первый вопрос: какие абстракции в вашем AI-продукте вы не сможете отладить, если они начнут «протекать»? Например, знаете ли вы, как формируется финальный промпт, какие документы попадают в контекст, как считаются расходы, где логируются вызовы инструментов и что произойдет при смене модели.
Второй вопрос: какая миграция почти наверняка понадобится в ближайшие 6–12 месяцев? Это может быть переход на другую модель, смена векторной базы, переработка схемы eval-тестов или вынос экспериментального агента в отдельный сервис. Если такая миграция выглядит невозможной, технический долг уже управляет продуктом.
Третий вопрос: кто в команде способен связать инженерные детали с организационными решениями? В LLM-проектах слабое место часто находится не только в коде, но и в процессе: кто разрешает доступы агенту, кто отвечает за качество ответов, кто утверждает стоимость inference, кто принимает решение об откате.
Источник Уиллисона остается короткой личной заметкой, а не исследованием и не отраслевым опросом. Поэтому корректнее читать ее как редакционный сигнал от опытного разработчика: в эпоху LLM выигрывают не только те, кто первым подключил новый API, но и те, кто понимает нижние слои, умеет проводить миграции и не боится пересобирать собственную роль по мере изменения продукта.