[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