Агенту поручили сохранять незавершённую заявку. Текст после открытия на месте, тесты зелёные. Затем пользователь меняет аккаунт — и получает ту же заявку. Кнопка исчезла: агент выбрал автосохранение. Новый пакет потребовал обновления SDK, и разработчик теперь чинит сборку.

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

Что значит закончить позже: после перехода на другой экран, перезапуска или входа с другого телефона? Сохранять по кнопке? Удалять при выходе? Выбор библиотеки не отвечает ни на один вопрос. После реализации догадку агента уже легко принять за договорённость.

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

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

Если решения нет, полезен точный вопрос: «Удалять черновик при выходе или оставлять до следующего входа? В требованиях ответа нет. При удалении человек потеряет заявку; при сохранении нужны правила доступа и срока хранения. Пока могу сделать кнопку и обработку ошибки записи».

Такой вопрос экономит переделку. Постоянное «можно прочитать следующий файл?» — нет.

Проверять работу тоже лучше через действия человека. Новый объект хранилища прочитал строку — это ещё не восстановление после завершения процесса. Скриншот «Сохранено» не проверяет отказ записи. К сценарию нужны версия кода и фактический результат; незапущенный тест не становится пройденным после уверенного отчёта.

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

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

В материале ArkTelos Lab «Агент написал код. Почему проект всё равно приходится переделывать?» — постановка, правила остановки и передача работы следующему агенту. Не обещание безошибочной разработки: способ раньше заметить, что написан уже другой продукт.

Полная статья: https://labs.arktelos.dev/ru/articles/agent-project-control/ ArkTelos: https://arktelos.dev/ru Журнал: https://labs.arktelos.dev/ru Lab RU: https://t.me/arktelos_lab_ru Lab EN: https://t.me/arktelos_lab ArkTelos RU: https://t.me/arktelos_ru ArkTelos EN: https://t.me/arktelos