Политика ИИ в программировании: правила на основе реальных ошибок команды

Почему командам нужна политика после первой плохой правки ИИ

Первая плохая правка ИИ редко выглядит драматично. Она выглядит небольшой, даже полезной. Разработчик просит помощника привести в порядок одну функцию, бегло смотрит diff и идёт дальше. А потом тесты начинают падать там, куда никто не заглядывал, и половина дня уходит на уборку.

Сломанные тесты часто становятся первым явным признаком того, что инструмент изменил больше, чем просили. Код по-прежнему собирается. Главный экран по-прежнему открывается. Но помощник переименовал хелпер, поменял значение по умолчанию или вернул mock не в том формате, который ждёт приложение. Команды теряют время, потому что ущерб прячется в скучных местах.

Правки не того файла опаснее, но тише. Помощник видит два похожих файла и меняет общий вместо локального. Сразу ничего не ломается. Через неделю другая функция начинает вести себя странно, потому что общий utility ушёл от своей исходной задачи. Такая дрейфующая ошибка обходится дороже, потому что никто не помнит, когда она началась.

Опасные команды превращают неаккуратную правку в настоящий инцидент. Инструмент ИИ может предложить git clean -fdx, жёсткий reset или команду для базы данных, чтобы починить окружение. Уставший разработчик может вставить её не задумываясь, особенно если предыдущий совет выглядел умно. Одна плохая команда может стереть локальную работу, сломать общее dev-окружение или направить не тот скрипт на реальные данные.

Вот тогда политика ИИ в программировании перестаёт звучать как бумажная формальность. Короткое правило вроде «ИИ не может запускать разрушительные команды» или «проверяй каждый файл вне запрошенной области» может сэкономить часы.

Большинству команд не нужен длинный документ. Им нужна простая политика, построенная на сбое, который все помнят, потому что именно такие правила люди действительно соблюдают.

Начинайте с инцидентов, а не с мнений

Большинство команд пишут политику слишком рано. Они спорят о вкусе, нейминге или о том, можно ли модели «разрешить» трогать определённые файлы. Обычно это ни к чему не приводит. Начните с ошибок, за которые команда уже заплатила.

Соберите пять–десять недавних сбоев ИИ из реальной работы. Пропустите странные крайние случаи. Возьмите те, что съели час, сломали деплой, изменили не тот файл или запустили команду, которую никто не должен был одобрять. Люди уважают правила, когда помнят, какой бардак за ними стоит.

Для каждого инцидента сохраните одно и то же:

• запрос или инструкцию, которые вызвали изменение
• diff, который сгенерировал ИИ
• вывод тестов, логи или сообщение об ошибке
• короткую заметку о том, как команда откатила или исправила проблему

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

Потом сгруппируйте инциденты по тому, что именно сломалось: правки кода, тесты и shell-команды. Одна группа может показать, что ИИ постоянно трогает соседние файлы, которые никто не просил менять. Другая — что он утверждает, будто тесты прошли, хотя полный набор никто не запускал. Третья — что возникают рискованные команды, например удаление сгенерированных файлов, переписывание миграций или использование force-флагов без ревью.

Будьте придирчивы к тому, что попадёт в список. Игнорируйте споры о стиле. Если одному разработчику не нравятся переменные, которые назвал ИИ, а другому всё равно, это ещё не проблема политики. Если ИИ изменил миграцию, сломал локальные данные и стоил двум людям полдня, это уже должно попасть в документ.

Хорошая политика начинается с дорогих сбоев, а не с абстрактных страхов. Если правило привязано к реальному запросу, реальному diff и реальному откату, команде проще соблюдать его без лишней драмы.

Превратите один инцидент в одно правило

Одна плохая правка ИИ может дать лучшее правило, чем длинная дискуссия. Начните с того, чтобы описать сбой одним простым предложением, которое поймёт любой в команде. Например: ИИ изменил хелпер для тестов вместо файла с платежами, который был указан в задаче.

Так правило остаётся привязанным к реальному воспоминанию, а не к теории. Люди помнят сломанный билд, правку не того файла или рискованную команду, которая задела не то окружение. Водянистые формулировки политики они не помнят.

Потом назовите риск обычными словами. Скажите, что произошло или что почти произошло. В примере выше риск простой: команда может влить изменение, которое выглядит правильным при ревью, но ломает не связанные тесты и прячет настоящую ошибку в платёжном коде.

