Разработка приложений с помощью ИИ: за что отвечает инженер

Кто отвечает за разработку приложений с помощью ИИ?

В марте 2026 года Anthropic представила Code Review: агенты ищут ошибки в изменениях кода, но одобрение изменений остаётся за человеком. Для меня здесь хорошо виден принцип, по которому должна работать разработка приложений с помощью ИИ: инструмент выполняет поручение, инженер решает, можно ли принять результат. Именно так разделены обязанности в анонсе Anthropic.

В CRT мы используем роль AI Software Engineer: один специалист с ИИ-инструментами ведёт задачу от бизнес-постановки до работающего решения. Я ценю в этой роли способность не потерять связь между этапами: задача → критерии приёмки → код → тестирование → передача. Быстро получить код – ещё полдела. Если инженер не может объяснить, как проверить приложение и запустить его, задача не решена.

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

В разработке с ИИ-агентами я предлагаю ещё до старта договориться, кто за что отвечает:

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

Что подготовить до начала разработки?

Фраза «нужен личный кабинет» почти ничего не говорит инженеру о будущей работе. Придётся выяснить, кто туда входит, что видит и может ли отменить действие. А какой системе верить, если сведения расходятся? Я бы начал с этих вопросов, а код отложил до ответов.

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

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

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

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

Как инженер организует работу ИИ-агентов?

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

У Anthropic описана попытка, которая зашла в тупик. В эксперименте с длительной разработкой агент пытался собрать приложение целиком, исчерпывал доступный контекст и оставлял незавершённые функции без ясного описания. В следующих сессиях он мог увидеть уже написанные части и преждевременно объявить работу законченной. Авторы перешли к списку функций, стали реализовывать их постепенно и сохранять состояние работы. Подробности есть в инженерном разборе Anthropic.

Я делаю из этого практический вывод: поручение агенту должно давать результат, который инженер может целиком просмотреть и проверить. Например, сначала сохранение заявки с проверкой обязательных полей, затем передача во внешнюю систему, затем отображение статуса. Порядок зависит от архитектуры. Но для каждого изменения нужно заранее знать, что будет считаться готовым.

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

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

Как принимать разработку приложений с помощью ИИ?

На приёмке я предлагаю требовать подтверждения. За сообщением «готово» должен стоять результат, который можно проверить: выполненный сценарий, отчёт о проверке, инструкция запуска. Заказчику для этого не обязательно читать исходный код.

Сначала нужно разделить проверку кода и проверку продукта. Код-ревью – разбор изменений другим проверяющим – помогает найти технические проблемы. Но чтобы ответить на вопрос «может ли пользователь выполнить задачу?», придётся запустить приложение и пройти нужный путь.

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

Я бы согласовал следующую таблицу ещё до реализации. И вписал имена участников приёмки: перечень ролей сам по себе никому работу не назначает.

В примере с заявкой показ приложения не заканчивается нажатием кнопки. Нужно найти запись в системе, открыть её после повторного входа и убедиться, что повторная отправка не создала дубликат. Если вместо внешнего сервиса использовали его имитацию, это нужно записать в результатах проверки. Работу с реальным сервисом пока никто не подтвердил.

Отдельно я бы выяснил, откуда взялись тесты. Их нужно сверять с согласованными требованиями: тест, написанный по готовой реализации, может закрепить ошибку как норму. Поэтому прошу показывать связь «требование → проверка → результат», в том числе для отрицательных сценариев (ошибочного ввода и других нештатных действий).

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

Ограничения допустимы, если заказчик их видит и принимает. Запись «интеграция проверена только в тестовой среде» даёт основание решить, что делать дальше. А что заказчик может решить по отметке «всё протестировано»?

Когда одного инженера недостаточно?

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

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

Обещать универсальный коэффициент ускорения я тоже не готов. В феврале 2026 года METR признала новые оценки эффекта ИИ ненадёжными: часть разработчиков отказывалась участвовать без ИИ, менялся отбор задач, а параллельная работа с агентами мешала учитывать время. Исследователи допускали, что ускорение выросло, но считали свои данные слабым основанием для оценки его размера. Источник: METR.

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