Factory: инженеры становятся менеджерами — а кто тогда остаётся инженером, способным проверить их исполнителей? (Рубрика #AI4SDLC)

Название с обложки 18-минутного доклада Davis Palmie, инженера Factory, хорошо продолжает нашу тему dark factories. На AI Engineer World's Fair 2026 он описывает систему, которая превращает баг-репорты и обратную связь пользователей в production-код. Человек задаёт направление и управляет агентами. Звучит как повышение, но давайте посмотрим на должностную инструкцию:)

1️⃣ Управлять всей цепочкой
Palmie считает, что написание кода давно не главное узкое место. Изменения ждут ревью, баги нужно воспроизвести, документация устаревает, продуктовые решения теряются между командами. Его software factory связывает эти этапы: сигнал → диагностика → план → код и тесты → ревью → выкладка → наблюдение за результатом. Обратная связь возвращается в следующий цикл. Это развитие factory model из The New SDLC: инженер строит систему, которая производит изменения.

2️⃣ Подготовить среду
У Factory восемь направлений agent readiness: линтеры и форматирование, сборка, тесты, документация, воспроизводимые окружения, модульность, наблюдаемость и безопасность. Агенту нужны понятные команды, актуальные инструкции и доступ к контексту за пределами репозитория. Всё это полезно и людям. Плюс возможность выбирать модель под задачу и размещать исполнение в пределах своей инфраструктуры.

3️⃣ Включать автономность постепенно
Начать с диагностики инцидента: агент читает alert из Sentry, собирает traces и отправляет вывод в Slack. Инженер проверяет и решает, что делать. Сначала каждый этап получает владельца и контроль, потом цепочка замыкается. Это рифмуется с нашим Loop Engineering: проверяющий должен уметь вовремя сказать «нет».

И вот здесь обложка оказывается смелее содержания. Palmie прямо говорит, что точное исполнение не предотвращает плохой дизайн: архитектура, стратегия и допуск изменений по-прежнему требуют людей. Поэтому с докладом Dex Horthy у него больше общего, чем кажется. Dex описывал, как HumanLayer перестала следить за изменениями своей lights-off factory и во время инцидента столкнулась с кодом, который уже плохо понимала. Его аргумент: тесты проверяют «работает сейчас», а цена плохого проектирования проявляется через месяцы.

Менеджерская часть работы действительно растёт: постановка, приоритеты, делегирование, обратная связь. Но как проверить решение, если перестал понимать систему? В доклада Geoffrey Litt это и есть новое узкое место: AI ускоряет изменения, а человеческая модель системы отстаёт. Назначить инженера проверяющим ещё не значит дать ему время разобраться.

Метрики Palmie предлагает полезные: время от сигнала до production, число человеческих вмешательств, время восстановления, срок жизни кода и стоимость PR. Для меня число вмешательств требует оговорки: оно может падать и потому, что всё работает, и потому, что люди перестали проверять. Сопоставимое качество здесь обязательно.

Но интересно, а что продаёт компания Factory?
На сайте компании эта картина превращается в платформу: Droid для работы с кодом, автоматизации, маршрутизация моделей, Mission Control, ревью и обновляемая документация. Для организаций — интеграции и управление доступом. Компания продаёт инструменты, через которые можно организовать и контролировать работу агентов.

В Missions это особенно видно: оркестратор разбивает цель на задачи, исполнители работают со свежим контекстом, отдельные агенты проверяют результат, состояние хранится в общих файлах. Роли и проверки становятся частью продукта. Так что «Engineers become managers» — ещё и объяснение, зачем покупать Factory: если теперь управляешь агентами, тебе предлагают рабочее место для этого управления. А способность оценить архитектуру и понять, что именно получилось, инженер приносит с собой.

#AI4SDLC #AI #Agents #Engineering #Management #DevTools