Почему опытные разработчики осторожны с агентным программированием
DeepSeek нашёл общую слепую зону у трёх ИИ-проверок, Claude не согласен
В обсуждении на Hacker News разбираются, почему опытные разработчики осторожны с агентным программированием. Автор связывает доверие к коду с ответственностью: ИИ полезен, если разработчик проверяет и понимает каждое изменение, ведь за поведение программы отвечает человек. По аналогии с парным программированием и TDD обсуждают, как инструменты меняют сеть доверия. Критики возражают: ответственность всё равно несёт коммиттер. Также отмечают пользу проверки кода несколькими агентами и моделями. Спор идёт о том, где проходит граница между делегированием и потерей контроля.
Материал на Hacker News посвящён спору о том, почему опытные разработчики с осторожностью относятся к агентному программированию. Отправная точка — мысль, что программное обеспечение работает потому, что за него кто-то отвечает. Автор проводит параллель с парным программированием и разработкой через тесты: в первом случае за конкретное изменение нет одного ответственного, во втором появляется соблазн считать, что прошедшие тесты уже доказывают качество, а в агентном программировании — что хороший промпт гарантирует хороший результат. По его мнению, ИИ действительно полезен в разработке, но только если человек просматривает и понимает каждое изменение: ответственность за то, как ведёт себя программа, всё равно остаётся на разработчике. При этом автор уточняет, что ответственность за отдельные изменения — плохой заменитель качества. Если требовать наказания за каждую ошибку, это скорее мешает, ведь люди ошибаются. Полезнее выстроить слои проверок и условия, при которых ошибку легче обнаружить и исправить. Он вспоминает опрос на работе с вопросом, безопасно ли на его команде ошибаться, и объясняет: речь не только о мягком руководстве, а о снижении вероятности проблем и упрощении восстановления после них. Показывать пальцем на виновного — не то, что делает софт надёжным; по мнению автора, это ближе к корпоративной логике, где важнее формальная ответственность, чем реальное качество. В обсуждении звучит и возражение: при парном программировании, TDD и работе с агентами всё равно есть коммиттер — один человек, который принимает изменение и несёт за него ответственность. Способ получить этот коммит — копирование, сниппеты IDE или агент — не меняет сути: отвечает человек, а не инструмент. Другой комментарий развивает пользу агентного подхода: агенту можно поручить добиваться высокого покрытия тестами, а затем попросить другие агенты и модели проверить код. Каждый слой проверки добавляет уверенности и повторяемости, хотя все проверки могут разделять одну слабость. Автор готов доверять коду, спроектированному, реализованному и проверенному тремя разными сильными моделями, больше, чем коду трёх средних программистов, но напоминает о цене такого подхода. Практический вывод для начинающего разработчика простой: агент ускоряет работу, но не снимает необходимость читать код, понимать изменения и отвечать за результат. Тесты и дополнительные проверки полезны как слои защиты, но не как замена ответственности. В материале также отмечают, что агенты пока слабы в делегировании, переговорах и видении контекста, поэтому человеку всё равно нужно управлять задачей и проверять результат.