ИИ-агенты обещают ускорить разработку, но также могут создать новые проблемы с тестированием, безопасностью и поддержкой кода. По мнению обозревателя ZDNET Дэвида Гевирца, главная ошибка разработчиков — воспринимать ИИ как магический инструмент.
ИИ-агенты обещают ускорить разработку, но также могут создать новые проблемы с тестированием, безопасностью и поддержкой кода. По мнению обозревателя ZDNET Дэвида Гевирца, главная ошибка разработчиков — воспринимать ИИ как магический инструмент.
Гевирц сравнивает агентное программирование с работой подрядчиков. Когда код пишет не сам разработчик, а внешняя команда (или ИИ-агент), — результат нельзя принимать на веру. Его нужно проверять, тестировать, интегрировать и сопровождать. «ИИ — это инструмент, а профессионал — вы», — пишет автор. Ниже краткий пересказ его колонки.
Сторонники вайб-кодинга часто говорят, что ИИ позволяет создавать приложения почти без участия человека, а критики предупреждают, что разработчики перестанут понимать, что находится внутри кода. Обе позиции карикатурны. На практике контроль не исчезает, но меняется роль разработчика: он становится не столько автором каждой строки, сколько менеджером, который ставит задачи, принимает работу и отвечает за качество. Не нужно давать ИИ огромные документы с требованиями сразу. Модель может неверно понять один пункт и увести проект в неправильную сторону. Более надежный подход — давать агенту небольшие задачи, проверять результат и только потом переходить к следующему шагу.
Автоматические тесты часто проверяют только ожидаемые сценарии, так называемые happy paths, но пропускают пограничные случаи. ИИ может помочь с тестированием, но если он сам пишет тесты, то унаследует те же слепые зоны, что и человек, который не представляет, как пользователь может «сломать» программу. Необходимо тестировать ИИ-код как внешний пользователь: специально искать нестандартные сценарии, злоупотребления, ошибки ввода и неправильное использование функций. Если вы используете агентное кодирование, помните: ваш проект никогда не завершен. Он просто находится в состоянии, достаточно хорошем для тестирования.
Сгенерированный код можно сравнить с продуктом, который достался от другой команды, подрядчиков или был куплен вместе с правами на ПО. С одной стороны, такой код может уже работать и решать нужную задачу. С другой — внутри часто скрываются неочевидные решения, технический долг, устаревшая логика и ошибки, о которых новый владелец проекта ничего не знает. Это похоже на покупку дома без проверки: снаружи все может выглядеть нормально, но позже выясняется, что в стенах неисправная проводка и сломанные трубы. Генеративный код устроен похожим образом: он может запускаться и даже выглядеть убедительно, но для разработчика остается «черным ящиком». Чтобы безопасно развивать такой проект, код нужно постепенно разбирать, проверять, документировать и приводить к понятной архитектуре.
ИИ-код может не избавлять от технического долга, а создавать новый: модель быстро пишет рабочие фрагменты, но не всегда соблюдает единую структуру проекта, логику архитектуры, стиль именования файлов и связи между компонентами. Например, когда Claude помогал Дэвиду делать iPhone-приложение, он сложил файлы в один большой каталог без понятной организации. Это удалось исправить, но только после отдельной команды «убрать за собой» и привести проект в порядок. Поэтому с ИИ-кодом нужны те же практики, что и с кодом подрядчика: ревью, проверка архитектуры и контроль структуры. Один из полезных приемов — использовать разные модели для взаимной проверки: например, одна пишет код, а другая делает код-ревью.
ИИ-модели обучались на большом количестве публичного кода, включая плохие примеры, устаревшие решения и уязвимые библиотеки. Поэтому они могут воспроизводить небезопасные паттерны: забывать проверку ввода, неправильно обрабатывать данные или подключать зависимости без учета рисков цепочки поставок. Дэвид описывает опыт работы над собственным security-продуктом: ИИ вообще не добавил проверку входных данных, хотя это базовая практика безопасности. После прямого указания модель написала хорошие validation routines, но сама по себе этого не сделала. Вывод: безопасность нужно явно требовать и отдельно проверять.
Автор признает, что ИИ действительно может сократить время вывода продукта на рынок, помочь с поддержкой и поиском уязвимостей. Но он предупреждает: одной фразы недостаточно, чтобы создать надежное приложение. «ИИ не является волшебной пулей», — приходит к выводу Гевирц. Чтобы избежать вайб-кодингового «апокалипсиса», разработчикам придется не меньше, а больше думать о дисциплине, тестировании и инженерном управлении.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Такой вопрос. Понимают ли все, включая экспертов, что ИИ это вероятностный (эктсраполятор многочлена лагранжа) генератор текста с 90-99% успеха и он по факту как большой продвинутый гугл выдает уже существующие данные. Что галлюцинации это не баг, а фича текущей мат. модели. Т.е по факту не будет у него 100% гарантии на верность, что влечет за собой определенные риски. И это не говоря, что про AGI и прочее уже даже не говорят. Т.е для анализа или обработки огромных данных неструктурированных он очень даже, а как точный инструмент не очень.