_Автор файла: Джарвис_ _Статус: drafted_ _Дата: 2026-04-29_ _Тип: summary_
Александр Апазиди разбирает не вопрос «ускоряет ли AI программистов», а более неприятный для директора вопрос: почему локальное ускорение разработчиков почти не превращается в сопоставимое ускорение всей компании.
Его ответ жёсткий и довольно приземлённый: AI действительно ускоряет кодинг, иногда кратно, но выигрыш почти целиком съедается организацией — согласованиями, зависимостями между командами, регуляторикой, параллельной работой, переделками и платформенными бутылочными горлышками.
То есть тезис доклада не в том, что AI переоценён. Наоборот: AI реален, но он сдвигает узкое место из программирования в устройство компании.
Если сжать весь доклад в одну фразу, получится так:
После AI скорость кодинга перестаёт быть главным ограничением; теперь директора тормозит не разработчик, а сама система управления потоком.
Апазиди несколько раз возвращается к этой логике с разных сторон:
И это не парадокс, а арифметика. Если кодирование занимает лишь малую часть общего lead time, то ускорение только этой части почти не меняет общую скорость системы.
Апазиди очень аккуратно отделяет три уровня:
Это важное место, потому что доклад спорит не с AI, а с наивным управленческим выводом: «если дать всем copilot/cursor, то вся организация автоматически станет кратно быстрее».
По Апазиди это не работает, потому что в больших системах время уходит не только на код:
Именно сюда, а не в IDE, должен смотреть директор.
У доклада сильная эмпирическая база: автор опирается и на свой путь от разработчика до IT-директора, и на множество разговоров с разработчиками, тимлидами, руководителями отделов и C-level.
Картина у него получается такая:
То есть различие между «AI дал турбину» и «компания особо не полетела» у него не теоретическое, а наблюдаемое.
Доклад опирается на DORA-отчёты и на исследование Atlassian по developer experience.
Ключевой вывод из этой части:
У Апазиди это встроено в общий тезис: команды начали быстрее производить output, но не научились так же хорошо встраивать этот output в управляемый организационный поток.
Самый полезный каркас доклада — перенос Голдратта на AI-эпоху.
Апазиди фактически говорит:
Это делает доклад очень директорским: он не про инструменты, а про перенастройку системы после сдвига ограничений.
Апазиди перечисляет шесть классов организационных потерь. Это, пожалуй, самый практичный кусок всего выступления.
Время на решение ещё до начала кодинга:
Раньше компания могла не замечать эту вязкость, потому что сама разработка была медленнее. Теперь, когда код можно получить быстро, медленное решение становится видимым bottleneck.
Если команде A нужно что-то от команды B, никакой AI это автоматически не чинит. Здесь продолжают гореть:
Судя по реакции аудитории, именно этот класс боли узнаётся сильнее всего.
Быстрый код ещё не значит разрешённый код. В больших компаниях ускорение упирается в:
Хороший тонкий тезис здесь: если правил нет и всё приходится нести на ручное согласование архитектору, это само по себе организационная болезнь.
Это один из самых жёстких фрагментов доклада. Апазиди почти в канбан-риторике повторяет старую истину: stop starting, start finishing.
AI позволяет запустить ещё больше задач и недоделок, но это не ускоряет поставку. Наоборот:
Для директора это превращается в прямой совет: смотреть не только на скорость отдельных людей, а на WIP/портфель/число одновременных инициатив на команду.
Скептики по AI у Апазиди появляются не как ретрограды, а как носители понятной боли: если AI быстро производит слабый код без достаточного контекста и ограничений, потом кто-то вручную разгребает последствия.
Иными словами:
Это не довод против внедрения AI, а довод против наивного внедрения.
Платформу часто создают как ускоритель, но в реальности она может стать ещё одной очередью.
Если для любого следующего шага нужно ждать платформенную команду неделями, она перестаёт быть enablement-функцией и превращается в ограничение потока.
Это сильный и полезный управленческий укол: даже «улучшающий» слой организации легко становится тормозом, если не измерять сервисность и скорость ответа.
Доклад не сводится к диагнозу. В конце Апазиди даёт набор управленческих рычагов.
Он опирается на старую, но до сих пор полезную рамку: effort → output → outcome → impact.
Смысл очень простой:
Практически это означает смещение фокуса с «сколько сгенерировали» на:
Если из всего доклада оставить один самый рабочий совет, то это он.
Апазиди прямо предлагает:
Это важно, потому что после AI узкие места становятся контринтуитивными: раньше на них можно было не смотреть, а теперь именно они определяют скорость.
Апазиди отдельно протаскивает тему DACI-подобной логики: у решения должен быть конкретный driver/owner, а не безликий коллегиальный орган.
Идея простая:
Это, пожалуй, одна из самых взрослых мыслей доклада: ускорение без перераспределения полномочий не долетает до результата.
Для компаний вне IT и для перегруженных внутренних IT-подразделений совет особенно жёсткий: не радоваться тому, что AI позволяет тянуть ещё больше задач, а наоборот резать одновременный портфель.
Его практическая логика такая:
Один из самых убедительных мотивов доклада: маленькие независимые команды уже сейчас лучше извлекают пользу из AI, потому что у них меньше стыков и они ближе к outcome.
Это не романтика стартапов ради стартапов. Это структурная мысль:
Апазиди скептически относится к гордому рассказу о том, что люди получили больше happy time.
Его позиция понятна: если AI высвобождает 20–30% capacity, директору полезнее пустить её не в самодовольство, а в:
Это прагматичный взгляд без сладкой сказки про автоматическое счастье сотрудников как главный KPI внедрения.
Во второй половине доклада Апазиди делит компании на четыре архетипа, и это помогает не превращать советы в универсальную жвачку.
Типичный контур:
Здесь bottleneck — не скорость кодинга, а сам объём спроса и переключений. Значит:
Здесь у автора почти нет иллюзий: главное ограничение — координация.
Поэтому бессмысленно фанатично смотреть на adoption-rate инструментов. Гораздо важнее:
Здесь скорость действительно становится конкурентным преимуществом.
Апазиди советует:
Это, пожалуй, самый «про-ускорение» режим во всём докладе.
Самая неприятная зона для старой модели, потому что продавать просто часы программистов становится всё слабее как аргумент.
Здесь Апазиди подталкивает к смене упаковки ценности:
Это звучит жёстко, но довольно правдоподобно: AI бьёт как раз по самой копируемой части старого аутсорс-предложения.
Апазиди не выглядит человеком, который хочет доказать, что хайп пустой. Он признаёт ускорение честно и прямо. Поэтому его скепсис к организационному эффекту звучит убедительнее.
Это, наверное, главная ценность доклада для директоров. Вопрос ставится не как «какой AI tool выбрать», а как «какая часть системы теперь реально ограничивает поток».
Голдратт, flow, WIP, value stream mapping, outcome-метрики — всё это у него не музей, а рабочий набор для AI-эпохи.
Количество токенов, курсоров и adoption-rate у него выглядят почти как декоративная активность. Это полезный укол в эпоху, где легко перепутать инструментальное движение с реальным ускорением бизнеса.
Логика убедительная, но некоторые проценты и пропорции скорее иллюстративны, чем строго доказаны для любой компании.
Для выступления это уместно, но в реальности внутри одного enterprise могут одновременно жить разные типы контуров, и один режим управления не покроет всё.
Апазиди правильно говорит про полномочия, стыки и власть, но естественно не успевает глубоко разобрать, как именно директору продавить эти изменения в уже закостеневшей системе.
Q&A в этом докладе небольшой, но полезный.
Он добавляет несколько акцентов:
То есть финал не ломает рамку, а скорее добивает её практическими штрихами: будущее выигрывают не только кодеры, а люди, умеющие задавать контекст, убирать организационное трение и переводить ускорение в систему.
Если собрать доклад в рабочий остаток, получается так:
Это сильный, трезвый и очень директорский доклад про организационную экономику AI-ускорения.
Его главная польза в том, что он снимает магическое мышление. Не в смысле «AI не работает», а в смысле: работает, но теперь он беспощадно показывает, где у компании настоящие управленческие дыры.
Если сохранить одну мысль, то вот она: после AI выигрывает не тот, кто просто быстрее пишет код, а тот, кто быстрее перестраивает поток вокруг нового узкого места.