Простые промпты сработали — а что делать дальше, неизвестно
Ситуация
Один из самых обманчиво благополучных кейсов. Основатель продукта писал простые, почти наивные промпты — и, на удивление, с первых итераций получил именно то, что нужно бизнесу: рабочее приложение, закрывающее реальную потребность аудитории. Продукт запустился, начал приносить первых клиентов.
Но постановка задачи, ход работы и промежуточные решения нигде не фиксировались — переписка с ИИ велась в разных чатах, часть удалена, часть потеряна при смене устройства. Архитектура не была описана ни единой схемой. И самое неприятное: было совершенно неизвестно, на каком именно моменте ИИ «остановился» — какие функции реализованы полностью, какие являются заглушками, что из задуманного вообще не было доделано и почему. Ситуация выглядела тупиковой: продукт есть, он работает, но развивать его страшно, потому что непонятно, что стоит за фасадом рабочих экранов.
Диагноз
Здесь не помогает попытка «просто почитать код» — потому что неясно, что искать. Подход был другим: реконструкция логики приложения по интерфейсу и поведению, а не по документации, которой не существует. Прошёл продукт как реальный пользователь по всем сценариям, параллельно сверяя это с кодом — где обработчик действительно что-то делает, а где просто возвращает заглушку с текстом «скоро здесь будет функциональность».
Так нашлось три критичных места: раздел аналитики был полностью нефункциональной обёрткой, обработка ошибок платежа отсутствовала как класс (система просто не показывала пользователю, что оплата не прошла), а часть данных сохранялась в локальное хранилище браузера вместо базы — то есть терялась при любой чистке кеша. Ни одна из этих проблем не была видна на демо, потому что демо всегда проходит по счастливому пути.
Что сделали
- Провёл полный аудит по методу «пользовательский путь → факт в коде» и составил документ: что реализовано, что является заглушкой, что отсутствует полностью — впервые появилась карта реального состояния продукта.
- Описал архитектуру постфактум в простых UML- и BPMN-схемах: как компоненты взаимодействуют, откуда куда идут данные — то, что нужно было сделать на старте, но лучше поздно, чем никогда.
- Закрыл критичный пробел с обработкой ошибок оплаты в первую очередь — это была не архитектурная роскошь, а прямой риск денег и репутации.
- Перенёс данные из локального хранилища браузера в базу с миграцией уже накопленной у пользователей информации.
- Настроил процесс на будущее: техническое задание фиксируется отдельно от переписки с ИИ, у каждой итерации есть краткий журнал изменений — то, что превращает случайную удачу в управляемую разработку.
Результат
Продукт получил вторую жизнь: основатель наконец увидел границы того, что у него есть, и смог осознанно планировать дальнейшие вложения, а не гадать, что «доделает ИИ в следующий раз». Ключевой урок этого кейса универсален: удачный промпт — это везение, а не процесс. Как только результат касается реальных денег пользователей, повезти один раз недостаточно — нужны протокол, архитектура на бумаге и понимание точки, на которой остановилась предыдущая итерация.
- Было
- ИИ с первого раза выдал рабочий продукт, но нет ни ТЗ, ни архитектуры, ни понимания, что доделывать, а ошибки оплаты не обрабатывались.
- Что сделал
- Провёл аудит «пользовательский путь → код», описал архитектуру в UML и BPMN, закрыл пробел с ошибками оплаты, перенёс данные из браузера в базу.
- Результат
- Основатель увидел границы продукта и планирует вложения осознанно, а не гадает, что «доделает ИИ»; ТЗ и журнал изменений теперь ведутся отдельно.
У вас похожая ситуация?
Давайте проведем бесплатный 15-минутный разбор