Вы заказали разработку, подрядчик говорит, что использует ИИ и потому быстрее. Продукт приняли, он работает. Вопрос: как понять, что вам отдали поддерживаемую систему, а не гору сгенерированного текста, которая развалится через полгода?
Ниже — то, что можно проверить, не будучи программистом.
Почему обычная приёмка не ловит проблему
Классическая приёмка проверяет функциональность: нажали кнопки, всё работает, подписали акт. С ИИ-сгенерированным кодом этого недостаточно, потому что типичные его проблемы не видны через интерфейс. Приложение может отлично работать на демо и при этом:
- падать при пустых данных или одновременных запросах;
- содержать три разных подхода к одной задаче;
- хранить ключи доступа прямо в коде;
- не иметь ни одного теста.
Всё это всплывает не на приёмке, а на второй-третьей доработке — когда любое изменение ломает что-то соседнее.
Что просить показать
1. Репозиторий и историю коммитов
Попросите доступ к репозиторию (он в любом случае должен быть вашим). Смотреть надо не код, а историю:
- Коммиты размазаны по всему периоду работы или свалены в два-три гигантских в конце? Второе — признак, что код готовили к сдаче, а не вели процессом.
- Есть ли пул-реквесты и следы ревью — комментарии, правки, обсуждения? Если весь код влит напрямую в главную ветку без единого обсуждения, значит, его никто не смотрел.
Это самая честная проверка: историю сложно подделать задним числом.
2. Тесты и их запуск
Спросите: какие сценарии покрыты автотестами и как их запустить. Хороший ответ — конкретный: «покрыты авторизация, оформление заказа, расчёт стоимости; запуск одной командой, отчёт вот здесь». Плохой — «мы всё тестировали руками».
Тесты не обязаны покрывать всё. Но критичные для денег и данных сценарии — обязаны.
3. Что происходит при сбое
Задайте три вопроса:
- Что увидит пользователь, если внешний сервис (оплата, СМС, CRM) не ответит?
- Куда пишутся ошибки и кто их видит?
- Как понять, что именно сломалось, если пользователь жалуется?
Отсутствие внятных ответов означает, что при первом же инциденте разбор начнётся с нуля.
4. Секреты
Прямой вопрос: где хранятся пароли, ключи к API и доступы к базе? Правильный ответ — в переменных окружения или в специальном хранилище, и в репозиторий они не попадают. Если ключи лежат в коде, это не «мелочь, потом поправим»: они уже в истории репозитория, и просто удалить строку недостаточно.
5. README и запуск с нуля
Простейший тест на поддерживаемость: попросите инструкцию, по которой другой разработчик поднимет проект локально. Если такой инструкции нет или она «на словах» — проект завязан на конкретных людей.
Признаки, что код никто не читал
Даже без технического бэкграунда заметно:
- Мёртвые куски. Функции и файлы, которые ни к чему не подключены, — след итераций «попробовали, не сработало, оставили».
- Комментарии-объяснялки. Пояснения к очевидному в стиле учебника — характерный почерк генерации без последующей чистки.
- Разнобой. В одном месте одно оформление и подход, в другом — совершенно другое.
- Однодневная история. Весь проект залит за один-два дня перед сдачей.
Что спросить на старте, а не на приёмке
Дешевле договориться заранее — вместе с тем, что покрывает гарантия. Четыре пункта в договор или в переписку:
- Репозиторий у заказчика с первого дня. Не «передадим в конце» — с первого дня.
- Ревью обязательно. Каждый значимый кусок смотрит человек, отвечающий за проект.
- Тесты на критичные сценарии. Список сценариев согласуется в начале.
- Инструкция по развёртыванию. Часть сдачи, а не бонус.
Ни один из пунктов не мешает использовать ИИ и не замедляет разработку сколько-нибудь заметно. Зато они превращают «нам что-то нагенерировали» в «у нас есть система, которую можно развивать».
И честная оговорка
Всё это имеет смысл ровно в той мере, в какой продукт вам важен. Если нужен одноразовый лендинг или прототип на показать — требовать полный инженерный процесс избыточно, и подрядчик, который честно скажет «здесь это лишнее», экономит вам деньги.
Разница в цене ошибки. Прототип можно выбросить. Систему, которая принимает заказы и хранит данные клиентов, выбросить нельзя.
Пишу из практики студии MKDGRUPP: ИИ ускоряет разработку, но каждый PR ревьюит сеньор, критичные сценарии покрыты автотестами, репозиторий у заказчика с первого дня. Обсудить проект: mkdgrupp.ru/vaybkoding.
