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

Питання взагалі не в тому, чи можна створити вдалу локальну автоматизацію — скоріше за все, можна. Питання в системній стратегії великих вендорів. Зараз їхній головний наратив і прихована бізнес-модель — перекласти величезні витрати на R&D на самі інженерні команди. Вони збирають телеметрію, аналізують ринкові патерни, виділяють робочі інженерні знахідки (ті самі локальні реалізації умовних фільтрів Калмана чи специфічних гардрейлів), розмивають авторство, а потім запаковують це в наступну версію свого комерційного продукту і продають ринку знову.

Від правильної постановки проблеми залежить те, як саме команди будуть проєктувати рішення. Можна просто повторювати євангелістське «побалуйте/донавчіть агента», але без побудови інших системних шарів контролю це ніяк не наблизить команду до передбачуваного результату.

А якщо розгорнути картину повністю, то з’ясується інша річ: команда, яка самостійно побудувала такий ефективний локальний фільтр контролю для агентської розробки, перебалансувала під нього свій SDLC і змогла не просто прискорити написання тексту, а вийти на якісно новий рівень передбачуваного делівері — фактично тримає в руках інтелектуальну власність (IP), реальна ринкова вартість якої в епоху Software 2.0 вимірюється мільярдами. І віддавати її вендорам за ціною місячної підписки на ліцензії — як мінімум, непрагматично.

Додатковий момент: у цій площині є ще одна серйозна проблема — непрозорість наративу.

Щоб інженерні команди вирішували правильні проблеми, їм треба чесно пояснити, що саме їх просять будувати. Не «додайте ще агента, який перевіряє агента», а «ми поки не маємо завершеного control layer для agentic coding, тому вам доведеться експериментально шукати локальні моделі контролю, верифікації, ownership, stop conditions і ROI».

Це вже зовсім інша постановка задачі.

Бо якщо команда десь локально побудує справді вдалу реалізацію такого контролю — умовний «Kalman filter» для agentic coding loop у конкретному домені — це не просто «налаштували агента». Це реальна інженерна інновація. І тоді логічно виникає питання авторства, винагороди й того, хто саме отримує економічну користь від цієї знахідки.

А зараз усе часто виглядає набагато менш прозоро. Ринку кажуть: будуйте agents, hooks, rules, skills, harness, dashboards, AI-review loops. Команди експериментують власним бюджетом, власними ризиками, власними production failures і власним часом. Вендор при цьому отримує revenue тут і зараз, а також величезний масив ринкового feedback: які патерни працюють, де loops ламаються, які guardrails потрібні, які метрики корисні, які сценарії дають хоча б натяк на ROI.

І якщо десь у цьому хаосі з’явиться справді робочий патерн, його можна буде швидко розпізнати, узагальнити, запакувати в наступну версію продукту й продати назад тому самому ринку вже як «новий breakthrough».

Тобто проблема не лише технічна. Вона ще й економічна: хто платить за R&D нового SDLC навколо AI, хто несе ризики, хто генерує практичне знання, хто втрачає авторство в цьому процесі, і хто потім монетизує результат.

І сьгодні це чиста схема — вам збитки, нам прибутки. Тому приватна порада — якщо щось будуєте, то будуйте навколо власних моделей, тих самих опенсорс наприклад. Бо якщо у вас щось вийде — в більшості випадків ви створили фактично інженерну інновацію. І маєте оцінити іі реальну вартість і думати над тим — як цю реалізацію запатентувати. Якщо будете будувати навколо моделей вендора — то ваша реалізація попаде швидко в наступний реліз вендора і все

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

Якщо ринку не потрібно ще 10 000 todo-apps, календарів, органайзерів, thin wrappers і чергових «Uber for X», то здатність швидше їх генерувати не є революцією. Це просто прискорення supply-side шуму. І якщо всі конкуренти отримали приблизно той самий інструмент, то індивідуальна перевага теж швидко розмивається. Усі пишуть швидше, але користувач не починає хотіти в 10 разів більше софту.

