Кто отвечает за код, который написал агент
Формальное правило одинаково от Google до open source: смёржил PR – значит отвечаешь, кто бы ни написал код, ты или агент.
Но когда в проде реально что-то падает, ответственность чаще утекает наверх: 46% enterprise-организаций называют виноватым CTO или VP Engineering, и лишь 7% – того, кто физически нажал "смёржить".
Дальше несколько моделей ответственности – и на практике работают не все.
👤 Кто написал – тот и отвечает
Это модель по умолчанию: имя в git blame отвечает за код целиком, независимо от того, кто его придумал.
Она работает, пока PR помещается в голову того, кто его одобрил. Но на масштабе в сотни PR в неделю содержательно понять каждое решение уже физически невозможно.
🔍 Кто ревьюит – тот и отвечает
Отсюда вторая линия защиты: ревьюер как гейт, который должен заметить то, что упустил автор.
Но объём работает и против него: в командах, где агент включён в поток, PR разрастаются, и ревьюер физически не успевает прочитать каждую строку до дедлайна одобрения.
Гейт такую нагрузку не выдерживает: почти две трети аппрувов уходят без единого комментария.
🎯 Кто владеет сервисом – тот и отвечает
Более зрелый ответ закрепляет ответственность по зоне риска.
Рутинные изменения идут ускоренным путём, а auth, платежи и миграции проходят через конкретного владельца сервиса, и итоговую подпись ставит служба безопасности.
🌀 Виноваты все – значит, не виноват никто
Там, где ответственность не определена, она естественно сползает на команду целиком.
PR ревьюился кем-то ещё, дизайн обсуждался до того, как открыли редактор.
Спросите отдельно службу безопасности, разработчика и ревьюера, кто виноват в инциденте – скорее всего, каждая сторона укажет на кого-то другого.
Это не распределённая ответственность, а её вакуум: три стороны одновременно считают виноватой друг друга.
📝 Кого назначили – тот и отвечает
У вакуума ответственности есть рабочее лекарство: то же коллективное владение, но с одним именем, названным заранее.
Reviewer of record – конкретное имя на каждый мерж с ИИ или без него, назначенное заранее, до инцидента.
Но важно, чтобы это имя было записано где-то, кроме памяти конкретного тимлида.
📚 Что почитать:
State of Code Abundance – CloudBees, 2026
State of AI in Security & Development – Aikido Security, 2026
