Как принимать код, который написал ИИ: чек-лист для заказчика

Вы заказали разработку, подрядчик говорит, что использует ИИ и потому быстрее. Продукт приняли, он работает. Вопрос: как понять, что вам отдали поддерживаемую систему, а не гору сгенерированного текста, которая развалится через полгода?

Ниже — то, что можно проверить, не будучи программистом.

Почему обычная приёмка не ловит проблему

Классическая приёмка проверяет функциональность: нажали кнопки, всё работает, подписали акт. С ИИ-сгенерированным кодом этого недостаточно, потому что типичные его проблемы не видны через интерфейс. Приложение может отлично работать на демо и при этом:

падать при пустых данных или одновременных запросах;
содержать три разных подхода к одной задаче;
хранить ключи доступа прямо в коде;
не иметь ни одного теста.

Всё это всплывает не на приёмке, а на второй-третьей доработке — когда любое изменение ломает что-то соседнее.

Что просить показать

1. Репозиторий и историю коммитов

Попросите доступ к репозиторию (он в любом случае должен быть вашим). Смотреть надо не код, а историю:

Коммиты размазаны по всему периоду работы или свалены в два-три гигантских в конце? Второе — признак, что код готовили к сдаче, а не вели процессом.
Есть ли пул-реквесты и следы ревью — комментарии, правки, обсуждения? Если весь код влит напрямую в главную ветку без единого обсуждения, значит, его никто не смотрел.

Это самая честная проверка: историю сложно подделать задним числом.

2. Тесты и их запуск

Спросите: какие сценарии покрыты автотестами и как их запустить. Хороший ответ — конкретный: «покрыты авторизация, оформление заказа, расчёт стоимости; запуск одной командой, отчёт вот здесь». Плохой — «мы всё тестировали руками».

Тесты не обязаны покрывать всё. Но критичные для денег и данных сценарии — обязаны.

3. Что происходит при сбое

Задайте три вопроса:

Что увидит пользователь, если внешний сервис (оплата, СМС, CRM) не ответит?
Куда пишутся ошибки и кто их видит?
Как понять, что именно сломалось, если пользователь жалуется?

Отсутствие внятных ответов означает, что при первом же инциденте разбор начнётся с нуля.

4. Секреты

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

5. README и запуск с нуля

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

Признаки, что код никто не читал

Даже без технического бэкграунда заметно:

Мёртвые куски. Функции и файлы, которые ни к чему не подключены, — след итераций «попробовали, не сработало, оставили».
Комментарии-объяснялки. Пояснения к очевидному в стиле учебника — характерный почерк генерации без последующей чистки.
Разнобой. В одном месте одно оформление и подход, в другом — совершенно другое.
Однодневная история. Весь проект залит за один-два дня перед сдачей.

Что спросить на старте, а не на приёмке

Дешевле договориться заранее. Четыре пункта в договор или в переписку:

Репозиторий у заказчика с первого дня. Не «передадим в конце» — с первого дня.
Ревью обязательно. Каждый значимый кусок смотрит человек, отвечающий за проект.
Тесты на критичные сценарии. Список сценариев согласуется в начале.
Инструкция по развёртыванию. Часть сдачи, а не бонус.

Ни один из пунктов не мешает использовать ИИ и не замедляет разработку сколько-нибудь заметно. Зато они превращают «нам что-то нагенерировали» в «у нас есть система, которую можно развивать».

И честная оговорка

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

Разница в цене ошибки. Прототип можно выбросить. Систему, которая принимает заказы и хранит данные клиентов, выбросить нельзя.

Пишу из практики студии MKDGRUPP: ИИ ускоряет разработку, но каждый PR ревьюит сеньор, критичные сценарии покрыты автотестами, репозиторий у заказчика с первого дня. Обсудить проект: mkdgrupp.ru/vaybkoding.