Спор вокруг оценки coding-агентов уперся в один неудобный тезис: проблема не в том, что агенты якобы невозможно измерить, а в том, что многие до сих пор пытаются измерять не то. Если смотреть на красивый диалог с моделью, выводы будут случайными. Если смотреть на код, тесты, логи и цену ошибки, оценка coding-агентов быстро перестает быть философией и становится обычной инженерной дисциплиной.
Именно это, как пишет The New Stack, и стало нервом колонки Pete Hampton: в споре с поставщиком software factory он возражает против позиции, будто coding agents в принципе не поддаются оценке. Контраргумент предельно земной: оценивать нужно не «интеллект» агента и не убедительность его реплик, а выполненную работу. Иначе говоря, вопрос надо ставить так же, как в нормальной разработке: задача закрыта или нет, тесты проходят или нет, изменения ограничены рамками запроса или агент утащил за собой полрепозитория, стало дешевле сопровождать код или дороже.
Это важный сдвиг для рынка, потому что вокруг агентной разработки за последний год накопилось слишком много маркетинга и слишком мало разговоров о приемке результата. Демка, где агент бодро правит баг за три минуты, выглядит эффектно. Но в реальной команде ценность измеряется иначе: сколько человеко-часов ушло на постановку задачи, сколько итераций потребовалось, что именно агент прочитал перед правкой, какие файлы изменил, какие проверки запустил, что сломал попутно и насколько легко ревьюеру понять, можно ли это мержить. Для CTO и тимлидов это не академический вопрос. Это уже вопрос стоимости внедрения и управляемости процесса.
Логика тут, по сути, старая добротная инженерная. Код давно оценивают не по красоте обещаний автора, а по артефактам: diff, покрытие, регрессии, производительность, безопасность, maintainability. С coding agents работает тот же принцип. Если агент закрыл issue, но добавил хрупкие тесты, нарушил контракты API или оставил после себя код, который команда потом будет распутывать неделю, такая «успешность» мало чего стоит. И наоборот: если агент не всегда решает задачу с первого прогона, но держит изменения в узких границах, честно показывает, что запускал, и оставляет воспроизводимый результат, его уже можно сравнивать с альтернативами. Это и есть взрослая оценка coding-агентов: не гадание о потенциале, а проверка качества поставки.
Контекст у этой дискуссии широкий. В 2025 и 2026 годах рынок AI for software engineering буквально оброс бенчмарками: от SWE-bench и SWE-bench Verified до более практических наборов задач, где проверяют не только фиксы багов, но и работу по всему инженерному циклу. Параллельно крупные игроки начали открыто говорить, что одной метрики «прошел тесты» уже недостаточно. Для одиночного PR это еще терпимо, но для production-разработки нужно видеть траекторию: как агент пришел к решению, какие инструменты использовал, как восстанавливался после ошибок, не переобучился ли на конкретный eval и не маскирует ли неуверенность длинными объяснениями. Иными словами, рынок сам подталкивает команды от шоу-кейсов к нормальным приемочным рамкам.
Для разработчиков это означает довольно трезвую вещь: лучший способ подготовить проект к работе с агентами — не искать «самую умную» модель по лидерборду, а сделать кодовую базу проверяемой. Хорошие unit- и integration-тесты, понятные контракты, линтеры, статический анализ, воспроизводимый CI и аккуратные правила репозитория внезапно становятся не бюрократией, а интерфейсом для ИИ. Агент особенно хорош там, где результат можно быстро и недвусмысленно проверить. Где критерии размыты, документация устарела, а доменные ограничения живут в головах двух старожилов команды, агент будет не ускорителем, а генератором дорогого шума. Отсюда и практический вывод для продактов и фаундеров: покупать доступ к модному агенту без вложений в верификацию процесса примерно так же разумно, как автоматизировать завод, не поставив датчики качества на линии.
Для бизнеса эта колонка The New Stack тоже бьет в больное место. Многие компании все еще обсуждают coding agents в терминах «заменит/не заменит разработчика», хотя операционный вопрос звучит иначе: на каком классе задач агент снижает стоимость поставки, а на каком создает скрытый долг. Если мерить только скорость первого ответа, почти любой инструмент покажется выгодным. Если мерить полный цикл, включая ревью, регрессии, переработки и пострелизные инциденты, картина может измениться радикально. Поэтому зрелые команды, скорее всего, будут сравнивать не модели как таковые, а целые рабочие контуры: агент плюс тестовый контур, агент плюс sandbox, агент плюс правила доступа к репозиторию, агент плюс обязательный human review для рискованных изменений.
На выходе у этого спора получается неприятный, но полезный вывод для всей отрасли: проблема не в том, что coding agents невозможно оценить, а в том, что их слишком долго пытались оценивать как чат-ботов. Следующий этап рынка, похоже, будет строиться не вокруг самых громких обещаний автономности, а вокруг тех команд, которые научатся задавать агентам проверяемую работу и быстро отбраковывать плохой результат. Победит не тот, кто громче всех рассказывает про «магический» ИИ-разработчик, а тот, кто первым превратит его в предсказуемый инструмент инженерного производства.