Как понять, что студия проверяет код до сдачи: чек-лист заказчика

Что такое no-mistakes и при чём тут заказчик

Репозиторий kunchenguid/no-mistakes на GitHub выложен под лицензией MIT (в файле LICENSE указан 2026 год и автор Kun Chen). Последний коммит, который я увидел в ленте репозитория, датирован 5 октября 2026 года, проект живой. Написан он на Go и работает на macOS, Linux и Windows.

Идея по README такая. Разработчик вместо обычной отправки кода пушит ветку в локальный прокси. Прокси создаёт временную рабочую копию, гоняет через неё цепочку шагов: ревью, тесты, документация, линтер. Только если все проверки зелёные, ветка уходит в настоящий удалённый репозиторий, и автоматически открывается pull request, то есть запрос на слияние изменений. Безопасные механические правки инструмент вносит сам, а спорное отдаёт человеку: принять, исправить или пропустить.

Зачем это вам, если вы не программист? Ставить его самим не нужно. Он показывает, как выглядит нормальный порядок: между «разработчик написал» и «изменение попало в проект» стоит автоматический барьер. Если студия называет что-то похожее, вы вправе попросить показать.

Чек-лист требований к студии

Перед стартом работ спросите по пунктам. Ответы лучше получить письменно, в переписке или в договоре. Что можно отдельно закрепить в самом договоре, разобрано в статье про договор на разработку.

Первое: репозиторий. Код хранится в системе вроде GitHub или GitLab, и либо принадлежит вам, либо у вас есть доступ с правом чтения. История изменений видна вам, а не лежит у подрядчика на ноутбуке.

Второе: автоматические проверки при каждом изменении. Минимум четыре вещи: линтер (ловит небрежный и подозрительный код), тесты, сканирование секретов (чтобы пароль или токен не оказался в коде) и проверка зависимостей на известные уязвимости. Попросите показать страницу, где видно, что проверки запускались и прошли.

Третье: описание изменений. К каждому изменению прикладывается короткое пояснение, что и зачем поменяли. Читать вам не обязательно, но при споре «кто это сломал» оно выручает.

Четвёртое: откат. Студия говорит, как вернуть предыдущую версию, и сколько на это уходит времени. Ответ «разберёмся по ситуации» не годится.

Пятое: тестовый стенд отдельно от рабочего. Новое сначала проверяется на копии, где нет ваших клиентов и заявок. Как самому пройти по такому стенду, описано в материале про тест бота и сайта перед запуском.

Шестое: что вам сдают. Исходники, инструкция по запуску и обновлению, доступы к серверу, домену и сервисам, оформленные на вас. Полный список есть в статье что вы получаете после сдачи проекта. До старта полезно пройти и чек-лист заказчика, а общие вопросы подрядчику собраны в отдельном материале.

Что даёт инструмент вроде no-mistakes

Это один из способов закрыть пункты со второго по четвёртый. По документации цепочка выглядит так: review, test, docs, lint, push, PR, CI. Тесты и линтер он запускает командами проекта, если те настроены. Если нет, часть работы берёт на себя ИИ-агент. Pull request получает описание: цель, изменения, оценка риска, результаты проверок. На поддерживаемых площадках инструмент ещё следит за проверками после отправки и пытается починить упавшие.

Для работы нужны Git и один настроенный ИИ-агент из списка в README (Claude, Codex и другие). Какие ключи и тарифы нужны для конкретного агента, определяется его собственными условиями, я это не проверял. Для студии это значит расход на подписку или токены, и вы вправе спросить, как это учтено в смете.

Чего автопроверка не заменяет

Это важнее всего. Я сверил по документации, и вот что нашёл. Сканирование секретов и уязвимостей зависимостей среди описанных шагов не упоминается. Значит, подобные проверки студии придётся подключать отдельно, одним инструментом тут не обойтись. Ревью в этой цепочке делает ИИ, то есть вероятностная система, которая может ошибиться. Разработчик может принять совет или пропустить его.

Есть вещи, которые не автоматизируются вообще. Приёмка по задачам: бот делает то, ради чего вы его заказывали, и это проверяете вы по списку из техзадания. Ручное прохождение сценариев: заявка дошла, оплата прошла, письмо не попало в спам. Безопасность логики: кто что может увидеть и сделать, не обходится ли оплата. Автоматика скажет, что код собирается и тесты зелёные. Если тесты проверяют не то, зелёный цвет ничего не доказывает.

Ещё один момент: инструмент рассчитан на разработчика, который работает с ним ежедневно. Зелёная галочка от него не гарантия, что ошибок нет. В README такого обещания нет, и я его вам тоже не дам.

Если студия пишет код с ИИ-ассистентом

Код с ассистентом появляется быстро и выглядит уверенно, а ошибки в нём бывают незаметными. Поэтому автоматические проверки там нужны строже, чем при ручной работе. Какие вопросы по безопасности стоит задать такой студии, я собрал в статье про восемь вопросов подрядчику. А за что вы платите, когда код пишет ИИ, разобрано в материале за что платить разработчику. Часть этой оплаты идёт как раз на проверку и ответственность за результат, и спрашивать про неё нужно прямо.

Что делаю я

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

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

Нужно ли мне самому ставить no-mistakes?

Нет. Это инструмент для разработчика, он работает на его компьютере. Вам нужно знать, что у студии есть похожий барьер, и уметь попросить его показать.

Если проверки зелёные, можно принимать работу?

Нет. Зелёные проверки говорят о качестве кода, а приёмка отвечает на вопрос, делает ли продукт то, что вы заказали. Это разные вещи, и вторую делаете вы.

Что делать, если студия говорит «у нас всё в порядке, просто верьте»?

Попросите доступ к репозиторию и страницу с результатами проверок. Если не показывают ни то, ни другое, это повод задуматься до оплаты следующего этапа.

Коротко о главном

Автоматическая проверка перед отправкой кода означает барьер между разработчиком и проектом: линтер, тесты, сканирование секретов и зависимостей, описание изменений, откат и отдельный стенд. no-mistakes (MIT, последний коммит 5 октября 2026 года) показывает один из подходов, но среди его описанных шагов нет сканирования секретов и уязвимостей, а приёмка остаётся за вами.

Если хотите, чтобы я посмотрел, как устроена проверка у вашего подрядчика, и составил список требований под ваш проект, напишите мне в Telegram кодовое слово «РЕВИЗИЯ».