Індустріалізація заводів змінила спосіб виробництва фізичних товарів у світі: більший випуск, нижчі витрати, швидше, ніж будь-що раніше. Зараз схожа зміна відбувається із програмним забезпеченням.
Великі мовні моделі (LLM) знизили бар’єр для написання коду, збільшили індивідуальну продуктивність та спонукали організації розглядати розробку програмного забезпечення як виробничу систему. Стандартний життєвий цикл розробки програмного забезпечення та практики CI/CD, що існували десятиліттями, не витримають цього тиску. Саме тут з’являється програмна фабрика — і, як і фізичні фабрики, їй потрібне більше, ніж просто швидкість, щоб дійсно працювати.
Ідея «програмної фабрики» почала формуватися протягом останнього року. Стаття Луки Россі «Ера програмної фабрики» чітко виклала це: ШІ не просто змінює швидкість написання коду людьми, він змінює всю виробничу систему навколо програмного забезпечення.
Концепція може означати різні речі: набір агентів для кодування та файлів із навичками; швидший CI/CD; кращі системи перевірки; або більше автоматизації навколо доставки програмного забезпечення. Краще сприймати її не як категорію інструментів, а як набір принципів. Програмна фабрика не може бути просто вільним набором підказок, агентів та плагінів. Їй потрібна платформа, яка визначає, як робота рухається системою, як генерується, перевіряється, тестується, відстежується, розгортається та вдосконалюється код, коли щось йде не так.
Інакше все, що ви робите, — це встановлення ще однієї одноразової машини в порожній кімнаті та називання її фабрикою.
Чому це відбувається зараз?
Є кілька сил, які діють одночасно.
Компанії завжди хотіли більше програмного забезпечення, ніж інженери могли виробити. Саме тому існують такі інструменти, як Excel: вони часто заповнюють прогалину для багатьох програм, які багато компаній хотіли б створити.
ШІ також знизив бар’єр для створення коду, і саме на цьому всі зосереджуються. Створення коду тепер стало легшим, хоча не завжди дешевшим чи кращим, про що свідчать багато відомих компаній, які турбуються про свої високі витрати на ШІ. Бар’єр для написання функціонального коду фактично обвалився.
Що ще важливіше, один інженер може генерувати більше коду, ніж кілька років тому. Це змінює вузьке місце: це вже не «Як швидко хтось може це написати?» або навіть, у деяких випадках, «Чи може хтось зрозуміти, як кодувати?» Натомість це стає «Чи варто це писати?»
Що ще важливіше, чи можемо ми насправді створювати кінцеві продукти, які є довговічними та надійними і не просто створюють технічний борг? Чи ми просто випускаємо більше «ШІ-шлаку» швидше, ніж будь-коли? Ось де криється небезпека.
Небезпеки сучасної програмної фабрики
Все це звучить чудово. Зрештою, фабрики зробили виробництво швидшим і послідовнішим.
Вони уможливили будівництво більшої кількості автомобілів та продуктів за менші гроші, що призвело до того, що більше людей могли дозволити собі автомобілі та продукти. Якщо відкинути вплив на довкілля, можна стверджувати, що це було позитивно.
Але, як і в багатьох інженерних речах, завжди є компроміси, і в цьому випадку є нові ризики.
Коли ви збільшуєте випуск однієї людини за допомогою механізмів, цифрових чи інших, ви також збільшуєте кількість помилок, які може зробити як сама людина, так і механізми. Швидкість, з якою код може бути випущений зараз, є промисловим масштабом. Навіть менші організації можуть раптом мати кодові бази, що роздуваються до розмірів кодових баз технологічних компаній десятилічної давнини.
Дані вже свідчать про проблеми. Faros AI виявив, що хоча пропускна здатність завдань на розробника зросла на 33,7%, а швидкість злиття PR — на 16,2%, співвідношення інцидентів до PR зросло на 242,7%, а кількість помилок на розробника — на 54%. Дослідження Google DORA виявило, що більше використання ШІ насправді асоціюється з гіршою стабільністю доставки.
Як частковий керівник відділу даних, мене залучали для вирішення саме таких проблем. Лише за останній рік я працював над двома проєктами, де згенерована ШІ інфраструктура даних з часом повільно трансформувалася.
Через роботу кількох інженерів, які намагалися рухатися швидко, та відсутність стандартів, ці проєкти стали некерованими. Кодові бази зазвичай проходять певний рівень еволюції, але коли різні стилі змішуються, LLM, у свою чергу, починають створювати власні мутації. Кодові бази розвивали п’ять-шість різних стилів протягом місяців — процес, який раніше займав роки. Шар за шаром, інженери повільно переставали розуміти, що саме відбувається.
Цей шаблон нагадує те, що сталося десятиліття тому з інструментами самообслуговування: початковий приріст продуктивності, який маскував подальшу складність.
І саме тому програмна фабрика не може бути лише про швидкість.
Що робить програмну фабрику ефективною
Існує кілька ключових принципів, які слід враховувати при побудові програмної фабрики.
Платформа замість інструментів: Багато команд повільно впроваджують ШІ у свої кодингові робочі процеси на периферії — додаючи агента для перевірки PR або файл навичок у свої репозиторії. Але побудова справжньої програмної фабрики вимагає платформи, а не сукупності інструментів на периферії. Платформа забезпечує єдиний фундамент, де інструменти не розкидані по окремих кутах. Натомість вони активно обмінюються даними, спілкуються між собою та працюють як єдина злагоджена система — стандарти, процеси та сама робота, все взаємопов’язано.
Повторність та відстежуваність: Справжня платформа вимагає можливості повернутися до будь-якого запуску, визначити, що пішло не так, і перезапустити його — саме тому одноразові агенти не створюють фабрику. Система повинна підтримувати взяття серійного номера, його пошук та відстеження того, як саме він призвів до отриманого результату. Ось чому машини станів мають більше сенсу, ніж цикли для робочих процесів ШІ: вони значно полегшують перезапуск процесу та розуміння того, що сталося на кожному кроці.
Безпека та захисні механізми: Фабрики — не безпечні місця. Так само і програмна фабрика. Зі зростанням кількості людей, що розробляють на цих платформах, необхідно вбудовувати кращі захисні механізми та заходи безпеки. Тестування та контроль якості повинні бути винесені на початок процесу — виявлення помилок на найнижчому можливому етапі зменшує вартість їх виправлення та обмежує радіус ураження.
Стандартизація: На корпоративному рівні кожна кодова база має свій власний «смак». Накладання кодового асистента зверху без стандартів призводить до суміші стилів. Стандартизація повинна бути вбудована в процес з самого початку.
Контроль якості: У старих моделях виробництва контроль якості відбувався наприкінці лінії. Продукт був виготовлений, перевірений, виявлені дефекти, і вони виправлялися пізніше. Підхід Toyota був іншим. Якість була вбудована в сам процес — працівники повинні були зупиняти лінію, коли щось було не так. Метою було не виявлення дефектів наприкінці, а запобігання їх просуванню далі в процесі.
Те саме стосується і програмної фабрики. Контроль якості повинен бути інтегрований у весь процес, починаючи з написання технічного завдання. Це означає інтеграцію статичного аналізу коду, який виявляє очевидні помилки, та надання шаблонів для LLM, щоб вони знали структуру, якої повинен дотримуватися код. Без цього вузьким місцем стає фінальна перевірка — або команди просто випускають більше «ШІ-шлаку».
Швидкість без якості — це не продуктивність
Підвищення швидкості випуску вашого коду не є справжньою продуктивністю, якщо подальші проблеми не керовані. Компанія не стає більш продуктивною, тому що випускає мільйони автомобілів, тільки щоб вони розвалилися через 100 миль. Вона також не стає більш продуктивною, якщо лише створює нескінченний потік концепцій, які ніколи не потрапляють у виробництво.
Справжня продуктивність — це коли програмна фабрика перетворює ефемерні токени на довговічні результати. Легко говорити про рядки коду та про те, наскільки швидше рухається ваша команда.
Переможе не та програмна фабрика, яка генерує найбільше коду. Переможе та, яка генерує найменше дефектів на наступних етапах.
Як захиститися (Порада CryptoDom): Усвідомте, що швидкість генерації коду за допомогою ШІ може призвести до появи нових, неочевидних помилок. Перед впровадженням таких інструментів у критично важливі системи, ретельно протестуйте згенерований код та переконайтеся в наявності чітких процесів контролю якості та стандартизації.
Подробиці можна знайти на сайті: venturebeat.com