Research First Builder: методология проверки архитектурных решений ИИ-агентов
Разработка программного обеспечения с использованием искусственного интеллекта часто сталкивается с проблемой «черного ящика»: сложно отследить, откуда агент взял то или иное архитектурное решение. Авторы материала предложили концепцию Research First Builder (RFB) — систему, которая фиксирует путь от исследования аналогов до написания кода и финальных проверок, делая процесс разработки прозрачным и воспроизводимым.
# Research First Builder: прозрачность архитектурных решений ИИ
В эпоху, когда ИИ-агенты пишут код, планируют архитектуру и управляют циклами разработки, возникает новая проблема: кто отвечает за качество принимаемых решений? Если нейросеть выбирает базу данных или формат хранения данных, может ли разработчик доверять этому выбору без ручного аудита? В статье, опубликованной на Habr, обсуждается подход Research First Builder (RFB), призванный решить эту задачу через строгую документацию исследовательского процесса.
От абстрактного плана к проверяемым фактам
Основная идея RFB заключается в разделении этапа исследования (research) и этапа реализации (building). Традиционные подходы к промптингу часто смешивают эти фазы, что приводит к тому, что конечный код может отличаться от инициальной идеи из-за внутренних ограничений модели или случайного выбора архитектуры во время генерации.
Автор предлагает последовательность действий, которую должен выполнить агент перед написанием строки кода: 1. Исследование: Изучение существующих решений для похожих задач (например, локальные менеджеры закладок). 2. Анализ решений: Детальное объяснение того, как аналогичные инструменты обрабатывают данные (парсинг тегов, уникальность URL, управление сессиями). 3. Планирование: Формулирование собственного плана на основе полученных знаний. 4. Реализация: Написание кода согласно плану. 5. Валидация: Создание проверочных тестов.
Этот порядок фиксируется в нескольких документах: RESEARCH.md, PLAN.md, VERIFICATION.md. Ключевым элементом является evidence.json, где хранятся связи между исходными наблюдениями, выбранными решениями, конкретными шагами плана и результатами тестов.
Кейс: локальный менеджер закладок
В качестве практического примера рассматривается задача создания локального приложения для управления закладками. Требования минималистичны: хранение URL, названия, необязательных тегов, базовый поиск и редактирование. Никаких серверов, Docker-контейнеров или облачных хранилищ.
Анализ тегов из Linkding
Для начала агент изучил популярное решение — Linkding. При парсинге тегов в оригинальном приложении применяется агрессивная нормализация: удаляются пустые значения, удаляются повторы без учета регистра, а пробелы внутри тегов заменяются дефисами. Так, тег Machine Learning превращается в machine-learning.
Однако для новой утилиты автор считает это решение избыточным. Вместо полной нормализации было принято решение оставить внутренние пробелы и сохранить первое написание тега, просто удаляя дубликаты с учетом регистра. Здесь важно различать то, *как работает* существующий инструмент, и то, *что нужно* в новом проекте. RFB требует зафиксировать это различие в отчете.
Уникальность URL в SQLite
Другой критический аспект — хранение данных. Исследуя проект Buku, агент обнаружил, что в базе данных используется ограничение UNIQUE на поле URL. В коде реализация выглядит следующим образом:
python import sqlite3 db = sqlite3.connect(":memory:") db.execute("CREATE TABLE bookmarks (url TEXT NOT NULL UNIQUE)") # Вставка и попытка повторной вставки nПри попытке записи дублирующегося URL в стандартной библиотеке Python срабатывает исключение IntegrityError`. Это простое решение, которое надежно предотвращает дубликаты.
Однако выбор SQLite как базы данных в памяти решает задачу только частично. Остается вопрос сохранения данных после перезапуска приложения, а также нормализация URL (например, разница между https://site.com и https://site.com/). В отчете необходимо явно записать эти ограничения и план их решения.
Валидация и границы применимости
Система RFB не просто генерирует код, она создает цепочку доказательств. Если решение помечено как ADOPT (принять), оно должно быть подтверждено тестом. Если REJECT (отклонить) или DEFER (перенести на потом), причина должна быть задокументирована. В примере с менеджером закладок решение по файловому жизненному циклу приложения Shaarli было отвергнуто не из-за его неэффективности, а из-за отсутствия необходимости переносить сложную архитектуру для простой задачи.
Программа-проверяющая (rfb.py) затем сверяет целостность всей собранной информации: проверяет, нет ли разрывов в логической цепи от требования к коду, соответствуют ли тесты заявленным решениям и обновляется ли версия файлов.
Важно понимать границы инструмента. RFB не читает репозитории за пользователя, не выполняет команды из записанных JSON и не гарантирует, что код, сгенерированный агентом, будет абсолютно корректным. Она лишь обеспечивает прозрачность процесса принятия решений. Если агент ошибется в логике, структура отчета будет правильной, но фактическое утверждение неверным. Поэтому конечная проверка содержания кода остается на людях.
Заключение
Research First Builder предлагает прагматичный подход к автоматизации разработки. Он не обещает мгновенного ускорения создания приложений, но дает мощный инструмент для контроля качества на этапе проектирования. Для сложных систем, где архитектурные ошибки могут привести к колоссальным потерям, возможность проследить каждое решение от источника к реализации становится критически важной.
Для внедрения такого подхода достаточно начать с отдельного этапа research-only, ограниченного одной спорной технической деталью, например, способом хеширования данных или выбором базы данных. Это позволит увидеть, насколько прозрачным становится процесс принятия решений ИИ, еще до написания основного кода приложения.