Что произошло
11 сентября OpenAI опубликовала клиентский кейс Cognition о применении GPT-6 Astra в Devin — облачном агенте и его вариантах для командной строки и рабочего стола. Главная тема материала не скорость написания кода, а проверка результата. Агент запускает собранный продукт, проходит пользовательский сценарий и возвращает артефакты: видеозапись работы, отчёт о выполненных и непроверенных пунктах либо снимок исправленного интерфейса. Это опыт самого разработчика продукта, а не независимый сравнительный тест.
Почему «код написан» недостаточно
Агент может создать правильный diff, который не собирается в окружении проекта, либо починить тест и сломать соседний сценарий. Текстовый отчёт тоже легко выглядит убедительно без фактического запуска. Поэтому единицей результата должна стать проверенная пользовательская задача: приложение запускается, действие выполняется, ожидаемое состояние наблюдается, а проверяющий может повторить маршрут. Сгенерированные строки — только промежуточный продукт.
Какие доказательства показаны
В одном примере Devin создаёт игру для iPhone, запускает её в симуляторе и отдаёт запись вместе со списком пройденных и непроверенных проверок. В другом пользователь присылает снимок дефекта, агент вносит исправление и возвращает новый снимок. Важна формулировка «непроверено»: зрелый отчёт отделяет отсутствие ошибки от отсутствия теста. Команда должна запрещать агенту превращать пропущенный шаг в зелёную галочку.
Переносим принцип в небольшой бизнес
Даже без сложного агента можно требовать пакет приёмки. Для изменения формы это ссылка на тестовую среду, запись отправки, скриншоты пустого и ошибочного состояния, результаты автоматических тестов и короткий список ограничений. Для импорта — исходный пример, журнал запуска, число принятых и отклонённых строк. Формат определяется до работы, поэтому исполнитель не выбирает после факта самые красивые доказательства.
Песочница обязательна
Агенту нужен доступ к браузеру, терминалу и файлам, но не к боевым данным. Тестовое окружение содержит фиктивные аккаунты, ограниченные ключи и возможность быстрого сброса. Отправка писем, платежи, публикация и удаление блокируются либо требуют явного подтверждения. Запись экрана полезна только тогда, когда на ней нет персональных данных и секретов из панели разработчика.
Составляем контракт готовности
До запуска запишите функцию, три обычных сценария, два пограничных и признаки отказа. У каждого пункта есть наблюдаемое доказательство: статус, строка базы, файл, снимок или тест. Агент может добавлять проверки, но не удалять обязательные. Если задача меняется по ходу, контракт получает новую версию. Такой порядок не даёт подменить исходную цель более удобным результатом.
Что всё равно проверяет человек
Видеозапись доказывает один маршрут и одну конфигурацию. Она не показывает доступность с клавиатуры, поведение на медленной сети, безопасность, нагрузку или редкий браузер. Ревьюер читает рискованные части diff, запускает критические тесты независимо и проверяет, что агент не ослабил утверждения ради зелёного отчёта. Для важных изменений нужен второй человек, не участвовавший в генерации.
Как измерять пользу
Считайте время от постановки до принятого изменения, число возвратов, долю задач с воспроизводимым пакетом и дефекты после выпуска. Отдельно отмечайте стоимость среды и повторных запусков. Сокращение времени первого diff ничего не значит, если ревью стало дольше. Полезный агент уменьшает неопределённость проверяющего, а не просто производит больше кода.
Как хранить доказательства
Артефакты связывают с задачей и версией коммита. Запись без хеша кода быстро становится бесполезной: непонятно, какую сборку на ней проверяли. Логи хранят ограниченный срок, скрывают токены и персональные данные. Для повторной проверки достаточно команды запуска, тестовых данных и ожидаемого результата; бесконечное видео рабочего стола не нужно.
Как начать без перестройки разработки
Выберите один тип небольших задач, например исправление визуального дефекта. Добавьте в шаблон заявки три проверяемых сценария и поле «не проверялось». На первой неделе агент только предлагает патч и пакет доказательств, а команда принимает работу прежним способом. После десяти задач сравните время и возвраты, затем решайте, расширять ли права.
Что сообщить заказчику
В описании результата укажите, где использовался агент, какие проверки выполнил человек и какие ограничения остались. Не нужно превращать технический отчёт в рекламу модели. Заказчику важны поведение функции, известные границы и контакт ответственного. Такая прозрачность упрощает разбор проблемы и не создаёт обещания, что любой следующий запрос будет выполнен без ошибок.
Ограничения кейса
OpenAI и Cognition рассказывают о собственном продукте и выбранных удачных сценариях. Материал не публикует общую частоту ошибок, стоимость каждой проверки и сравнение с другими моделями на одинаковых задачах. Поэтому кейс даёт хороший производственный принцип, но не готовое бизнес-обоснование покупки. Его нужно подтвердить на репозитории, стеке и команде конкретной компании.
Вывод и частые вопросы
Главный урок — агент должен приносить доказательство выполненной задачи. Нужна ли запись каждой правки? Нет, формат зависит от риска: иногда достаточно теста и журнала. Можно ли выпускать изменение после отчёта агента? Только по правилам проекта и с человеческой приёмкой. С чего начать? С одного повторяемого изменения, тестовой среды и заранее написанного контракта готовности.