Пока Copilot дописывал по две-три строки, вопрос авторства кода меня особо не интересовал. IDE предложила условие, я нажал Tab, что-то поправил и пошёл дальше. Даже если половина метода была собрана автодополнением, решение всё равно оставалось довольно очевидно моим: я придумал, что нужно сделать, видел код в момент появления и примерно понимал каждую строчку.
С coding agents всё стало не так однозначно. Теперь я могу описать задачу текстом, а через несколько минут получить несколько новых классов, migration, тесты и готовый diff. Иногда физически я не написал руками вообще ничего. Если такой код потом упадёт в production, довольно естественно спросить: кто в этом случае отвечает? Я, модель, разработчики модели или человек, который посмотрел pull request и нажал Merge?
Мне кажется, здесь смешиваются две разные вещи. Первая — кто произвёл текст. Вторая — кто решил, что этот текст должен стать частью работающей системы. AI очень сильно поменял первую часть и почти не поменял вторую.
Если я попросил agent добавить rate limiting, получил реализацию, посмотрел её и согласился отправить в production, не так уж важно, кто именно набрал символы. В системе появился код, потому что кто-то из людей принял решение его оставить.
Именно в этом месте, на мой взгляд, и начинается ответственность.
Авторство стало немного странным понятием
Допустим, agent написал такой метод:
public function canViewInvoice(User $user, Invoice $invoice): bool
{
return $invoice->userId() === $user->id();
}Я его не печатал. Возможно, даже название придумала модель. Но перед merge я посмотрел реализацию, сверил её с остальным кодом и решил, что именно так правило должно работать.
Формально автор текста здесь действительно AI.
Практически эта информация довольно быстро теряет значение.
Через полгода другой разработчик откроет метод и будет разбираться уже не с тем, кто его написал, а с тем, почему доступ к invoice проверяется именно здесь. Если во время инцидента выяснится, что условие неверное, модель, которая когда-то его сгенерировала, вообще никак не будет участвовать в разговоре.
Production-код существует намного дольше конкретного сеанса с LLM.
Поэтому мне всё меньше нравится попытка провести чёткую границу:
human code
AI codeПосле merge остаётся просто codebase.
Часть строк я написал руками, часть дополнил Copilot, часть полностью сделал агент, ещё часть приехала из библиотеки. Через какое-то время происхождение отдельных строк становится почти археологией.
Гораздо интереснее другая граница: понимает ли кто-то в команде, зачем этот код существует и почему он устроен именно так.
Я бы проверял ownership очень простым способом
Если человек отправляет pull request, он должен уметь его объяснить.
Не пересказать summary, которое написал agent, а действительно ответить на нормальные вопросы reviewer.
Почему здесь появился новый service?
Почему используется эта dependency?
Почему transaction начинается на этом уровне?
Что произойдёт при повторном вызове?
Почему существующую abstraction нельзя было расширить?
Что будет при timeout?
Если ответ примерно такой:
не знаю, Cursor так сделал,
для меня это не проблема Cursor. Изменение просто ещё не готово.
Это правило хорошо работает независимо от того, сколько кода написал AI. Можно вручную написать пятьсот строк и плохо понимать последствия собственного решения. Можно попросить agent сделать почти всё, потом внимательно разобрать результат, поменять архитектуру, проверить edge cases и понимать систему лучше, чем после обычной ручной реализации.
В августе 2026 года Debian довольно долго спорил о том, как относиться к LLM-assisted contributions, и в итоге выбрал именно такую логику: использование AI разрешено, но ответственность за отправленную работу остаётся у человека, который её отправляет. От него ожидается, что он понимает contribution и способен отвечать за его качество и допустимость.
Мне нравится здесь не столько сама политика Debian, сколько принцип. Инструмент может быть любым. На входе в общий проект всё равно появляется человек, который говорит: эту работу можно принимать.
С Merge теперь связано чуть больше смысла
Раньше разработчик обычно проводил с кодом достаточно много времени ещё до review. Пока пишешь реализацию, успеваешь несколько раз наткнуться на соседние классы, передумать, переписать метод, увидеть странный тест и случайно узнать, почему один старый if вообще нельзя трогать.
Agent может перескочить весь этот путь.
Он способен за несколько минут сделать довольно убедительное изменение, а человек увидит результат уже в готовом виде. Код аккуратный, naming нормальный, тесты есть, CI зелёный. Возникает сильное ощущение, что осталось просто проверить diff и принять работу.
Но часть понимания, которая раньше появлялась сама во время написания, теперь приходится получать специально.
Именно поэтому мне кажется немного опасной формулировка «я посмотрел код». Посмотреть можно очень по-разному.
Если agent поменял семь файлов, недостаточно проверить, что отдельные методы выглядят нормально. Нужно восстановить сам ход решения: зачем затронуты эти файлы, где проходит граница изменения, какие существующие правила оно сохраняет и что произойдёт за пределами happy path.
GitHub формулирует это похожим образом: AI меняет то, что происходит до merge, но последнее решение о принятии кода всё равно остаётся за разработчиком.
Мне здесь нравится воспринимать Merge не как кнопку подтверждения того, что код «выглядит нормально», а как момент, когда кто-то принимает изменение в собственную инженерную картину системы.
Тесты не снимают этот вопрос
С AI у тестов появляется одна интересная проблема. Agent почти всегда охотно пишет их вместе с реализацией, поэтому pull request может выглядеть особенно убедительно: feature сделана, coverage есть, всё зелёное.
Только реализация и тест могут быть основаны на одной и той же неправильной предпосылке.
Допустим, есть правило:
скидка действует до конца 10 сентября по локальному времени пользователя.
Модель поняла его немного иначе и написала:
$isActive = $now <= new DateTimeImmutable('2026-09-10 23:59:59');Потом она же написала тест, который проверяет ровно эту границу.
Получаем красивую ситуацию:
неправильно понятое требование
↓
неправильная реализация
↓
тест под эту реализацию
↓
greenНикакого противоречия внутри изменения нет.
Проблема находится снаружи.
Поэтому тесты, написанные одновременно с кодом одним agent, я бы не воспринимал как независимое подтверждение корректности. Их тоже нужно читать как часть предложенного решения.
Особенно там, где есть деньги, permissions, security или сложные business invariants.
OWASP сейчас рекомендует довольно похожий подход: AI-assisted change должен иметь конкретного human owner, пройти человеческую проверку и не обходить обычные требования к security и maintainability только потому, что код сгенерирован инструментом.
Это, кстати, одна из причин, почему идея «пусть один AI напишет, а второй AI проверит» полезна, но не закрывает вопрос полностью.
Второй agent может найти ошибку.
Третий может найти ещё одну.
Static analysis найдёт четвёртую.
Но если все они не знают одно старое правило бизнеса, пять моделей подряд могут совершенно уверенно согласиться между собой.
AI-коду не нужен отдельный стандарт качества
Я бы вообще не вводил для сгенерированного кода какую-то особую категорию качества.
У нас всё равно остаются старые вопросы.
Корректен ли код?
Безопасен?
Можно ли его поддерживать?
Нормально ли он вписывается в архитектуру?
Есть ли тесты?
Не тащит ли лишнюю dependency?
Можно ли понять его через год?
Если ответ плохой, происхождение реализации не очень важно.
Фраза:
но это ведь AI написал,
не делает method менее сложным.
И наоборот, было бы странно отклонять хорошее решение только потому, что большую часть текста сделал агент.
В этом смысле я согласен с подходом, который выбрал Debian: не вводить для AI-assisted contributions отдельный сниженный стандарт, а применять обычные требования к качеству и ответственности.
Но review всё-таки немного меняется, потому что у AI есть свои характерные ошибки. Он может придумать package, использовать API не той версии, повторно реализовать уже существующую функцию, создать abstraction ради одного случая или написать код настолько аккуратно, что reviewer перестанет задавать главный вопрос: а нужно ли вообще было делать именно так?
То есть quality bar тот же.
Способ добраться до уверенности немного другой.
Отвечает всё-таки не один разработчик
Здесь есть ещё одна крайность, которая мне тоже не нравится. Если сказать, что ответственность всегда лежит на человеке, который нажал Merge, легко представить разработку как историю про одного человека, который лично отвечает за абсолютно всё, что когда-либо произошло с его кодом.
В нормальной команде так не работает.
У изменения есть автор или owner.
Есть reviewer.
Есть CI.
Есть архитектурные правила.
Есть engineering manager, tech lead или другие люди, которые определяют процесс.
Есть сама компания, которая решила использовать конкретные AI-инструменты и разрешила им определённый уровень доступа.
Если организация разрешает автономному agent менять проект, самостоятельно устанавливать dependencies, создавать pull requests и merge'ить их после AI-review, странно потом объяснять проблему исключительно ошибкой разработчика.
Это уже свойство процесса.
Поэтому я бы разделял хотя бы два уровня.
Человек отвечает за изменение, которое он сознательно принимает и отправляет дальше.
Команда и организация отвечают за то, каким способом вообще разрешено производить и принимать такие изменения.
Если agent может случайно получить production credentials, это не вопрос качества prompt.
Если pull request из тысячи строк можно merge'ить без human review, это не проблема конкретной модели.
Если компания разрешила отправлять приватный source code во внешний сервис без понятной политики, ответственность тоже находится выше отдельного разработчика.
AI в этом плане не отменяет старую engineering management. Он просто добавляет нового очень производительного участника процесса, которому при этом нельзя делегировать организационную ответственность.
С автономными агентами это становится особенно заметно
Пока AI только предлагает код, всё довольно просто.
С агентами постепенно появляются реальные действия. Они могут запускать shell commands, ставить packages, менять database migrations, работать с GitHub, создавать branches и pull requests.
В какой-то момент agent уже не только пишет текст.
Он что-то делает.
И тогда ответственность удобнее рассматривать так же, как мы всегда рассматривали permissions любой другой системы.
Если сервису не нужно удалять данные, у него нет права удаления.
Если agent должен только читать repository и создавать branch, ему не нужны production credentials.
Если операция необратимая, можно потребовать подтверждение.
То есть вместо попытки научить модель «никогда не делать ничего плохого» гораздо надёжнее ограничить пространство действий архитектурно.
OWASP отдельно рекомендует для AI-assisted development human ownership и явное approval перед merge, а также аудит того, кто принял конкретное изменение.
Мне это кажется очень знакомой идеей.
Мы ведь не строим обычный backend в расчёте на то, что разработчик никогда не ошибётся. Мы добавляем access control, transactions, constraints и audit log.
С agent ровно то же самое.
Если он способен сделать опасное действие, вероятность ошибки должна учитываться архитектурой.
Отдельно остаются лицензии и данные
Есть ещё менее интересная, но довольно важная часть — откуда вообще взялся сгенерированный код и какие данные использовались для его получения.
Если модель внезапно выдала большой специфичный фрагмент реализации, человек, который принимает его в проект, не может полностью снять с себя вопрос происхождения словами:
я это не копировал, оно само сгенерировалось.
Для open source этот вопрос особенно заметен из-за лицензий. Debian в новой политике отдельно оставил на contributor ответственность и за legal acceptability отправленной работы.
В коммерческой разработке всё зависит уже от используемого сервиса, договоров, юрисдикции и внутренних правил компании, поэтому я бы не пытался сформулировать универсальный юридический ответ.
С инженерной стороны вывод проще.
Код, который мы принимаем, должен иметь приемлемое происхождение.
Данные, которые отправляем модели, должны быть разрешены для такого использования.
И здесь опять получается та же схема: AI поменял инструмент, но не убрал необходимость принять решение.
Нужно ли вообще отмечать, что код написал AI
Я пока не уверен, что через несколько лет такие отметки будут особенно полезны.
Сейчас можно представить комментарий:
Generated by Claudeили metadata в pull request с названием agent и модели.
Для анализа процесса это может быть интересно. Можно посмотреть, какие типы задач agents делают лучше, где больше возвратов с review, насколько растёт размер PR или где чаще появляются bugs.
Для самого codebase ценность уже сомнительная.
Через два года мне важнее понять:
почему здесь именно такой алгоритм?
чем:
какой моделью он был написан?
Если provenance нужна для безопасности, compliance или внутренней аналитики — хранить её вполне логично.
Но я бы не превращал AI-generated code в отдельный биологический вид внутри репозитория.
В конечном итоге хороший код должен быть понятен без истории чата, в котором он появился.
Для себя я пришёл к довольно простому правилу
Мне не особенно важно, кто напечатал строки.
Если я принимаю изменение, я должен понимать его настолько, чтобы суметь дальше жить с ним без AI-сессии, в которой оно создавалось.
Не обязательно помнить каждую строчку.
Но нужно понимать решение.
Почему оно здесь.
Какие ограничения учитывает.
Какой trade-off был выбран.
Где оно может сломаться.
Что менять, если требования поменяются.
Если этого понимания нет, проблема не в том, что код написал AI.
Проблема в том, что в систему попадает код без владельца.
И вот это уже действительно опасно.
Вместо заключения
Мне кажется, через несколько лет сам вопрос «кто написал этот код?» станет гораздо менее интересным.
Мы уже давно не считаем вручную набранные символы хорошей мерой работы программиста. IDE генерирует boilerplate, frameworks создают файлы, formatter переписывает код, compiler делает огромную часть работы, которой разработчик вообще никогда не касается.
AI просто сильно расширил этот список.
Он уже может написать реализацию, tests, migration, документацию и исправить замечания reviewer.
Но остаётся момент, который пока не получается автоматизировать одним красивым вызовом модели: кто-то должен решить, что именно это изменение стоит оставить в системе.
Мне кажется, настоящее авторство инженерного решения теперь всё сильнее находится именно там.
Не в момент, когда появился текст.
А в момент, когда человек его понял и сказал: да, это можно оставить.