Разработчики привязываются к таким инструментам, как Vim и Emacs, или к интегрированным средам разработки не просто из-за привычки, а потому, что эти инструменты становятся частью того, как они думают, пишут и проверяют код. По мере приобретения пользователем многолетнего опыта команды и процедуры превращаются в неявное знание и мышечную память, поэтому инструмент начинает казаться естественным продолжением руки. Эта связь объясняет отчасти настороженность по отношению к инструментам агентного программирования, которые способны быстро создавать целые приложения, но уступают в точности, прозрачности и предсказуемости.
В статье инструменты связываются с доверием и окружающим их процессом. Надёжный инструмент — это не только тот, который выполняет задачу, но и тот, который позволяет разработчику понимать его ограничения и поведение, а также предсказывать результаты его работы. Возможности агентных инструментов искусственного интеллекта, напротив, постоянно меняются, а сами они зависят от команд на естественном языке, которые могут быть неоднозначными. Согласно данным последнего опроса разработчиков, на который ссылается статья, доля использования искусственного интеллекта выросла с 76% до 84%, тогда как доверие к нему снизилось с 40% до 29%.
Инструмент — часть процесса разработки
Обучение работе в терминале, текстовом редакторе или интегрированной среде разработки означает не просто освоение отдельной программы; оно означает создание целого процесса написания, понимания и улучшения кода. Поэтому переход от терминала к интегрированной среде разработки может потребовать переосмысления рабочего процесса, а переход от любой из них к инструменту агентного программирования представляет собой ещё более значительную трансформацию.
Tricia Gee, сторонница повышения продуктивности разработчиков, отмечает, что разработчик может работать быстрее в знакомой среде разработки, поскольку его пальцы привыкли к тому, что нужно делать. То же относится к опытным пользователям Vim и Emacs. Со временем формируется неосознанная компетентность, которая помогает разработчику доверять инструменту и использовать его для создания и улучшения кода.
Традиционные инструменты, такие как интегрированные среды разработки, инструменты контейнеризации и статические анализаторы, дают пользователю ясное представление о своих границах и ролях. Искусственный интеллект, напротив, проникает в разные части цепочки инструментов жизненного цикла разработки программного обеспечения, поэтому снижение доверия к нему влияет на весь процесс. Написание кода может ускориться, но его проверка и убеждённость в том, что он не вызовет дорогостоящих сбоев в рабочей среде, могут занять больше времени.
Инструменты не исправляют сломанные процессы
Инструменты агентного программирования изменили характер процесса разработки, из-за чего инструменты, созданные вокруг прежнего процесса, — например, статические анализаторы, модульные тесты, а также средства непрерывной интеграции и непрерывного развёртывания — могут оказаться менее подходящими в их нынешнем виде. Однако статья проводит различие между инструментом и воплощаемым им процессом: хороший инструмент непрерывной интеграции и развёртывания не гарантирует более быструю поставку, мощная интегрированная среда разработки не гарантирует написания лучшего кода, а система отслеживания задач не гарантирует точности оценки трудозатрат.
Часть процесса формируется культурой организации, поведением её сотрудников и их стандартами. Поэтому новые инструменты, какими бы многообещающими ни были их заявления, могут потерпеть неудачу, если не соответствуют существующей культуре и процессам или если разработчики не понимают, зачем их использовать. В статье отмечается, что инструменты агентного программирования быстро распространились, поскольку помогают разработчикам оперативно решать проблемы, но одновременно выявили давние недостатки в определении требований, формулировке проблемы и понимании того, что означает её решение.
Производство кода стало почти бесплатным по сравнению с прошлым, но его проверка не стала такой же. Разработчики могут столкнуться с огромными изменениями в запросах на слияние, которые агенты создают за считаные мгновения, что увеличивает нагрузку на проверяющих или побуждает их ограничиваться формальными проверками. Разрабатывается подход, при котором языковая модель выступает в роли судьи, чтобы расширить масштаб проверки, однако формирование доверия к способности искусственного интеллекта проверять код, написанный искусственным интеллектом, требует дополнительной работы.
Запуск кода также связан с затратами. К ним относятся расходы на инфраструктуру, облачные ресурсы — вычислительные мощности, память и трафик, — зависимые сервисы и размещённые программные интерфейсы, а также стоимость сбоев, включая простои, нарушения безопасности и альтернативные издержки. Инструменты, создающие код без учёта этих факторов, не обязательно полезны и могут ослабить процесс, который ранее позволял выпускать надёжное программное обеспечение.
Построение доверия через ответственность и процессы
В традиционном цикле разработки доверие распределялось между взаимосвязанными ролями: менеджеры по продукту определяли требования, архитекторы проектировали решения, инженеры создавали программное обеспечение и проверяли изменения, команда контроля качества тестировала точки отказа, а специалисты DevOps и SRE после запуска отслеживали производительность и ресурсы. Такое распределение помогало снизить вероятность того, что отдельный человек или инструмент выйдет за установленные границы и нанесёт ущерб системе.
В статье утверждается, что цикл разработки с поддержкой искусственного интеллекта нуждается в аналогичных принципах: работе с людьми, определении ответственности и подотчётности, совместном использовании и постепенном совершенствовании процессов, а также снижении вероятности ошибок. Люди должны оставаться ответственными сторонами, при этом следует ясно указывать, где именно участвовал искусственный интеллект.
Ответственность не переходит к агенту лишь потому, что он создал изменение. Человек, который отправляет изменение в репозиторий, отвечает за код, а тот, кто одобряет запрос на слияние, отвечает за это одобрение. Согласно логике статьи, если изменение приведёт к сбою в рабочей среде, нельзя переложить вину на среду разработки или инструмент; ответственность лежит на людях и процессе, которые позволили изменению пройти.
Эта трансформация создаёт ещё одну проблему, связанную с сотрудничеством. Агент может позволить одному разработчику выполнять задачи, охватывающие путь от требований к продукту до операций DevOps, что повышает вероятность его превращения в изолированный остров, не взаимодействующий с дизайнером или инженером, специализирующимся на конкретной кодовой базе. Статья предупреждает, что такой путь может привести к огромным запросам на слияние, даже если инструмент способен быстро выполнять работу.
Главный вывод заключается не в том, что новые инструменты бесполезны, а в том, что одного совершенствования инструментов недостаточно для исправления сломанного цикла разработки. Организациям нужны процессы, которые разработчики понимают и принимают, чёткие границы роли агентов, ответственная человеческая проверка и сотрудничество, не позволяющее превратить разработку в замкнутую индивидуальную деятельность. Тогда инструменты и культура смогут работать вместе, создавая новое доверие в среде разработки, основанной на искусственном интеллекте.