Затем запишите самое маленькое правило, которое остановило бы этот сбой. Маленькие правила используют. Общая фраза вроде «будь осторожен с правками ИИ» бесполезна. Узкое правило работает лучше: ИИ может менять только файлы, перечисленные в задаче, а разработчик должен подтвердить эти пути перед сохранением изменений.

Добавьте одну проверку, которая впишется в обычную работу. Хорошие проверки намеренно скучные:

• сравни изменённые файлы с задачей
• запусти связанные тесты до ревью
• подтверди, что команда выполнится в нужном окружении
• проверь, не удалён ли код вне запрошенной области

И наконец, назначьте конкретного человека. Если никто не владеет проверкой, её не делает никто. В маленькой команде человек, который открыл задачу, может подтвердить пути файлов, а ревьюер — проверить тесты или безопасность команды перед merge.

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

Что должна покрывать ваша первая политика

Первая версия политики должна сосредоточиться на моментах, где маленькая ошибка превращается в болезненную уборку. Большинству команд не нужен длинный документ. Им нужно несколько чётких правил для области правок, чувствительных файлов, тестов, shell-доступа, секретов и проверки перед merge.

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

Проведите чёткую границу вокруг чувствительных файлов. Если правка затрагивает настройки деплоя, миграции базы, auth, billing или общие библиотеки, инструмент должен остановиться и попросить одобрение, прежде чем писать код. Правки не того файла в таких областях очень быстро съедают часы.

Для тестов нужны правила по обе стороны изменения. До правки инструмент запускает нужные тесты, проверки lint или type check и сохраняет результат. После правки он запускает те же проверки ещё раз, плюс всё, что относится к изменённому коду. Если базовая проверка уже падает, инструмент должен сказать об этом прямо, а не делать вид, что он всё вызвал или всё починил.

Shell-команды требуют второго взгляда, если они могут уничтожить данные или изменить окружение. В политике можно выделить небольшой набор команд только для одобрения: команды удаления, переписывание истории git, записи в базу, команды деплоя, обновления пакетов и всё, что меняет инфраструктуру. Dry run помогает, но не заменяет одобрение.

Правила доступа важны ещё сильнее. Не позволяйте ИИ-инструментам читать production secrets, писать в live-базы или смотреть сырые данные клиентов, если человек не выбрал это осознанно. Используйте staging, очищенные примеры и короткоживущие учётные данные, где это возможно. Небольшие команды часто работают быстрее с такими ограничениями, потому что они убирают лишнюю уборку после избегаемого ущерба.

Перед merge человек должен проверить изменение, если оно пересекает чёткую границу:

• правка затрагивает auth, платежи, инфраструктуру или миграции
• инструмент запускал рискованную shell-команду
• тесты изменились или были пропущены
• правка затрагивает много файлов или сгенерированный код
• изменение использует секреты, доступ к production или живые данные

Если ваша политика покрывает эти зоны простым языком, люди будут ей пользоваться. Большинство команд уже ощущали боль, которую предотвращает каждое правило.

Простой пример из одного неудачного дня

Небольшая команда попросила ИИ-агента исправить баг на экране отчётов. Баг казался узким: одно поле даты ломалось, когда пользователи экспортировали CSV. Агент быстро нашёл проблему, но изменил общий хелпер вместо кода отчёта.

Этот хелпер также форматировал даты для счетов, email-сводок и админской панели. Исходный баг выглядел исправленным. Тесты отчёта проходили. Люди продолжили работу.

Примерно через двадцать минут в другой части репозитория начали падать не связанные тесты. Изменился snapshot счета. Тест фоновой задачи сломался, потому что ожидал старый формат даты. Сначала никто не заметил правку общего хелпера, потому что в сообщении коммита говорилось только о баге в отчёте.

Потом день стал ещё хуже. Кто-то попытался навести порядок в рабочей копии и заново всё прогнать с нуля. В спешке он использовал рискованную команду очистки, которая удалила больше локальных файлов, чем ожидалось. Теперь у команды было две проблемы: плохая правка ИИ и запутанное восстановление.

Такой день даёт идеи для политики лучше, чем длинная встреча. Команда не писала огромный документ. Она записала три коротких правила, привязанных к тому, что реально произошло:

