Большинство компаний думают, что строят фабрику программного обеспечения. На самом деле они просто быстрее выпускают исправления ошибок.
Бенджамин Рогоян
Индустриализация производства изменила способы производства материальных товаров в мире: увеличилась производительность, снизились издержки, скорость производства стала непомерной. Сейчас аналогичные изменения происходят и в сфере программного обеспечения.
Программы магистратуры в области программного обеспечения снизили барьер для написания кода, повысили производительность труда отдельных специалистов и подтолкнули организации к рассмотрению разработки программного обеспечения как производственной системы. Стандартные методы жизненного цикла разработки программного обеспечения и практики CI/CD, которые существовали десятилетиями, не выдержат такого давления. Вот тут-то и вступает в игру «фабрика программного обеспечения» — и, как и физические заводы, ей нужно больше, чем просто скорость, чтобы действительно работать.
Идея «фабрики программного обеспечения» начала обретать конкретные очертания в течение последнего года. В своей книге «Эра фабрики программного обеспечения» Лука Росси ясно показал: ИИ меняет не только скорость написания кода, но и всю систему производства программного обеспечения.
Концепция может означать разные вещи: набор агентов для кодирования и файлов с навыками; более быструю CI/CD; улучшенные системы проверки; или большую автоматизацию процесса разработки программного обеспечения. Лучше рассматривать её не как категорию инструментов, а скорее как набор принципов. Фабрика программного обеспечения не может быть просто набором подсказок, агентов и плагинов. Ей нужна платформа, которая определяет, как работа перемещается по системе и как код генерируется, проверяется, тестируется, отслеживается, развертывается и улучшается в случае возникновения проблем.
В противном случае вы просто устанавливаете очередной уникальный станок в пустую комнату и называете это фабрикой.
Почему это происходит именно сейчас?
На это одновременно воздействует несколько факторов.
Компаниям всегда хотелось создавать больше программного обеспечения, чем могут произвести инженеры. Именно поэтому существуют такие инструменты, как Excel: они часто восполняют пробел в разработке программного обеспечения, которое многие компании хотели бы иметь в своем распоряжении.
Искусственный интеллект также снизил порог входа для создания кода, и именно на этом все сосредотачиваются. Создание кода стало проще, хотя и не всегда дешевле или качественнее, о чем свидетельствуют многочисленные крупные компании, обеспокоенные высокими затратами на ИИ. По сути, барьер для написания функционального кода рухнул.
Что еще более важно, один инженер может написать больше кода, чем всего несколько лет назад. Это меняет узкое место: вопрос больше не в том, «Как быстро кто-то может это написать?» или даже, в некоторых случаях, «Понимает ли кто-то, как писать код?». Вместо этого он становится вопросом: «Стоит ли это писать?»
Что еще важнее, можем ли мы действительно создавать конечные продукты, которые будут долговечными и надежными, а не просто накапливать технологический долг? Или мы просто выпускаем все больше и больше некачественной продукции, созданной с помощью ИИ, быстрее, чем когда-либо? Вот где кроется опасность.
Опасности современной фабрики программного обеспечения
Всё это звучит замечательно. В конце концов, заводы сделали производство быстрее и стабильнее.
Благодаря им стало возможным производить больше автомобилей и товаров по более низким ценам, что позволило большему числу людей приобрести автомобили и товары по доступной цене. Если отбросить экологические последствия, можно утверждать, что это было позитивно.
Но, как и во многих областях инженерии, всегда есть компромиссы, и в данном случае это новые риски.
Когда вы увеличиваете производительность одного человека с помощью оборудования, цифрового или иного, вы также увеличиваете количество ошибок, которые могут быть допущены как отдельным человеком, так и оборудованием. Скорость, с которой сейчас можно создавать код, достигла промышленных масштабов. Даже небольшие организации могут внезапно увеличить свои кодовые базы до размеров кодовых баз технологических компаний десять лет назад.
Данные уже указывают на проблемы. Компания Faros AI обнаружила, что, хотя пропускная способность задач на одного разработчика выросла на 33,7%, а скорость слияния запросов на слияние — на 16,2%, соотношение инцидентов к запросам на слияние увеличилось на 242,7%, а количество ошибок на одного разработчика — на 54%. Исследование DORA от Google показало, что более широкое внедрение ИИ на самом деле связано с ухудшением стабильности доставки.
В качестве частичного руководителя отдела данных меня привлекли для решения именно этих проблем. Только за последний год я работал над двумя проектами, в рамках которых инфраструктура данных, генерируемых ИИ, постепенно начала трансформироваться с течением времени.
Из-за множества инженеров, стремящихся к быстрой работе, и отсутствия стандартов эти проекты стали неуправляемыми. Кодовые базы, как правило, проходят определенный этап эволюции, но по мере смешения различных стилей, разработчики, в свою очередь, начинают создавать свои собственные мутации. Кодовые базы за несколько месяцев развили пять-шесть различных стилей — процесс, который раньше занимал годы. Слой за слоем инженеры постепенно переставали точно понимать, что происходит.
Эта тенденция перекликается с тем, что произошло десять лет назад с инструментами самообслуживания: первоначальный рост производительности маскировал сложность последующих этапов.
Именно поэтому программная фабрика не может быть ориентирована только на скорость.
Что обеспечивает эффективную работу программной фабрики?
При создании фабрики программного обеспечения следует учитывать несколько ключевых принципов.
Платформа важнее инструментов: многие команды постепенно внедряют ИИ в свои рабочие процессы кодирования на периферии — добавляя агент проверки запросов на слияние или файл навыков в свои репозитории. Но для создания настоящей фабрики программного обеспечения нужна платформа, а не набор инструментов на периферии. Платформа обеспечивает единую основу, где инструменты не разбросаны по разным углам. Вместо этого они активно обмениваются данными, взаимодействуют друг с другом и работают как единая целостная система — стандарты, процессы и сама работа взаимосвязаны.
Возможность повторного запуска и отслеживаемость: Настоящая платформа должна иметь возможность вернуться к любому запуску, определить, что пошло не так, и запустить его заново — именно поэтому одноразовые агенты не создают фабрику. Система должна поддерживать получение серийного номера, его поиск и точное отслеживание того, как она привела к полученному результату. Именно поэтому конечные автоматы более целесообразны для рабочих процессов ИИ, чем циклы: они значительно упрощают повторный запуск процесса и понимание того, что произошло на каждом шаге.
Безопасность и меры предосторожности : Заводы — небезопасные места. Небезопасна и фабрика программного обеспечения. По мере того, как всё больше людей разрабатывают приложения на этих платформах, необходимо внедрять более совершенные меры безопасности и контроля. Тестирование и контроль качества должны быть выдвинуты на первый план — выявление ошибок на самом низком этапе снижает затраты на их исправление и ограничивает масштабы последствий.
Стандартизация: На уровне предприятия каждый код имеет свой собственный стиль. Внедрение системы автоматического написания кода без соблюдения стандартов приводит к смешению разных стилей. Стандартизация должна быть заложена в процесс с самого начала.
Контроль качества: В более старых моделях автомобилей контроль качества осуществлялся в конце производственной линии. Изделие собиралось, проверялось, обнаруживались дефекты и устранялись позже. Подход Toyota был иным. Качество было интегрировано в сам процесс — от рабочих ожидалось, что они остановят линию, если что-то пойдет не так. Цель заключалась не в обнаружении дефектов в конце, а в предотвращении их попадания в последующие производственные процессы.
То же самое относится и к программной фабрике. Контроль качества должен быть встроен во весь процесс, начиная с того, как написана спецификация. Это означает интеграцию статического анализа кода, который выявляет очевидные ошибки, и предоставление шаблонов для LLM, чтобы они знали, какой структуре должен следовать код. Без этого узким местом становится финальная проверка — или команды просто выпускают больше некачественного кода, созданного с помощью ИИ.
Скорость без качества — это не производительность.
Повышение скорости генерации кода не является реальной производительностью, если не решаются проблемы, возникающие на последующих этапах. Компания не становится более продуктивной, если производит миллионы автомобилей, которые разваливаются через 100 миль. Она также не становится более продуктивной, если всё, что она делает, — это создает бесконечный поток прототипов, которые никогда не доходят до производства.
Реальная производительность — это когда программная фабрика берет временные токены и превращает их в долговременные результаты. Легко говорить о строках кода и о том, насколько быстрее работает ваша команда.
Победителем становится не та программная фабрика, которая генерирует больше всего кода, а та, которая создает меньше всего дефектов на последующих этапах разработки.
Подпишитесь, чтобы получать самые свежие новости!
Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.
Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.
Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.
Источник: venturebeat.com
Оцените материал:
