Как проверить код, написанный ИИ, если вы не программист

«Работает в демо» и «работает у клиентов» — разные вещи

Демонстрация обычно проходит по сценарию: вводятся правильные данные, нажимаются кнопки в ожидаемом порядке, интернет не пропадает. ИИ-инструменты особенно хороши в том, чтобы быстро собрать код, который проходит именно такой сценарий — это ровно то, на чём их учили. А вот что происходит, когда клиент вводит телефон с буквами, дважды нажимает «Оплатить» из нетерпения, или два заказа приходят одновременно на один и тот же товар на складе, — отдельный вопрос, и ИИ его часто не решает сам, если не попросить об этом прямо.

Простая проверка: попросите того, кто делал систему, показать её не в демо-режиме, а с намеренно «плохими» действиями — двойным кликом, пустым полем, странным вводом. Если разработчик пожимает плечами или говорит «такого не будет», это не мелочь. Именно нестандартные ситуации — то, из-за чего теряются реальные заказы.

Смотрел ли код кто-то, кроме того, кто его писал

В обычной разработке есть практика код-ревью: второй человек читает код перед тем, как он попадёт в работу, и ищет то, что автор мог упустить — не со зла, а потому что автору со стороны свои решения кажутся очевидными. С ИИ-написанным кодом это ещё важнее: инструмент может сгенерировать рабочий, но неаккуратный или избыточно сложный вариант, и единственный человек, который его видел, — тот, кто нажимал «Generate».

Вам не нужно самим читать код, чтобы задать вопрос: «Кто-то ещё смотрел на это до сдачи?». Если код писал и «принимал» один и тот же человек без стороннего взгляда — это не обязательно катастрофа для простого лендинга, но точная причина попросить независимую проверку перед тем, как через систему пойдут деньги или личные данные клиентов.

Есть ли место, где можно ломать без последствий

Продакшен — это то, что видят реальные клиенты прямо сейчас. Тестовая (staging) среда — отдельная копия системы, где можно нажимать любые кнопки, вводить любые данные и даже что-то сломать, ничем не рискуя. Если у вашей системы такой копии нет и любое изменение сразу выходит «в бой» — рано или поздно ошибка, которую не заметили при правке, окажется на глазах у клиента в худший момент.

Спросите прямо: «Где вы проверяете изменения перед тем, как они попадают ко мне на сайт / в бота / в CRM?». Если ответ — «нигде, сразу правим на живом сайте», для визитки это ещё терпимо, но для всего, что принимает заказы или платежи, это повод настоять на отдельном тестовом контуре.

Кто отвечает за безопасность и данные клиентов

ИИ пишет код, который выполняет задачу, но не думает о том, как его можно обойти или взломать — это не входит в задачу «сделай форму заказа». Типичные дыры выглядят безобидно: пароли хранятся открытым текстом, у любого пользователя есть доступ к чужим заказам через изменённую ссылку, ключи от платёжной системы лежат прямо в коде, который потом случайно попадает в открытый репозиторий.

Это не повод отказываться от ИИ в разработке — многие такие вещи закрываются за час работы специалиста. Повод — прямо спросить, кто отвечает за эту часть, до запуска, а не после утечки. Отдельно стоит держать в голове: если в переписке с ИИ-инструментом для генерации кода фигурировали реальные данные клиентов или доступы — это уже само по себе риск, независимо от качества итогового кода.

Частые вопросы