Книжный куб

[2/2] Autonomy Is All You Need (Рубрика #Agents) Продолжая рассказ про доклад Michele Catasta, president & head of AI в Replit, хочется поделиться выводами о том, что может быть полезно инженерам из этого доклада 1️⃣ “Автономность” надо проектировать как фичу, а не надеяться на модель Если вы делаете собственный агент/код‑ассистент, важно принять позицию Michele: автономия — это не свойство модели, это свойство системы. Нужно осознанно строить: - Слой автоматического тестирования и валидации - Модели работы с репозиторием и долгим контекстом - Архитектуру планирования/параллелизации - Политику откатов и ошибок (recovery) Иначе вы получаете “очень умный autocomplete”, а не агента. 2️⃣ Автотесты и CI/CD превращаются из “инженерной гигиены” в API для агента Для команд разработки это переворачивает отношение к тестам и инфраструктуре: - Хорошее покрытие тестами и быстрый CI — это не только про людей, а про то, чтобы агенты могли безопасно модифицировать систему. - “Red → Green → Refactor” становится циклом не только для человека, но и для агента. - Инфраструктура (test env, staging, feature flags) — это уже операционная среда для автономного агента, а не просто удобство для разработчика. Если вы хотите в будущем доверять агенту делать миграции, фичи и рефакторинги, ему нужно: - Где запускать код изолированно - Как проверять, что ничего не сломано - Куда откатываться, если сломано 3️⃣ Контекст‑менеджмент как новый слой архитектуры продукта Архитектурно, “context management” для агента — это почти отдельный сервис: - Индекс кода и артефактов (vector + структурные индексы); - Долговременная память решений (design docs для агента); - История траекторий (что агент делал, что сработало, что нет); - Слой планирования, который может: -- Резать задачи на подзадачи -- Отслеживать прогресс -- Решать, что можно делать параллельно Это очень похоже на добавление “оркестратора” в микросервисную архитектуру, только теперь мы оркестрируем не сервисы, а действия модели. 4️⃣ Параллелизм в агентах = новые паттерны UX и DevEx Для технических руководителей и платформенных команд: - Нужно думать не только о том, как агент “правильно пишет код”, но и о том, как пользователь переживает его работу: -- Показывает ли агент понятный прогресс; -- Может ли пользователь вмешаться/скорректировать план; -- Как отображаются параллельные ветки (логи, диаграммы, “job view”). - План‑ориентированный UI (как в Replit Agent, LangGraph‑подобных системах) становится новым стандартом: разработчики хотят видеть траекторию агента, а не чёрный ящик. 5️⃣ Стратегический вывод: “AI‑инфраструктура” станет нормой для дев‑команд Если принять аргументацию Michele всерьёз, ближайшие 2–3 года для инженеров и техлидов означают: - Надо вкладываться в: -- Тестируемость/наблюдаемость кода; -- Явное моделирование домена (чтобы агенту было чем оперировать); -- Инфраструктуру для экспериментов с агентами (sandbox, telemetry, safety‑rails). - Нужно перестать мыслить агентом как “персональным Copilot’ом”; агент — это участник команды, который: -- Идёт по задачам бэклога, -- Делает изменения, -- Проходит те же quality‑гейты, что и человек (тесты, ревью, линтеры). #AI #ML #Agents #Software #Engineering #Architecture