13 — Директор 2026: AI ускорил код. Почему компания все равно тормозит

Статус: drafted

Спикер / автор: Александр Апазиди

Описание

Доклад четвёртого дня конференции «Управление 2026» о том, почему ускорение кодинга само по себе не убирает организационные задержки: узким местом остаётся не только разработка, но и управленческая вязкость компании, стоимость решений и способность директора ускорять всю систему, а не отдельного исполнителя.

Короткий комментарий по статусу

есть canonical links, slides.pdf, chat.pdf, transcript.raw.json, transcript.md, восемь chunk-файлов, содержательный summary-jarvis.md, честный comparison.md; Gemini-слой явно помечен как not run

Полезные ссылки

Что уже собрано

Тринадцатый talk по текущей структуре/очереди — это доклад Александра Апазиди «Директор 2026: AI ускорил код. Почему компания все равно тормозит».

По этой карточке теперь собраны: - canonical source links (YouTube + Teachable); - slides.pdf (4.1.pdf) из описания YouTube; - chat.pdf (Chat4.pdf) из описания YouTube; - transcript.raw.json, собранный через YouTube watch page -> Innertube player (ANDROID client) -> timedtext; - transcript.md с 2-минутной нарезкой; - 8 chunk-файлов по ~8 минут; - содержательный summary-jarvis.md; - честный comparison.md без выдуманного Gemini; - summary-gemini-raw.md и summary-gemini.md как явные placeholders со статусом not run.

Смысловой результат

Главная мысль доклада в текущем semantic-pass собрана так: AI действительно ускоряет кодинг, но в больших компаниях главный bottleneck смещается из разработки в управленческую систему — решения, зависимости, governance, WIP, rework и платформенные очереди.

Из полезного остатка особенно выделяются: - различие между локальным ускорением разработчика и системной скоростью компании; - перенос теории ограничений/Голдратта на AI-эпоху; - шесть классов организационных потерь, которые съедают выигрыш от AI; - практический акцент на value stream mapping, outcome-метриках, снижении параллельности и автономных командах.

Практические замечания

  • Прямой fetch caption baseUrl из обычного web-player path на этом контуре снова возвращает пустой ответ; рабочим оказался обход через Innertube player с ANDROID client context, после чего timedtext уже отдал полноценный XML transcript.
  • В описании YouTube для этого ролика явно указаны 4.1.pdf и Chat4.pdf, так что привязка локальных slides.pdf и chat.pdf выглядит твёрдой.
  • Локально закреплённый transcript содержит 1657 текстовых сегментов при длительности видео около 59:38.
  • Gemini-слой в этом проходе сознательно не запускался; отсутствие второго summary отражено явно, а не замаскировано.

Оценка готовности

Для текущего staged-пайплайна карточка сейчас выглядит как уверенный drafted: - артефактный слой собран; - основной смысловой слой поднят; - отсутствие Gemini-pass отмечено честно; - возвращаться сюда нужно только если понадобится отдельный реальный Gemini/enrichment-проход.

Выжимка

О чём этот доклад на самом деле

Александр Апазиди разбирает не вопрос «ускоряет ли AI программистов», а более неприятный для директора вопрос: почему локальное ускорение разработчиков почти не превращается в сопоставимое ускорение всей компании.

Его ответ жёсткий и довольно приземлённый: AI действительно ускоряет кодинг, иногда кратно, но выигрыш почти целиком съедается организацией — согласованиями, зависимостями между командами, регуляторикой, параллельной работой, переделками и платформенными бутылочными горлышками.

То есть тезис доклада не в том, что AI переоценён. Наоборот: AI реален, но он сдвигает узкое место из программирования в устройство компании.

Центральная мысль

Если сжать весь доклад в одну фразу, получится так:

После AI скорость кодинга перестаёт быть главным ограничением; теперь директора тормозит не разработчик, а сама система управления потоком.

Апазиди несколько раз возвращается к этой логике с разных сторон: - отдельный разработчик может ускориться в 3–5 раз; - маленькая независимая команда — в 2–3 раза; - большая организация — в лучшем случае примерно на 10%.

И это не парадокс, а арифметика. Если кодирование занимает лишь малую часть общего lead time, то ускорение только этой части почти не меняет общую скорость системы.

Главный нерв доклада: локальная производительность не равна системной

