Большинство компаний строят программную фабрику неправильно
Индустриальные фабрики изменили подход мира к производству материальных товаров: больший объём выпуска, более низкие издержки, выше скорость, чем у чего-либо существовавшего ранее. Теперь аналогичные перемены происходят и в сфере программного обеспечения.
Большие языковые модели (LLM) снизили порог входа в написание кода, увеличили индивидуальную производительность и заставили организации взглянуть на разработку ПО как на производственную систему. Стандартный жизненный цикл разработки ПО и практики CI/CD, действовавшие на протяжении десятилетий, не выдержат этого давления. Именно здесь на сцену выходит концепция «программной фабрики» (software factory) — и, подобно физическим заводам, ей требуется нечто большее, чем просто скорость, чтобы реально работать.
Идея «программной фабрики» начала обретать чёткие очертания за последний год. В материале Луки Росси (Luca Rossi) «Эпоха программной фабрики» (The Era of the Software Factory) этот тезис обосновывается предельно ясно: ИИ не просто меняет скорость написания кода людьми — он меняет всю производственную систему вокруг программного обеспечения.
Эта концепция может означать разные вещи: набор агентов для кодинга и файлов с навыками; ускоренный CI/CD; более совершенные системы ревью; или расширенную автоматизацию доставки ПО. Лучше воспринимать это не как категорию инструментов, а как набор принципов. Программная фабрика не может быть просто разрозненным набором промптов, агентов и плагинов. Ей необходима платформа, которая определяет, как задачи перемещаются по системе и как код генерируется, проверяется, тестируется, отслеживается, развертывается и дорабатывается в случае возникновения сбоев.
В противном случае всё, что вы делаете, — это помещаете очередную разовую машину в пустую комнату и называете её фабрикой.
Почему это происходит именно сейчас?
Сразу несколько факторов сошлись в одной точке.
Компании всегда хотели получать больше программного обеспечения, чем инженеры способны произвести. Именно поэтому существуют такие инструменты, как Excel: они часто восполняют нехватку софта, который многие компании хотели бы иметь возможность создавать.
ИИ также снизил порог входа в создание кода, и именно на этом все акцентируют внимание. Создание кода теперь дается проще, хотя и не всегда дешевле или качественнее, о чем свидетельствуют многочисленные крупные компании, обеспокоенные своими огромными счетами за ИИ. Порог написания функционального кода фактически рухнул.
Что еще важнее, один инженер теперь может генерировать больше кода, чем несколько лет назад. Это меняет узкое место: вопрос больше не звучит как «Как быстро кто-то может это написать?» или даже, в некоторых случаях, «Умеет ли кто-нибудь кодить?». Вместо этого возникает вопрос: «Стоит ли это писать?»
И что еще важнее, можем ли мы на выходе создавать действительно долговечные и надежные продукты, которые не просто накапливают технический долг? Или мы просто штампуем некачественный ИИ-контент быстрее, чем когда-либо? В этом и заключается опасность.
Опасности современной программной фабрики
Всё это звучит прекрасно. В конце концов, фабрики сделали производство более быстрым и стабильным.
Благодаря им стало возможно выпускать больше автомобилей и товаров с меньшими затратами, что позволило большему количеству людей позволить себе эти автомобили и товары. Если оставить за скобками экологическое воздействие, можно утверждать, что это было благом.
Но, как и во многих инженерных задачах, здесь всегда есть компромиссы, и в данном случае возникают новые риски.
Когда вы увеличиваете производительность одного человека с помощью механизмов — цифровых или иных — вы одновременно увеличиваете количество ошибок, которые могут быть допущены как самим человеком, так и машиной. Скорость, с которой теперь можно выпускать код, приобрела промышленные масштабы. Даже небольшие организации могут столкнуться с тем, что их кодовые базы внезапно раздуваются до размеров кодовых баз технологических гигантов десятилетней давности.
Данные уже указывают на проблемы. В Faros AI выяснили, что хотя объем задач на одного разработчика вырос на 33,7%, а частота слияния пулл-реквестов (PR merge rate) — на 16,2%, соотношение инцидентов к пулл-реквестам подскочило на 242,7%, а количество багов на одного разработчика увеличилось на 54%. Исследование DORA от Google показало, что более активное внедрение ИИ на самом деле коррелирует с худшей стабильностью релизов.
Будучи внештатным директором по данным (fractional head of data), я привлекаюсь именно для решения подобных проблем. Только за последний год я работал над двумя проектами, в которых сгенерированная ИИ инфраструктура данных со временем начала деформироваться.
Из-за того, что несколько инженеров пытались двигаться быстро при отсутствии стандартов, эти проекты вышли из-под контроля. Кодовые базы склонны проходить определенные этапы эволюции, но по мере смешения разных стилей языковые модели начинают порождать собственные мутации. В кодовых базах за считанные месяцы развивалось по пять-шесть разных стилей — процесс, который раньше занимал годы. Слой за слоем инженеры постепенно переставали понимать, что именно происходит.
Эта картина перекликается с тем, что происходило десятилетие назад с инструментами самообслуживания: первоначальный прирост производительности маскировал возникающую в дальнейшем сложность.
И именно поэтому программная фабрика не может сводиться исключительно к скорости.
Что заставляет программную фабрику работать
При создании программной фабрики необходимо учитывать несколько ключевых принципов.
Платформа важнее инструментов: Многие команды постепенно внедряют ИИ в свои рабочие процессы на периферии — добавляя агента для ревью пулл-реквестов или файл с инструкциями в свои репозитории. Но создание реальной программной фабрики требует платформы, а не набора разрозненных инструментов. Платформа обеспечивает единый фундамент, где инструменты не раскиданы по разным углам. Вместо этого они активно делятся данными, взаимодействуют друг с другом и работают как единая слаженная система, в которой стандарты, процессы и сама работа тесно связаны между собой.
Возможность перезапуска и прослеживаемость: Настоящая платформа требует возможности вернуться к любому запуску, определить, что пошло не так, и перезапустить его — именно поэтому точечные агенты не делают фабрику фабрикой. Система должна поддерживать получение серийного ID, его поиск и детальное отслеживание пути к полученному результату. Вот почему конечные автоматы (state machines) подходят для ИИ-воркфлоу лучше, чем циклы: они значительно упрощают перезапуск процесса и понимание того, что произошло на каждом этапе.
Безопасность и защитные механизмы (guardrails): Фабрики — это небезопасные места. Программная фабрика — не исключение. По мере того как всё больше людей ведут разработку на этих платформах, необходимо встраивать более надежные защитные механизмы и меры безопасности. Тестирование и контроль качества должны быть перенесены на самые ранние этапы процесса: обнаружение багов на минимально возможной стадии снижает стоимость их исправления и ограничивает радиус поражения.
Стандартизация: На уровне предприятия каждая кодовая база имеет свой собственный характер. Наслоение помощника по написанию кода поверх этого без соблюдения стандартов порождает конгломерат стилей. Стандартизация должна быть заложена в процесс с самого начала.
Контроль качества: В старых моделях производства контроль качества осуществлялся в конце линии. Продукт изготавливался, инспектировался, в нем находили дефекты и исправляли их позже. Подход Toyota был иным. Контроль качества был внедрен в сам процесс — от рабочих ожидали остановки линии, если что-то шло не так. Целью было не выявление дефектов на выходе, а предотвращение их попадания на последующие этапы изначально.
То же самое справедливо и для программной фабрики. Контроль качества должен быть заложен во весь процесс, начиная с того, как пишется спецификация. Это означает интеграцию статического анализа кода, который выявляет очевидные ошибки, и предоставление шаблонов для LLM, чтобы они понимали структуру, которой должен следовать код. Без этого узким местом становится финальное код-ревью — или команды просто продолжают штамповать некачественный ИИ-код.
Скорость без качества — это не производительность
Повышение скорости генерации кода не является реальной производительностью, если не контролируются сопутствующие проблемы на последующих этапах. Компания не становится более продуктивной от того, что выпускает миллионы автомобилей, если все они рассыпаются через 100 миль пути. Она также не становится продуктивнее, если всё, что она делает, — это штампует бесконечный поток PoC (proof-of-concept), которые никогда не доходят до продакшна.
Реальная производительность — это когда программная фабрика превращает мимолетные токены в долговечные результаты. Легко рассуждать о строках кода и о том, как быстро движется ваша команда.
Побеждает не та программная фабрика, которая генерирует больше всего кода. Побеждает та, которая генерирует меньше всего дефектов в дальнейшем.
