
Неочікувані витрати на ШІ-інструменти
Команда з 50 розробників, що працює в агентному темпі, цього року витратить приблизно 900 000 доларів на ШІ та інструменти розробки. Хоча більшість керівників інженерних відділів очікували витрат на обчислювальні ресурси, вони не передбачали, де саме приховані інші значні витрати. Головною причиною є проблема часу.
Моделі нового покоління тарифікують читання контексту за змінною шкалою, а стандартні конвеєри валідації займають більше часу, ніж дозволяє вікно знижок. До того моменту, як повертається інформація про збій, агент повторно читає всю кодову базу за повною ціною, включаючи вихідні дані попередньої спроби та логи збірки. Кожна наступна спроба коштує дорожче за попередню.
Нові метрики для нової ери
Розуміння того, що саме спричиняє такі витрати, вимагає іншого підходу до вимірювання. Метрики, які більшість команд використовують для оцінки стану розробки, були розроблені з припущенням, що роботу виконує розробник. Метрики DORA, такі як частота розгортання та рівень відмов змін, є корисними сигналами, але вони не були створені для обліку того, що відбувається, коли агенти керують обсягом роботи. Вони показують, як швидко ви рухаєтеся, а не скільки коштує кожен крок.
Це призвело до фокусування на метриці Cost Per Shipped Change (CPSC) — вартість за відвантажену зміну. CPSC — це загальні витрати на CI та токени ШІ, необхідні для переведення однієї зміни від розробки до продакшену, включаючи всі спроби та повторні спроби у гілках функцій, а також фінальне злиття в основну гілку. CPSC відображає те, чого не показують окремо ціни на ШІ за користувача та рахунки за обчислення: повну економічну вагу кожного циклу, необхідного для відвантаження.
Операційна картина показує, чому ця метрика важлива: команди генерують більше коду, ніж будь-коли, але мають труднощі з його впровадженням у продакшен. Згідно з останнім звітом State of Software Delivery Pulse Report, показник успішності основної гілки становить 76,7%, що означає, що майже кожна четверта спроба злиття коду в продакшен завершується невдачею. Коли збірки все ж таки зазнають невдачі, середній команді потрібно більше години на відновлення.
Економіка розробки з ШІ
Розглянемо економіку з урахуванням витрат на токени ШІ. Для команди з 50 розробників, яка відвантажує приблизно 3000 змін на місяць, за типового показника Merge Efficiency Ratio (MER) — кількості циклів валідації гілки функцій, необхідних до того, як зміна потрапить в основну гілку — кожна відвантажена зміна вимагає близько п'яти загальних запусків CI: чотири у гілках функцій та один в основній гілці.
За нашою моделлю витрат, кожна зміна обходиться приблизно в 13 доларів на вхідні токени (через перезавантаження холодного кешу та роздування контексту), 9 доларів на вихідні токени (агенти переписують код після збоїв CI) та 3 долари на обчислення CI. Це становить приблизно 25 доларів за відвантажену зміну. Для 3000 змін це 75 000 доларів на місяць, або 900 000 доларів на рік. Фактичні витрати можуть відрізнятися залежно від моделі, розміру контексту, поведінки кешу та частоти повторних спроб, але закономірність зберігається: при обсягах, керованих ШІ, повільні цикли зворотного зв'язку споживають значну частину бюджету на розробку. Для більших кодових баз, що вимагають 500 тис. вхідних токенів або більше, ця ж закономірність перевищує 1,5 мільйона доларів.
Найдорожче не виявлення збоїв, а їхнє виявлення занадто пізно.
Рішення: Оптимізація валідації
Команди, які успішно вирішують цю проблему, переносять валідацію на ранні етапи, у внутрішній цикл, до відправлення коду. Це дозволяє CI виконувати роботу, для якої він був створений: відтворювані середовища, інтеграційні тести, фінальний шлюз перед відвантаженням коду. Інструменти, такі як Chunk sidecars, створені для цього. Вони запускають скорочений набір перевірок у середовищі агента менш ніж за 30 секунд, виявляючи збої, поки кеш контексту теплий, а виправлення дешеве. У нашому тестуванні вихідні дані мікрозбірки були приблизно в 5 разів ефективнішими за токенами, ніж стандартні логи CI, оскільки вони повертають сфокусований контекст збою, а не повний вихідний потік конвеєра.
Команди, які усувають цей розрив, не лише зменшують свої поточні рахунки. Вони будують інфраструктуру доставки, яка витримає зростаючий темп агентної розробки.
Реклама · cv-finder.com
Резюме розробника, яке читають до кінця
Подивіться приклад CV Software Engineer і зберіть своє за його структурою.
Що це означає для розробників
Розробникам необхідно усвідомити, що традиційні метрики не відображають повну вартість їхніх циклів розробки в умовах ШІ-керованих процесів. Важливо переносити валідацію на ранні етапи розробки, щоб уникнути значних витрат, пов'язаних з повторним читанням коду та затримками у виявленні збоїв, що може призвести до значної економії бюджету.
Ключові факти
-
Команда з 50 розробників може витратити близько $900 000 на ШІ та інструменти розробки за рік через приховані витрати.
-
Основною причиною високих витрат є проблема часу: стандартні конвеєри валідації перевищують вікно знижок, змушуючи агентів повторно читати код за повною ціною.
-
Традиційні метрики, такі як DORA, не враховують витрати, коли агенти керують обсягом роботи, що призвело до розробки метрики Cost Per Shipped Change (CPSC).
-
CPSC вимірює загальні витрати на CI та токени ШІ для переведення однієї зміни в продакшен, включаючи всі спроби та повторні спроби.
-
Лише 76.7% спроб злиття коду в основну гілку є успішними, а відновлення після збою займає понад годину для середньої команди.
Додайте Voydevich.com у бажані джерела Google, щоб частіше бачити наші новини в пошуку.
Джерело
DevOps.comRob Zuber
The Anatomy of a $900,000 Validation Bill28 липня 2026 · оновлено 28 липня 2026
Реклама · cv-finder.com
Резюме розробника, яке читають до кінця
Подивіться приклад CV Software Engineer і зберіть своє за його структурою.
Попередні статті

Amazon інвестує в Lean для підвищення безпеки та надійності ШІ-агентів
Amazon надає значну фінансову підтримку команді, що стоїть за мовою програмування Lean, з метою посилення безпеки та надійності ШІ-агентів через формальну верифікацію.

Від перфокарт до об'єктно-орієнтованого програмування: еволюція підходів
Автор ділиться своїм шляхом від FORTRAN на IBM 360 до розуміння переваг об'єктно-орієнтованого програмування (ООП) для сучасних складних проєктів.

Основи ООП та їх застосування у розробці 2D ігрового рушія
Матеріал розкриває три ключові принципи об'єктно-орієнтованого програмування — успадкування, поліморфізм та інкапсуляцію — та пропонує практичне завдання з їх застосування у створенні рудиментарного 2D ігрового рушія.
Наступні статті

Від авіаційної безпеки до досліджень ШІ: історія Камани Парведж Мішу
Камана Парведж Мішу, колишня інспекторка авіаційної безпеки, змінила кар'єру на інженерні дослідження завдяки освіті в Університеті Трайн, зосередившись на ШІ та оптимізації систем.

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

Еволюція програмування ПЛК для сучасної автоматизації
Програмовані логічні контролери (ПЛК) пройшли шлях від простих апаратних систем до інтегрованих компонентів кіберфізичних платформ, поєднуючи детерміністичне управління з можливостями сучасних ІТ-технологій.