Апазиди очень аккуратно отделяет три уровня: - индивидуальный — разработчик пишет быстрее; - командный — маленькая автономная команда реально поставляет быстрее; - организационный — крупная компания почти не ощущает этого ускорения как бизнес-результат.

Это важное место, потому что доклад спорит не с AI, а с наивным управленческим выводом: «если дать всем copilot/cursor, то вся организация автоматически станет кратно быстрее».

По Апазиди это не работает, потому что в больших системах время уходит не только на код: - на решения до написания кода; - на ожидание другой команды; - на проверки, согласования, compliance; - на одновременное ведение слишком большого числа инициатив; - на rework; - на инфраструктурные/платформенные очереди.

Именно сюда, а не в IDE, должен смотреть директор.

Как он это доказывает

1. Через наблюдения с рынка

У доклада сильная эмпирическая база: автор опирается и на свой путь от разработчика до IT-директора, и на множество разговоров с разработчиками, тимлидами, руководителями отделов и C-level.

Картина у него получается такая: - отдельные сильные инженеры и маленькие студии реально говорят об ускорении в разы; - крупные компании говорят максимум о скромных процентах, причём часто даже не уверены, что это честно измеренный эффект, а не желаемое мышление.

То есть различие между «AI дал турбину» и «компания особо не полетела» у него не теоретическое, а наблюдаемое.

2. Через DORA и другие исследования

Доклад опирается на DORA-отчёты и на исследование Atlassian по developer experience.

Ключевой вывод из этой части: - AI даёт локальный выигрыш; - но throughput и стабильность системы не обязаны расти так же; - в 2024 и 2025 годах индустрия увидела не только ускорение, но и рост нестабильности/ошибок.

У Апазиди это встроено в общий тезис: команды начали быстрее производить output, но не научились так же хорошо встраивать этот output в управляемый организационный поток.

3. Через Голдратта и теорию ограничений

Самый полезный каркас доклада — перенос Голдратта на AI-эпоху.

Апазиди фактически говорит: - если компания не ускоряется, значит ускоряли не там; - узкое место после внедрения AI сместилось; - теперь час, сэкономленный на кодинге вне текущего bottleneck, почти ничего не даёт системе; - а час, снятый с реального организационного ограничения, ускоряет весь поток.

Это делает доклад очень директорским: он не про инструменты, а про перенастройку системы после сдвига ограничений.

Самая полезная часть: шесть типов потерь, которые съедают выигрыш от AI

Апазиди перечисляет шесть классов организационных потерь. Это, пожалуй, самый практичный кусок всего выступления.

1. Decision time

Время на решение ещё до начала кодинга: - споры архитекторов; - долгое принятие решений; - эскалация наверх; - ожидание арбитража от человека, у которого и так нет времени.

Раньше компания могла не замечать эту вязкость, потому что сама разработка была медленнее. Теперь, когда код можно получить быстро, медленное решение становится видимым bottleneck.

2. Зависимости между командами

Если команде A нужно что-то от команды B, никакой AI это автоматически не чинит. Здесь продолжают гореть: - блокировки; - ожидания; - очереди на чужую работу; - стыки ответственности.

Судя по реакции аудитории, именно этот класс боли узнаётся сильнее всего.

3. IT governance / проверки / комплаенс

Быстрый код ещё не значит разрешённый код. В больших компаниях ускорение упирается в: - ревью и проверки; - архитектурные стандарты; - требования безопасности и комплаенса; - долгий цикл допуска к production.

Хороший тонкий тезис здесь: если правил нет и всё приходится нести на ручное согласование архитектору, это само по себе организационная болезнь.

4. Параллельная работа

Это один из самых жёстких фрагментов доклада. Апазиди почти в канбан-риторике повторяет старую истину: stop starting, start finishing.

AI позволяет запустить ещё больше задач и недоделок, но это не ускоряет поставку. Наоборот: - очередь пухнет; - внимание дробится; - растёт незавершёнка; - команде тяжелее доводить что-либо до конца.

Для директора это превращается в прямой совет: смотреть не только на скорость отдельных людей, а на WIP/портфель/число одновременных инициатив на команду.

5. Rework

Скептики по AI у Апазиди появляются не как ретрограды, а как носители понятной боли: если AI быстро производит слабый код без достаточного контекста и ограничений, потом кто-то вручную разгребает последствия.

Иными словами: - AI ускоряет не только правильный output; - он так же быстро ускоряет производство техдолга, мусора и переделок.

