Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности с фабрикой о экономически эффективном массовом производстве их совков для уборки собачьих экскрементов, комфортных носков или мочалок. Идея массового производства может быть актуальна и для доставки ПО, пишет на портале ZDNet независимый аналитик Джо Маккендрик.

Представьте, что вы отправляете свой прототип — например, начальную версию приложения, написанную с помощью вайб-кодинга, — в сервис, который будет массово производить ваше решение в повторяемом автоматизированном режиме для распространения среди широкой аудитории. В этом и заключается обещание «фабрики ПО».

В этой концепции нет ничего нового — она была очень популярна около двух десятилетий назад, когда разработка ПО стала более компонентной и повторяемой. Microsoft заговорила о фабриках ПО еще в 2008 г. Идея на некоторое время затихла, но теперь она вернулась, подпитываемая быстрым созданием программного кода, генерируемого и управляемого искусственным интеллектом.

До недавнего времени, даже при наличии автоматизации и практик DevOps, «кодирование создавало узкие места для многих организаций, — говорит Мориц Плассниг, генеральный директор CloudBees. — Приходилось нанимать больше инженеров, но это было очень сложно и дорого».

Сегодняшняя фабрика ПО построена на моделях ИИ

Благодаря возможностям кодирования базовых моделей ИИ и связанных с ними агентов, концепция фабрики ПО возродилась — и сегодня серьезно рассматривается автоматизация жизненного цикла разработки ПО на уровне повторяющихся этапов. С помощью агентного кодирования «мы меньше ограничены в части кодирования», отмечает Плассниг. Оно также может повысить роль ИТ-специалистов: «Мастерство разработчиков никуда не денется, поскольку разработчики и инженеры переходят от написания кода к принятию решений о том, что будет создано и выпущено».

Современная концепция фабрики ПО построена на основе моделей ИИ, представленных на рынке, — и эта концепция практически одинакова для всех моделей. «За последние полтора года многие компании, находящиеся на переднем крае использования агентов для автоматизации жизненного цикла разработки ПО, создавали одну и ту же машину и независимо друг от друга приходили к одному и тому же выводу о том, как эта машина должна выглядеть», — говорит Джеймин Уэст, инженер-разработчик и технологический евангелист.

Среди компаний, создающих фабрики ПО, — такие светила современной агентной экономики, как Anthropic, Cognition, Cursor, Factory, Google, Github, OpenAI и Ramp. «Каждая из этих компаний пришла к одной и той же форме, — отмечает Уэст. — На данном этапе очень важно понимать, что это компании, находящиеся на передовой, и что формируется четкая закономерность в том, как они структурируют всю свою инженерную работу».

По словам Пласснига, фабрика ПО служит способом быстрого воплощения идей: «Допустим, кто-то работает в службе поддержки клиентов, и у него возникает интересная идея, основанная на отзывах клиентов. Такой человек с идеей ПО может отправить ее на фабрику, где создается первая итерация. Далее специалисты по продуктам, инженеры и ИТ-специалисты изучают ее. Затем фабрика может снова взять ее и воплотить в жизнь. Это подобно тому, как в автоиндустрии появляется экспериментальный прототип, который потом передается на завод, который производит автомобили в больших масштабах».

Фабрика ПО помогает решить проблему проверки и поддержки сотен тысяч строк кода, а также релизов, обновлений и модернизаций ПО, которые сегодня ежедневно происходят во многих организациях.

«Вы хотите знать, действительно ли ПО работает, нет ли ошибок или хотя бы резкого роста частоты ошибок. Или, может быть, оно работает, но не превышает ли потребление памяти агентом желаемый уровень? Сегодня люди проверяют все эти оповещения, но если изменений будет в 100 раз больше, например, каждые несколько минут, система сломается. Мы дойдём до того момента, когда люди больше не смогут проверять, что работает, а что нет», — говорит Плассниг.

Как выглядит фабрика ПО?

Уэст описывает типичную фабрику, поддерживаемую базовыми моделями, как состоящую из шести компонентов:

1. Очередь. «Работа поступает в виде проблемы, а не промпта».

2. Плоскость управления. «Надежный уровень, а не ноутбук».

3. Песочница. «Одна на задачу. Уничтожается после ее завершения».

4. Запрос на слияние. «Единица вывода. Его получает человек».

5. Поток событий. «Отслеживает каждое действие. Прерывает его, не нарушая выполнение».

6. Надежная память. «Песочница выполняет каждый запуск. То, что не записано в файл, не сохраняется».

Конечно, фабрики ПО, какими бы эффективными они ни были, не являются панацеей для внедрения передовых методов разработки ПО.

«Сейчас уже не секрет, что генерация кода стала невероятно простой, — говорит Уэст. — Она теперь невероятно дешева. Но препятствием для многих компаний стала верификация. Убедиться, что агенты пишут код, очень легко. Но убедиться в правильности этого кода по-прежнему остается серьезной инженерной проблемой. И важно понимать, что создание фабрики ПО не означает, что вы просто отказываетесь от верификации или снижаете качество своей кодовой базы».