Lovable снизила число тупиков на 5% с помощью файлов знаний и RAG

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

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

Сначала сузить задачу

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

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

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

Инструкции оказались полезнее ранней дообученной модели

Команда ожидала, что будет дообучать модели на истории пользовательских сессий. На практике быстрее сработали обычные текстовые файлы. Инженеры изучали сломанные приложения, находили повторяющиеся причины и записывали короткие правила. Например: использовать только реально существующие иконки из выбранной библиотеки, а при сомнении брать универсальную.

Перед очередной генерацией поиск подбирал подходящие правила и добавлял их в контекст модели. По сути, это знакомая сегодня связка из базы инструкций и RAG. Один разобранный сбой начинал помогать следующим пользователям без нового цикла обучения. По данным самой Lovable, ранняя версия системы поиска по проблемам и решениям снизила долю пользователей, застревавших при работе, на 5%. Это внутренняя метрика компании, поэтому воспринимать её как универсальный результат нельзя.

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

Скорость зависит от проверки, а не только от модели

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

Именно здесь находится наиболее практичный вывод. При разработке агента измеряйте не только скорость первого ответа, но и весь цикл: изменение, проверка, обнаружение сбоя и исправление. Начните с ограниченного набора действий, собирайте повторяющиеся ошибки в проверяемые инструкции и добавляйте автономность только там, где есть быстрый сигнал о результате и безопасный откат. Lovable не доказала, что нашла окончательную архитектуру. Зато её история хорошо показывает, почему надёжный агент — это не одна сильная модель, а модель внутри правильно ограниченной и наблюдаемой системы.