Саме тому мене бентежить не лише технічна частина, а й ринковий наратив. Коли не видно сильного сигналу з боку user value, ринок починає переносити увагу в іншу площину: «просто додайте агентів», «закрийте loop», «побудуйте harness», «додайте reviewer-agent», «додайте ще один шар контролю». Тобто замість чесної розмови про попит, ROI і повний SDLC-cost нам продають наступний рівень складності.

І тут проблема не в тому, що agents, hooks, evals чи guardrails непотрібні. Частина з них справді потрібна. Проблема в тому, що поки немає зрілої теорії й практики, яка б надійно закривала головну діру: як стабільно контролювати стохастичну систему, що генерує зміни в коді, архітектурі й поведінці продукту. У нас немає умовного «Kalman filter» для agentic coding loops, який дозволяє надійно оцінювати реальний стан системи через шумні сигнали від тестів, review-агентів, lint, runtime, telemetry і людського feedback.

Тому «додайте ще одного агента, який перевіряє першого агента» — це не автоматично control system. Це може бути ще один стохастичний шар, який створює відчуття контролю, але не гарантує ні correctness, ні maintainability, ні ROI.

І ось тут питання до вендорів та ринку: ви продаєте готову productivity-систему чи фактично запрошуєте клієнтів самим добудовувати відсутній control layer за власний бюджет, на власних командах і з власними ризиками?

Бо якщо відповідь друга, то це вже зовсім інша економіка. Частина R&D, перебудови процесів, експериментів, помилок, інтеграцій і пошуку робочих патернів перекладається на покупця. Вендор отримує revenue тут і зараз, а ринок паралельно фінансує великий експеримент: які agentic workflows виживуть, де вони ламаються, які guardrails потрібні, які метрики працюють, а які тільки красиво виглядають у презентаціях.

І якщо робочі патерни десь намацаються, їх потім можна буде запакувати в наступну версію продукту й продати назад тому самому ринку.

Тому так, головне питання справді «а навіщо?». Не «чи може AI писати код швидше», а чи перетворюється ця швидкість на попит, revenue, retention, user value і стійку delivery-продуктивність. Поки що дані значно краще підтримують обережну інтерпретацію: ми навчились швидше виробляти софт, але не довели, що навчились швидше створювати потрібні людям продукти.

Тобто Ші стає тоді не способом зекономити. А способом реструктуризації витрат між різними кроками SDLC і способом відкласти частину витрат на майбутнє але ціною або жорстокого обмеження його використання в цьому майбутньому або з прийняттям в цьому майбутньому додаткових витрат і ризиків.

Так, це сильніший сценарій: senior engineer / architect + AI замість частини junior/middle capacity.

І тут я частково згоден. І писав — це працює для МВП і грінфілд. Якщо є сильний інженер, добре описана архітектура, обмежений scope і зрозумілий домен, AI справді може замінити частину роботи, яку раніше робили менш досвідчені розробники.

Але bottleneck тоді не зникає. Він просто переїжджає в senior capacity.

Раніше senior не тільки «дивився і направляв». Команда з 5 людей давала паралельну когнітивну потужність: хтось писав, хтось рев’юїв, хтось тестував, хтось пам’ятав контекст, хтось потім підтримував свій шматок. Junior/middle теж поступово набирав ownership. AI цього ownership не бере.

Якщо тепер один senior має задавати архітектуру, писати правила для AI, перевіряти результат, ловити fake correctness, тримати контекст, приймати рішення, фіксити інциденти і відповідати за production — він дуже швидко стає єдиною критичною ланкою системи.

«AI швидко перепише» теж не безкоштовно. Так, токени дешеві. Але кожна невдала ітерація все одно спалює увагу senior-а: треба зрозуміти, чому не те, чи не зламалась архітектура, чи не з’явились hidden mocks, fake tests, зайві абстракції, security issues, regression risk. Ціна помилки низька тільки тоді, коли помилка локальна і швидко виявляється. У складному продукті частина помилок вилізає не в момент генерації, а через тижні або місяці.

Тому я не заперечую модель «senior + AI». Вона реальна. Але це не доказ, що AI автоматично робить повний SDLC дешевшим. Це доказ, що частину coding capacity можна замінити генерацією, якщо поруч є сильний human owner.

