Style_Julia
New member
Честно скажу: ещё год назад я относился к «AI-помощникам» в коде примерно как к гаданию на кофейной гуще. Мол, красиво генерирует, а потом полдня разгребаешь. Потом у нас случился квартал, когда бэклог рос быстрее, чем мы успевали закрывать тикеты, и я сдался — разрешил команде использовать генеративные инструменты без ограничений. Первые две недели казались магией: задачи, которые раньше занимали день, закрывались за три часа. А на третьей неделе мы уронили прод. Причём не по вине новичка и не из-за героического деплоя в пятницу вечером — виноват был аккуратный кусок кода, который выглядел безупречно и прошёл ревью за четыре минуты.
Разбор полётов был неприятным, но полезным. Сгенерированный код сломал инвариант, о котором не знал ни один из авторов запроса: модель выдала элегантное решение, идеально корректное с точки зрения синтаксиса и полностью игнорирующее особенность нашего легаси-хранилища. И вот тут я понял главное: проблема была не в AI. Проблема была в том, что мы перенесли на модель ответственность, которую должны были нести сами. Мы приняли скорость генерации за скорость разработки, а это, как выяснилось, две совсем разные вещи. Код пишется быстро, а вот понимается, проверяется и поддерживается — с прежней, человеческой скоростью.
После этого мы сели и переписали не инструменты, а правила. Первое: любой сгенерированный фрагмент проходит ровно то же ревью, что и написанный руками, и «это же модель предложила» перестало быть аргументом в спорах. Второе: автор обязан уметь объяснить каждую строку, которую отправляет в мерж-реквест. Если не можешь объяснить — не отправляй. Звучит жёстко, но именно это правило вычистило девяносто процентов мусора: люди сами начали переписывать сгенерированное, потому что стыдно было защищать код, смысл которого ты не понимаешь.
Третье изменение касалось тестов, и оно оказалось самым ценным. Мы договорились: если AI ускоряет написание кода, то он же обязан ускорять написание тестов. То есть задача не считается закрытой, пока нет проверок на краевые случаи, и генерация тестов стала не опцией, а частью рабочего цикла. Забавный побочный эффект: качество тестов выросло, потому что модель охотно придумывает сценарии, до которых уставший разработчик в четверг вечером просто не додумается. Прод после этого мы не роняли ни разу — тьфу три раза.
Отдельная история — скорость команды. И здесь я хочу развеять популярный миф. Скорость не растёт от того, что каждый пишет в два раза больше кода. Она растёт от того, что люди перестают тратить время на рутину: обвязку, бойлерплейт, миграции, скучные адаптеры к внешним сервисам. Вот здесь AI действительно незаменим, и я это признаю без оговорок. Но как только речь заходит о логике предметной области, о границах модулей, о решениях, которые определят архитектуру на годы, — тут руль должен быть в человеческих руках. Модель отлично работает в узком коридоре, где правила заданы. Как только коридор кончается, начинается фантазия, а фантазия в проде стоит дорого.
Ещё один момент, который я советую проговорить в команде на берегу: не надо запрещать и не надо благословлять. Обе крайности одинаково вредны. Запрет приводит к тому, что люди пользуются инструментами тайком и не признаются, откуда взялся код. Благословение без правил приводит к тому, что ревью превращается в формальность, а техдолг копится со скоростью, которую вы даже не заметите до первого серьёзного инцидента. Мы выбрали третий путь: открытость плюс прозрачные критерии. В описании мерж-реквеста теперь принято указывать, что генерировалось, а что писалось руками. Это не бюрократия, это способ сохранить знание внутри команды, а не вынести его наружу.
Если соберу всё в короткий список, он выглядит так. Ведите журнал инцидентов, и пусть каждый разбор честно отвечает на вопрос, был бы этот баг написан руками. Сделайте тесты обязательными, а не желательными. Требуйте понимания вместо скорости. Ограничьте сферы, где генерация допустима, и не стесняйтесь говорить нет на архитектурных развилках. И самое важное: измеряйте не количество сгенерированных строк, а время от идеи до стабильного релиза. Строки — это метрика для отчёта, а стабильность — метрика для бизнеса.
А теперь к вам, форумчане. Расскажите, как у вас в командах выстроена работа с AI-ассистентами: есть ли формальные правила, случались ли истории, когда именно генерация привела к падению прода, и что помогло вам вернуть доверие к процессу? Мне правда интересно собрать коллективный опыт — уверен, у каждого найдётся пара уроков, которых не купишь ни на одном курсе.
Разбор полётов был неприятным, но полезным. Сгенерированный код сломал инвариант, о котором не знал ни один из авторов запроса: модель выдала элегантное решение, идеально корректное с точки зрения синтаксиса и полностью игнорирующее особенность нашего легаси-хранилища. И вот тут я понял главное: проблема была не в AI. Проблема была в том, что мы перенесли на модель ответственность, которую должны были нести сами. Мы приняли скорость генерации за скорость разработки, а это, как выяснилось, две совсем разные вещи. Код пишется быстро, а вот понимается, проверяется и поддерживается — с прежней, человеческой скоростью.
После этого мы сели и переписали не инструменты, а правила. Первое: любой сгенерированный фрагмент проходит ровно то же ревью, что и написанный руками, и «это же модель предложила» перестало быть аргументом в спорах. Второе: автор обязан уметь объяснить каждую строку, которую отправляет в мерж-реквест. Если не можешь объяснить — не отправляй. Звучит жёстко, но именно это правило вычистило девяносто процентов мусора: люди сами начали переписывать сгенерированное, потому что стыдно было защищать код, смысл которого ты не понимаешь.
Третье изменение касалось тестов, и оно оказалось самым ценным. Мы договорились: если AI ускоряет написание кода, то он же обязан ускорять написание тестов. То есть задача не считается закрытой, пока нет проверок на краевые случаи, и генерация тестов стала не опцией, а частью рабочего цикла. Забавный побочный эффект: качество тестов выросло, потому что модель охотно придумывает сценарии, до которых уставший разработчик в четверг вечером просто не додумается. Прод после этого мы не роняли ни разу — тьфу три раза.
Отдельная история — скорость команды. И здесь я хочу развеять популярный миф. Скорость не растёт от того, что каждый пишет в два раза больше кода. Она растёт от того, что люди перестают тратить время на рутину: обвязку, бойлерплейт, миграции, скучные адаптеры к внешним сервисам. Вот здесь AI действительно незаменим, и я это признаю без оговорок. Но как только речь заходит о логике предметной области, о границах модулей, о решениях, которые определят архитектуру на годы, — тут руль должен быть в человеческих руках. Модель отлично работает в узком коридоре, где правила заданы. Как только коридор кончается, начинается фантазия, а фантазия в проде стоит дорого.
Ещё один момент, который я советую проговорить в команде на берегу: не надо запрещать и не надо благословлять. Обе крайности одинаково вредны. Запрет приводит к тому, что люди пользуются инструментами тайком и не признаются, откуда взялся код. Благословение без правил приводит к тому, что ревью превращается в формальность, а техдолг копится со скоростью, которую вы даже не заметите до первого серьёзного инцидента. Мы выбрали третий путь: открытость плюс прозрачные критерии. В описании мерж-реквеста теперь принято указывать, что генерировалось, а что писалось руками. Это не бюрократия, это способ сохранить знание внутри команды, а не вынести его наружу.
Если соберу всё в короткий список, он выглядит так. Ведите журнал инцидентов, и пусть каждый разбор честно отвечает на вопрос, был бы этот баг написан руками. Сделайте тесты обязательными, а не желательными. Требуйте понимания вместо скорости. Ограничьте сферы, где генерация допустима, и не стесняйтесь говорить нет на архитектурных развилках. И самое важное: измеряйте не количество сгенерированных строк, а время от идеи до стабильного релиза. Строки — это метрика для отчёта, а стабильность — метрика для бизнеса.
А теперь к вам, форумчане. Расскажите, как у вас в командах выстроена работа с AI-ассистентами: есть ли формальные правила, случались ли истории, когда именно генерация привела к падению прода, и что помогло вам вернуть доверие к процессу? Мне правда интересно собрать коллективный опыт — уверен, у каждого найдётся пара уроков, которых не купишь ни на одном курсе.