Я всё ещё боюсь работать с ИИ: почему ускорение разработки добавляет проблем

Подробности изложены в материале первоисточника. Привет всем читателям сайта Sergey Bagrov! Меня зовут Сергей Багров, и сегодня я хочу продолжить разговор о том, с какими реальными трудностями сталкиваются разработчики при активном внедрении искусственного интеллекта в повседневные задачи. Многим кажется, что современные нейросети полностью решают все проблемы написания кода, но на практике ситуация выглядит гораздо сложнее и требует более глубокого осмысления.

Когда тесты успешно проходят, а нужная функциональность работает с первого раза, возникает соблазн сразу переключиться на следующую задачу. Однако за скорость генерации кода всегда приходится платить необходимостью глубоко разбираться в написанном продукте, проверять чужие или сгенерированные решения и нести ответственность за итоговый результат.

Теперь мы все продуктовые инженеры

Бизнес всегда стремился выпускать как можно больше полезных функций при минимальных затратах на разработку. Концепция фулстек-разработки отлично вписывалась в эту стратегию: один специалист самостоятельно пишет и бэкенд, и фронтенд, не дожидаясь помощи от смежных команд. Теперь же к этому добавляется искусственный интеллект, и от разработчика требуют закрывать задачи из самых разных технологических областей.

Специалисты по продуктовой разработке еще несколько лет назад прогнозировали размывание границ между узкими специализациями. Предполагается, что в будущем ИИ возьмет на себя всю техническую рутину, а человек будет лишь определять требования и оценивать итоговый результат. Но на практике это означает, что мне приходится погружаться в незнакомые кодовые базы — например, в старые монолиты на C++ — и самостоятельно проверять чужой или сгенерированный код, тратя на это немало времени.

Одного болванчика уже мало

Обычно всё начинается с использования одной простой нейросети. Со временем для разных задач подбираются специализированные инструменты от разных компаний, и формируется целый набор предпочтений, который приходится постоянно пересматривать из-за частых обновлений. Приходится решать, какому помощнику доверить конкретную задачу, а где перепроверить спорный фрагмент кода.

Такой подход порождает массу дополнительной рутины. Новому агенту нужно подробно объяснять текущий контекст проекта, прошлые попытки решения и имеющиеся ограничения. Более того, модели иногда демонстрируют регрессию качества после обновлений, из-за чего вчерашний эффективный помощник начинает повторять ошибки, а разработчик тратит рабочее время на отладку инструкций вместо решения бизнес-задач.

Если на работе разрешён только свой болванчик

Многие компании вводят жесткие ограничения на использование внешних облачных сервисов из соображений безопасности. В таких условиях передовые инструменты от ведущих зарубежных разработчиков остаются доступны только дома, а на рабочем месте приходится пользоваться локальными или корпоративными аналогами.

Когда привыкаешь к мощным агентам, способным автономно анализировать проект и выполнять сложные тесты, возвращение к менее функциональным локальным моделям сильно замедляет работу. Приходится вести такого помощника буквально за руку, самостоятельно доделывая то, с чем продвинутые нейросети справлялись за считанные минуты, и рисковать отставанием от конкурентов.

Meat proxy: я уже переслал твой вопрос нейросетке

В современной разработке появился новый антипаттерн — человек, который просто пересылает запросы и ответы между коллегами и нейросетью, не пытаясь вникнуть в суть происходящего. Когда кто-то приносит Pull Request с архитектурными изменениями, в создании которых участвовал исключительно ИИ, обсуждение превращается в пересылку готовых простыней текста.

В результате реальный разработчик тратит время на анализ и направление процесса, пока его коллега формально отчитывается об ускорении своей работы за счет копирования ответов нейросети. Подобное взаимодействие не уменьшает общую нагрузку, а лишь перераспределяет её, превращая код в результат слепого доверия алгоритмам.

Код пишет агент, а занят всё равно ты

Даже при добросовестном подходе, когда каждый участник команды проверяет сгенерированный код, объем работы не уменьшается. Пока я разбираю один объемный diff, нейросеть успевает подготовить следующий, требующий не менее внимательного изучения и отладки.

Исследования показывают, что после внедрения искусственного интеллекта на этап ревью кода уходит значительно больше времени. Разработчики начинают брать в работу больше параллельных задач, что напрямую ведет к профессиональному выгоранию, ведь вместо долгожданного отдыха приходится непрерывно проверять отчеты и исправления от нескольких ИИ-помощников одновременно.

Теперь нужно читать ещё и спецификации

Для улучшения качества генерации кода принято использовать разработку на основе спецификаций, когда перед написанием реализации подробно фиксируются все требования. Специальные инструменты помогают развернуть краткое описание в полноценный технический план и набор markdown-файлов.

Однако эти спецификации также требуют тщательного ревью и постоянного обновления по мере изменения логики проекта. Если сгенерированный документ изначально содержит ошибку в понимании задачи, она беспрепятственно дойдет до кода и тестов, создавая видимость идеальной согласованности при совершенно неверном итоговом результате.

Репозиторий Шрёдингера

После нескольких месяцев активного использования агентов проект начинает казаться чужим. Функциональность работает корректно, коммиты числятся за мной, но при необходимости внести изменения в недавний модуль приходится заново просить нейросеть объяснить происходящее внутри.

Команда постепенно теряет глубокое общее понимание системы, накапливая своеобразный когнитивный долг. Если стандартный вопрос о назначении той или иной проверки раньше решался обращением к автору кода, то теперь авторов двое — коллега и языковая модель, а реальные знания о внутренней логике проекта безвозвратно теряются.

Бизнес уже заложил ускорение в следующий план

Руководство быстро замечает рост производительности на первых этапах и закладывает возросшую скорость в новые планы разработки. При этом время, затрачиваемое на детальное ревью кода и исправление скрытых дефектов, в эти расчеты обычно не включается.

В результате возникает серьезное давление сроков, подталкивающее разработчиков просто просматривать основные файлы и нажимать заветную кнопку подтверждения. Без официального признания ревью полноценной частью рабочего процесса погоня за закрытыми тикетами приводит к накоплению скрытых проблем в проекте.

И что в итоге

Подводя итог, можно сказать, что искусственный интеллект действительно помогает закрывать стандартные задачи гораздо быстрее. Однако общий объем работы от этого не уменьшается, а специфика обязанностей существенно меняется.

Я не собираюсь отказываться от использования современных агентов, но важно понимать, что быстро написанный код требует не меньше внимания на этапе проверки и осмысления. Высвободившееся время стоит направлять на глубокое понимание архитектуры проекта, чтобы не превратиться в оператора чужих алгоритмов.