А далі питання економіки: чи не стане цей human owner новим bottleneck? Чи не виросте bus factor? Чи не переїде економія з зарплат у review, QA, documentation, support, incidents і майбутній TCO? І чи не повернемося ми в результаті до тієї самої потреби в команді, тільки з іншими ролями навколо AI?

І де тоді РОІ і в чому був сенс? Та сама команда, в найкращому сценаріі ті самі витрати в місяць+токени, значно більше ризиків операційних для команди, значно більш складна інфраструктура і стек команди, частина інженерних рішень віддана назовні, більше точок відмови

І тоді виникає наступне цікаве питання: а що, якщо сам наратив «AI зробить розробку дешевшою, а класичні розробники стануть менш потрібними» — хибний або принаймні сильно перебільшений?

Що, якщо простого рішення так і не буде знайдено? Що, якщо ми не прийдемо до моделі, де один розробник з AI стабільно замінює команду з п’яти людей у серйозному довгоживучому продукті? Можливо, реальна картина буде значно менш романтичною: у класичну команду просто додасться новий технологічний шар, який теж треба підтримувати.

Agents, prompts, skills, rules, hooks, RAG, evals, sandboxes, dashboards, policy gates, provenance, AI-review loops — усе це не безкоштовна магія. Це нові артефакти, нові процеси, нові навички, нова інфраструктура і нові точки відмови. Їх треба проєктувати, оновлювати, рев’юїти, документувати, моніторити й інтегрувати в SDLC. Тобто ми можемо не прибрати складність, а просто додати ще один складний шар поверх старого.

При цьому частину наших інженерних і бізнес-процесів ми точно віддаємо назовні: контекст, патерни роботи, частину логіки прийняття рішень, іноді навіть фрагменти продуктової або архітектурної моделі. Ми також збільшуємо залежність від vendor stack, pricing, policy changes, model behavior і якості чужої інфраструктури.

А головне — на рівні команди тепер треба дуже тонко балансувати: що можна довірити AI, що не можна, де потрібна людина, де потрібен stop condition, де автоматизація вже створює більше ризику, ніж користі. І помилка в цьому балансі сьогодні може згенерувати непропорційні витрати завтра: у review, QA, support, incidents, security, compliance, debugging, документації та майбутньому TCO.

Тобто можлива й така інтерпретація: AI не обов’язково зменшує загальну вартість розробки серйозного продукту. Він може просто змінити структуру витрат та навіть збільшити іх. А також збільшити ризики і додати нових точок відмови. Менше ручного написання коду, але більше контролю, інтеграції, перевірки, ownership, документації, tooling і операційного ризику.

І тоді головна помилка ринку — рахувати економію на рівні «мінус чотири розробники», не рахуючи весь новий шар витрат, який потрібен, щоб ця схема не зламала продукт через рік.

А тоді — де ROI і який сенс в цьому?

TL;DR: NBER показує незручну картину: AI coding tools розганяють code output у 6–9 разів, іноді до 17 разів, але приріст релізного output стискається приблизно до 30%, а marketplace usage не показує пропорційного зростання. Тобто ми точно бачимо вибух генерації коду, але не бачимо такого самого вибуху delivery productivity або user value. Саме це я називаю Subprime Code Crisis.

Частково згоден.

Для MVP, proof-of-concept, greenfield-сценаріїв або невеликих продуктів, де якість коду ще не критична, сценарій «1 розробник + AI замість 5» справді може працювати. Там головна ціль — швидко перевірити гіпотезу, а не побудувати систему, яку хтось буде підтримувати роками.

І механічно скоротити команду теж можна. У вакуумі це виглядає привабливо: було 5 розробників, залишився 1 з AI, payroll менший, фічі потроху додаються.

Але тут є проблема, яку AI-кодогенератори поки не вирішили. Вони не стільки вирішили задачу «написання коду» як інженерної діяльності, скільки радикально здешевили написання тексту коду. Це різні речі.

Створити елегантне інженерне рішення, правильно розбити систему на модулі, не зламати архітектурні межі, не наростити майбутній TCO, зберегти ownership і підтримуваність — це не те саме, що швидко згенерувати багато рядків. Модель може згенерувати синтаксично правильний код, але це ще не означає, що вона створила хороше інженерне рішення.

