Чек‑лист при приёме унаследованного AI‑кода для агентств

Почему агентствам нужен иной процесс приёма унаследованного AI‑кода

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

Такое несоответствие предсказуемо. Многие AI‑сгенерированные прототипы создают видимость завершённости прежде, чем станут безопасными и надёжными. Инструменты AI быстро сворачивают экраны вместе, но часто пропускают скучную работу, которая держит софт в продакшне.

Точки отказа повторяются из проекта в проект: аутентификация недоделана или подклеена латками, секреты живут в репозитории или в неправильной среде, модель данных меняется от недели к неделе, а деплой зависит от ручных шагов, которые помнит только один человек. Если проводить приёмку как обычную разработку (wishlist фич, дизайн, сроки), вы пропустите эти риски и унаследуете сюрпризы.

Сильный приём у унаследованного AI‑кода ориентирован не на «что вы хотите добавить?», а на «что может сломаться на следующей неделе?». Получите чёткие ответы на вопросы:

• Где реальные пользователи до сих пор застревают (не то, что в роадмапе)
• Кто управляет репозиторием, хостингом и сторонними аккаунтами
• Какие данные хранятся и что нужно защищать
• Что обязательно должно работать, чтобы бизнес функционировал (вход, оплата, почтовые уведомления)
• Что уже было «починено», и кем

Если вы нацелены на короткое окно стабилизации (обычно 48–72 часа), первая задача — остановить кровотечение: сделать приложение надёжным, закрыть очевидные дыры в безопасности и получить повторяемый деплой. Улучшения идут после того, как базовые вещи держатся.

Типичный сценарий: основатель говорит «почти готово», потому что демо‑регистрация работает. Ваш приём должен подтвердить, что произойдёт при регистрации 50 пользователей, при сбросе пароля и при деплое приложения «с нуля».

Установите цель: сначала стабилизировать, потом улучшать

Когда вы наследуете AI‑код, самый быстрый способ потерять доверие — пообещать новые функции до того, как базовые вещи начнут работать. Определите ясную первую цель: стабилизация. Это даст всем общее определение «готово» на первые 48–72 часа и сделает вашу смету защищённой.

Опишите «стабилизировано» простыми словами, которые клиент сможет проверить. Для большинства приложений это значит:

• Вход и регистрация работают полностью (включая сброс пароля, если используется)
• Главный пользовательский поток завершается без падений и путанных ошибок
• Деплой выполняется одинаково каждый раз (без таинственных шагов)
• Данные явно не под угрозой (нет открытых ключей, нет широко доступного админ‑доступа)

Затем проведите чёткое разграничение между стабилизацией, ребилдом и новыми функциями.

• Стабилизация останавливает кровотечение.
• Ребилд заменяет шаткие основания.
• Новые функции ждут, пока продукт не станет надёжным.

Включите такой язык в приём, чтобы вся команда (и клиент) пользовались одними и теми же определениями.

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

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

Быстрая триажа проекта (10 минут)

Короткий звонок‑триаж предотвращает сюрпризы. Цель не в том, чтобы понять каждые детали, а чтобы узнать, что вы принимаете, что уже сломано и реалистично ли окно стабилизации 48–72 часа.

Используйте эти вопросы, чтобы быстро получить базу:

• Кто это строил (человек или вендор), и какой AI‑инструмент использовался (Lovable, Bolt, v0, Cursor, Replit и т.д.)? Что изменилось с тех пор, как это в последний раз «работало»?
• Где это сейчас запускается: только на чьем‑то ноутбуке, на стейджинге, в продакшне или нигде? Кто имеет доступ?
• Кто сейчас пользуется этим (если кто‑то есть), и какие 1–2 ключевых сценария должны работать (регистрация, оплата, бронирование, правки в админке)?
• Что сейчас ломается, простыми словами? Попросите один недавний пример, с которым столкнулся пользователь (текст ошибки, пустая страница, неверные данные).
• Есть ли дедлайны, связанные с демо продаж, пилотом, привлечением инвестиций или проверкой на соответствие? Что случится, если всё сдвинется на неделю?

