Швидший код, та сама доставка? Що AI насправді робить із темпом розробки софту

Зміна не доходить до користувачів, коли код написано. Вона доходить до них, коли хтось зрозумів проблему, написав код, пройшов рев’ю, прогнав його через CI, виправив те, що зламалося, задеплоїв і спостерігав за ним у продакшні. AI стиснув один із цих кроків колосально. Решта зрушили значно менше.

Це закон Амдала, застосований до команд: якщо написання коду було третиною lead time, а тепер займає десяту частину від колишнього, увесь конвеєр прискорюється набагато менше, ніж у десять разів. Решта lead time нікуди не поділася, і тепер це більша частина того, що залишилося. Прискорення одного кроку — це не прискорення доставки.

Ніщо з цього не означає, що зміна мала. У деяких видах роботи це справжній стрибок:

• Від ідеї до прототипу

  Робочий прототип, на який раніше йшов спринт, тепер може існувати до кінця дня. Команди перевіряють більше ідей, перш ніж зупинитися на одній.

• Механічна робота

  Міграції, шаблонний код, каркаси тестів, API-клієнти та повторюваний рефакторинг — там, де агенти економлять найбільше годин із найменшим ризиком.

• Незнайома територія

  Читання застарілої кодової бази, нового фреймворку чи мови, до якої ви рідко торкаєтеся, більше не означає тиждень розгону до першого корисного коміту.

• Малі команди

  Двоє-троє людей тепер можуть будувати й експлуатувати продукти, для яких колись потрібен був відділ. Це змінює не лише швидкість, а й те, хто може конкурувати.

Коли код стає дешевим у виробництві, усе, що має статися з цим кодом, стає відносно дорожчим. Ми бачимо, як цей патерн повторюється:

• Рев’ю стає чергою. Більше pull request’ів, і більших, потрапляє до тих самих кількох рев’юерів. Їхня увага тепер — дефіцитний ресурс.
• CI виконує більше роботи. Агенти ітерують, запускаючи конвеєр. Швидша ітерація — більше запусків, і більше з них падає дорогою до зеленої збірки.
• Не кожна сесія стає зміною. Деяка робота з AI закінчується комітом, деяка — покинутою гілкою. Обидві коштують часу й грошей, але лише одна потрапляє в release notes.
• Рішення лишаються зі швидкістю людини. Розуміння того, що потрібно клієнту, домовленість про обсяг і відповідальність за наслідки в продакшні не прискорилися у десять разів.

Спокусливо говорити про «AI і розробку софту» як про одну глобальну криву. На практиці прискорення дуже нерівномірне, і причини здебільшого не технічні.

• Ціна глобальна, зарплати — ні. Використання моделей оцінюється однаково всюди, тоді як вартість години інженера сильно різниться між країнами. Той самий рахунок за AI може бути похибкою округлення для однієї команди й серйозною часткою бюджету для іншої.
• Регулювання задає стелю. Банки, охорона здоров’я й публічний сектор впроваджують повільніше, бо спершу йдуть вимоги до розміщення даних, аудиту й погоджень. Їхній темп обмежує управління, а не інструменти.
• Спадкові системи опираються. Greenfield-продукти відчувають прискорення першими. Системи з десятиліттями історії, рідкісними тестами й знаннями, що живуть у головах, виграють, але повільніше й ризикованіше.
• Навички накопичуються. Команди, які навчилися давати агентам добрий контекст, малі завдання й швидкий зворотний зв’язок, отримують із тих самих інструментів набагато більше, ніж команди, що просто їх увімкнули.

Тож глобальна картина — це не стільки «усі стали швидшими», скільки «відстань між швидкими й повільними командами зростає». Цей розрив тепер визначають процес та економіка більше, ніж доступ до моделей.

Коли щось дешевшає, ми зазвичай споживаємо його більше. Софт іде тим самим шляхом. Внутрішні інструменти, які раніше ніхто б не профінансував, тепер будують за вечір. Експерименти, надто дорогі для спроби, стали рутиною. Світ не просто пише той самий софт швидше; він пише значно більше софту.

Це має ціну, що приходить пізніше. Кожен рядок, який потрапляє в реліз, треба переглянути, убезпечити, оновити й урешті-решт зрозуміти комусь, хто його не писав. Темп створення зріс; темп підтримки має встигати за ним, і цей рахунок лише починає надходити.

Якщо написання коду більше не повільна частина, вимірювання того, як швидко пишеться код, мало що каже. Важливі питання стосуються всієї зміни:

1. 1

   Стежте за зміною, а не за інструментом

   Дивіться на шлях від задачі до AI-сесії, коміту, pull request’а, CI та деплою як на одну одиницю роботи.
2. 2

   Рахуйте те, що так і не вийшло

   Сесії без коміту й pull request’и, закриті без злиття, — частина реальної ціни швидкості.
3. 3

   Знайдіть нову чергу

   Якщо рев’ю чи CI — місце, де зміни тепер чекають, саме там наступне покращення, а не в ще одному інструменті для коду.
4. 4

   Тримайте невідоме видимим

   Число з відсутньою ціною — неповне, а не нульове. Чесні прогалини корисніші за впевнені підсумки.

Саме на цьому погляді збудовано Nythrex: вартість кожної зміни від AI-запиту до production, з підставою кожної цифри поруч. Як працює ланцюг.

AI зробив сам акт написання софту швидшим, ніж будь-коли в історії. Чи перетвориться це на швидший прогрес, залежить від усього навколо коду: як команди ухвалюють рішення, рев’юють, тестують, деплоять і платять за роботу. Команди, які бачать увесь конвеєр, а не лише найшвидший його крок, — це ті, чия швидкість справді дійде до їхніх користувачів.