І тут виникає bottleneck, який навряд чи просто вирішить нова модель: review і ownership.

Один розробник не може якісно рев’юїти сам себе. LLM-reviewer теж не може бути фінальним авторитетом для серйозної системи, бо має ті самі класи сліпих зон. Добре, залишаємо двох розробників. Але якщо вони обидва з AI починають генерувати в рази більше коду, вони дуже швидко зашиються рев’юїти цей обсяг. Якщо не будуть рев’юїти — кодова база почне надуватися низькоякісним кодом.

Але review — тільки перший шар. Більший change surface означає більше тестування, більше регресійних ризиків, більше QA-навантаження, більше документації, більше підтримки. Якщо це серйозний продукт, а не одноразовий MVP, довгострокове роздування кодової бази почне збільшувати Run-cost: підтримку, інциденти, debugging, onboarding, документацію, архітектурний контроль.

І в якийсь момент production incident уже не вирішиться простим «згенеруємо ще один патч поверх існуючого коду». Хтось має руками залізти в систему, зрозуміти, що там відбувалося останні 1–2 роки, які рішення були прийняті, де саме зламалася логіка, і як це виправити без нового шару slop поверх старого slop. А якщо весь цей час код генерувався на швидкості в 6–9 разів більшій за людську, то вартість такого ручного розбору може бути дуже болючою.

Щоб не прийти в цю точку, треба робити те, що AI сам по собі не закриває: якісне review, актуальну технічну документацію, architecture decision records, правила модульності, ownership, тестову стратегію, контроль blast radius, stop conditions. Але тоді ми повертаємося до першого питання: а може, не треба було звільняти цих чотирьох розробників?

Можливо, у реальній команді один тепер більше генерує, а інші мають концентруватися на review, архітектурі, тестах, документації, refactoring, production-readiness і контролі якості. Тобто економія від скорочення dev-команди починає переїжджати в інші витрати.

Тому я не заперечую, що AI змінює ринок. Змінює. Особливо в greenfield, MVP, proof-of-concept і низькоризикових сценаріях. Але як тільки ми переходимо до серйозного довгоживучого продукту, команда, швидше за все, починає використовувати цей інструмент набагато обережніше, а операційні витрати поступово повертаються ближче до звичних показників, а може і зростають, бо тепер треба підтримувати додаткові практики, документацію і інфраструктуру — для ШІ.

Бо ownership, review і здатність людини полагодити систему руками залишаються важливими. І, можливо, їх просто неможливо прискорити так само, як генерацію тексту коду.

Тому головне питання не «чи можна скоротити команду». Можна. Питання в тому, чи не переїде зекономлений dev-cost у review cost, QA cost, documentation cost, support cost, incident cost і майбутній TCO.

І саме тому я кажу: AI може дати економію в окремих сценаріях, але він не дає автоматичної економії на рівні повного SDLC. Без перебудови операційної моделі ми не зменшуємо вартість розробки, а просто переносимо витрати в інше місце або в майбутнє.

Якщо коротко, звіт показує дуже просту картину.

Маса коду, яка тепер залітає в репозиторії, виросла в 6–9 разів, а в окремих сценаріях — до 17 разів. Але на виході з delivery pipeline приріст релізного output стискається приблизно до 30%. А на рівні marketplace usage, тобто реакції кінцевого користувача, пропорційного зростання взагалі не видно.

Тому тут є сумнів навіть щодо «індивідуальної продуктивності». Бо що саме ми називаємо продуктивністю розробника? Кількість згенерованого тексту? Кількість змінених рядків? Кількість PR? Чи кількість прийнятих, перевірених, стабільних і корисних змін, які реально дійшли до користувача?

Маса сирого згенерованого коду сама по собі не є продуктивністю. Це може бути корисна робота. А може бути churn, переписування, зайві абстракції, fake tests, hidden mocks, невдалі PR, code slop або просто зміни, які потім pipeline відкидає.