Слушайте несоответствия. Если говорят «всё работало на прошлой неделе», но одновременно «никто не может войти», у вас уже приоритет: аутентификация и доступ.

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

Доступ и владение: получите контроль прежде чем трогать код

Прежде чем открыть репозиторий или обещать сроки, убедитесь, что клиент действительно может передать контроль. У унаследованного AI‑кода проблема часто не только в коде. Это аккаунты, токены и недоделанные деплои, за которыми никто не отвечает.

Начните с прямого вопроса: где сейчас хранится код? Если ответ «на чьем‑то ноутбуке» или «в инструменте вроде Replit» без ясного владельца, считайте это реальным риском. Доступ — сначала, работа — потом.

Минимальный набор доступа, который вам нужен

Попросите эти вещи заранее, чтобы работать безопасно и избежать сюрпризов:

• Местоположение репозитория и один реальный админ (GitHub, GitLab или другой хост)
• Доступ для деплоя (кто может пушить в продакшн, если он есть)
• Список окружений (dev, staging, prod) и есть ли что‑то общее между ними
• Метод хранения секретов (env‑файлы, переменные в дашборде, секретный менеджер) и кто может ротацию секретов выполнять
• Владелец домена и почты (кто контролирует DNS и настройки транзакционной почты)

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

Ожидания по секретам и деплойам

Прототипы, сделанные AI, часто имеют открытые ключи или захардкоженные пароли. Даже если приложение «работает», предполагайте, что секреты нужно ротировать.

Уточните, кто может менять:

• Пароли базы данных и ключи API
• Настройки провайдера аутентификации (OAuth‑приложения, JWT‑секреты)
• Переменные хостинга и настройки сборки

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

Бизнес‑критичные потоки: что согласовать и какие вопросы задать

Чтобы избежать сюрпризов, договоритесь о нескольких потоках, которые обязательно должны работать. Это предотвратит починку не тех вещей в первую очередь.

Начните с идентификации и прав. «Вход работает» недостаточно. Спросите, кто что должен уметь делать и где это правило применяется. Если права реализованы только в UI, пользователь может обойти их, подставив другой ID или вызвав endpoint напрямую.

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

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

Задавайте практичные вопросы:

• Аут: какие роли существуют (user, admin, staff) и что может каждая роль?
• Платежи: что считается «оплачено» и что меняется при ошибке платежа или возврате?
• Данные: какие чувствительные поля есть и нужно ли удалять данные по запросу?
• Интеграции: что подключено к почте, CRM, хранилищу файлов, AI API или webhook‑ам, и что ломается, если это упадёт?
• Админ‑доступ: есть ли «временная» админ‑панель, общий пароль или бэкдоры в использовании?

Пример: основатель говорит «только админы могут экспортировать данные клиентов». В унаследованном коде это иногда просто кнопка, а не проверка прав.

Флаги риска, которые видно ещё на первом звонке

Некоторые проблемы проявляются раньше, чем вы увидите репозиторий. Хороший первый звонок — это не про детали, а про сигналы: можно ли запустить код где‑то, чист ли доступ и можно ли верить тому, что вам говорят?

Следите за этими красными флажками:

• Приложение работает только на компьютере одного человека или говорят «мы больше не можем деплоить». Это часто значит, что нет описания окружения, сломаны шаги сборки или не задокументированы сервисы.
• Секреты обращаются небрежно: ключи API в чате, токены в общем документе или «просто используйте этот админ‑пароль». Считайте их скомпрометированными, пока не доказано обратное.
• Аутентификация непоследовательна: «вход иногда работает», роли не работают или один пользователь видит данные другого.
• Баги кажутся случайными и исчезают при обновлении страницы. Это может указывать на нестабильное состояние, проблемы с кэшем или несоответствие фронтенда и бэкенда.
• Нет тестов, нет логов, и никто не знает, что менялось в последний раз. Без следа аудита каждое исправление превращается в домыслы.

