Stack Overflow: разработчики всё чаще используют ИИ-агентов, но всё меньше им доверяют

Шесть лет назад блог Stack Overflow опубликовал статью о том, что IDE стали настолько мощными, что пользоваться Vim или Emacs, почти анахронизм; материал вызвал бурный спор разработчиков. Один из читательских комментариев тогда сослался на книгу «The Pragmatic Programmer» Дэвида Томаса и Эндрю Ханта: разработчикам как ремесленникам нужны «острые инструменты», которые ощущаются продолжением руки, а Vim и Emacs благодаря бесконечной настраиваемости можно подогнать точно под себя, время, вложенное в освоение и доработку инструмента, окупается доверием к нему.

Новые инструменты, агенты, с которыми разговаривают на естественном языке, менее точны, чем код, написанный вручную, зато выдают целые приложения за малую долю времени. Центральный вопрос, можно ли доверять результату. По собственному Developer Survey Stack Overflow (издание не называет год или выпуск опроса), доля разработчиков, использующих ИИ, выросла с 76% до 84%, но доверие к нему за то же время упало с 40% до 29%. Триша Джи, эксперт по продуктивности разработчиков, объясняет свою осторожность так: «Одна из причин, почему я не спешу с ИИ-программированием, с привычной IDE я быстрее, потому что знаю, как она работает. То же самое я видела у людей, которые прекрасно знают Vim и Emacs: можно показать им инструменты рефакторинга в IntelliJ IDEA, но это новая кривая обучения. Я так долго пользуюсь своим инструментом, что руки сами знают, что делать, это неосознанная компетентность». Автор добавляет мысль Бьёрна Страуструпа, создателя C++: «Код, это точная формулировка решения. Английский, негодный язык для выражения вещей, которые должны быть однозначными».

Тезис статьи: инструменты кодируют процесс, но никогда не были процессом сами по себе. Хороший CI/CD-конвейер сам по себе не означал более быструю поставку, хорошая IDE, не означала более качественный код, трекер задач со story points, не означал точную оценку трудозатрат; часть процесса всегда существовала как культура, как поведение и нормы команды. Агентный кодинг быстро прижился именно потому, что позволил решать задачи быстрее, но тем самым обнажил слабые места процессов, которые существовали и раньше: нечёткие и плавающие требования, просто теперь, чтобы решить задачу, нужно явно определить, что вообще значат «задача» и «решение». Новым узким местом стало код-ревью: раньше шутили, что PR быстро одобряют, если в нём меньше 100 строк; агенты же за секунды выдают огромные диффы, которые люди либо тщательно проверяют, либо просто штампуют не глядя. LLM-as-a-judge (когда код, написанный одной моделью, проверяет другая) развивается как масштабируемое решение, но выстроить доверие к тому, что ИИ способен проверять код, написанный ИИ, по словам автора, требует отдельной работы. Выполнение кода тоже не бесплатно: это расходы на инфраструктуру, оплачиваемые зависимости и API, а также цена сбоев, простоев, утечек безопасности и упущенных возможностей.

В старом цикле разработки продакт-менеджеры формулировали требования на основе исследований и общения с клиентами, архитекторы проектировали систему исходя из опыта, инженеры писали код и ревьюили коммиты, QA пытались сломать программу, а DevOps и SRE следили за продакшеном, и доверие строилось через совместную работу с людьми, понимание их мышления и ограничение того, насколько один человек или инструмент может подвести всю систему. Автор утверждает, что доверие к ИИ-циклу разработки нужно строить на том же: сделать людей ответственными и подотчётными, делиться рабочими процессами и дорабатывать их сообща, минимизировать пространство для ошибок. Первый шаг, закрепить, что ответственность несёт человек, а вклад ИИ отдельно помечен. Чарити Мэйджорс, CTO Honeycomb, о фразе «human-in-the-loop»: по её словам, это звучит как приглашение из жалости, тогда как на деле человек сам создал этот контур, сам им владеет и сам, единственная причина, по которой контур вообще существует. Если раньше, обрушив продакшен в пятницу, разработчик не винил в этом IDE, то и теперь ответственность лежит не на агенте, а «между клавиатурой и креслом», на том, кто закоммитил и кто одобрил PR.

