[Перенос узких мест] Когда код почти бесплатен, куда делись узкие места программной инженерии? Преобразования программной инженерии в эпоху ИИ — Медленное изучение ИИ 173
Когда код становится почти бесплатным, узким местом становятся запросы, интеграция, верификация и согласование
Когда производство кода становится почти бесплатным, узким местом в доставке программного обеспечения перестаёт быть «написание кода» — оно перемещается в другие места: определение правильной проблемы, сбор фрагментов в работоспособную систему, проверка, что она действительно правильная, и согласование внутри организации. Это повторение Теории Ограничений (Theory of Constraints) в сфере программной инженерии. Промышленность прошла этот путь 40 лет назад: каждый раз, когда один этап становился дешевле, узкое место не исчезало — оно просто смещалось на следующий самый дорогой этап. Поняв это, вы сможете объяснить распространённое недоумение: AI-инструменты для программирования внедрены по всей компании, написание кода явно ускорилось, но скорость доставки практически не изменилась.
Один CIO промышленной группы показал мне свои данные за последние полгода. ИТ-команда насчитывает более 80 человек, все полностью перешли на AI-инструменты для программирования: если смотреть только на объём кода, среднее количество коммитов и скорость слияния выросли более чем на 30%. Но ощущения со стороны бизнеса совершенно иные: небольшая функция умного планирования производства — от инициации до запуска — по-прежнему занимает не менее трёх месяцев. Он ожидал, что инструменты дадут двукратное ускорение, а получил лишь «быстрое написание кода». Его слова были прямыми: «Я потратил несколько миллионов на лицензии — и купил только то, что разработчики стали ещё занятынее, а бизнес — ещё более нетерпеливее».
Он ошибочно определил место узкого места. Его истинное узкое место — другое: каждая новая функция должна проходить через MES, ERP, систему контроля качества, терминалы цеха и дополнительную систему отчетности перед регуляторами — интеграция и отладка поглощают большую часть сроков; а код, сгенерированный ИИ, не встречает ни одной официальной контрольной точки между собой и производственной средой. Даже если код пишется быстро, он просто стоит в очереди за неправильным узким местом.
I. Производство: 40 лет назад уже знали — узкое место перемещается
Чтобы понять настоящее, сначала возьмем очки, которые производство носит уже 40 лет.
В 1984 году израильский консультант, физик по образованию Элияху Голдратт, написал роман «Цель» (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 уже неприемлемо.
Сложив эти три цифры, вывод неоспорим: стоимость производства одной строки кода стремительно приближается к нулю. Возникает острый вопрос: если написание кода почти бесплатно, почему программное обеспечение остаётся таким дорогим, медленным и трудным в доставке? Ответ даёт теория ограничений: вы расширили этап «написания кода» — узкое место просто переместилось. Куда?
Три: узкие места переместились в четыре места
На этот раз узкие места сосредоточены в четырёх этапах. Каждый из них — то, чего ИИ не сможет достичь в ближайшее время.
Первый: определение правильной проблемы.
ИИ может за секунды написать «ту функцию, которую вы упомянули», но он не может написать «ту функцию, которую вы действительно нужны». Большинство проектов по разработке ПО проваливаются потому, что созданный продукт никто не использует — изначально не было чётко понято, какую проблему нужно решить. После того как производство кода стало дешевле, способность «преобразовать расплывчатую бизнес-проблему в чёткий, решаемый и стоящий решения спецификации» (problem formulation) стала самой редкой и самой дорогой компетенцией. Промышленные коллеги хорошо это знают: если технологический маршрут или инженерные чертежи ошибочны, даже самый эффективный производственный цех будет массово выпускать брак.
Второй: системная интеграция.
ИИ отлично генерирует «фрагмент кода», «функцию», «страницу». Но рабочая система — это интеграция сотен таких фрагментов, которые должны обмениваться данными, обрабатывать граничные случаи, сохранять согласованность и выдерживать сбои. Генерация фрагментов дешева, но сборка из них надёжной целостной системы — дорого. Этот издержки коренятся в согласовании организационной структуры и архитектуры — именно то, чем занимаются закон Конвей и топологии команд (см. две предыдущие статьи серии). Вернёмся к упомянутому в начале CIO промышленного предприятия: его сроки не тратились на написание кода, а ушли на настройку взаимодействия между системами MES, ERP, контроля качества и отчётности.
Третий барьер: верификация. Объем кода резко возрастает, его надежность неоднородна. Кто решает, «это правильно»? Тестирование, ревью кода, наблюдаемость, постепенное развертывание — вес этих «операций верификации» только растет. Это самый недооцененный барьер и самая глубокая имитация производственной модели. Об этом — отдельный раздел в четвертой части.
Четвертый барьер: согласование в организации. Когда в команде появляются AI-агенты, кто решает, что делать? Кто проверяет? Кто несет ответственность за результат? Это продолжение закона Конвэя и теории топологий команд — согласование внутри организации само становится узким местом. Об этом — отдельная статья в серии №11: когда узлы организации — не только люди, управление превращается в ключевое конкурентное преимущество.
# 4. Самая глубокая резка: верификация, и что на самом деле учит нас «самодвижению» (jidoka) от ToyotaИз четырех барьеров наиболее часто неправильно понимают именно верификацию. Многие считают: «раз AI пишет быстро, значит, нужно больше тестировать». Это верно лишь наполовину. Чтобы понять, почему верификация стала дороже, нужно сначала правильно объяснить концепцию, которая чаще всего искажается и неверно трактуется — «самодвижение» (jidoka).
Сначала исправим широко распространённое заблуждение. Jidoka — это не «замена людей ИИ или машинами», и не «превращение людей в машины, которые должны беспрерывно работать». Оба направления — полная противоположность сути.
Слово «jidōka» само по себе содержит ответ. В японском языке «автоматизация» — это обычное автоматизирование, но Тойота сознательно использует «自働化», где иероглиф «働» содержит радикал «человек», подчеркивая «автоматизацию с человеческим фактором» (automation with a human touch). Его точное значение: когда машина или производственная линия обнаруживают аномалию, они автоматически останавливаются, чтобы человек вмешался, устранил корневую причину и возобновил производство. Здесь работают два параллельных механизма: машина сама оснащена обнаружением аномалий и останавливается сама; любой работник на линии, заметив неполадку, тянет за шнур андона (andon) — и вся линия мгновенно останавливается. Качество не проверяется на финальном этапе, а встроено в каждую операцию и устраняется на месте.
Здесь есть контринтуитивный вывод, напрямую соответствующий программному обеспечению: чем глубже автоматизация, тем больше становится контрольных точек качества и роль человеческого вмешательства. Jidōka освобождает человека от «повторяющихся операций» и возвращает его на позицию «обнаружения аномалий, остановки линии, устранения корневой причины». Тойота предоставляет рабочим на линии право остановить всю производственную линию именно потому, что понимает: как бы ни была сильна автоматизация, нужен человек, способный вовремя остановить процесс. Именно в этом и заключается истинный смысл лозунга «наделить роботов мудростью»: дать машинам возможность остановиться и вызвать человека. Человек всегда присутствует, чтобы устранять корневые причины.
Программное обеспечение снова идёт этим путём — и идёт быстро. Исследования GitClear по качеству кода, сгенерированного ИИ, уже зафиксировали рост повторяющихся фрагментов кода и увеличение краткосрочных изменений: ИИ пишет быстро, но его код «выглядит правильно». Когда огромные объёмы кода никто не писал вручную, традиционный механизм доверия — «разработчик знает, что делает» — перестаёт работать. Здесь вам нужен программный аналог андзё-тэй и системы остановки линии:
- Тестирование (юнит, интеграционное, энд-ту-энд) переходит из категории «стараемся делать» в жёсткое требование: без прохождения — не сливаются;
- Code review смещает акцент с «проверки стиля» на «проверку намерений и границ»: что именно этот код должен решать, охвачены ли все граничные условия;
- Наблюдаемость (мониторинг, логи, трассировка) становится стандартом, потому что поведение в продакшене говорит о проблемах громче, чем сам код;
- Грей-релизы / feature flag позволяют сначала протестировать сгенерированный ИИ код на небольшой аудитории, и только после подтверждения стабильности — выпускать в массы.
Возвращаясь ко второму разделу: 1300 PR от Stripe — писал их агент, но все слияния проходили через ручной ревью. Это и есть живой пример самодёрга в программировании: автоматизировать производство, но оставить проверку на человеке — и дать человеку право остановить процесс. Производство стало дешевле, контроль качества — дороже. Это правило не менялось 40 лет.
Пять. Премия за «формулирование проблемы»: способность, ценность которой превосходит prompt
Если верификация — это недооценённый узкий участок, то «формулирование проблемы» — это способность, недооценённая в разы. Prompt engineering некоторое время был в моде, и многие подумали, что «умение писать prompt» — это ключевая компетенция. Но prompt — это всего лишь техника «выразить проблему». То, что по-настоящему редко — это шаг дальше: formulation of the problem, то есть разложение нечёткого бизнес-вызова на чёткую, решаемую и стоящую решения проблему. Этот шаг AI не может выполнить в ближайшее время — ведь ему нужно, чтобы вы сначала сказали ему: «Какова именно проблема?»
Старшие инженеры в производстве лучше всего чувствуют вес этого шага. Если инженерный чертёж или технологический маршрут ошибочны — даже самый эффективный последующий процесс обработки и сборки приведёт к массовому производству ошибок. То же самое в программировании: если спецификация требований неверна, AI поможет вам в десять раз быстрее создать массу продуктов, которые никому не нужны.
Простой критерий: перестаньте соревноваться в скорости написания кода — тренируйте чёткость разложения проблем. В организации это означает: сделайте «определение требований» и «верификацию и приёмку» официальными должностями, а не оставляйте их на усмотрение разработчиков. После того как AI сделал реализацию дешёвой, доходность этих двух ролей выросла быстрее всего.
Шесть. Как выглядят реальные узкие места в четырёх отраслях
Применяя «сдвиг узких мест» к четырём отраслям, мы видим: в каждой из них узкое место — не в написании кода.
Производство. Главная история — это CIO, упомянутый в начале. Функции, такие как интеллектуальное планирование производства, отслеживание качества и оптимизация энергопотребления, технически несложны: модели часто уже готовы. Бутылочное горлышко — интеграция и настройка систем MES/ERP/контроля качества/отчетности, а также полевая валидация на производственных терминалах. Код для таких проектов пишется быстро, но на интеграцию MES/ERP уходит в несколько раз больше времени, чем на написание кода. Только если проверяющие находятся прямо на производственных терминалах и в цепочке интеграции, дефекты можно остановить на месте, а не ждать, пока они проявятся после запуска.
Телеком / операторы связи. Процесс изменения тарифного плана или подключения корпоративной专线 проходит через несколько доменов: каналы продаж, биллинг, CRM, настройка сети и планирование монтажа. AI ускорил разработку в каждом домене, но ключевым узким местом остаётся сквозная интеграция и проверка согласованности между доменами. У операторов связи есть ещё одна уникальная проблема: соответствие нормам и сверка расчётов. Разница в один цент в биллинге — это авария, и проверка здесь важнее, чем в любой другой отрасли. Например, при подключении корпоративной专线: хотя AI ускорил разработку в каждом домене, сквозная интеграция плюс сверка биллинга всё равно занимает большую часть срока проекта.
Финансы. Настройка правила кредитного риска или борьбы с отмыванием денег затрагивает несколько систем: приложение, ядро, движок рисков, платформу данных и отчетность для регуляторов. Валидация здесь имеет критически высокий вес — одна ошибка может привести к нарушению регуляторных требований. Узкое место — объяснимость, аудит и восстанавливаемость: даже самое точное правило, написанное ИИ, не выйдет в продакшн, если регулятор спросит: «Почему именно такое решение?». Итерация правил борьбы с отмыванием денег — типичный пример: ИИ ускоряет написание правил, но проверка объяснимости модели и согласование с требованиями регулятора зачастую поглощают большую часть всего цикла.
Электронная коммерция. Функция акции или распродажи затрагивает товары, транзакции, маркетинг, склад и службу поддержки. ИИ позволяет быстро генерировать страницы и API, но узкое место смещается на нагрузочное тестирование, согласованность остатков, защиту от мошенничества и сверку. Во время распродажи падают не медленно написанные коды — а те, чьи граничные случаи не были протестированы. Подготовка к распродаже — идеальный пример: страницу акции ИИ генерирует мгновенно, но энд-ту-энд нагрузочное тестирование и проверка согласованности остатков занимают большую часть рабочего времени.
Общая черта этих четырех отраслей очевидна: ИИ ускоряет «написание», а тормозит «сборка, проверка, согласование». Вложить освободившиеся ресурсы разработки именно в эти три области —这才是 настоящая эффективность.
Семь. Что будет, если ошибка произойдет: три наиболее распространенных несоответствия
Первый тип: считать, что «быстрое написание кода» означает «ускорение доставки».
Это самое распространённое заблуждение. Код — лишь одно звено в цепочке доставки; расширение его не ускорит всю цепочку, а лишь приведёт к накоплению полуфабрикатов за узким местом. Теория ограничений называет это запасами; в программировании это — непринятые PR и ветки без интеграционного тестирования. Результат: разработчики всё заняты, бизнес всё более спешит, а объём результата не меняется — именно такова ситуация, описанная в начале у CIO.
Второй тип: ускорение производства за счёт снятия контрольных точек качества.
Это классическая ошибка, нарушающая принцип дзидзя-отоко. Некоторые считают: «AI пишет быстро и хорошо — можно упростить code review и сократить тестирование». Наоборот: чем быстрее производство, тем важнее тянуть за шнур ан-дзё. Устранение контрольных точек — это как запустить конвейер на полную мощность без присутствия операторов: дефекты начнут быстрее и быстрее проникать в продакшн.
Третий тип: вложение средств не в узкое место.
Интеграция — узкое место, а вы покупаете ещё лицензии на AI-программирование; верификация — узкое место, а вы нанимаете ещё разработчиков. Теория ограничений давно это объяснила: вложение ресурсов не в узкое место не приносит никакого вклада в общий выход — только ухудшает показатели на бумаге. Правильный порядок: сначала определить узкое место, затем сконцентрировать на нём все ресурсы.
8. Выводы для лиц, принимающих решения
Вывод 1: Прежде чем покупать инструменты, нарисуйте диаграмму узких мест. Разберите последние три случая, когда вы застряли в доставке — где именно уходило время? Не могли написать код? Не могли собрать всё вместе? Никто не проверял? Требования были неясны? Если вы не можете обозначить проблему — вы просто гадаете на уровне технологий. Диаграмма узких мест ценнее любого списка закупок: она предотвращает как минимум половину неэффективных IT-инвестиций в крупных компаниях.
Вывод 2: Вложите высвободившиеся ресурсы в определение требований и верификацию. AI ускоряет разработку — значит, у вас появляется лишний человеческий ресурс. Назначьте этих людей официально на позиции «Определение требований» и «Верификация и приёмка» — не позволяйте им дальше писать ещё больше кода. Доходность этих двух ролей в эпоху AI растёт быстрее всего.
Вывод 3: Установите для ПО «ан-дэн-сёну». Самый прямой путь внедрения автономизации — установить жёсткие пороги в вашей CI/CD: не допускать слияния, если тесты не прошли; проверять в ревью не только код, но и намерения и граничные случаи; запускать в灰度 сначала на малом объёме; сделать наблюдаемость стандартом. Чем выше автоматизация в продакшене, тем строже должна быть эта проверка — это предотвращает превращение «бесплатного кода» в «бесплатные инциденты».
Вывод 4: Перераспределите людей, а не увольняйте их. Автономизация ведёт к одному и тому же выводу: чем глубже автоматизация, тем важнее разместить людей на позициях «принятие решений, верификация, поиск корневых причин». Освободите их от рутинных операций и перенаправьте на верификацию и согласование — это ключевое действие в дизайне организаций в эпоху AI, и именно об этом мы подробно расскажем в следующих статьях серии.
9. Возможно, вы задаёте вопрос
«Мы просто пилотируем ИИ в отдельных отделах — зачем нам рисовать карту узких мест всей компании?»
Даже пилот требует предварительного анализа: является ли именно этот этап настоящим узким местом? Если проблема на самом деле в интеграции или верификации, то внедрение ИИ именно на этапе «написания кода» — это траты денег не на том участке, что попадает под третий тип несоответствия, описанный в главе 7. Сначала проведите небольшой анализ узких мест — только тогда деньги на инструменты будут потрачены эффективно.
«Не замедлит ли этап верификации доставку?»
Краткосрочно — да, возникнут трения; долгосрочно — это ускорение. «Быстрота» без контрольных точек — это быстрая доставка дефектов в продакшн, где стоимость исправления в десять раз выше. Опыт автоматизации показывает: стоимость устранения дефекта на месте — лишь крошечная доля от стоимости его исправления на следующих этапах.
«Как это связано с нашей текущей ИИ-трансформацией?»
Связь прямая. Самая частая ошибка при ИИ-трансформации — предположение, что узкое место находится в «написании кода / производительности», и закупка множества инструментов для его расширения. Сначала проведите анализ узких мест — только потом решайте, куда вкладывать деньги. Именно поэтому я размещаю «оценку компетенций» и «идентификацию ценностных сценариев» на ранних этапах в рамках «7-шаговой коуч-модели ИИ-трансформации»: сначала определите, где узкое место — только потом говорите об инструментах.
Обратная самопроверка (не украшайте ответ): Последний раз, когда вы застряли с доставкой, где именно ушли ваши часы — на написание кода или на сборку, проверку и согласование? Сколько из кода, сгенерированного вашими AI-инструментами, стабильно выходит в продакшн и реально используется пользователями? Есть ли в вашей CI/CD жёсткий барьер «не допускать слияние, если тесты не прошли»? Если хотя бы один из этих трёх пунктов вызывает у вас чувство неуверенности — не спешите покупать новые AI-инструменты, сначала найдите своё узкое место.
Следующий шаг
Это третья статья из серии из 15 «Преобразования программной инженерии в эпоху ИИ». Мы перешли от Конвей (организация определяет архитектуру) и топологий команд (как проектировать организацию) к смещению узких мест (когда код почти бесплатен, куда уходит узкое место?). Следующая статья (№4) сместит фокус на более практический аспект: как выбирать основные AI-инструменты для программирования. Но вывод может показаться контринтуитивным: выбор инструмента — это в конечном счёте организационное решение, и его нужно принимать исходя из вашей зрелости и уровня управления, а не из того, «чей код выглядит круче».
Примечание к серии: Эта серия будет отслеживать последние тенденции в AI-инструментах для программирования, организационных архитектурах и парадигмах программной инженерии — например, новые формы закона Конвей в эпоху AI-агентов к 2026 году, зрелость новейшей экосистемы инструментов и т.д. Подпишитесь на серию, чтобы получать актуальные инсайты.
О серии
«Преобразования программной инженерии в эпоху ИИ» — это глубокая исследовательская серия из 15 статей, адресованная CIO/CDO/CTO и ответственным за цифровизацию в таких отраслях, как телекоммуникации, финансы, производство и электронная коммерция. На основе более чем 200 академических статей и отраслевых отчётов серия предоставляет обоснованные рекомендации для принятия решений с указанием уровня доказательности.
Я бывший инженер IBM, сертифицированный коуч ICF, который реализовывал проекты по внедрению ИИ и цифровизации в телеком-операторах и крупных корпорациях. Всё, что здесь написано, — это практические выводы, выработанные в процессе сопровождения компаний через реальные трудности.
Источники (все проверены)
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Цитата Стивена Синовски, бывшего президента Windows Microsoft: «Длинный хвост не стал короче — он просто удлинился иначе»; независимое подтверждение закона смещения узкого места TOC с позиции корпоративного ПО; первичный источник — аудиозапись подкаста. Позиция: партнёр a16z / бывший руководитель Microsoft. Гости подтверждены: партнёр команды a16z по корпоративным технологиям Сима Амбл, бывший президент Windows Microsoft Стивен Синовски (board partner), автор a16z Элена Бургер; выпущено в июле 2026 г.)
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. (Прямое применение TOC Goldratt в IT-операциях; мост от производства к программному обеспечению; первичный источник.)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = автоматизация с человеческим участием; остановка линии при аномалии + вмешательство человека для устранения корневой причины; система Andon; первичный источник.)
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 в неделю с полным ручным ревью (первичный + вторичный источник.)
NVIDIA / Джефф Хуан. Открытые заявления о том, что 100% инженеров используют AI-инструменты программирования, такие как Cursor (прямые высказывания.)
GitClear (2025). AI-Assisted Code Quality Research. (Наблюдается рост повторяющегося кода и краткосрочного churn при использовании ИИ — подтверждает тезис «проверка становится дороже»; вторичный источник.)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Производительность доставки определяется культурой, скоростью потока и обратной связью, а не индивидуальной скоростью написания кода; первичный источник.)
buymeacoffee
![[Перенос узких мест] Когда код почти бесплатен, куда делись узкие места программной инженерии? Преобразования программной инженерии в эпоху ИИ — Медленное изучение ИИ 173](https://cdn.iaiuse.com/img/2026/07/13/d39583784356669e4e768cd4d75981e6.webp)
