Когда код пишет агент: узким местом становится формулировка задачи
Когда AI‑агент пишет рабочий модуль быстрее, чем человек успевает его набрать, главным ограничением становится формулировка задачи. К такому выводу пришли авторы анализа месяца разработки с кодовым агентом. Они собрали 1,263 уникальных текстовых запроса одного инженера, сопоставили их со счетами за токены, историей merge и прокси‑метриками дефектов. Как пишет Towards AI, все три массива данных показывают одну и ту же закономерность: в agentic‑разработке решающим навыком становится ясность намерения. От нее напрямую зависят и скорость работы, и затраты.
На практике эффективные запросы почти не похожи на привычные шаблоны «prompt engineering». Медианный запрос оказался длиной 78 символов, около 13 слов. Две трети сообщений были короче 120 символов, а 86% начинались со строчной буквы и содержали опечатки, сокращения, слитные фразы. Чаще всего это короткие управляющие реплики вроде «yes, baseline, add todos», иногда плотные однострочные спецификации. Значение имеет не длина, а концентрация намерения: ожидаемый результат, жесткие ограничения, причина этих ограничений, область применения, уровень автономии и даже то, чего автор пока не знает.
Отдельно авторы подчеркивают роль объяснения причин. Если разработчик указывает, почему действует ограничение, модель переносит это суждение на последующую работу и может сама избегать неверных решений в коде, который пишет позже. По их наблюдению скорость разработки в такой среде фактически равна ясности намерения, деленной на неоднозначность. Расплывчатая постановка задачи нередко приводит к уверенно написанному, но неправильному коду.
В качестве примера приводится создание изолированной среды синтетических данных. Идея возникла на утренней встрече команды, и уже к тому же дню система запускала полный data plane на ноутбуке, изолированно от общего окружения и на детерминированных данных. Всю функциональность задали двумя сообщениями. Первое описывало исходные данные, артефакт, точку интеграции и цель. Второе вводило запрет на попадание реальных данных в synthetic corpus, задавало примерный масштаб и ставило вопрос: как системе различать synthetic и live данные, по имени или другим способом. Этот вопрос заранее определил архитектуру. Реализация использовала существующую маршрутизацию и выбирала зарезервированного synthetic tenant, без отдельной ветки «if synthetic». От первого запроса до рабочего решения прошло около четырех часов: примерно 2,700 чистых строк кода в двух репозиториях, оформленных как последовательность небольших pull request и подключенных к локальному harness.
Ключевые факты
В анализ включили 1 263 уникальных промпта, набранных человеком за месяц разработки с агентом в рамках сборки одного инженера.
Медианный промпт составлял 78 символов (около 13 слов); две трети сообщений были короче 120 символов, а 86% начинались со строчной буквы и часто содержали опечатки и сокращения.
Пример из практики: среда синтетических данных, идея которой появилась на утреннем совещании, к тому же дню запускала полный data plane на ноутбуке и была изолирована от общих сред.
От первого промпта до рабочего решения прошло около четырёх часов; результат включал примерно 2 700 чистых строк кода в двух репозиториях и был разбит на небольшие pull request.