Сотрудничество в эпоху ИИ становится сложнее и необычнее. Джейми Деланге, директор по продукту в Slack, отмечает: с агентом не обязательно советоваться с дизайнером насчёт дизайна и не обязательно работать с инженером из смежной области, чтобы разобраться в его коде, можно просто спросить агента и в одиночку зайти очень далеко, вплоть до создания огромного PR в одиночку. Некоторые предлагают промптить агентов в общей комнате, чтобы вся команда могла комментировать и корректировать процесс, либо прикладывать к каждому PR транскрипт переписки с агентом. Дейн Кнехт, технический директор Cloudflare, считает это ценным: возможность открыть PR и увидеть, как разработчик реально размышлял и решал задачу. Скотт Хансельман, вице-президент по работе с сообществом разработчиков в Microsoft, формулирует главный принцип нового процесса, убирать случайность ещё до того, как код написан: всё, что код должен делать, нужно явно прописать в промпте (для этого можно использовать файлы spec.md). Его пример: он попросил агента собрать небольшое приложение для кольцевого света на x64, но хотел и сборку под ARM, пришлось прямо сказать агенту «сделай версию для ARM», иначе такая версия просто не появилась бы. При этом нельзя втиснуть в один умный промпт всё нужное, не начав повторяться и не упустив что-то из негласного знания компании, такое знание нужно где-то фиксировать, проверять и подавать агенту как контекст по мере необходимости. А получив однажды хорошо специфицированный, прошедший ревью и доехавший до продакшена компонент, следующая проверка, больше никогда не писать его заново, а переиспользовать: это и есть принцип DRY (don't repeat yourself, «не повторяйся»).

Ключевые факты

• По Developer Survey Stack Overflow доля разработчиков, использующих ИИ, выросла с 76% до 84%, а доверие к нему за тот же период упало с 40% до 29%.
• Триша Джи (эксперт по продуктивности разработчиков) описывает разрыв через мышечную память: с привычной IDE и Vim/Emacs руки «сами знают, что делать», а с агентами такой наработанной интуиции пока нет.
• Автор эссе: инструменты вроде CI/CD, IDE или трекеров со story points сами по себе никогда не были процессом, они лишь кодировали его; агентный кодинг обнажил нечёткость требований, которая существовала и раньше.
• Новое узкое место, код-ревью: раньше шутили, что PR легко одобряют при изменении не больше 100 строк, а агенты выдают огромные диффы за секунды, которые либо тщательно проверяют, либо штампуют не глядя.
• Руководители Honeycomb, Slack, Cloudflare и Microsoft сходятся в рецепте восстановления доверия: ответственность остаётся за человеком, который коммитит и одобряет PR, а всё, что должен делать код, нужно явно прописывать в промпте или spec.md, иначе, по формулировке Скотта Хансельмана, «оставленное на волю случая так и останется на волю случая».

Почему это важно

Материал фиксирует конкретный и измеримый разрыв (рост использования ИИ при одновременном падении доверия к нему) и объясняет его не капризом, а системной причиной: доверие строится не вокруг возможностей инструмента самих по себе, а вокруг стабильного процесса и наработанной привычки к нему. Для читателя, который следит за внедрением ИИ-агентов в разработку, это редкий взгляд не на очередной релиз модели, а на организационные последствия, почему быстрый и мощный инструмент не превращается в доверие автоматически.

Кому это важно

Разработчикам, которые каждый день используют агентные инструменты кодинга и пытаются понять, почему их не отпускает недоверие к результату. Тимлидам, архитекторам и инженерным директорам, перестраивающим код-ревью и передачу знаний под агентную разработку, в статье прямо цитируются CTO Honeycomb, CTO Cloudflare, CPO Slack и вице-президент Microsoft по сообществу разработчиков, формулирующие, как распределять ответственность между человеком и агентом.

Как это применить

Явно прописывать в промпте (или в отдельном spec.md-файле) всё, что код должен делать, пример из статьи: Скотт Хансельман получил сборку приложения под ARM только после того, как прямо попросил её у агента. Прикладывать к PR транскрипт диалога с агентом, чтобы ревьюер видел ход рассуждений, так предлагает Дейн Кнехт из Cloudflare. Держать ответственность за коммит и за одобрение PR на человеке, который их сделал, а не перекладывать её на агента. Получив однажды рабочий и проверенный компонент, не писать его заново, а переиспользовать, принцип DRY.

Можно ли доверять

Это авторское эссе на блоге Stack Overflow, а не научное исследование. Ключевая статистика (рост использования ИИ с 76% до 84% при падении доверия с 40% до 29%) взята из собственного Developer Survey издания, но статья не называет ни год, ни конкретный выпуск опроса, на который ссылается. Основная аргументация построена на подборке цитат действующих руководителей (Honeycomb, Slack, Cloudflare, Microsoft) и одном читательском комментарии из статьи шестилетней давности, это набор экспертных мнений и наблюдений, а не количественное исследование причин падения доверия.

Риски и подводные камни

Автор предупреждает: агенты выдают ревьюерам огромные диффы за секунды, и код-ревью рискует превратиться в формальный штамп вместо реальной проверки; предлагаемое решение, LLM-as-a-judge, когда код одной модели проверяет другая, сам автор называет подходом, который «требует работы», то есть ещё не готовым. Отдельный риск, разработчик может превратиться в «разработчика-одиночку»: с агентом не обязательно советоваться с дизайнером или коллегой из смежной области, и вместе с этой эффективностью теряется командная проверка решений. Наконец, лучшие инструменты сами по себе не чинят сломанный процесс: если культура и практики команды остаются прежними, сломанный процесс с более совершенными инструментами так и останется сломанным.

«Если что-то оставить на волю случая, так оно и останется на волю случая. Мне нужно было собрать небольшое приложение для кольцевого света, я работаю на x64, но хотел, чтобы оно работало и на ARM, пришлось прямо сказать агенту: «Сделай версию под ARM». Не скажи я этого, версии под ARM просто не появилось бы.»

— Скотт Хансельман, вице-президент по работе с сообществом разработчиков в Microsoft