Навіть якщо припустити, що значна частина цього коду корисна, наступна метрика показує: до кінця труби долітає набагато менше. Значить, pipeline або не встигає це поглинати, або частину змін відсікає, бо вони не проходять review, QA, integration, architecture чи product validation.

І agentic coding цю картину принципово не змінив. Він ще сильніше розігнав upstream-генерацію, але не дав пропорційного ефекту на delivery output і user value.

Можна сказати: «ок, можливо в цих 30% тепер більше фічей». Але тоді де реакція користувача? Де сплеск usage, downloads, ratings, adoption? Його немає.

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

Тобто під сумнівом
— Індивідуальна продуктивність
— Ціна якою купується приріст до 30%
— Чи є в кінці збільшення велью? Схоже сьогодні нема, а отже і цей приріст 30% може дорівнювати 0 якісно.

А що точно є — спалюється все більше токенів. Від появи перших Ші асистентів і дотепер цей показник виріс в 7-8 разів з досі нульовим велью.

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

Та що ж це таке? Можу ще багато накидати де чомусь саме цей анонімний акаунт проти тези «Ші-код генератори не є лінійним прискорювачем SDLC» сперечався до останнього 4 місяці тому. Наприклад
Або
. Або

Полускали агенти ці проблеми як горішки?

Що насправді відбувається.

AI-кодогенератори як продукт містять у собі стохастичне ядро. Щоб така система була стабільно корисною, навколо неї потрібен керуючий шар: обмеження, перевірки, метрики, stop conditions, ownership, fallback paths, provenance, review policy, QA strategy.

Бо чорна стохастична скринька не може стабільно працювати у відкритому контурі, якщо її просто підключити до репозиторію й сказати команді: «тепер ви швидші».

І тут головна проблема ринку: вендори продають дуже сильний генератор коду, але не завершений delivery-productivity продукт рівня повного SDLC. Тобто не систему, де вже доказово показано: ось як це інтегрується в review, QA, architecture, support, ownership, production-readiness і дає вимірюваний ROI.

Натомість клієнту поступово пропонують добудовувати навколо цього продукту відсутній control layer: agents, hooks, skills, rules, pipelines, harness, reviewers, permissions, dashboards, orchestration. І кожен наступний шар подається як новий крок до «справжньої» AI-продуктивності. Ніхто не пояснює повної картини і не показує повного чеку на цю трансформацію. Замість цього через мережу сейлз-петрушок під виглядом інженерів-блогерів і всяких лідів розробки — вкидують в наратив ці окремі елементи — ну от ще це добудуйте і будете щасливі.

У результаті значна частина витрат на інтеграцію, перебудову команд, зміну процесів, внутрішнє R&D, рев’ю, QA, production failures і пошук робочої операційної моделі лягає на плечі покупця. Ризики теж.

Вендор отримує revenue тут і зараз, поступово веде клієнта у vendor lock-in, а ринок фактично фінансує масовий експеримент: які патерни агентської розробки виживають, де вони ламаються, що реально дає ROI, які guardrails потрібні, які метрики працюють, які команди здатні це поглинути.

І якщо на ринку з’явиться робочий патерн, його можна буде швидко розпізнати, запакувати, заскейлити й продати назад як наступну версію продукту. Ну а ті хто з цього зоопарку експериментів не виживе? За токени то все одно заплатять — хоч якась з них користь.

З бізнесової точки зору це дуже сильна стратегія. Але з точки зору покупця питання просте: чи ви купуєте готовий productivity продукт, чи фактично фінансуєте доведення незавершеного інструмента до production-grade SDLC-моделі власним бюджетом, своїми командами й своїми ризиками?

І на цю ж тему розмова трохи під іншим кутом — як нам згодовують по частинам теорію контролю і чому це все залишається збитковим якщо ви ведетесь сліпо за наративом(вже побігли будувати агентьскі петлі? Ні? Це ж тренд сезону) — бо вам не дали завершений контур продукту досі і ви все ще будуєте стохастичні системи з відкритим контуром — тобто на рівні команди це не запрацює ефективно, з роі, ні сьогодні ні завтра. Ганяйте токени далі, кадило крутиться баблішко мутиться як то кажуть...це ж так захопливо www.reddit.com/...​architecture/s/nm7UbIt56w