Если вы услышали хотя бы один из них, используйте спокойные уточняющие вопросы, чтобы превратить расплывчатую боль в чёткую область работ:

• «Где это сейчас работает, и кто может перезапустить, если сломается?»
• «Как хранятся секреты и кто сейчас имеет к ним доступ?»
• «Какие действия пользователей должны всегда работать, чтобы бизнес не падал?»
• «Когда это в последний раз работало и что произошло перед тем, как перестало?»

Пример: приложение было собрано в Replit, деплой сломался на прошлой неделе, а ключ Stripe шарят в Slack. Этого достаточно, чтобы приостановить запросы на новые функции и переключиться на intake, ориентированный на стабилизацию: контроль, безопасность и повторяемый деплой.

Что проверить, когда вы увидите репозиторий (высокоуровнево, нетехнически)

Получив доступ, не нужно читать каждый файл, чтобы понять, безопасно ли стабилизировать проект. Быстрый осмотр покажет, это мелкий рескью или глубокий ребилд.

Начните с уровня данных — сюрпризы там распространяются везде. Ищите дублирующиеся концепции (например, users и app_users), неясные поля «источника правды» и отсутствующие миграции. Если репозиторий не объясняет, как меняется база данных со временем, релизы быстро становятся рискованными.

Затем проведите базовую сверку безопасности, даже если вы не эксперт по безопасности. Проверьте, насколько аккуратно обрабатывается ввод пользователя, ограничены ли загрузки файлов и не похоже ли что‑то на исполнение сырых SQL или недоверяемых команд. Просканируйте репозиторий на секреты (ключи API, пароли баз). Если видите — считайте их утёкшими.

Обратите внимание на структуру. AI‑прототипы часто копируют логику в несколько мест. Это делает исправления медленными, а баги — легко возвращаемыми.

Короткий набор проверок, который обычно выявляет основные риски:

• Явное ли разделение бэкенда и фронтенда, или всё смешано?
• Повторяется ли одна и та же логика в нескольких файлах?
• Аут и права реализованы в одном месте или разбросаны?
• Есть ли отчёт об ошибках или всё молча падает?
• Есть ли базовые вещи: бэкапы, конфиги окружения и простой путь деплоя?

Наконец, ищите потенциальные проблемы с производительностью. Если страницы зависят от множества повторяющихся API‑вызовов или приложение постоянно запрашивает одни и те же данные, при приходе реальных пользователей вы столкнётесь с медленной загрузкой и таймаутами.

Простой план стабилизации на 48–72 часа (пошагово)

Окно стабилизации — это не спринт фич. Цель — заставить приложение надёжно работать, остановить кровотечение и дать всем ясное представление о том, что нужно для дальнейших улучшений.

План из 5 шагов

1. Получить доступ, запустить и воспроизвести худшие отказы. Соберите доступы к репозиторию, креденшелы хостинга и переменные окружения. Затем запустите приложение так, как это делают пользователи. Выберите топ‑3 отказа и воспроизведите их с чёткими заметками.

2. Зафиксировать объём и определить «готово» для стабилизации. Согласуйте, что новые функции ждут. «Готово» должно быть конкретным: вход работает, основной поток завершается, деплой не зависит от ручных ха́ков.

3. Сначала исправить блокеры. Приоритизируйте всё, что останавливает пользователей или создаёт немедленную опасность: сломанная аутентификация, открытые секреты, падающие страницы, неудачные сборки и деплои, которые работают только на одной машине.

4. Добавить базовые защитные меры, чтобы стабильность сохранилась. Добавьте простое логирование, понятные сообщения об ошибках и пару смоук‑проверок, которые поймают повторную поломку.

5. Передать короткий отчёт и следующий шаг. Резюмируйте, что починили, что всё ещё рисковано и что вы рекомендуете дальше (рефактор, усиление безопасности или ребилд).

Частые ошибки при приёме, которые потом взрываются

Самый быстрый путь, чтобы унаследованный AI‑проект пошёл не так — относиться к нему как к обычной разработке. Клиент может попросить новые функции с первого дня, но если основание шаткое, каждая «маленькая правка» способна поломать три других вещи.

