Мы пользуемся ИИ-инструментами каждый день. Эта статья не о том, как они губят разработку.
Она об асимметрии, которую почти никто не заложил в цену:
Стоимость написания кода рухнула. Стоимость владения кодом не изменилась вообще.
Написание никогда не было дорогой частью. Проверка, тестирование, защита, поддержка и возможность через два года что-то изменить, не сломав при этом ещё три вещи, — вот куда всегда уходили деньги, и ничто из этого не подешевело. Изменилось то, что кода теперь гораздо больше, он появляется быстрее, чем кто-либо успевает его проверить, и часть этого кода теперь лежит в основании вашего бизнеса.
Доказательства — с источниками
Это не ощущение. Три независимых исследования указывают в одну сторону.
Veracode протестировала более 100 больших языковых моделей на 80 реальных задачах по программированию. Когда модели нужно было выбрать между безопасной и небезопасной реализацией, она выбирала небезопасную в 45% случаев. В деталях: 86% примеров не защищали от межсайтового скриптинга (CWE-80), а 88% были уязвимы к внедрению в логи (CWE-117). Хуже всех оказалась Java — более 70% провалов; Python, C# и JavaScript — от 38% до 45%. Вывод, который должен тревожить покупателей больше всего: по мере того как модели учились писать код, который работает, писать код, который безопасен, они лучше не стали — отчёт самой Veracode.
В Georgia Tech работает проект Vibe Security Radar, который сканирует бюллетени безопасности в поисках уязвимостей, связанных с ИИ-инструментами для программирования. Из более чем 43 000 бюллетеней он подтвердил 74 случая уязвимостей — 14 критических и 25 высокого риска. Важнее общего числа — динамика: 18 случаев за второе полугодие 2025 года, 56 за первые три месяца 2026-го и 35 только за март 2026-го. Уязвимости — внедрение команд, обход аутентификации и подделка серверных запросов (SSRF) — Georgia Tech Research.
А главный структурный вывод этой работы стоит держать в голове:
Поскольку ИИ-модели повторяют похожие ошибки, атакующему достаточно найти баг один раз, чтобы потенциально эксплуатировать его в тысячах репозиториев, созданных с помощью тех же инструментов.
Это действительно новая форма риска. Раньше малоизвестность защищала малый бизнес: никто не искал именно вас. Если ваш сайт разделяет сгенерированный шаблон с десятью тысячами других, малоизвестность перестаёт работать. Вы не мишень — вы совпадение.
Сканирование работающих приложений, о котором сообщает OX Security со ссылкой на проверку 5 600 приложений компанией Escape.tech, выявило более 2 000 уязвимостей, более 400 раскрытых секретов и 175 случаев раскрытия персональных данных. Раскрытые секреты — API-ключи, пароли к базам данных, платёжные учётные данные, закоммиченные прямо в код, — самый дешёвый из доступных катастрофических сбоев.
Вопрос, который изменился
Инстинкт подсказывает спросить подрядчика: это писал человек?
Это неправильный вопрос, и ответ на него будет бесполезным. Этими инструментами пользуется каждая серьёзная студия, включая нас. Происхождение кода — не та переменная.
Переменная — это проверяемость. Спрашивайте иначе:
Если вы завтра исчезнете, сможет ли другой разработчик разобраться в этом коде настолько, чтобы исправить баг в условиях цейтнота?
Код, написанный человеком, который его не понимал, и код, написанный моделью, не имевшей никакого представления о вашем бизнесе, — одинаковое обязательство. У обоих нет хозяина. Определяющее свойство бесхозного кода — не то, кто его набрал, а то, что никто не может объяснить, почему он устроен именно так.
Чек-лист проверки для владельца без технического бэкграунда
Чтобы пройти по нему, не нужно читать код. Каждый пункт — вопрос с ответом, который вы способны оценить.
1. Где хранятся секреты? Спросите: «Покажите, как пароль от боевой базы данных попадает на сервер». Правильный ответ — переменные окружения или менеджер секретов, но никогда не файл в репозитории. В Bronjoy деплой падает ещё до запуска миграций, если не хватает какого-то боевого секрета: система отказывается стартовать наполовину настроенной, вместо того чтобы стартовать небезопасно.
2. Что покрывают тесты? Попросите назвать их число и объяснить, что происходит, когда один из них падает. Дело не в числе, а в наличии привычки. В Knigopoisk параллельно прогоняются 171 тест и 898 проверок, включая регрессионный тест, который валит сборку, если колонка в админ-панели выходит без подписи. В BiliMind — 164 бэкенд-теста. В абсолютных цифрах это не впечатляет. Но это доказательство того, что кто-то решил: сбои должны быть громкими.
3. Правила соблюдаются на уровне базы данных или только в интерфейсе? Это лучший технический вопрос, который может задать нетехнический человек. В Xceed — футбольной платформе с живыми данными, которую мы построили, — построчная защита в Postgres (row-level security) обеспечивает три роли, а триггеры базы данных — правила турнира, поэтому недопустимые состояния отклоняются, даже если интерфейс полностью обойти. Если ответ — «для этих пользователей кнопка неактивна», ваших правил не существует; существует только декорация.
4. Может ли одна и та же ошибка случиться дважды?Nomadeo изолирует клиентов-арендаторов на трёх уровнях: контекст запроса, специальный тип транзакции, из-за которого отсутствие арендатора становится ошибкой компиляции, и построчная защита в Postgres. Самый интересный — средний уровень: архитектура, при которой опасная ошибка просто не соберётся. Спросите, какой класс ошибок ваша система делает невозможным, а не просто маловероятным.
5. Кто-нибудь его читал? Спросите, проходил ли код ревью, кто его проводил и может ли этот человек объяснить части, которые писал не он. «Тесты прошли» — это не ревью.
6. Как выглядит список зависимостей? Каждый пакет — это третья сторона, которая может вас сломать или скомпрометировать. Спросите, сколько их, когда их в последний раз обновляли и следит ли кто-нибудь за бюллетенями безопасности.
7. Можете ли вы уйти? Лежит ли исходный код в вашей Git-организации, оформлены ли облачные аккаунты на ваше имя, сможет ли другой разработчик подхватить проект? Мы прописываем это письменно: код и все аккаунты принадлежат вам с первого дня — если мы завтра исчезнем, проект сможет подхватить другой разработчик. Исходный код входит в каждый тариф, начиная с лендинга за $99. Более широкую версию этого аргумента мы разбираем в статье «Против вашего конструктора сайтов».
Как звучит хороший ответ
Вопросы помогают, только если вы умеете отличить настоящий ответ от уверенного. Три примера.
«Где хранятся секреты?»
- ⚠️ «Не волнуйтесь, всё защищено». — никакой информации. Спросите ещё раз.
- ⚠️ «В конфигурационном файле, но репозиторий приватный». — это секрет в вашем коде. Приватный сегодня, открытый следующему подрядчику завтра и навсегда оставшийся в каждом историческом коммите.
- ✅ «В переменных окружения на хостинге / в менеджере секретов. В репозитории нет ничего чувствительного, и вот как заменить любой из них».
«Правила соблюдаются на уровне базы данных или только в интерфейсе?»
- ⚠️ «Пользователи эту кнопку не видят». — это не защита, это занавеска.
- ⚠️ «API проверяет права доступа». — лучше, и стоит задать один уточняющий вопрос: проверяет каждый эндпоинт или только те, о которых кто-то вспомнил?
- ✅ «Роли обеспечиваются на уровне данных, ограничения заданы в базе данных, поэтому недопустимое состояние отклоняется, даже если вызвать API напрямую».
«Можете ли вы уйти?»
- ⚠️ «Если понадобится, мы отдадим вам файлы». — у вас этого нет, вам это обещают.
- ⚠️ «Он в нашем репозитории, мы можем его передать». — та же проблема, только позже.
- ✅ «Он уже в вашей организации. Вот ваш доступ. Инфраструктурные аккаунты оформлены на вас, и платите за них вы».
Общая закономерность во всех трёх: хороший ответ описывает механизм, слабый — намерение. Оценивать сам механизм вам не нужно. Нужно лишь заметить, какой ответ вы получили, а это навык, который любой может применить прямо на встрече.
Если из трёх ответов все три — намерения, вы узнали нечто важное, не прочитав ни строчки кода.
Что делать, если ответы плохие
Не бросайтесь в панике всё переписывать. Действуйте по порядку.
Сначала замените секреты. Если учётные данные когда-либо попадали в репозиторий, считайте, что они публичны. Это день работы, и это самый ценный день из возможных.
Получите независимую оценку. Аудит производительности и кода от $90 покажет, что у вас на самом деле есть. Смысл — в письменных выводах, по которым можно действовать, а не в продающей презентации, и с этими выводами вы должны иметь возможность пойти к любому разработчику, в том числе к другому.
Исправляйте по радиусу поражения, а не по ярлыку критичности. Всё, что касается платежей, персональных данных или аутентификации, — в первую очередь. Косметический баг на маркетинговой странице может подождать год.
Потом решайте. Иногда ответ — точечное исправление. Иногда — переписывание, и в честной версии этого разговора звучит, сколько оно стоит и чего оно не исправит.
Почему для нас это личное
Одно из пяти обязательств на странице о нас звучит так:
Без уловок и плохого кода. «В нашей сфере легко обмануть клиента, который не умеет читать код. Мы так никогда не поступим».
Это обязательство старше самой проблемы, и с тех пор на нём держится всё больше. Почему оно важно не только с моральной, но и с коммерческой точки зрения, объяснить просто: клиент не может проверить то, что покупает. Софт — одна из немногих покупок, где единственная защита покупателя — стандарты продавца.
На практике, помимо чек-листа выше, это выражается в том, что исправления мы отправляем в проекты, от которых зависим, а не латаем их у себя втихую, — принятые исправления в Filament, изменение в плагине Chart.js для реактивных фронтендов, баг-репорты в исходные проекты. Код, который мы не можем показать, — это код, над которым мы недостаточно подумали.
Расскажите, что вам нужно. В ответ вы получите фиксированную цену и дату сдачи — бесплатно и без обязательств продолжать.
Частые вопросы
Попросить агентство не пользоваться ИИ-инструментами?
Нет, и любое агентство, которое на это согласится, либо лжёт, либо работает медленнее, чем могло бы. Спросите лучше, как устроено ревью, что покрывают тесты и где обеспечиваются бизнес-правила. Риск не в инструменте, а в отсутствии проверки.
Как понять, есть ли эти проблемы у моего нынешнего сайта?
Семь вопросов выше, заданные тому, кто его поддерживает, за час расскажут вам большую часть. Если на них никто не может ответить, это само по себе ответ.
Небольшому сайту-визитке это правда угрожает?
Меньше, чем приложению с платежами, но не нулевой риск: раскрытые учётные данные, злоупотребление формой обратной связи и устаревшие зависимости касаются всех. Конкретная уязвимость обычно такая: форма, которая отправляет письма, плагин, который никто не обновляет, и API-ключ в JavaScript-файле.
Сколько стоит нормальная проверка безопасности?
Гораздо меньше, чем инцидент. Для типичного маркетингового сайта это ограниченный объём работы; для приложения, которое работает с деньгами или персональными данными, это должно быть плановое регулярное мероприятие, а не разовое.
Станет ли со временем лучше?
Модели учатся писать корректный код быстрее, чем безопасный, — именно этот разрыв и зафиксирован в исследовании Veracode. Исходите из того, что бремя проверки остаётся на вас, и вырабатывайте привычку, а не ждите, пока инструменты избавят от необходимости в ней.