Кому цікаво — те саме обговорюємо на реддіт в архітектурному комьюніті — www.reddit.com/...​architecture/s/xTjjVjdUFO . Більшість проблему бачать і в принципі згодні з тим що без суттєвих додаткових інвестицій в перебудову команд(а це бюджети які можуть бути скажемо в разів 10 більше ніж сама вартість ліцензій або токенів) — цей тек це те що генерую команді збитки, і нічого не дає натомість

Все саме так — ніяка модель не буде срібною кулею. І задачка «перебалансувати сдлс щоб ШІ генерований код не вбив проект, а навпаки — приніс користь» — це системна задачка. Не для розробника або тімліда — в них не буде стільки бюджету і банально «прав» в середині більш меньш великої організації. І саме тому — важливо як на мене цю проблему і артикулювати і обговорювати. Бо на рівні прописання скілів, промптів, створенні своїх агентьских воркфлоу, індивідуальної контрибюціі — вона не вирішується. А щоб взагалі хтось щось почав вирішувати(власники, вендори) — про це треба говорити. Тому що будь який пошук рішення починається з правильного формулювання проблеми. Поки проблеми не видно і більшість власників вважають що ШІ код генератори це просто прискорювачі роботи по типу «нової ІДЕ» — ніхто нічого не буде перебудовувати, бо це великий бюджет. Ваша модель мені здається робочою — але накидаю питань трохи, пізніше.

О тепер по суті, покручу вашу модель деякий час та повернусь. Але ж ми вже розуміємо що така модель, щоб її імплементувати — це взагалі не рівень прийняття рішень розробника, або навіть команди? І що о це все — це дуже не малий бюджет який «приходить» в проект в вигляді додаткових витрат. Тобто купити всім ліцензіі і роздати клод — це те що вашу команду за 2-3 роки вбʼє . А щоб не вбило, а навпаки, утилізувати ефективність ШІ максимально — треба будувати нову операціну модель і треба буде влити не мало додаткових інвестицій в це, можливо значно більше ніж загальна вартість ліцензій

Ще про це

«Ребята, простой промпт в ChatGPT не работает, стройте свои пайплайны, создавайте свой харнесс, вот как это делаем мы — смотрите и пробуйте свое»

Як благородно — продати ринку інструмент який не приносить роі, а потім рухати наратив таким чином щоб підштовхувати користувача витрачати все більше і більше і намагатися вирішувати за свій власний рахунок проблеми які цей же продукт створив. Більше того — в ситуаціі коли сам вендор навіть не здатний доказово показати повний процес, який працює і має роі. І сам вендор цього роі не має. Тобто продається — не продукт сьогодні, а рішення рівня ПоС. А може правильно було б — спочатку побудувати реальний продукт з доказовим роі(рівня сдлс) — а потім продавати? Закінчити спочатку інженерну роботу?

Ну от якби ви читали статтю, а ще краще — подивилися оригінальний звіт, то побачили б, що поява agentic coding проблему розбалансування SDLC не вирішила. Навпаки: у звіті видно, що з переходом до агентських інструментів code output росте ще сильніше, а ефект на releases і usage все одно різко затухає.

Тобто зміна наративу виглядає так: спочатку «AI просто допоможе писати код швидше», потім «агенти самі напишуть код і заллють PR у репозиторій», тепер «треба ще будувати harness, pipelines і guardrails навколо агента». І кожен наступний крок поки що більше розганяє upstream-генерацію і збільшую збитки команд, ніж вирішує проблему downstream-контролю.

Саме про це стаття: без нового контрольного контуру SDLC agentic coding не стає лінійним прискорювачем delivery. Він просто створює більше коду, який усе одно треба рев’юїти, тестувати, інтегрувати, підтримувати й доводити до реального value.

А доказового ROI або пропорційного зростання user value у цих даних поки не видно. Якщо ви хочете й далі сліпо йти за цим наративом і витрачати гроші без зрозумілого ROI — я не проти, гроші ваші. Але тоді не треба називати це аргументованою дискусією про delivery-продуктивність.