Это не довод против внедрения AI, а довод против наивного внедрения.

6. Платформенные команды как новый bottleneck

Платформу часто создают как ускоритель, но в реальности она может стать ещё одной очередью.

Если для любого следующего шага нужно ждать платформенную команду неделями, она перестаёт быть enablement-функцией и превращается в ограничение потока.

Это сильный и полезный управленческий укол: даже «улучшающий» слой организации легко становится тормозом, если не измерять сервисность и скорость ответа.

Что директору делать по версии Апазиди

Доклад не сводится к диагнозу. В конце Апазиди даёт набор управленческих рычагов.

1. Перестать мерить суррогаты и смотреть на outcome/impact

Он опирается на старую, но до сих пор полезную рамку: effort → output → outcome → impact.

Смысл очень простой: - строки кода, PR и объём активности после AI ещё менее надёжны как ориентир; - директору важнее смотреть на общекомандные и общесистемные метрики; - поэтому DORA-метрики и похожие flow-метрики становятся полезнее, чем раньше.

Практически это означает смещение фокуса с «сколько сгенерировали» на: - частоту поставки; - lead time for changes; - стабильность; - инциденты в production.

2. Делать value stream mapping

Если из всего доклада оставить один самый рабочий совет, то это он.

Апазиди прямо предлагает: - проследить путь фичи от планирования до деплоя; - разложить шаги процесса; - увидеть, кто владеет каждым участком; - посчитать стыки и время ожидания.

Это важно, потому что после AI узкие места становятся контринтуитивными: раньше на них можно было не смотреть, а теперь именно они определяют скорость.

3. Давать полномочия на решения, а не только ответственность

Апазиди отдельно протаскивает тему DACI-подобной логики: у решения должен быть конкретный driver/owner, а не безликий коллегиальный орган.

Идея простая: - если сильные люди или команды реально производят в разы больше, - но не имеют права быстро убирать препятствия, - то организация сама обнуляет их выигрыш.

Это, пожалуй, одна из самых взрослых мыслей доклада: ускорение без перераспределения полномочий не долетает до результата.

4. Сокращать параллельность

Для компаний вне IT и для перегруженных внутренних IT-подразделений совет особенно жёсткий: не радоваться тому, что AI позволяет тянуть ещё больше задач, а наоборот резать одновременный портфель.

Его практическая логика такая: - спрос почти всегда превышает ёмкость; - ускорение разработки не уменьшает поток входящих хотелок; - если просто открыть ещё больше работ, будет только хуже.

5. Строить маленькие автономные команды

Один из самых убедительных мотивов доклада: маленькие независимые команды уже сейчас лучше извлекают пользу из AI, потому что у них меньше стыков и они ближе к outcome.

Это не романтика стартапов ради стартапов. Это структурная мысль: - меньше зависимостей; - короче контур поставки; - проще увидеть эффект; - меньше мест, где ускорение теряется.

6. Перераспределять высвобождаемую capacity в полезные задачи

Апазиди скептически относится к гордому рассказу о том, что люди получили больше happy time.

Его позиция понятна: если AI высвобождает 20–30% capacity, директору полезнее пустить её не в самодовольство, а в: - важные, но вечно отложенные инициативы; - улучшение системы; - проекты, до которых раньше «не доходили руки».

Это прагматичный взгляд без сладкой сказки про автоматическое счастье сотрудников как главный KPI внедрения.

Четыре типа компаний — четыре разных управленческих режима

Во второй половине доклада Апазиди делит компании на четыре архетипа, и это помогает не превращать советы в универсальную жвачку.

1. IT внутри не-IT компании

Типичный контур: - много входящих запросов от бизнеса; - большой legacy; - внутренний IT постоянно захлёбывается от спроса.

Здесь bottleneck — не скорость кодинга, а сам объём спроса и переключений. Значит: - нужно резать параллельность; - использовать AI для дешёвого прототипирования и быстрой проверки срочных бизнес-идей; - вытаскивать знания из незаменимых легаси-героев.

2. Большой enterprise

Здесь у автора почти нет иллюзий: главное ограничение — координация.

Поэтому бессмысленно фанатично смотреть на adoption-rate инструментов. Гораздо важнее: - выращивать новые процессы на пилотных командах; - перераспределять высвобождённую ёмкость осмысленно; - делиться полномочиями, если хочется реального ускорения.

