Разработчики FFmpeg обвинили AMD в безответственном использовании ИИ при подготовке патчей
Разработчики мультимедийного проекта FFmpeg выступили с резкой критикой в адрес AMD из‑за качества отправленных компанией патчей. Поводом стала серия изменений, добавляющих поддержку AMD HIP SDK (Heterogeneous-compute Interface for Portability) под Windows для ускорения обработки видео на GPU AMD. Вместо ожидаемого аккуратного и выверенного кода команда FFmpeg обнаружила в патчах множество бессодержательных и лишних фрагментов, что вызвало подозрения в использовании генерации кода средствами искусственного интеллекта без последующей тщательной ручной проверки.
FFmpeg: «Не шлите AI-патчи без рецензирования»
Представители FFmpeg обратились к AMD с просьбой ответственнее относиться к подготовке изменений: не отправлять автоматически сгенерированный ИИ код, пока он не будет детально отревьюен разработчиком-человеком. По их словам, в представленных патчах было слишком много признаков машинной генерации: избыточные пояснения, бессмысленные конструкции и фрагменты, не имеющие практической ценности для проекта.
Особенно остро была воспринята попытка внедрить такие изменения напрямую в основной репозиторий без предварительной «чистки» и адаптации под стандарты разработки FFmpeg.
Бессмысленные константы и лишняя документация
Среди примеров неудачных решений разработчики FFmpeg привели конкретные случаи. В коде обнаружилась константа с говорящим названием и при этом абсолютно тривиальным содержимым:
```c
const int EIGHT = 8;
```
Смысл подобной записи в контексте проекта вызвал закономерные вопросы: такое объявление не добавляет ясности, не скрывает «магическое число», не несёт дополнительной семантики и лишь засоряет код.
Помимо этого, в патчах была найдена объемная инструкция по установке инструментов разработки (gcc и make) с использованием пакетного менеджера pacman. Для проекта уровня FFmpeg подобные пошаговые руководства по настройке окружения в тексте коммита выглядят чужеродно: они относятся скорее к документации или wiki, чем к изменениям исходного кода. Разработчики отметили, что подобная документация в коммитах бесполезна и лишь отвлекает от сути правок.
Подозрение на ИИ и реакция автора патчей
Необычный стиль и структура правок, наличие бессмысленного кода и явно избыточной документации породили предположение, что значительная часть изменений, по крайней мере, была сгенерирована при помощи ИИ. Главная претензия заключалась даже не в самом факте использования нейросетей, а в отсутствии должного пост-обзора: разработчики AMD, по мнению FFmpeg, не уделили достаточно внимания ручной проверке, позволив машинным заготовкам «проскочить» в финальный вариант.
Автор спорных патчей со стороны AMD, однако, заявил, что, по крайней мере, часть документации была добавлена осознанно. Он пояснил, что включил инструкцию по использованию pacman, написанную им несколько лет назад, и считал её полезной для тех, кто будет собирать зависимости. При этом он признал, что если рецензенты считают такой блок лишним, он готов удалить его из коммита.
Таким образом, часть критики оказалась вызвана не только возможным применением ИИ, но и различием в понимании того, что уместно включать в историю изменений крупного проекта.
Резкий, но показательный ответ FFmpeg
В FFmpeg на это отреагировали довольно жёстко. Представитель проекта извинился за недопонимание контекста, но одновременно подчеркнул, что был удивлён самим фактом: есть разработчики, которые не проводят границу между полноценной wiki-страницей и сообщением к коммиту в системе контроля версий.
Он напомнил базовый, но важный принцип: текст, прикреплённый к коммиту, должен кратко и чётко описывать суть внесенных изменений и их назначение. В нём нет места подробным руководствам по компиляции, установке тулчей или настройке окружения. Никто из разработчиков не будет искать в журнале коммитов информацию о том, как ставить gcc или make через тот или иной пакетный менеджер, — для этого существуют отдельные документы и инструкции.
Фактически FFmpeg сформулировал стандарт: сообщение коммита — это не учебник и не заметка в личном блоге, а точечное объяснение, зачем и что именно было изменено в коде.
Константы вида EIGHT = 8 как симптом плохого стиля
Отдельный пласт критики вызвали подобные константы, как `EIGHT = 8`. Подобная практика нередко встречается в промышленном коде: разработчики создают идентификаторы для значений, которые и так очевидны и не нуждаются в абстракции. В результате растёт «шум» — дополнительный слой имен, который не даёт читателю новой информации.
Иногда подобный подход оправдан: например, когда число используется в специфическом контексте (размер буфера, количество каналов, ограничение протокола), и имя обозначает именно смысл этого значения, а не его числовую величину. Однако простое дублирование цифры словом (EIGHT, TEN, THIRTY_TWO) без семантики чаще превращается в антипаттерн.
Разработчики FFmpeg, по сути, указали: если константа не объясняет логику, а всего лишь озвучивает число, она вредит читаемости кода.
Где проходит грань между помощником и мусором от ИИ
Ситуация с AMD наглядно показывает, что использование ИИ в разработке — это инструмент, а не автоматическая экономия времени. Нейросети действительно могут ускорять рутинные задачи: генерировать шаблонный код, подготавливать черновики, помогать с рефакторингом. Но их результат требует не меньшей, а иногда и большей проверки, чем код, написанный вручную.
Разработчики FFmpeg фактически сформулировали несколько негласных правил:
- AI-код — не повод ослаблять ревью;
- генерация — лишь стартовая точка, а не готовое решение;
- ответственность за качество патча всегда лежит на человеке, который отправляет его в проект;
- если ИИ добавляет лишнюю «позолоту» — документацию не по адресу, бессмысленные константы, избыточные конструкции — это нужно вычищать до публикации.
Почему конфликт показателен для индустрии
Случай с AMD и FFmpeg — не просто частный спор о стиле. Он отражает более широкий конфликт между «быстрым» подходом к разработке с опорой на ИИ и тщательно выстроенными процессами в зрелых open source-проектах.
У крупных проектов есть:
- сформированные кодстайлы и стандарты коммитов;
- устоявшиеся практики ревью;
- требования к ясности и минимализму изменений;
- разделение кода, документации и инфраструктурных инструкций.
Когда в такую среду попадает патч, выглядящий как «автоматически сгенерированная простыня», он воспринимается не просто как неудачное изменение, а как неуважение к процессу.
Чему учит эта история разработчиков и компании
Из этого конфликта можно сделать несколько практических выводов:
1. Используете ИИ — закладывайте время на редактирование. Нельзя относиться к нейросетевым подсказкам как к «готовому продукту», особенно в проектах с высокими требованиями к качеству.
2. Сообщение к коммиту — не контейнер для всего подряд. Оно должно объяснять конкретные изменения. Инструкции по установке, развёртыванию и сборке должны жить в отдельной документации.
3. Не плодите константы ради констант. Если имя не раскрывает смысл значения, а лишь повторяет его, оно вредно.
4. Уважайте культуру проекта, куда отправляете патч. Прежде чем делать pull request, полезно изучить существующую историю коммитов, стиль кода, принятые соглашения.
5. Компаниям важно строить внутренние правила по использованию ИИ. Нужны четкие гайды: где можно применять генерацию, кто и как обязан ревьюить результаты, какие проверки обязательны перед отправкой вверх по стеку.
AMD и FFmpeg: разные ожидания от одной и той же задачи
AMD, судя по репликам автора патча, пыталась сделать изменения «полезнее» — включить в патч дополнительные пояснения и инструкции. FFmpeg, напротив, ожидает от вклада чистоты и фокусировки: минимум шума, только рабочий код и краткие пояснения по делу.
Такое расхождение показывает, как по-разному могут понимать «заботу о пользователях» участники экосистемы. Для одного — это более подробная инструкция прямо в коммите, для другого — строгое соответствие структуре проекта и разграничение зон ответственности (код отдельно, документация отдельно).
Будущее AI-патчей: интеграция, а не подмена разработчиков
История с раздутыми патчами вокруг HIP SDK под Windows подталкивает к более зрелому подходу в использовании ИИ. Нейросети логично рассматривать как инструмент интегрированный в выстроенный процесс: генерация черновиков кода, автоматическая саммари изменений, подсказки по API. Но окончательное решение — что войдёт в репозиторий — должно оставаться за разработчиком, который понимает архитектуру, требования к качеству и культуру проекта.
FFmpeg своим резким ответом фактически обозначил границу: машинные помощники допустимы, но ответственность и контроль — исключительно человеческие. И чем крупнее и старше проект, тем строже будут относиться к любым попыткам «ускориться» за счёт компромисса с качеством.
Итог
Конфликт между FFmpeg и AMD стал наглядным примером того, как не стоит внедрять AI в процесс разработки: без фильтра, без жёсткого ревью и без уважения к существующим правилам. Он высветил важные аспекты современной разработки — роль сообщений к коммитам, ценность чистого кода, опасность бессмысленных констант и необходимость дисциплины при работе с ИИ. Для всей индустрии это напоминание: технологии меняются, но ответственность за результат по-прежнему лежит на разработчике, чьё имя стоит под коммитом.
