Соавтор Kubernetes Крейг Маклаки 12 июня 2026 года описал проблему, которую многие разработчики уже успели почувствовать на практике: AI в open source приносит не только ускорение, но и поток мусорных pull request. Для русскоязычной IT-аудитории это важный сигнал: если код теперь дешевле, то дефицитом становятся не строки, а внимание мейнтейнеров, инженерная дисциплина и нормальная командная культура.
В подкасте InfoQ Маклаки, сегодня CEO Stacklok и один из создателей Kubernetes, довольно жестко сформулировал происходящее. По его словам, open source-сообщества исторически оставляли часть простых задач открытыми намеренно: помечали их как good first issue, чтобы начинающие инженеры могли войти в проект, разобраться в кодовой базе и получить обратную связь от опытных участников. Теперь эта схема начинает ломаться. Как только такая задача появляется, в течение дня на нее могут прилететь десятки AI-сгенерированных PR, которые формально что-то «чинят», но не соответствуют стилю проекта, его архитектуре и реальной логике развития.
Проблема не в самом факте использования ассистентов для кодинга, а в том, что издержки перекладываются на тех, кто и так держит проект на себе. Мейнтейнеры open source всегда тратили время на ревью чужого кода, это часть негласного контракта сообщества. Но одно дело — ревьюить вклад человека, который пытался понять систему и осознанно сделал изменение. Другое — разбирать поток сгенерированного кода, который выглядит правдоподобно, но требует ручной проверки почти по каждой строчке. В итоге AI в open source может не снижать, а повышать стоимость сопровождения: коммитов больше, пользы не обязательно больше, усталости у команды точно больше.
У Маклаки здесь особенно весомая оптика. Он не просто комментатор со стороны: в Google он вместе с Джо Бедой занимался запуском Google Compute Engine, а затем вместе с Бедой и Бренданом Бёрнсом участвовал в создании Kubernetes. Позже он был среди тех, кто помогал запускать Cloud Native Computing Foundation, а после продажи своего первого стартапа VMware отвечал за портфель Tanzu. Когда человек с таким бэкграундом говорит, что open source переживает серьезное давление из-за AI-кодинга, это не похоже на очередную моральную панику вокруг новых инструментов.
При этом Маклаки не сводит разговор к жалобе на «плохой AI». Его тезис шире: похожая динамика уже заметна и внутри обычных инженерных организаций. Если дать команде генеративные инструменты без правил, ограничений и внятных критериев качества, она может начать производить больше кода без соответствующего роста полезной поставки. Для бизнеса это неприятный сценарий. На дашбордах активность вроде бы растет, pull request и diff-ов больше, но фичи не едут быстрее, техдолг не уменьшается, а трение между людьми только усиливается. И это один из самых важных моментов для CTO, VP Engineering и техлидов: AI ускоряет локальную генерацию, но легко замедляет коллективную разработку, если не перестроить процессы под новую реальность.
Отсюда Маклаки переходит к теме, которая вынесена в заголовок подкаста: культура как операционная система команды. Формулировка не новая, но в его версии она звучит довольно прикладно. Культуру, по его мнению, нельзя считать чем-то самозаводящимся. Ее нужно проектировать намеренно, подкреплять ежедневными действиями и пересобирать, когда меняются требования бизнеса. Иначе организация начинает жить по случайным стимулам: где громче KPI, там и правда; где проще нагенерировать код, там и создается видимость прогресса. На фоне AI-инструментов этот разрыв становится опаснее, потому что команды получают возможность быстро увеличивать объем изменений, не договорившись, что именно они считают хорошей инженерной работой.
Самая резкая формула Маклаки — «лицемерие убивает культуру». Для инженерных компаний это, пожалуй, важнее всех разговоров о промптах и агентах. Если руководство декларирует качество, ответственность и пользовательскую ценность, а поощряет только скорость выкладки и количество закрытых задач, команда очень быстро понимает реальный сигнал. Тогда AI начинает использоваться не как усилитель сильных инженеров, а как инструмент для наращивания видимости. В таком режиме организация действительно может писать больше, но понимать меньше. А это уже прямой путь к усталости от ревью, конфликтам вокруг стандартов и деградации доверия внутри команды.
Еще один неприятный вывод касается карьеры разработчиков. Традиционный путь роста в профессии долгое время был довольно понятным: джун делал рутинные и небольшие задачи, через них учился разбираться в системе, получал насмотренность на ошибки, архитектурные компромиссы и внутреннюю кухню продукта. Если эти ранние задачи первыми уходят к AI, то ломается не только рынок найма, но и сама механика формирования инженера. Маклаки фактически говорит о разрыве в обучающем конвейере: индустрия рискует потерять слой практики, на котором раньше выращивалось глубокое системное понимание. Для HR в IT и руководителей команд здесь вопрос уже не в модных инструментах, а в том, как строить онбординг, менторство и оценку потенциала, когда «маленькая работа для старта» исчезает или уходит агентам.
На уровне отрасли это поднимает и более широкий вопрос: что вообще будет с привычной модульной моделью разработки, на которой вырос open source последних лет. Если хороший код становится дешевле в производстве, а генерация все сильнее сдвигается в сторону требований, спецификаций и управления агентами, изменится не только вклад отдельных разработчиков, но и ценность существующих экосистем. Пока рано объявлять конец open source или смерть библиотек, но спор уже идет не о том, можно ли генерировать код, а о том, где в этой цепочке теперь находится настоящая инженерная работа. Оригинальный разговор Маклаки можно проверить в материале .