3. IT-продукт

Здесь скорость действительно становится конкурентным преимуществом.

Апазиди советует: - не раздуваться без нужды; - оставаться маленькими и юркими; - использовать AI для быстрого тестирования гипотез; - усиливать продукт не только через кодинг, но и через встроенный AI.

Это, пожалуй, самый «про-ускорение» режим во всём докладе.

4. IT-аутсорс

Самая неприятная зона для старой модели, потому что продавать просто часы программистов становится всё слабее как аргумент.

Здесь Апазиди подталкивает к смене упаковки ценности: - продавать outcome и impact; - продавать доменный контекст; - продавать опыт внедрения AI и организационного переустройства, а не только «руки».

Это звучит жёстко, но довольно правдоподобно: AI бьёт как раз по самой копируемой части старого аутсорс-предложения.

Что в докладе особенно сильное

1. Он не спорит с реальностью AI

Апазиди не выглядит человеком, который хочет доказать, что хайп пустой. Он признаёт ускорение честно и прямо. Поэтому его скепсис к организационному эффекту звучит убедительнее.

2. Он переводит разговор из IDE в операционную модель

Это, наверное, главная ценность доклада для директоров. Вопрос ставится не как «какой AI tool выбрать», а как «какая часть системы теперь реально ограничивает поток».

3. Он хорошо соединяет старую управленческую классику с новой технологической волной

Голдратт, flow, WIP, value stream mapping, outcome-метрики — всё это у него не музей, а рабочий набор для AI-эпохи.

4. Он даёт внятный антидот против ложных метрик внедрения AI

Количество токенов, курсоров и adoption-rate у него выглядят почти как декоративная активность. Это полезный укол в эпоху, где легко перепутать инструментальное движение с реальным ускорением бизнеса.

Где доклад слабее или спорнее

1. Часть цифр и коэффициентов всё-таки эвристична

Логика убедительная, но некоторые проценты и пропорции скорее иллюстративны, чем строго доказаны для любой компании.

2. Местами он сознательно грубо огрубляет организационные типы

Для выступления это уместно, но в реальности внутри одного enterprise могут одновременно жить разные типы контуров, и один режим управления не покроет всё.

3. В practical layer мало внимания культурным и политическим ограничениям изменений

Апазиди правильно говорит про полномочия, стыки и власть, но естественно не успевает глубоко разобрать, как именно директору продавить эти изменения в уже закостеневшей системе.

Что даёт Q&A

Q&A в этом докладе небольшой, но полезный.

Он добавляет несколько акцентов: - незаменимого легаси-эксперта лучше не давить абстракцией «документируй себе замену», а разгружать и переводить в более сильную позицию; - value/effort после AI действительно сдвигается: effort дешевеет, а value начинает играть ещё большую роль; - бизнес-аналитики потенциально оказываются в сильной позиции, потому что умеют задавать контекст — а это становится критичным навыком; - локальным моделям автор лично не особенно доверяет и скорее склоняется к покупке сильного внешнего инструмента, если это возможно.

То есть финал не ломает рамку, а скорее добивает её практическими штрихами: будущее выигрывают не только кодеры, а люди, умеющие задавать контекст, убирать организационное трение и переводить ускорение в систему.

Сухой вывод

Если собрать доклад в рабочий остаток, получается так:

  • AI реально ускоряет кодинг, иногда очень заметно;
  • но в крупных системах кодинг больше не является главным ограничением;
  • выигрыш съедают решения, зависимости, проверки, незавершёнка, rework и платформенные очереди;
  • значит, задача директора — искать новое bottleneck на уровне потока, а не праздновать локальную продуктивность;
  • лучшие рычаги тут — value stream mapping, outcome-метрики, снижение WIP, маленькие автономные команды и перераспределение полномочий;
  • главный вопрос теперь не «ускорили ли мы разработчика», а ускорили ли мы компанию как систему.

Моя оценка

Это сильный, трезвый и очень директорский доклад про организационную экономику AI-ускорения.

Его главная польза в том, что он снимает магическое мышление. Не в смысле «AI не работает», а в смысле: работает, но теперь он беспощадно показывает, где у компании настоящие управленческие дыры.

Если сохранить одну мысль, то вот она: после AI выигрывает не тот, кто просто быстрее пишет код, а тот, кто быстрее перестраивает поток вокруг нового узкого места.