З анонімними заходами в стилі «slop / не дочитав / псевдонаука» я зазвичай не дискутую. Це не аргументація, а шум.

Але тут цікаве інше: за 4 місяці дуже змінилася позиція саме вашої когорти коментаторів. У першій дискусії теза про те, що SDLC розбалансовується від AI-кодогенерації, викликала шалене заперечення. Тоді звучало: все прискорилось, проблеми немає, треба просто краще користуватися інструментами, прописати скіли, промпти і т.п.

А тепер раптом виявляється, що «простий prompt не працює», треба будувати pipelines, harness, guardrails і власний процес навколо моделі.

Так це і є моя теза.

Те, що ви перевзуваєтесь разом із вендорами, мене не дуже дивує. Тренд змінюється швидко: ще вчора продавали історію про пряме заміщення людей і майже автоматичне здешевлення розробки(і ви в це вірили і цю маячню поширювали), а сьогодні вже звучить значно обережніше: будуйте контрольні контури, рахуйте ROI, не очікуйте магії від простого prompt.

Якщо вендори вже кажуть: «не просто генеруйте код, а будуйте harness, pipelines і guardrails», то це означає просту річ: сама AI-кодогенерація не є лінійним прискорювачем delivery. Її треба вбудовувати в новий SDLC: з новими DoD, review policy, QA strategy, ownership, stop conditions, метриками й економікою підтримки.

І приємно розуміти що ви тепер не заперечуєте що від Ші код генераторів як є із коробки, нема роі, бо Альтман же так сказав — то тепер і вам можна. А до того — сперечались з цією тезою теж

Тут, здається, ми знову говоримо про різні рівні проблеми.

T&M — це не модель контролю SDLC. Це billing-модель. Вона може пояснити, хто заплатить за додаткові години, але не відповідає на питання, як саме команда має стабільно поглинати кратно більший change surface.

«Дивитися індивідуально» теж не є операційною моделлю. Це порада рівня «треба робити добре». Але велика вибірка з 100 000+ розробників якраз показує, що сама по собі наявність досвідчених команд, інструментів і практик не конвертує AI-code output пропорційно ні в releases, ні в usage.

Уявімо просту команду: 6 розробників, техлід, 2 QA, PM і product. Команда агресивно переходить на AI-кодогенерацію. Code output росте кратно. Що саме ви змінюєте в SDLC?

Які нові roles?
Який review policy?
Який DoD?
Які guardrails?
Які stop conditions?
Як рахуєте review load, escaped defects, support load, token cost, cognitive load і ROI?
Коли зупиняєте генерацію?
Хто має ownership за AI-generated code через 6 місяців?

Бо якщо відповідь «по ситуації», то це не контрольний контур. Це ручне гасіння пожежі. А саме про це і стаття: AI прискорює upstream-генерацію, але без нової операційної моделі решта SDLC починає розбалансовуватися.

А і щодо автоматизаціі бізнес процесів. ЛЛМ, як на мене тут може допомогти. Це окремий кейс. Але в таких випадках часто проблема — це взагалі зрозуміти як люди реально працюють. Бо частина бізнес процесів, навіть в дуже гарно забюрократизованих корпораціях — все одно сидить в голові і «ходить по кабінетах». Я обдумував ідею ЛЛМ як скаут. Тобто роздаємо всім чат асистента, але не від вендора, а будуємо свого. Під кожну роль в компаніі вбудовуємо в нього корисних агентів, скажемо для рекрутингу, щоб допомагало з конкретними точковими кейсами. Люди починають використовувати. Але там є і звичайний режим чату — тобто люди будуть використовувати його і для вирішення інших питань. Це все декілька місяців складається в масивний лог. Всі дії і всі запити. Потім харвестимо з цього массива — корисні патерни. Класифікуємо на ті, які можно покрити детермінованим кодом, звичайною автоматизацією і такі — де треба ЛЛМ. І запускаємо безперервний цикл баесовоі гри, де мета, використовувати ЛЛМ як розвідника, але фінальна ціль — взагалі від ЛЛМ відмовитись де тільки можливо і перейти на звичайну автоматизацію або црм-воркфлоус.