[Переміщення обмежень] Коли код майже безкоштовний, куди поділися обмеження програмної інженерії? Зміни в програмній інженерії в епоху ШІ — Повільне вивчення ШІ 173
Коли код майже безкоштовний, обмеження зміщуються до визначення вимог, інтеграції, верифікації та узгодження
Коли виробництво коду майже безкоштовне, обмеженням у доставці програмного забезпечення стає не “написання коду”, а визначення правильного питання, збирання фрагментів у працюючу цілісність, перевірка, що це дійсно правильний розв’язок, та узгодження в організації. Це повторення Теорії обмежень (Theory of Constraints) у сфері програмування. 40 років тому виробництво вже проходило цей шлях: коли будь-який етап стає дешевшим, обмеження не зникає — воно просто зміщується на наступний найдорожчий етап. Розуміючи це, ви зможете пояснити загальне непорозуміння: AI-інструменти для програмування впроваджено в усій компанії, написання коду явно прискорилося, але швидкість доставки не змінилася.
Один CIO виробничої групи показав мені дані за останні шість місяців. ІТ-команда з 80+ людей повністю перейшла на AI-інструменти для програмування: якщо дивитися лише на вихід коду, середній обсяг комітів та швидкість мерджів зросли більше ніж на 30%. Але бізнес-сторона відчуває інше: мінімальна функція розумного планування виробництва все ще вимагає не менше трьох місяців від ідеї до запуску. Він очікував, що інструменти дадуть подвоєння швидкості, а отримав лише “швидше написання коду”. Його слова були прямі: “Я витратив мільйони на ліцензії — і отримав розробників, які працюють напружено, і бізнес, який стає ще більш нетерплячим.”
Він неправильно визначив місце вузького місця. Його справжнім вузьким місцем було інше: кожна нова функція мусила пройти крізь MES, ERP, системи контролю якості, термінали на виробництві та додаткову систему звітності перед наглядом — інтеграція та налагодження з’їдали більшість термінів; тоді як код, згенерований AI, не мав жодних офіційних етапів прийняття між собою та виробничим середовищем. Навіть якщо код пишеться швидко, це просто черга за вузьким місцем, але не там, де треба. # I. Виробництво: 40 років тому вже знали — вузькі місця міняють місця Щоб зрозуміти сьогодні, спочатку надіньте окуляри, якими виробництво користується вже 40 років. У 1984 році ізраїльський консультант, фізик Еліяhu Голдратт, написав роман «Мета» (The Goal), де розповідав, як директор заводу, що мав стати банкрутом, врятував свій завод. Уся суть книги — одна фраза: вихід будь-якої системи визначається її найвужчим елементом (обмеженням, тобто вузьким місцем). Розширення не-вузьких ділянок не дає ніякого приросту загального виходу; лише розширення самого вузького місця робить всю систему швидшою. Але відразу після того, як ви розширили вузьке місце, воно миттєво зміщується на наступне найвужче місце. Ось і теорія обмежень (Theory of Constraints, TOC).
Після 40 років автоматизації в виробництві історія майже є історією «пересування обмежень». Коли ЧПУ верстати зробили різання дешевшим, обмеження змістилося на заміну оснастки та контроль якості; коли гнучкі виробничі лінії прискорили заміну оснастки, обмеження змістилося на планування виробництва та координацію ланцюга постачання; коли MES зробив планування точнішим, обмеження змістилося на прогнозування попиту та міжзаводське планування. Кожен відрізок, що автоматизувався, відкривав наступний. Автоматизація ніколи не знищує обмеження — вона лише переносить їх на інше місце. Це правило не є виключною привілеєю виробництва. У липні 2026 року у подкасті a16z «Software in the Age of Agents» колишній президент Windows у Microsoft Стівен Сінофскі, використовуючи приклади корпоративного ПЗ, самостійно прийшов до того ж висновку. Його слова: > “The long tail got no shorter. It just got longer in a different way.”
Він навів приклад служби підтримки Amazon: відмова від телефонів і автоматичне відправлення товарів чат-ботом — на перший погляд, це економить персонал, але відразу ж виникає потреба в аналізі кореневих причин: «Як запобігти повторенню цієї проблеми?» — це складніше, ніж відповідати на дзвінки. Те ж саме з відшкодуванням витрат: після автоматичного введення рахунків за допомогою OCR, фінансистам доводиться займатися оптимізацією витрат на командування та динамічним порівнянням цін — робота не зникла, вона просто змістилася з «введення даних» на «аналіз і прийняття рішень». Колишній співробітник Microsoft, партнер a16z, не використовував теорію Голдратта, але прийшов до такого ж висновку, як і виробництво 40 років тому. Один — з цеху, інший — з корпоративного ПЗ: дві незалежні траєкторії ведуть до однієї й тієї ж закономірності.
Але треба додати до цієї закономірності обмеження, щоб її не сприймали як абсолютну істину. Дійсно, деякі обмеження були знищені назавжди: машиністки, оператори телефонних станцій, набірники літер — ці професії не «піднялися» вище, вони повністю зникли. Визначити, чи робота просто зміститься, чи зникне, ключово — чи вивільнена автоматизацією продуктивність породжує новий попит (у економіці це називається парадоксом Джевонса), чи просто зменшує існуючий попит. Більшість робіт навколо корпоративних систем належать до першого: чим швидше рахують бухгалтери, тим більше і детальніших аналізів хоче бачити керівництво. Тож висновок тут не в тому, «скільки робіт можна скоротити за допомогою автоматизації», а в тому, «перенести людей і бюджет з автоматизованого рівня на новий, що з’явився» (довгий хвіст переносу з погляду корпоративного ПЗ — повністю розгорнуто в додатковій статті «Корпоративне ПЗ: липкість»).
Ця справа ближча до програмного забезпечення, ніж ви думаєте. У 2013 році Джин Кім майже без змін переніс історію Голдратта про завод у сферу IT-підтримки, написавши «Проект Фенікс» (The Phoenix Project): як CIO використав теорію обмежень, щоб врятувати від краху IT-відділ, що майже зруйнував всю компанію. Отже, «дивитися на програмне забезпечення через призму виробничих обмежень» — це вже перевірений шлях, а не тимчасова метафора. # 2. Повернення до програмного забезпечення: написання коду стає найдешевшим етапом Три цифри, які чітко пояснюють «наближення вартості виробництва коду до нуля».
- Copilot: GitHub власні дослідження показали, що у файлах із ввімкненим Copilot приблизно 46% коду створено Copilot. Зверніть увагу на формулювання: це відсоток у межах ввімкнених файлів, а не 46% усієї кодової бази GitHub.
- Stripe: Внутрішній саморозроблений кодовий агент “Minions” щотижня створює та об’єднує понад 1 300 PR (раніше — 1 000, показник постійно зростає). Тут важливий деталь, який варто запам’ятати: кожен PR проходить ручний рев’ю перед об’єднанням. Stripe автоматизував “написання”, а “прийняття” залишив людині. Цей момент буде використано в розділі 4.
- NVIDIA: Джен-сен Хуанг публічно заявив, що 100% інженерів NVIDIA використовують AI-інструменти для програмування, такі як Cursor; “працювати без AI” у NVIDIA вже не прийнятно.
Поклавши ці три цифри разом, висновок очевидний: вартість створення однієї рядки коду швидко наближається до нуля. Виникає гострий питання: якщо написання коду майже безкоштовне, чому програмне забезпечення все ще таке дорого, повільне й важке у доставці? Відповідь дає теорія обмежень: ви розширили процес “написання коду”, але обмеження лише змістилися. Куди?
Три: вузли переселилися в чотири місця
На цей раз вузли зосередилися на чотирьох етапах. Кожен з них — те, чого AI не зможе досягти в короткій перспективі.
Перший: визначення правильного питання.
AI може за кілька секунд написати «функцію, про яку ви говорите», але не зможе написати «функцію, яку ви справді потребуєте». Більшість проектів програмного забезпечення провалюються, бо створений продукт нікому не потрібен — на початку не було чітко зрозуміло, яку проблему треба вирішити. Коли виробництво коду стало дешевим, «перетворення невизначеного бізнес-виклику на чіткий, розв’язуваний і вартий розв’язання специфікацію» (problem formulation) стало найрідкіснішою й найдорожчою здатністю. Виробництво це добре знає: якщо технологічний маршрут або інженерні креслення визначені неправильно, навіть найефективніший цех виробить лише велику партію браку.
Другий: інтеграція систем.
AI добре генерує «фрагмент коду», «функцію», «сторінку». Але робоча система — це інтеграція сотень таких фрагментів, які мають обмінюватися даними, обробляти крайові випадки, зберігати консистентність і витримувати винятки. Генерація фрагментів — дешева, але зібрати їх у надійну цілісність — дорого. Ця вартість коріниться в синхронізації організації та архітектури — саме те, чим займаються закон Конвей та топології команд (див. дві попередні статті цієї серії). Повернемося до CIO з виробництва з початку: його час не витрачався на написання коду, а на налагодження взаємодії між MES, ERP, системами контролю якості та звітності.
Третій бар’єр: верифікація. Обсяг коду стрімко зростає, а його надійність — неоднорідна. Хто вирішує: «Це правильно»? Тестування, рев’ю коду, спостережуваність, грейс-релізи — ці роботи з верифікації набирають не менше, а більше ваги. Це найбільш недооцінений бар’єр і найглибший віддзеркалення виробничого досвіду. Про це — окремо в розділі 4.
Четвертий бар’єр: організаційна згідність. Коли в команді з’являються AI-агенти, хто вирішує, що робити? Хто перевіряє? Хто відповідає за результат? Це продовження закону Конвей та теорії топології команд — сама організаційна згідність стає бар’єром. Про це — окремо в 11-й статті серії: коли вузли організації — не лише люди, управління стає ядром конкурентної переваги.
# 4. Найглибший розріз: верифікація, і що саме вчить нас «самодія» ТойотиЗ усіх чотирьох бар’єрів найчастіше неправильно розуміють верифікацію. Багато хто вважає: «Оскільки AI пише швидко, то треба більше тестувати». Це правильна лише наполовину. Щоб зрозуміти, чому верифікація стає дорожчою, спочатку треба правильно пояснити концепцію, яку найчастіше спотворюють — «самодію» (Jidoka).
Спочатку виправимо поширений міф. Самодія — це не «заміна людей AI або машинами», і не «перетворення людей на машини, що безперервно працюють». Обидва напрямки — зовсім протилежні до суті.
Слово «само-дія» вже містить відповідь. У японській мові «автоматизація» — це звичайна автоматизація, але Тойота свідомо використовує «само-дія» — з ієрогліфом «働», що має ідеограму «людина» в якості складової. Це підкреслює «автоматизацію з людським дотиком» (automation with a human touch). Її точне значення: коли машина або виробнича лінія виявляють аномалію, вони автоматично зупиняються, щоб людина могла втрутитися, виявити корінну причину та відновити виробництво. Тут працюють два паралельних механізми: машина має вбудований детектор аномалій і зупиняється сама; будь-хто на лінії, що помічає незвичайне, просто тягне за мотузку андону — і вся лінія миттєво зупиняється. Якість не перевіряється на фінальному етапі — вона вбудована в кожен етап процесу і вирішується на місці.
Ось непереконливий висновок, який прямо відповідає програмному забезпеченню: чим глибша автоматизація, тим більше зростає кількість контрольних точок та ролі людини. Само-дія звільняє людей від «повторюваних дій» і повертає їх на позицію «виявлення аномалії, зупинки лінії, вирішення корінної причини». Тойота надає робітникам на лінії повноваження зупиняти всю виробничу лінію саме тому, що розуміє: навіть найпотужніша автоматизація потребує людини, яка зможе сказати «стоп» при проблемі. Ось що насправді означає слоган «надавати роботам розум»: надавати машинам здатність зупинятися та закликати людину. Людина завжди присутня — вона відповідає за вирішення корінної причини.
Программне забезпечення зараз знову йде цим шляхом — і дуже швидко. Дослідження GitClear щодо якості коду, сгенерованого ШІ, виявили зростання кількості дублюючих блоків коду та збільшення короткострокової змінності: ШІ пише швидко, але його код «виглядає правильно». Коли величезний обсяг коду ніхто вже не писав рядок за рядком, традиційний механізм довіри «розробник знає, що робить» перестає працювати. Тут вам потрібен програмний аналог андзю-троса та механізму зупинки лінії:
- Тестування (одиничне, інтеграційне, енд-ту-енд) піднімається з «краще зробити» до жорсткого порогу: без проходження — не злити;
- Рев’ю коду зміщує акцент з «перевірки стилю» на «перевірку наміру та меж»: що саме цей код намагається вирішити, чи охоплено всі граничні умови;
- Наглядність (моніторинг, логи, трасування) стає стандартом, бо поведінка в продакшні говорить більше, ніж сам код;
- Грей-деплой / фіч-флаги дозволяють спочатку перевірити код, згенерований ШІ, на невеликій аудиторії, перш ніж розгорнути масово.
Повертаючись до розділу 2: ті 1300 PR в Stripe — писав їх агент, але процес злиття залишався повністю на розгляді людини. Ось живий приклад автоматизації в програмуванні: автоматизувати виробництво, а прийняття — залишити людині, надавши їй повноваження «зупинити це». Виробництво стає дешевшим, контроль якості — дорожчим. Це правило, що не змінювалося 40 років.
П’ять. Премія за “формулювання проблеми”: здатність, що цінніша за prompt
Якщо верифікація — це недооцінений обмежуючий фактор, то “формулювання проблеми” — це надзвичайно недооцінена здатність.
Prompt engineering якийсь час був у моді, і багато хто вважав, що “вміння писати prompt” — це ключова компетенція. Але prompt — це лише техніка “виразити проблему”. Справжня рідкість — це крок далі: problem formulation — розбити нечіткий бізнесовий виклик на чітку, розв’язну та варто розв’язувати проблему. Цей крок AI на короткий термін зробити не може, бо він чекає, поки ти скажеш йому: “Що саме це за проблема?”
Старі майстри виробництва найкраще відчувають вагу цього кроку. Якщо інженерний креслення або технологічний маршрут визначені неправильно — навіть найефективніша обробка та збірка на нижньому етапі призведуть лише до масового виробництва помилок. Те ж саме в програмуванні: якщо специфікація вимог неправильна, AI допоможе тобі в десять разів швидше виробити купу речей, які ніхто не хоче.
Простий критерій: перестань гнатися за швидкістю написання коду — розвивай чіткість розбиття проблеми.
У організації це означає: зробіть “визначення вимог” і “верифікацію та прийняття” окремими офіційними посадами — не залишайте це на розсуд розробників. Після того як AI зробив реалізацію дешевою, саме ці дві посади мають найвищий приріст вартості.
Шість. Як виглядають реальні обмеження в чотирьох галузях
Застосувавши “зсув обмежень” до чотирьох галузей, ми бачимо: у кожній з них обмеження — не в написанні коду.
Виробництво. Головна лінія — це CIO, з якого розпочинається розповідь. Функції, такі як розумне планування виробництва, відстеження якості, оптимізація споживання енергії — технічно це не складно, моделі часто вже готові. Проблема — у інтеграції та налагодженні систем MES/ERP/контролю якості/звітності, а також у полевій перевірці на терміналах цеху. Код для таких проектів пишеться швидко, але налагодження MES/ERP-систем з’їдає в кілька разів більше часу, ніж написання коду. Лише коли контрольні точки розташовані безпосередньо на терміналах цеху та на етапі інтеграції, дефекти можна зупинити на місці, а не дозволити їм виявитися лише після запуску.
Телеком / оператори. Процес зміни тарифного плану або підключення корпоративної лінії проходить крізь кілька доменів: канали, білінг, CRM, підключення мережі, планування монтажу. AI прискорює розробку в кожному домені, але саме міждоменне енд-ту-енд налагодження та перевірка на узгодженість — це головний вузький місце за часом. У операторів є ще одна унікальна перешкода: відповідність вимогам та звітність. Розбіжність у ціні на одну копійку — це аварія, і перевірка має більше ваги, ніж у будь-якій іншій галузі. Наприклад, при підключенні корпоративної лінії: хоча AI прискорив розробку в кожному домені, енд-ту-енд налагодження разом із білінговою звітністю все ще займає більшість часу проекту.
Фінанси. Зміна правила кредитного ризику або боротьби з відмиванням коштів стосується всіх систем: від додатків до ядра, системи контролю ризиків, платформи даних та звітності перед регуляторами. Тут вага перевірки надзвичайно висока — одна помилка — це порушення відповідності. Бутылочне горло — пояснюваність, аудитованість, відстежуваність: навіть найточніші правила, написані AI, не вийдуть на продакшн, якщо регулятор запитає: «Чому саме таке рішення?». Ітерації правил боротьби з відмиванням коштів — класичний приклад: AI прискорює написання правил, але перевірка пояснюваності моделі та синхронізація з вимогами регулятора разом поглинають більшість циклу.
Електронна комерція. Функція знижки або великого розпродажу охоплює товари, транзакції, маркетинг, склади, службу підтримки. AI дозволяє швидко генерувати сторінки та інтерфейси, але бутылочне горло зміщується на навантажувальні тести, консистентність запасів, захист від використання знижок, балансування. Під час великого розпродажу падають не коди, написані повільно — а ті, що не перевірили межі. Підготовка до розпродажу — це мініатюра: AI швидко генерує сторінку з акцією, але енд-ту-енд навантажувальні тести та перевірка консистентності запасів часто займають більшість часу підготовки.
Чітко видно спільне для чотирьох галузей: AI прискорює «написання», а зупиняє «збирання, перевірка, синхронізація». Інвестування звільнених ресурсів розробки саме в ці три справи — справжнє підвищення ефективності. # Сім. Що станеться, якщо помилилися: три найпоширеніші невідповідності
Перший: вважати «швидке написання коду» еквівалентом «швидшої доставки».
Це найпоширеніша ілюзія. Код — лише ланка в ланцюжку доставки; розширення цієї ланки не прискорить весь ланцюжок, а лише призведе до накопичення напівфабрикатів поза обмеженням. Теорія обмежень називає це запасами; у програмуванні — це неприйняті PR та гілки, що не пройшли інтеграцію. Результат: розробники працюють напружено, бізнес тисне, а вихід залишається незмінним — саме така ситуація, яку описував у початку CIO.
Другий: прискорення виробництва за рахунок знищення контрольних точок якості.
Це класична помилка, що суперечить принципам самодії. Хтось вважає: «AI пише швидко й якісно — можна спростити code review та скоротити тести». Навпаки: чим швидше виробництво, тим важливіше потягнути за шнурок ан-дзю. Видалення контрольних точок — це як запустити конвеєр на повну швидкість без нагляду: дефекти почнуть швидше виливатися в продакшн.
Третій: інвестування в необмежувальні ділянки.
Інтеграція — це обмеження, а ти купуєш більше ліцензій на AI-програмування; верифікація — обмеження, а ти наймаєш більше розробників. Теорія обмежень чітко пояснює: додавання ресурсів до необмежувальних ділянок не дає жодного приросту загального виходу — лише погіршує фінансові показники. Правильна послідовність: спочатку визначити обмеження, потім зосередити всі ресурси саме на ньому.
Вісім: висновки для приймачів рішень
Наслідок 1: Перш ніж купувати інструменти, намалюйте діаграму обмежень. Розберіть три останніх моменти, коли ви застрягли, і подивіться, куди саме витрачалося час. Це було через неможливість написати код, складнощі зі збиранням, відсутність перевірки чи нечітке визначення вимог? Якщо ви не можете позначити це — ви просто гадаєте на рівні технологій. Діаграма обмежень коштує більше, ніж будь-який список для закупівлі інструментів — вона може запобігти щонайменше половині неефективних IT-інвестицій у великих компаніях.
Наслідок 2: Вкладайте звільнені ресурси в визначення вимог і перевірку. AI робить розробку швидшою — це означає, що у вас з’являється вільний персонал. Поставте цих людей на офіційні позиції «Визначення вимог» і «Прийняття/Перевірка», і не дозволяйте їм продовжувати писати більше коду. Дохідність цих двох ролей в епоху AI зростає найшвидше.
Наслідок 3: Встановіть для програмного забезпечення «ан-дзю» — стрічку зупинки. Найпряміший спосіб реалізації самодії — встановити жорсткі пороги в вашій CI/CD: не дозволяти злиття, якщо тести не пройдені; обов’язково перевіряти інтенцію та межі під час рев’ю; починати з малих обсягів у грей-фазі; робити спостережуваність стандартом. Чим більше автоматизації в продакшні, тим важливіше це обмеження. Це запобігає тому, щоб «код був безкоштовним» не перетворився на «аварії були безкоштовними».
Наслідок 4: Перерозподіліть людей, а не звільняйте їх. Самодія веде до одного й того ж висновку: чим глибше автоматизація, тим важливіше розмістити людей на позиціях «прийняття рішень, перевірка, виявлення кореневих причин». Звільніть їх від повторюваних операцій і перерозподіліть на перевірку та узгодження — це ключова дія в організаційному дизайні в епоху AI, і саме це ми розгорнемо в наступних статтях цього серіалу.
9. Можливо, ви хочете запитати
«Ми лише пілотуємо AI — чому нам треба малювати діаграму усіх узузьких місць компанії?» Навіть пілотні проекти вимагають розуміння: чи є саме цей етап справжнім обмеженням? Якщо справжній вузький місце — інтеграція чи верифікація, то пілотування AI саме в етапі «написання коду» — це витрачання грошей там, де це не потрібно, і це саме та третя невідповідність, про яку йшлося в розділі 7. Спочатку проведіть невелике діагностування обмежень — тоді витрати на інструменти будуть виправданими.
«Чи не уповільнить це доставку через перевірку?» На короткостроковій перспективі буде тертя, але на довгостроковій — прискорення. «Швидкість» без перевірки — це швидке поширення дефектів у виробництво, а вартість виправлення зростає в десять разів. Досвід автоматизації: вартість виправлення дефекту на місці — це лише дрібна частка від витрат на його усунення після того, як він потрапив у наступний етап.
«Як це пов’язано з нашою AI-трансформацією?» Зв’язок прямий. Найпоширеніша помилка AI-трансформації — це припущення, що обмеження лежить у «написанні коду / продуктивності», і купівля великої кількості інструментів для розширення саме цього етапу. Спочатку зробіть діагностику обмежень, а потім вирішуйте, куди вкладати гроші. Саме тому я розміщую «оцінку здібностей» і «ідентифікацію ціннісних сценаріїв» на початку рамки «7 кроків AI-трансформації»: спочатку визначте, де обмеження, а потім — про інструменти.
Обернена самоперевірка (не прикрашай відповідь): Останній раз, коли ти застряг зі здачею — на чому саме витратив час: на написанні коду, чи на збиранні, перевірці, вирівнюванні? Скільки коду, згенерованого твоїми AI-інструментами, стабільно виходить в продакшн і реально використовується користувачами? У твоєму CI/CD є жорсткий етап «не дозволити мердж, якщо тести не пройдені»? Якщо хоча б на одну з цих трьох питань ти відповідаєш зі скривдженням — не поспішай купувати більше AI-інструментів, спочатку знайди свій узький місце. # Наступний крок Це третій із 15 статей серії «Зміни програмної інженерії в епоху AI». Від Конві (організація визначає архітектуру) і Team Topologies (як проектувати організацію) ми перейшли до зсуву обмежень (коли код майже безкоштовний, куди зміщується обмеження?). Наступна стаття (№4) змінює погляд на більш практичний: як вибирати основні AI-інструменти для програмування. Але висновок може здатися протилежним інтуїції: вибір інструментів — це в кінцевому рахунку організаційне рішення, яке треба приймати залежно від рівня зрілості та управління, а не за критерієм «хто пише найкрутийший код». — > Примітка про серію: Ця серія постійно слідкує за останніми змінами в AI-інструментах для програмування, організаційних архітектурах та парадигмах програмної інженерії — наприклад, новими формами закону Конві в епоху AI-агентів у 2026 році, рівнем зрілості нових інструментів тощо. Підпишись на серію, щоб отримувати актуальні інсайти. # Про цю серію
Зміна програмної інженерії в епоху ШІ — це глибокий дослідницький серіал з 15 статей, призначений для CIO/CDO/CTO та відповідальних за цифрові трансформації в таких галузях, як телекомунікації, фінанси, виробництво та електронна комерція. На основі 200+ академічних статей та галузевих звітів, серія надає рішення з позначками рівня доказів.
Я колишній інженер IBM, сертифікований коуч ICF, який реалізовував проекти з ШІ та цифрової трансформації для операторів зв’язку та великих підприємств. Усі матеріали тут — це практичні висновки, отримані під час супроводу компаній через реальні виклики.
参考来源（均已核实）
- a16z (2026). Software in the Age of Agents. The a16z Podcast.（前微软 Windows 总裁 Steven Sinofsky 金句 “The long tail got no shorter, it just got longer in a different way”，企业软件视角独立印证 TOC 瓶颈搬家律；一级来源——播客原声。立场标注：a16z 合伙人 / 前微软高管，VC 立场。嘉宾已核实：a16z 企业团队合伙人 Seema Amble、前微软 Windows 总裁 Steven Sinofsky（board partner）、a16z 撰稿 Elena Burger；播出 2026 年 7 月。）
- Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement.（约束理论 TOC 的原始出处，一级来源；以制造业工厂为场景的小说）
- Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press.（把 Goldratt 的 TOC 原样搬进 IT 运维，制造业→软件的桥，一级）
- Toyota. Toyota Production System — Jidoka（自働化）. toyota-global.com（自働化 = 带人字旁的自动化，异常停线 + 人介入解根因；安灯系统；一级来源）
- GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle.（Copilot 在启用文件内完成约 46% 代码，口径为”启用文件内”，一级）
- Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog；InfoQ 报道每周 1,300+ PR，全量人工 review（一级 + 二级）
- NVIDIA / 黄仁勋. 100% 工程师使用 Cursor 等 AI 编程工具的公开表态（一手言论）
- GitClear (2025). AI-Assisted Code Quality Research.（观察到 AI 辅助下重复代码 / 短期 churn 上升，支撑”验证变贵”，二级）
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press.（交付绩效由文化、流速、反馈决定，非个人编码速度，一级）
buymeacoffee
![[Переміщення обмежень] Коли код майже безкоштовний, куди поділися обмеження програмної інженерії? Зміни в програмній інженерії в епоху ШІ — Повільне вивчення ШІ 173](https://cdn.iaiuse.com/img/2026/07/13/d39583784356669e4e768cd4d75981e6.webp)
![[Ваша організаційна структура вже вирішила долю вашого програмного забезпечення] Закон Конвей — управлінський закон, який 56 років недооцінювали Зміни в інженерії ПЗ у епоху ШІ —慢慢学AI171](https://cdn.iaiuse.com/img/2026/04/06/97308b44819c0d12a4fd8e758b91ddd0.webp)
