Агентный искусственный интеллект обещает более быстрое кодирование, но скрытые риски в тестировании, безопасности и сопровождении могут сорвать проекты, если разработчики не переосмыслят подход к управлению, проверке и контролю за ПО, созданным машинами в больших масштабах, пишет на портале ZDNet ИТ-аналитик Дэвид Гевирц.
Существуют два основных нарратива о вайб-кодинге. Первый заключается в том, что вы можете написать одно предложение, и ИИ создаст вам приложение стоимостью в миллион долларов. Второй — в том, что, поскольку весь код пишет ИИ, люди понятия не имеют, что в нем содержится. Следовательно, в конечном итоге он должен потерпеть неудачу и вызвать масштабный апокалипсис. Оба этих нарратива — карикатуры на реальность.
В этой статье я собираюсь углубиться в вопросы сопровождения и устойчивости, которые возникают при передаче контроля над кодированием машине.
Когда я был молодым менеджером по продуктам, меня отправили в Лос-Анджелес поддержать нашего вице-президента по продажам. Он решил взять меня в один из своих любимых ресторанов. Этот ресторан специализировался на фьюжн-кухне, что означало, что шеф-повар смешивал множество разных влияний в своих блюдах. Он славился своим фирменным блюдом, которое представляло собой то, что шеф-повар решал приготовить для вас в тот вечер.
Я помню, как задавался вопросом, во что я ввязался. Я знал, что мне подадут еду, но понятия не имел, что мне придется съесть. Как оказалось, еда, которую мы ели в тот вечер, была... странной. Она была съедобной. Но я бы туда больше не пошел по собственной воле.
Агентное программирование очень похоже на поход в этот ресторан. Вы знаете, что репутация используемого вами ИИ-кодера хороша, но вы понятия не имеете, что вы получите. У вас мало информации о самом коде, исходящем от ИИ. Но вам, по сути, придется это съесть, независимо от того, что вам подали.
Когда ваш код пишут агенты, это всё равно что иметь группу подрядчиков или подчинённых, пишущих ваш код. Пока вы его не протестируете и не оцените, вы понятия не имеете, что получили.
С ИИ всё зависит от вашего промпта. Принцип «мусор на входе — мусор на выходе» имеет гораздо более глубокий смысл, чем подразумевает старая избитая фраза. Если вы не задаёте промпт достаточно чётко и не поддерживаете диалог с достаточными ясностью и контролем, код, который вы получите от ИИ, будет трудно принять.
Хотя большая часть мрачных прогнозов в отношении вайб-кодинга — это гипербола, в них есть и доля правды. Без стандартов и практик качества вы можете получить проблемный код. Ниже мы обсудим мифы, окружающие агентное программирование, и лучшие практики, которые помогут вам получить от ИИ именно то, что вы запрашивали.
1. Миф о потере контроля
Менеджеры инженерных проектов сталкиваются с проблемой управления контролируемых ими подрядчиков ещё со времён пирамид. Распределение работы и оценка результатов — это то, чем они занимаются. Поддержание качества и контроля в этом процессе лежит в основе разработки ПО.
Многие сторонники ИИ-кодирования рекомендуют предоставлять ИИ подробные, богатые документы с требованиями. Однако, по моему опыту, ИИ может неправильно истолковать один-единственный элемент подобного документа и полностью сойти с рельсов таким образом, что это невозможно отследить или обнаружить.
Я предпочитаю дать ИИ одну простую задачу. После ее успешного выполнения я даю ему другую. Таким образом, у ИИ или у меня меньше шансов потерять из виду общий план.
В свою бытность разработчиком я привык писать код построчно. Я тщательно прорабатывал каждую строку. Я знал о своем коде все. Но когда я стал инженерным руководителем, мне пришлось полагаться на свои команды и отдельных разработчиков в моих командах.
Конечно, у нас были программисты (примерно эквивалент агентов). Но мне все равно нужно было внедрить в систему дисциплину тестирования и интеграции, чтобы убедиться, что все, что было предоставлено любым из наших программистов или подрядчиков, работает со всем остальным.
Если вы собираетесь использовать агентное программирование, вам нужно будет сделать то же самое. Расставьте контрольные точки на каждом этапе. Тщательно отслеживайте интеграцию. Представьте, что вы получаете работу от сторонних подрядчиков, и поэтому вам необходимо проверить ее, прежде чем включать в основной проект.
2. Миф о готовности к реальному миру
У меня есть друг, с которым я боюсь делиться своими программными проектами. Как бы тщательно я ни проектировал и ни тестировал свой код, как только я даю ему его запустить, он ломается.
Это потому, что он использует код без моего «проклятия знания». Я знаю, что должен делать мой код. Я знаю, как должна работать программа. Я пишу код именно для этого. Мой друг, однако, не имеет этой внутренней карты в голове. Он просто использует его. В процессе использования он всегда пытается сделать что-то, чего я никогда не ожидал. Код ломается.
Это классический пример хрупкости автоматизированных систем тестирования. Конечно, автоматизированные тесты могут помочь определить, не сломало ли недавнее исправление что-то ещё. Но поскольку вы заранее планируете тесты, вы неизбежно что-то упустите, что посторонний человек без «проклятия знания» о полной спецификации вашего проекта неизбежно обнаружит.
В некотором смысле, ИИ может выполнять роль неподготовленного друга. Ему можно поручить провести различные тесты, чтобы проверить, выдержит ли код. Но когда ИИ просят создать собственный набор тестов, он также ограничен той точкой зрения, которую он использует или которая ему предлагается при работе над проектом.
Большинство модульных тестов проверяют так называемые «счастливые пути» — пути, которые разработчики знают и ожидают от кода. Но эти же модульные тесты часто упускают из виду крайние случаи. Когда ИИ создает модульные тесты, он часто наследует те же слепые пятна, что и тесты, созданные человеком.
Кроме того, тестовые среды не являются реальными средами. Более 20 тыс. веб-сайтов работают под управлением моего ПО для обеспечения безопасности. Вы не поверите, о каких проблемах сообщают некоторые пользователи. Они варьируются от реальных ошибок до многодневных обращений в службу поддержки, чтобы в итоге выяснить, что ПО не работает, потому что пользователь его не устанавливал.
Многие менеджеры программистов основывают свои предположения о корректности на отчетах диагностических и тестовых систем. Получение хорошего покрытия и показателей производительности от тестов, страдающих от «проклятия знания», может легко скрыть реальные проблемы.
Вот реальная цена. Когда ошибки обнаруживаются на этапах интеграции и развертывания, а не в процессе разработки, сложность и стоимость отладки могут значительно возрасти.
Чтобы преодолеть эту проблему, тестируйте как сторонний наблюдатель. Внедряйте методы тестирования с использованием состязательных сценариев. В своих запросах обязательно включайте в каждый план тестирования сценарии крайних случаев, режимов отказов и неправильного использования. Назначайте людей и/или ИИ для преднамеренно неправильного использования и злоупотребления кодом без руководства, имитируя реальных пользователей без внутреннего контекста. Встраивайте средства мониторинга для выявления неожиданного поведения. Кодируйте все с учетом возможных ошибок и сбоев.
Если вы используете агентное программирование, помните, что ваш проект никогда не заканчивается. Он находится лишь в состоянии, достаточно хорошем для тестирования. Ожидайте поломок. Встраивайте процессы исправления в вашу структуру управления и в сам код.
3. Миф о наследуемом коде
На протяжении многих лет работы в индустрии ПО как в качестве сотрудника, так и в качестве владельца бизнеса, одной из моих основных компетенций было приобретение прав на интеллектуальную собственность в области ПО.
За исключением двух приложений для Apple, над которыми я сейчас работаю методом вайб-кодинга, все продукты, которые я выводил на рынок, изначально были написаны кем-то другим. В этом были свои преимущества. Большинство продуктов уже имели существующую клиентскую базу и глубокое понимание основной функциональности.
Но приобретение продуктов также сопряжено с трудностями. Обычно есть причины, по которым интеллектуальная программная собственность становится доступной для приобретения. Это может быть технический долг, когда что-то не работает. Изменения на рынке могут снизить ценность ПО. Или это может быть (и это было важным фактором моих приобретений) сильная усталость со стороны первоначальных разработчиков. Они больше не хотят брать на себя ответственность за обслуживание и поддержку.
Обычно мне доставались «черные ящики». Код был создан другими людьми и командами. Чтобы улучшить его, поддерживать и просто не дать ему взорваться у меня перед глазами, мне приходилось каким-то образом осваивать код, в котором скрыты всевозможные секреты. Это как купить дом без осмотра, а потом обнаружить неисправную проводку и сломанные трубы внутри стен.
Вот так будет выглядеть любой опыт ИИ-кодирования. По определению, код пишут не люди-разработчики. ИИ создают целый «черный ящик». Вам остается только надеяться, что он запустится.
Не сдавайтесь. Я построил карьеру, поставляя код, который не до конца понимал после приобретения. На ранних этапах мне приходилось полагаться на свои команды программистов, чтобы разобраться. Позже, когда я перешел к самостоятельной карьере разработчика, я систематически изучал отдельные сегменты кода, прорабатывая функцию за функцией, часто движимый желанием добавить новую функцию или исправить проблему, о которой сообщили клиенты.
4. Миф о долге за обслуживание
Поскольку ИИ не является человеком, проектные решения и структура кода не разрабатываются с учетом человеческих потребностей. В случае возникновения проблем отладка состоит из сочетания обратного проектирования работы ИИ и убеждения ИИ исправить то, что он, возможно, изначально не до конца понял.
Код, созданный ИИ, часто не обладает последовательной целью, структурой и архитектурной согласованностью. Это создает шаткий фундамент, поэтому все, что строится на его основе или впоследствии, становится лоскутным одеялом из разрозненных элементов, собранных воедино. Аналогично, соглашения и шаблоны именования могут сильно различаться в компонентах, созданных ИИ. В результате изменения и обновления приводят к неожиданным ошибкам в слабо связанных областях.
После нескольких дней работы с Claude над новым приложением для iPhone я решил взглянуть на файловую структуру. Она оказалась совершенно непоследовательной. ИИ решил размещать файлы где угодно. Он называл их так, как, казалось, хотел. Что касается структуры, он ничего не группировал. Это была огромная куча файлов в одном главном каталоге. Но так быть не должно. Я дал указание ИИ убрать за собой, и он это сделал. Потребовалось несколько попыток, чтобы создать осмысленную файловую структуру. Потребовалось ещё несколько попыток, чтобы закрепить эту практику в стартовых инструкциях. Мышление менеджера помогло мне справиться с управлением своим цифровым подчинённым.
Точно так же бывают случаи, когда тщательный анализ кода может привести к значительным результатам. Мой совет для эры агентного программирования, в которую мы вступаем, — использовать несколько систем агентного ИИ, основанных на разных больших языковых моделях. Не несколько агентов, а несколько ИИ. Пусть одна модель проверяет код другой модели. Пусть одна модель будет создателем. Пусть другая будет оценщиком.
Этот подход не решит всех проблем. Я использовал Claude Code и OpenAI Codex для проверки работы друг друга. Я был очень доволен тем, как при тщательной координации с моей стороны они обеспечили друг другу достаточную честность.
5. Миф об отсутствии уязвимостей в исходном коде
Если задуматься, как только вы сочетаете хрупкость тестирования с долгом по поддержке, неизбежно возникают слепые зоны безопасности. Плохо написанный код с присущими ему точками отказа — это рецепт идеального шторма проблем безопасности.
В некотором смысле, с ИИ ситуация еще хуже. Модели ИИ-кодирования обучались на основе информации из общедоступного Интернета. Она включает в себя огромное количество ошибочного кода и плохих советов. Программисты публикуют информацию в Интернете дольше, чем любая другая профессиональная группа, поэтому масштаб и диапазон этой базы знаний могут быть больше, чем практически в любой другой области.
Поскольку бóльшая часть открытого исходного кода размещается на GitHub, базовое ПО, на котором работает бóльшая часть мира, также доступно для обучения моделей. В чем подвох? Этот код не всегда работает, регулярно содержит ошибки и уязвимости, иногда тестировался лишь косвенно одним разработчиком и часто сопровождается комментариями от программистов, которые допускают ошибки. Очень много ошибок.
Таким образом, модели вполне могут воспроизводить небезопасные шаблоны кодирования, полученные из общедоступных данных. Пробелы в проверке и очистке входных данных позволяют использовать скрытые векторы эксплуатации уязвимостей. Я был шокирован, обнаружив, что ИИ, который я использовал для работы над своим продуктом безопасности, абсолютно не проверял входные данные, полностью игнорируя лучшие практики. Как только я скорректировал свои человеческие предположения и дал указание ИИ правильно проверять входные данные, процедуры проверки оказались лучше, чем те, которые я написал сам. Но мне пришлось тщательно проинструктировать ИИ, чтобы он обеспечивал безопасность.
ИИ также, вероятно, будет включать библиотеки, которые, кажется, подходят для решения проблемы, не проверяя цепочку поставок на наличие уязвимостей или проблем в нисходящем потоке. Поскольку ИИ генерирует код гораздо быстрее, чем мы, люди, можем его перепроверить, существует большая вероятность появления ошибок, которые мы просто не сможем обнаружить на скорости реального мира.
Добавьте к этому быстро растущие объемы кода, ставшие возможными благодаря генерации, которая занимает часы вместо месяцев, и вы получите гигантскую бомбу замедленного действия из непроверенного и потенциально небезопасного кода.
Имейте в виду, что код, написанный человеком, также может быть кошмаром с точки зрения безопасности. ИИ иногда может помочь решить эту проблему.
Мой хостинг-провайдер недавно сообщил мне, что используемый мной опенсорсный блокировщик спама имеет серьезную уязвимость. Автор не смог внести исправления. Тогда я попросил свой ИИ проверить код, выявить уязвимости и создать новый модуль кода, который не содержал этих уязвимостей.
Использование отдельного ИИ для проверки кода первого ИИ выявило еще несколько моментов, которые требовали исправления, и я затем попросил первый ИИ их исправить. Мы повторяли цикл, пока ошибки не перестали обнаруживаться. Прошло уже несколько месяцев с тех пор, как я установил этот новый код на свой сервер. За это время хостинг-провайдер не пометил новую реализацию как подозрительную.
Мыслите как генеральный подрядчик, а не как мастер-ремесленник
Возможно потому, что бóльшую часть своей карьеры в сфере разработки ПО я работал с кодом, приобретенным в результате поглощения интеллектуальной собственности или созданным подрядчиками и сотрудниками, меня не пугает тот факт, что код, написанный ИИ, — это большой черный ящик. Просто для работы с ним требуются другие навыки.
Многие статьи, предостерегающие от использования ИИ в программировании, утверждают, что, хотя период написания кода в жизненном цикле ПО значительно сокращается, периоды отладки и сопровождения расширяются, чтобы учесть беспорядок, который ИИ создает в своем коде, часто после того, как он был отправлен пользователям.
В этом опасении есть доля правды, но на самом деле это ничем не отличается от ситуации с приобретенным кодом или кодом, написанным подрядчиками. Инженерные менеджеры сталкиваются с этими проблемами десятилетиями. Хорошие методы разработки, планирования и управления ПО призваны преодолеть проблему непрозрачности подрядчиков. Для этого просто требуются дисциплина, обучение и опыт.
Все это сводится к тому, что ИИ — это не волшебная палочка. Вам никогда не удастся, задав промпт в одну строку, создать продукт стоимостью в миллион долларов. Вам придется поработать. Вы можете сократить время выхода на рынок. Вы можете использовать ИИ для помощи в техническом обслуживании. Вы можете использовать ИИ для поиска и устранения уязвимостей безопасности. Вы можете получать удовольствие от работы с ИИ.
Просто помните, что ИИ — это инструмент, а вы — профессионал. Вам нужно управлять процессом, целенаправленно делегировать и активно тестировать. Если вы будете это делать, вы, скорее всего, сможете избежать «апокалипсиса» вайб-кодинга и добиться надежных результатов.