Распространённые ошибки:

• Обещать даты поставки до проведения окна стабилизации
• Ждать доступы днями, а потом принимать решения в спешке
• Определять успех как «без багов» вместо небольшого списка бизнес‑сценариев
• Лечить поверхностные проблемы, не ротируя открытые секреты
• Писать изменения прямо в продакшн без плана отката

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

Копировать‑вставить чек‑лист для приёма (быстрые проверки)

Используйте это, когда нужно быстро подтвердить базу и избежать сюрпризов. Предназначено для 10–15‑минутного звонка передачи и короткого фоллоу‑апа.

[ ] Access confirmed: repo + hosting + database + domain/DNS (who has admin?)
[ ] Third-party accounts listed: auth/email/payments/storage/analytics (who owns each?)
[ ] Security baseline: where secrets live today, how they will be rotated, and what data is sensitive
[ ] User roles: who can do what (admin, staff, customer) and which role is highest risk
[ ] Top 3 broken flows written down with a "done" definition for each
[ ] Deploy plan: how releases happen today and who can press the button
[ ] Observability: logs exist, error tracking is on, and someone will watch it after release
[ ] Backups: database backup status + restore test (or date of last known good backup)
[ ] 48-72 hour stabilization: what's included (fix critical breakages, stop data leaks) vs excluded (new features, redesign)
[ ] Sign-off: one decision-maker for tradeoffs, plus a fallback if they are unavailable

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

Пример: если клиент говорит «платёжный флоу не работает», закрепите его до одной тестируемой последовательности (от страницы товара до успешной оплаты) и одного владельца платёжного аккаунта. Без этого вы можете исправить код, но оставаться заблокированными из‑за отсутствия доступа.

Пример сценария: от унаследованного прототипа к стабильному релизу

Клиент приходит с прототипом Bolt, который использовали для демонстраций. В демо выглядит всё нормально, но реальные пользователи не могут войти. Иногда кнопка входа крутится вечно, иногда создаются аккаунты, но данные не сохраняются.

На первом звонке используйте приём, ориентированный на стабилизацию. Тон нейтральный: вы не судите сборку, вы выясняете, что нужно, чтобы сделать её надёжной.

На практике обычно делают следующее:

• Подтвердить 1–2 сценария, которые должны работать на этой неделе.
• Получить доступы во время звонка: репозиторий, хостинг, база, домен, сторонние сервисы.
• Подтвердить, где хранятся секреты и кто владеет аккаунтами.
• Зафиксировать флаги риска: несколько наполовину подключённых провайдеров аутентификации, захардкоженные ключи или шаткая модель данных.
• Установить цель на 48–72 часа: стабилизировать, добавить базовые ограждения и выпустить маленький безопасный релиз.

За 2–3 дня команды часто могут стабилизировать вход: исправить обработку сессий, упорядочить переменные окружения и добавить базовое логирование ошибок, чтобы поломки стали видимы. Очевидные проблемы с безопасностью (например, открытые секреты) можно закрыть, и «рандомные» падения часто исчезают, когда несколько запутанных частей упрощают.

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

Следующие шаги: сделать приём повторяемым и сократить сюрпризы

Относитесь к приёму как к небольшому продукту. Когда процесс одинаков каждый раз, вы тратите меньше времени на погоню за деталями и больше — на исправление важного.

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

Практичный подход — заранее забронировать окно стабилизации перед планированием новых функций. Запланируйте 48–72 часа, чтобы подтвердить, что есть, что ломается и что рисковано. После этого вы сможете оценивать улучшения с меньшим количеством сюрпризов.

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

Если вам нужна внешняя помощь с унаследованным AI‑кодом, FixMyMess (fixmymess.ai) делает диагностику и ремонт кодовой базы, включая усиление безопасности, рефакторинг и подготовку деплоя. Они также предлагают бесплатный аудит кода, чтобы выявить проблемы до принятия решения о плане.