«Этот код точно писал ИИ»: разработчик объяснил, как LLM ломают культуру командной разработки

от admin

И что в целом ему плевать, откуда взялся код. Главное, чтобы он подходил проекту по код-стайлу

Разработчик поделился наблюдением: все чаще в коде коллег появляется что-то, что не похоже на стиль команды.

Код рабочий, понятный, покрыт тестами — но его структура, решения и стиль не вписываются в принятую архитектуру проекта.

По словам автора, он почти наверняка знает, что такие фрагменты были сгенерированы с помощью больших языковых моделей (LLM), вроде ChatGPT или GitHub Copilot.

И проблема не в том, что код плохой. Проблема в том, что он — чужой. Его будто писали не члены команды, а кто-то извне, не знающий, как у них принято.

LLM игнорируют контекст проекта

В команде договорились использовать определенную библиотеку для загрузки данных — а ИИ пишет свой собственный обработчик.

Везде используется функциональный подход — а LLM сгенерировал класс. Уже есть модуль с нужными утилитами — но модель пишет их заново. Такие случаи множатся.

Пуши на все платформы: как работает новый российский сервис MULTIPUSHEDtproger.ru

И вроде подобные решения выглядит разумно, но на деле идут вразрез с архитектурой, принципами и здравым смыслом команды. Это превращает проект в набор несовместимых кусков, ухудшает читаемость и усложняет поддержку.

Читать также:
Маск опроверг сделку по внедрению ИИ Grok в Telegram. Но Дуров не сдается

ИИ — мощный инструмент, но он не заменяет инженера

Автор подчеркивает: ему все равно, как код попал в IDE — был он написан вручную, скопирован с форума или сгенерирован ИИ. Важно то, что попадает в кодовую базу.

И если ты пользуешься LLM, то будь инженером, а не оператором. Ставь четкие задачи, указывай нужные библиотеки, приводи примеры, ограничивай объем кода.

Важно не скорость, а качество. Времена «быстрее значит лучше» уже показывают свою цену. Как новичок в кофейне, пытающийся угнаться за очередью, программисты спешат выпустить фичу, не думая о последствиях.

Разработка — это про долгосрочность

По словам автора, софт должен быть не просто рабочим, а поддерживаемым годами.

Именно ради этого сообщества создавали паттерны, стандарты и правила. ИИ может предложить решение, но не знает, как живет ваш проект и чего от него ждет команда.

Похожие статьи