Почему я пока не верю в универсальные темные фабрики софта (dark software factory)
Несколько месяцев назад появился тренд на построение полностью автоматизированных фабрик софта: систему, в которой AI-агенты получают цели, а дальше сами формируют задачи, пишут код, запускают тесты и выкатывают изменения в прод, без какого либо участия людей.
Эффективным менеджерам далеким от разработки эта идея кажется отличной. Можно сэкономить много денег компании и получить жирный бонус.
Тем не менее проностью автономная универсальная фабрика корпоративного софта пока невозможна по нескольким причинам:
1⃣ Недетерминированность описания цели на человеческом языке. И это особенно критично, если у вас уже есть legacy ситстема с своей доменной онтологией, на которой llm просто не натренированна.
2⃣ Проверка не масштабируется вместе с генерацией. Агент может создать тысячи строк за минуты, но быстро проверить архитектуру, неявные бизнес-правила и долгосрочные последствия нельзя.
3⃣ Зеленые тесты не означают, что решение хорошее. Они проверяют основные сценарии, но не поддерживаемость, правильность границ компонентов и совместимость с будущим развитием продукта. Особенно опасно когда тесты генерируются тем же агентом после написания кода - повышается вероятность, что код будет использоваться как source of truth и фактически тесты не будут проверять бизнес-логику.
4⃣ Непрочитанный код создает "интеллектуальный" долг. Если люди перестают читать код, команда постепенно теряет ментальную модель системы. Это особенно дорого проявляется во время сложных production-инцидентов.
5⃣ Длинные автономные циклы теряют контекст. Чем больше взаимосвязанных решений агент принимает без остановки, тем выше вероятность, что локально разумные изменения приведут к неправильному общему результату.
6️⃣ Некоторые ошибки слишком дороги. Для приема оплат, авторизации, управления деньгами, прав доступа и персональных данных даже один процент ошибок может быть неприемлемым.
Для частных случает сделать software factories можно уже сейчас. Агентам можно автономно отдавать обновление зависимостей, механические рефакторинги, исправление известных классов ошибок и другие задачи с быстрым объективным критерием готовности. Вероятно таких типовых задач довольно много, но это не универсальные решения.
PS: мой приятель Тимур Хахалев, с которым мы 9 месяцев назад собирали best practices по работе с AI агентами для разработки (пост), стартует второй поток своего курса "AI coding для разрабов". Лично знаю не только Тимура, но и двух человек прошедших у него обучение и оставшихся довольными, так что считайте это личной рекомендацией. Курс стартует уже через 3 дня - 10 августа, а пробный урок - бесплатный. По промокоду MAX - скидка 5%. Детали можно посмотреть здесь.
Несколько месяцев назад появился тренд на построение полностью автоматизированных фабрик софта: систему, в которой AI-агенты получают цели, а дальше сами формируют задачи, пишут код, запускают тесты и выкатывают изменения в прод, без какого либо участия людей.
Эффективным менеджерам далеким от разработки эта идея кажется отличной. Можно сэкономить много денег компании и получить жирный бонус.
Тем не менее проностью автономная универсальная фабрика корпоративного софта пока невозможна по нескольким причинам:
1⃣ Недетерминированность описания цели на человеческом языке. И это особенно критично, если у вас уже есть legacy ситстема с своей доменной онтологией, на которой llm просто не натренированна.
2⃣ Проверка не масштабируется вместе с генерацией. Агент может создать тысячи строк за минуты, но быстро проверить архитектуру, неявные бизнес-правила и долгосрочные последствия нельзя.
3⃣ Зеленые тесты не означают, что решение хорошее. Они проверяют основные сценарии, но не поддерживаемость, правильность границ компонентов и совместимость с будущим развитием продукта. Особенно опасно когда тесты генерируются тем же агентом после написания кода - повышается вероятность, что код будет использоваться как source of truth и фактически тесты не будут проверять бизнес-логику.
4⃣ Непрочитанный код создает "интеллектуальный" долг. Если люди перестают читать код, команда постепенно теряет ментальную модель системы. Это особенно дорого проявляется во время сложных production-инцидентов.
5⃣ Длинные автономные циклы теряют контекст. Чем больше взаимосвязанных решений агент принимает без остановки, тем выше вероятность, что локально разумные изменения приведут к неправильному общему результату.
6️⃣ Некоторые ошибки слишком дороги. Для приема оплат, авторизации, управления деньгами, прав доступа и персональных данных даже один процент ошибок может быть неприемлемым.
Для частных случает сделать software factories можно уже сейчас. Агентам можно автономно отдавать обновление зависимостей, механические рефакторинги, исправление известных классов ошибок и другие задачи с быстрым объективным критерием готовности. Вероятно таких типовых задач довольно много, но это не универсальные решения.
PS: мой приятель Тимур Хахалев, с которым мы 9 месяцев назад собирали best practices по работе с AI агентами для разработки (пост), стартует второй поток своего курса "AI coding для разрабов". Лично знаю не только Тимура, но и двух человек прошедших у него обучение и оставшихся довольными, так что считайте это личной рекомендацией. Курс стартует уже через 3 дня - 10 августа, а пробный урок - бесплатный. По промокоду MAX - скидка 5%. Детали можно посмотреть здесь.