GitHub опубликовал материал о том, как массовое использование ИИ‑агентов меняет цену небольших изменений в продукте и подход к планированию разработки.
Автор отмечает, что стоимость написания кода резко снизилась, а стоимость владения им осталась прежней. Раньше самой дорогой частью небольшой фичи было собственно программирование. Теперь, по мнению GitHub, больше ресурсов уходит на обсуждения: встречи, асинхронные переписки и споры о том, стоит ли вообще делать изменение.
Инженеры привыкают защищать команду от «маленьких запросов», которые легко превращаются в долгие доработки: нужны тесты, план раскатки, учёт крайних случаев, поддержка после релиза. Эта установка остаётся важной, но она строится на устаревшем предположении, что первая версия кода обходится дорого.
GitHub описывает типичный сценарий: кто‑то просит вывести на странице настроек поле last_active_at, которое уже есть в бэкенде. Команда тратит около сорока минут на обсуждение, вспоминает старые миграции, сроки релиза и в итоге называет оценку «день‑два, а может и больше», не попробовав сделать прототип.
Раньше такой подход оправдывался, так как попытка требовала времени: нужно было переключиться, загрузить контекст, вручную внести изменения, написать тесты и разобраться с побочными эффектами. Когда первый заход в задачу стал дешёвым, защита границ разработки может стоить дороже самого эксперимента.
Сейчас ИИ‑агент может за время обсуждения подготовить первый патч. Он не будет идеальным и бесплатным, но достаточно недорогим, чтобы перейти от догадок к анализу конкретного diff. Ошибка, по мнению автора, — считать этот патч готовым результатом. Его правильнее трактовать как зонд, который превращает абстрактный спор о «скоупе» в предметный артефакт для проверки.
Такой подход меняет вопросы в обсуждении. Вместо «похоже ли это на расширение объёма работ?» команда может спросить: что именно изменилось в коде, где риск, насколько сложно это поддерживать. Если diff состоит из четырёх строк с проходящими тестами, изменение можно быстро принять. Если тот же запрос затрагивает middleware авторизации, становится понятно, что задача изначально была «несанкционированно большой» — и это выясняется за полчаса, а не за два дня.
GitHub подчёркивает, что это не передача решения ИИ, а использование ИИ для удешевления и улучшения человеческого суждения. При этом дёшево стоит только то изменение, которое человек может уверенно проверить и взять на сопровождение. Большой diff, который формально проходит тесты, но не находит владельца, превращается в отложенную стоимость, а не в «быструю победу».
Поэтому принципиальная граница проходит не по вопросу «может ли агент это написать», а по вопросу «может ли инженер это качественно валидировать». Многие изменения по‑прежнему должны получать жёсткий отказ, даже если сгенерировать код легко: это всё, что меняет продуктовые договорённости, создаёт нагрузку на поддержку или затрагивает приватность, биллинг и соответствие регуляторным требованиям. ИИ уменьшает цену кандидатного решения, но не стоимость владения им.
Раньше дисциплина по управлению объёмом работ выстраивалась до начала реализации, потому что реализация была главным объектом защиты. Сейчас часть этой дисциплины может смещаться на этап ревью. Речь не об отказе от планирования, а об уточнении, какое планирование действительно экономит ресурсы.
Вместо затяжных споров о мелких изменениях автор предлагает запрашивать ограниченную попытку от агента с чёткими условиями: минимальный патч, сохранение текущих feature flag, отсутствие изменений публичного контракта, обязательные тесты и явный список затронутых файлов с пометкой рискованных мест. Если агент не может уложиться в эти рамки, задача больше, чем казалась. Если может — это тоже сигнал.
По оценке GitHub, в эпоху ИИ лучшими инженерами станут не те, кто соглашается на всё или всё отклоняет, а те, кто умеет быстро оценить неопределённость и реальную цену изменений. Они будут различать, где запрос маскирует продуктовое решение, где ревью обойдётся дороже написания кода, а где изменение действительно достаточно мало, чтобы разумной стратегией было «просто попробовать» в заданных рамках.
Ранее «попробовать и посмотреть» означало отвлечь разработчика от основной работы. Теперь для некоторых задач это означает выдать ИИ‑агенту чётко ограничённое задание и использовать результат для более обоснованного решения. Так меньше времени уходит на догадки и больше — на контроль и оценку конкретных артефактов.
GitHub делает вывод, что рост кода, сгенерированного ИИ, ослабляет аргумент «любое новое изменение слишком дорого». Производство кода подешевело, тогда как понимание, ревью и сопровождение остались прежними по цене. Поэтому ключевой вопрос смещается от «добавит ли это работы?» к «где настоящая стоимость этого решения?». Для небольших ограниченных запросов она всё чаще заключается не в самом изменении, а в усилиях, необходимых, чтобы это понять.
Автор статьи — инженер команды Copilot Agent Control Plane в GitHub, которая разрабатывает слой управления подагентами для клиентов Copilot.
Источник: материалы GitHub о GitHub Copilot, ИИ‑агентах и инженерных практиках.
