Discovery Loop в ИИ-разработке: как правильно запустить первый контур разработки

Discovery Loop — «петля открытий» — это итеративный подход к разработке с использованием искусственного интеллекта, при котором требования к продукту уточняются не до начала генерации кода, а непосредственно в процессе взаимодействия человека и ИИ. Разработчик формулирует исходную задачу, получает результат, исследует его, обнаруживает новые требования и ограничения, а затем использует полученные знания для следующей итерации.

Discovery Loop является первым из трех этапов в ИИ-разработке. Это петля открытий — этап уточнения требований к продукту.

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

Что такое Discovery Loop

Discovery Loop можно рассматривать как цикл совместного исследования задачи разработчиком и ИИ-ассистентом. На входе имеется первоначальная идея или достаточно общее описание проблемы, а на выходе — постепенно уточняющееся понимание того, что именно необходимо создать и каким требованиям должен соответствовать результат.

В классической разработке discovery часто воспринимается как предварительная стадия: аналитики и заказчики выясняют требования, после чего команда передает их разработчикам. В AI-разработке такой подход оказывается слишком жестким. Часть требований становится известна только после того, как человек увидел работающий результат и смог с ним взаимодействовать.

Discovery Loop превращает разработку с ИИ из последовательного выполнения заранее известных требований в процесс непрерывного обнаружения и уточнения требований.

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

Расшифровка

Название Discovery Loop можно перевести как «цикл открытий», «петля исследований» или «цикл выявления». В данном случае discovery означает не разовое исследование перед проектированием, а процесс постоянного выяснения того, каким должно быть решение.

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

Место в AI SDLC

Discovery Loop можно рассматривать как первый контур AI SDLC. До того как ИИ начнет последовательно реализовывать требования, необходимо понять саму задачу, исследовать предметную область и определить, что именно предстоит создавать. Поэтому разработка с ИИ может быть представлена как последовательность трех связанных петель: Discovery Loop → Intent Loop → Implementation Loop.

В Discovery Loop человек и ИИ исследуют проблему и обнаруживают требования. Затем в Intent Loop задача анализируется, уточняется, сопоставляется с существующими бизнес-возможностями, архитектурой и ограничениями системы. Результатом становится формализованная спецификация, которая становится основным источником знаний для последующих этапов.

На этом уровне возникает связь с SSD (Specification-Driven Development) — разработкой, управляемой спецификацией. Спецификация становится промежуточным слоем между бизнес-намерением и реализацией: ИИ уже не должен каждый раз интерпретировать исходную идею с нуля, а получает более точное описание того, что именно требуется реализовать.

После этого начинается Implementation Loop. На его этапе спецификация преобразуется в код, код выполняется и тестируется, выявленные проблемы исправляются, а результат сопоставляется с заданными требованиями. Таким образом, AI SDLC становится не цепочкой «промпт → код», а системой взаимосвязанных циклов исследования, формализации намерения и реализации.

Стадия	Основной вопрос	Результат
Discovery Loop	Что на самом деле нужно решить?	Выявленные требования, ограничения, сценарии и новые знания
Intent Loop	Что именно должна делать система?	Формализованная спецификация и согласованное намерение
Implementation Loop	Как реализовать это технически?	Код, тесты и работающая реализация

Простыми словами

Если объяснять Discovery Loop без специальной терминологии, его можно представить как работу с ИИ по принципу «сначала попробуй, потом пойми, что именно нужно улучшить». Человек не обязан заранее знать все детали будущей системы. Он начинает с общей задачи, получает первый результат и уже на его основе понимает, какие требования были упущены.

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

Таким образом, ИИ становится не только исполнителем, но и инструментом исследования. Человек смотрит на результат, задает вопросы, проверяет гипотезы и постепенно превращает первоначальную идею в более точное описание продукта.

Понятный пример

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

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

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

Как работает: алгоритм и важные нюансы

На практике Discovery Loop представляет собой повторяющийся цикл, в котором каждый следующий шаг опирается на результат предыдущего. Ключевой принцип заключается в том, что разработчик не пытается заранее описать абсолютно все требования, а использует ИИ и промежуточные результаты для последовательного исследования задачи.

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

Этап	Что происходит	Результат
1. Постановка	Формулируется исходная задача	Первичный intent
2. Генерация	ИИ создает первую реализацию или прототип	Рабочий артефакт
3. Проверка	Человек запускает и исследует результат	Найденные несоответствия
4. Открытие	Фиксируются новые требования и ограничения	Новые знания
5. Уточнение	Новые знания преобразуются в следующий запрос	Обновленная постановка
6. Фиксация	Значимые решения и требования сохраняются	Накопленный контекст

Постановка первоначальной задачи

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

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

Генерация первой версии

ИИ создает первоначальную реализацию на основании доступного контекста. Это может быть код, интерфейс, SQL-запрос, API, тест или другой технический артефакт. На этой стадии не следует ожидать, что результат будет полностью готовым.

Первая версия нужна прежде всего как объект исследования. Она позволяет перейти от абстрактного разговора о будущем продукте к конкретному результату, который можно запустить, проверить и обсудить.

Проверка результата

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

При этом недостаточно ограничиваться проверкой того, «работает ли код». Нужно оценивать, соответствует ли поведение системы реальной задаче. Технически работающая функция может оказаться бесполезной, неудобной или противоречащей бизнес-правилам.

Выявление открытий

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

Именно здесь возникает принципиальное отличие Discovery Loop от обычной отладки. Ошибка рассматривается не только как дефект реализации, но и как источник новой информации о требованиях.

Уточнение намерения

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

Постепенно промпты становятся все более точными, а первоначальное намерение — более формализованным. На определенном этапе накопленные требования уже можно преобразовать в спецификацию для дальнейшего Intent и Implementation Loop.

Фиксация контекста

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

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

Инструменты

Discovery Loop не требует специального программного продукта. Его можно реализовать практически в любой среде, где разработчик способен последовательно формулировать запрос, получать результат, проверять его и возвращаться к постановке задачи. Однако разные классы инструментов поддерживают этот цикл с разной эффективностью.

Чат-интерфейсы удобны для исследования требований, обсуждения архитектуры и техники «интервью с ИИ». IDE с AI-функциями позволяют одновременно видеть код и вносить изменения, сокращая расстояние между запросом и результатом. Автономные агенты дополнительно усиливают цикл, поскольку способны самостоятельно запускать команды, анализировать ошибки и возвращаться с результатами проверки.

К таким инструментам относятся ChatGPT и Claude для диалога и анализа, GitHub Copilot и Cursor для работы непосредственно в среде разработки, а также агентные решения вроде Claude Code. При выборе инструмента важно учитывать не только качество генерации, но и насколько удобно организован переход между постановкой задачи, результатом, проверкой и следующей итерацией.

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

Ошибки разработчиков

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

Принимать код на веру

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

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

Выполнять цикл вслепую

Можно несколько раз отправить ИИ запросы на изменение кода, практически не разбираясь в том, что произошло между итерациями. Формально цикл будет продолжаться, но настоящего discovery не произойдет.

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

Править код руками вместо уточнения требований

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

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

Не фиксировать открытия

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

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

Игнорировать вопросы ИИ

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

Гораздо полезнее рассматривать вопросы ИИ как инструмент discovery. Каждый хороший уточняющий вопрос помогает обнаружить скрытое требование и сделать будущую реализацию более предсказуемой.

Добавлять слишком много изменений за один цикл

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

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