• Если агент ИИ меняет общий хелпер, человек должен проверить все файлы, которые от него зависят, до merge.
• Если после правки ИИ падают не связанные тесты, остановитесь и проверьте изменённые файлы, прежде чем просить ИИ о ещё одном исправлении.
• Агентам ИИ и людям в спешке нельзя запускать разрушительные команды очистки без явного одобрения.

Эти правила сработали, потому что повторяли цепочку сбоя. Первое правило закрыло правку не того файла. Второе не позволило команде наслаивать путаницу на путаницу. Третье решило проблему панической попытки, которая только замедлила восстановление.

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

Простые правила приживаются, когда все помнят цену ошибки. Один сломанный helper изменил тесты там, где никто не ожидал. Одна поспешная команда превратила обычный rollback в неприятную уборку. После этого политика из трёх правил кажется разумной, а не тяжёлой.

Правила, которые люди действительно соблюдают

Люди игнорируют политику, если она читается как юридический текст. Они следуют правилам, которые звучат как команда, помещаются на один экран и указывают на беспорядок, который все помнят.

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

Лучшие правила идут с прикреплённым воспоминанием. «После того как ИИ изменил не тот файл» звучит сильнее, чем «Обеспечить точность области файлов». Люди помнят тот день, когда потеряли два часа. Они не помнят отполированные формулировки политики.

Используйте те же слова, которые команда уже применяет в pull request, на стендапах и в Slack. Если у вас говорят «красные тесты», так и пишите «красные тесты». Если говорят «правка не того файла», используйте именно эту фразу. Простой язык снижает шанс, что люди пропустят правило или начнут спорить о смысле.

Ещё лучше работает короткий пример рядом с правилом:

• «Сначала назови файл, потом редактируй его». Пример: «Исправь auth timeout в session.ts, а не в billing.ts».
• «Не заглушай падающий тест, чтобы он стал зелёным». Пример: «Никаких skipped test, обновления snapshot или правок mock, если этого не просит задача».
• «Прочитай shell-команду перед запуском». Пример: «Всё, что содержит rm, migration или bulk update, сначала проверяет человек».

Это не элегантно. Поэтому это работает. Это звучит так, как сказал бы коллега после уборки плохого изменения ИИ.

Политика тоже быстро устаревает, если никто к ней не прикасается. Каждый новый сбой должен запускать короткий пересмотр. Задайте один вопрос: показала ли эта ошибка отсутствие правила или правило, которое никто не смог понять?

Маленькие команды справляются с этим хорошо, потому что цикл обратной связи короткий. Кто-то видит сбой утром, после обеда пишет одно ясное правило, и уже следующий pull request его учитывает. Если для правила нужен абзац объяснения, разделите его или удалите.

Ошибки, которые делают политику бесполезной

Самый быстрый способ убить доверие к политике — сделать её про вкус. Если правило требует, чтобы ИИ писал комментарии в определённом тоне или называл переменные особым образом, люди будут это игнорировать. Правила должны фокусироваться на рисках: сломанные тесты, правка не того файла, секреты в запросах или команды, которые могут изменить данные.

Одно правило должно решать одну проблему. Команды часто запихивают в одно предложение три-четыре идеи, а потом спорят о том, что оно значит. «ИИ может менять код только после ревью и тестов и одобрения для infra-изменений» звучит строго, но никто не понимает, какая часть сломалась. Разбейте это на отдельные правила, чтобы команда могла им следовать и чинить именно то, что пошло не так.

Запрет на всё выглядит красиво на бумаге и проваливается на практике. После одного неприятного инцидента некоторые команды запрещают ИИ писать тесты, трогать миграции или менять production-конфиг вообще. Короткая пауза может иметь смысл. Проблема начинается, когда нет пути для исключения, нет владельца и нет срока действия.

Тогда люди обходят политику втихую, а это хуже, чем открыто использовать ИИ. Маленькая команда может запретить ИИ трогать тестовые файлы после одной плохой правки, а потом потерять день на безопасном рефакторинге, потому что никто не может одобрить исключение.

Скрытая политика почти то же самое, что отсутствие политики. Если единственная копия лежит в пособии на сорок страниц, никто не смотрит туда перед рискованной правкой. Держите правила там, где идёт работа: рядом с руководством по репозиторию, в шаблоне pull request или в command runner, который блокирует опасные команды.

Старые правила тоже наносят тихий вред. Команда может оставить правило со своего первого хаотичного месяца, даже когда у неё уже есть лучшие тесты, владельцы кода и привычки ревью. Тогда политика тормозит безопасную работу и пропускает новые риски. Пересматривайте её по расписанию или после реального инцидента и удаляйте правила, которые больше не приносят пользы.

