Kenton Varda — один из наиболее узнаваемых системных инженеров в мире edge-computing, архитектор Cloudflare Workers — публично объявил о моратории против AI-написанных описаний изменений в коде. PR, коммиты, issues, тикеты — всё это теперь пишут только люди. Причина сформулирована точно:
«AI описывал детали кода, которые можно увидеть просто посмотрев на код, но упускал высокоуровневый фрейминг, необходимый чтобы понять что вообще делает этот код» — Kenton Varda
Это не жалоба на качество текста. Это диагноз структурной проблемы в том, как AI интегрируется в инженерный процесс.
Контекст
Та же неделя, когда вышла эта цитата: Simon Willison — создатель Django, активный хроникёр AI-тулинга — публикует sqlite-utils 4.0, проект почти полностью написанный Claude Fable за $149. То есть AI уже пишет production-код. Но объяснить, что именно и зачем было сделано — не умеет. Это не противоречие, это карта территории.
AI-ассистенты в разработке (Cursor, GitHub Copilot, агентные пайплайны) стали стандартом для команд, которые хотят скорости. Описания PR начали генерироваться автоматически — кажется, экономия времени. На практике это создаёт иллюзию документации: место заполнено, поле не пустое, ревьюер открывает, читает, тратит внимание и не получает ничего, что не было бы видно из самого diff.
Проблема не новая — плохие commit messages существовали задолго до AI. Но раньше пустое сообщение хотя бы было честным. Теперь оно выглядит как документ и при этом ничего не сообщает. Это хуже: создаёт видимость процесса без его содержания.
Аналитика
Суть — в разнице между «что» и «зачем». AI читает diff и транскрибирует его: добавлен метод X, изменён параметр Y, удалена строка Z. Всё это ревьюер видит сам. Чего AI не знает — это намерение. Почему этот рефакторинг нужен именно сейчас? Какой баг он закрывает? Какой архитектурный принцип реализует? Что изменится в поведении системы для пользователя? AI не имеет доступа к этому контексту — он видит только файлы и историю git.
Хорошее описание PR — это акт коммуникации, не транскрипция. Оно требует понимания цели задачи, истории обсуждений в команде, знания того что было до. Когда AI заполняет это поле красиво звучащим текстом без намерения, происходит следующее: ревьюер психологически «закрывает» задачу описания («документация есть»), хотя реальной коммуникации не произошло. Это когнитивная нагрузка без информационной отдачи.
Масштаб проблемы растёт пропорционально проникновению AI в разработку. Сегодня AI пишет 20-40% кода в активно использующих его командах, по различным оценкам. Завтра — больше. Ревью кода — последний барьер, где человек видит изменения и принимает решение об их безопасности и корректности. Если описания деградируют, этот барьер становится формальным. Это структурный риск, который не решается никаким улучшением модели — это вопрос процесса.
Кейсы применения в бизнесе
B2B-SaaS стартап (5–12 разработчиков): команда активно использует Cursor или агентные пайплайны для написания кода. Ввести правило: AI-код приходит с человеческим описанием. Шаблон PR: «Что изменилось (1 строка) → Почему именно сейчас → Как проверить → Что могло сломаться». Реализация через GitHub PR templates с обязательными полями. Эффект — ревью ускоряется, онбординг новых членов команды упрощается, история изменений становится читаемой через 6 месяцев.
Корпорация с legacy-кодом: если AI-ассистенты уже развёрнуты и описания генерируются автоматически, первый шаг — аудит последних 30–50 PR: можно ли понять цель изменения без чтения кода? Если нет — не запрет AI, а добавление обязательного поля «Намерение» в PR template, которое заполняет только автор. AI не трогает это поле. Остальное — пусть генерирует.
SMB и локальный бизнес в КР/СНГ: для команды из 1–3 разработчиков проблема острее — там нет полноценного code review. Но именно здесь история изменений критична: через год нужно понять, почему была добавлена эта функция. Commit message — это документация. «Updated user model» ничего не говорит. «Добавлен флаг is_verified для соответствия требованиям КР-compliance, Закон №178» — говорит всё.
Кейсы в личной жизни
Разработчик: если активно используешь AI-ассистентов, заведи одно правило — описание PR пишешь ты, до того как смотришь что предложит AI. 2–3 минуты. Это заставляет формализовать намерение и часто выявляет дыры в логике до того, как ревьюер их найдёт. Побочный эффект: начинаешь лучше понимать собственный код.
Контент-мейкер / продуктовый менеджер: та же проблема в описаниях задач, тикетах, postmortem-документах. AI структурирует текст, но не знает почему задача важна. Гибрид: AI форматирует и структурирует, человек заполняет поля «намерение» и «контекст». Это быстро и информативно одновременно.
Студент / начинающий разработчик: написание хороших commit messages — недооценённый навык. Это не бюрократия, это умение формулировать намерение кратко и точно. Именно этот навык будет отличать старших разработчиков от AI-операторов — потому что AI никогда не знает зачем, он знает только что.
Как применить сегодня
- Введи правило в команде: код — AI, описание PR — только человек. Достаточно 3–5 строк о намерении.
- Создай PR template с обязательными полями: «Намерение», «Как проверить», «Риски». AI не заполняет эти поля — они для автора.
- Проверь свои последние 10 коммитов: понятно ли зачем каждый из них — без чтения diff? Если нет — это технический долг коммуникации.
- Если используешь AI для помощи с описаниями — уточняй промпт явно: «Объясни ЗАЧЕМ этот код существует, а не что он делает. Не описывай синтаксис — описывай намерение и контекст задачи».
- Для команд с CI/CD: рассмотри commitlint или аналог — lint на commit messages, который требует категорию и осмысленное описание. Пустые или шаблонные сообщения блокируют pipeline.