[1/2] Autonomy Is All You Need (Рубрика #Agents) Посмотрел интересный доклад Michele Catasta, president & head of AI в Replit, который он рассказывал месяц назад на конференции AI Engineer. До этого Michele работал head of applied research в Google, а сейчас отвечает за всю AI‑стратегию Replit, который собирает прототипы приложений “с нуля до демки” за минуты. Вот основные тезисы его выступления 1️⃣ Автономия — главный измеримый прогресс в агентах Кодовые ассистенты можно оценивать не только по качеству подсказок, а по тому, насколько далеко агент доходит сам, без человека “на ручнике”. Для нетехнических пользователей это вообще единственный смысл: либо агент способен сам довести задачу до результата, либо продукт для них бесполезен. Отсюда “north star”: степень автономии — ключевая метрика развития AI‑агентов в разработке, а не просто качество одного запроса. 2️⃣ Две фундаментальные способности для настоящей автономии Michele выделяет два базовых кирпича автономного агента в разработке: 1. Автоматическое тестирование Агент должен уметь сам проверять себя — через юнит‑тесты, интеграционные проверки, e2e‑сценарии, health‑чеки и т.д. Без автоматической валидации он либо: - Нуждается в постоянном человеке‑ревьювере - Либо будет “галлюцинировать” успешность и ломать прод В Replit вокруг этого построен целый цикл: генерация кода → запуск тестов → анализ фейлов → автопочинка. Без этого никакой реальной автономии нет. 2. Продвинутый контекст‑менеджмент Агент, который делает что‑то сложнее одного файла, обязан: - Понимать структуру репозитория и артефактов - Удерживать состояние долгих задач (дни/недели работы над проектом) - Помнить решения, компромиссы и ограничения (memory) - Управлять планом: что сделано, что сломано, какие подзадачи открыты Без хорошего управления контекстом агент либо “забывает” важные детали через N шагов, либо начинает плодить противоречия в кодовой базе. 3️⃣ После автономии — параллелизм как ключ к UX Когда агент может действовать сам, следующая проблема — как сделать так, чтобы пользователю не приходилось ждать вечность. Michele разбирает несколько моделей параллелизации: - Task‑level parallelism. Декомпозиция работы на независимые подзадачи: генерация фронта, бэка, конфигов, тестов и т.п. в разных “ветках” выполнения. Это снижает latency и даёт раннюю обратную связь: пользователь видит прогресс по частям, а не ждёт один гигантский ответ. - Out‑of‑order execution. Не обязательно выполнять задачи строго в порядке плана, если есть независимые куски, которые можно тащить вперёд. Похожая идея на out‑of‑order в CPU: выигрыш по времени, но нужно аккуратно работать с зависимостями. - Параллельная план‑декомпозиция. Не один линейный “Chain of Thought”, а дерево плана, где разные ветки могут развиваться отдельно и потом схлопываться. Это повышает устойчивость: можно откатываться не “ко всему началу”, а к узлу дерева. Ключевая идея: последовательный агент = плохой UX. Пользователь залипает в ожидании и теряет flow. Настоящий “AI engineer experience” — это когда агент шуршит параллельно по нескольким направлениям, а человек видит понятный прогресс. 4️⃣ Баланс: latency vs ресурсы vs корректность** Как только добавляем параллелизм и автономию, начинается классическая инженерная тройка: - Меньше latency → больше параллельных веток → выше расход токенов/вычислений. - Больше автономии → меньше человеческого контроля → выше риск некорректных изменений. - Жёсткие гарантии корректности → больше проверок/ручных подтверждений → хуже UX. Michele по сути говорит: нет “магического” решения. Нужно явно проектировать эту тройку под свой продукт: - где мы готовы платить вычислительными ресурсами ради вау‑эффекта; - где ради безопасности согласны пожертвовать скоростью; - где нужна явная точка “здесь всегда спрашиваем человека”. В продолжении будут мысли о том, а что можно извлечь инженерам при создании своих автономных агентов. P.S. Кстати, историю Replit хорошо рассказал Амджада Масада (CEO) в интервью Y Combinator летом (см. мой разбор) #AI #ML #Agents #Software #Engineering #Architecture