Слабая политика обычно показывает одни и те же симптомы:

• люди каждую неделю просят исключения
• ревьюеры спорят о формулировках, а не о риске
• самый безопасный путь кажется медленнее, чем игнорирование правила
• никто не может сказать, когда правило в последний раз предотвратило плохое изменение

Последний пункт особенно важен. Хорошие правила заслуживают уважения, потому что люди помнят ошибку, из-за которой они появились, и всё ещё видят риск сегодня.

Быстрые проверки перед тем, как правка ИИ попадёт в код

Короткая проверка в конце ловит большинство ошибок ИИ до того, как они разрастутся. Пяти минут часто хватает, чтобы не дать правке не того файла, ложному фиксy или одной опасной shell-команде превратиться в долгую уборку.

Лучше всего этот шаг работает, когда он обязателен по привычке, а не по желанию. Держите его коротким, чтобы люди выполняли его даже в загруженный день.

1. Сопоставьте изменённые файлы с исходной задачей. Если запрос был «исправить одну ошибку в checkout», а diff затрагивает ещё auth, billing и CI config, остановитесь и спросите, зачем это нужно.
2. Прочитайте diff сверху вниз. Не просматривайте только новую функцию. ИИ часто незаметно добавляет переименованные переменные, удалённые проверки или лишнюю уборку, о которой никто не просил.
3. Запустите самый маленький тест, который доказывает, что правка работает. Если изменение касается одного parser, сначала запустите тест именно этого parser. Полный набор тестов не нужен, чтобы поймать первую очевидную поломку.
4. Проверьте недавние shell-команды, которые ИИ использовал или предложил. Ищите удаления, изменения прав, переписывание ветки, удаление пакетов или команды, которые могут задеть live-системы.
5. Попросите одного ревьюера проверить предположения ИИ. Второй взгляд может поймать заявления вроде «этот файл не используется» или «эта конфигурация уже существует», когда это не так.

Небольшие ошибки накапливаются быстро. ИИ меняет правильную функцию, но ещё чистит второй файл, о котором никто не говорил. Тесты проходят, потому что никто не запустил тот единственный тест, который закрывал крайний случай. Позже кто-то замечает shell-команду, которая удалила сгенерированные файлы, всё ещё нужные команде.

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

Если команда маленькая, держите правило простым: никакая правка ИИ не попадает в код, пока один человек не проверит область, diff, доказательства, команды и предположения. Эта привычка даёт больше, чем длинный документ, который никто не читает.

Следующие шаги для маленькой команды

Маленькой команде не нужен толстый документ политики. Первая версия должна помещаться на одной странице, а люди должны помнить её без открытия вики каждый час. Если правила кажутся тяжёлыми, никто не будет пользоваться ими в загруженный момент.

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

Простой стартовый набор часто выглядит так:

• ИИ может менять только файлы, указанные в задаче
• ИИ должен запустить согласованную проверку тестов перед коммитом
• ИИ не может запускать рискованные shell-команды без проверки человеком

Держите формулировки простыми. Если новый сотрудник не понимает правило за десять секунд, перепишите его.

Храните каждое правило в одном общем месте вместе с владельцем, проверкой и одним реальным примером. Достаточно маленькой таблицы: правило, кто его обновляет, как команда проверяет его в ревью или CI, и инцидент, из-за которого оно появилось. Когда люди видят правило рядом со сбоем, они меньше спорят о том, нужно ли оно вообще.

Не добавляйте правила каждый раз, когда кому-то становится тревожно. Добавляйте новое правило только тогда, когда чёткий инцидент показывает повторяющуюся проблему. Если ИИ дважды за спринт изменил не тот файл, это кандидат на правило. Если у одного человека был странный запрос и он исправил всё за пять минут, скорее всего, это не оно.

Так политика остаётся короткой. Большинству маленьких команд нужно меньше правил, чем им кажется. Шесть точных правил лучше, чем двадцать расплывчатых.

Если вашей команде всё ещё неясно, где должны жить проверки ревью, что должен блокировать CI или какие команды требуют одобрения, Oleg Sotnikov на oleg.is работает с небольшими командами как Fractional CTO и startup advisor. Он помогает настраивать практичные процессы AI-разработки, правила ревью и безопасный контроль команд без превращения процесса в бюрократию.

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