11 — ИИ справляется, техдир не нужен

Статус: drafted

Спикер / автор: Самат Галимов

Описание

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

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

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

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

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

Одиннадцатый talk по текущей структуре/очереди — это доклад Самата Галимова «ИИ справляется, техдир не нужен».

Теперь по нему собраны уже не только артефакты, но и базовый смысловой слой: - canonical source links (YouTube + Teachable); - slides.pdf (3.3.pdf) из описания YouTube; - chat.pdf (Chat3.pdf) из описания YouTube; - transcript.raw.json через youtube-transcript-api; - transcript.md с 2-минутной нарезкой; - семь chunk-файлов по ~8 минут; - содержательный summary-jarvis.md; - честный comparison.md; - Gemini placeholders (summary-gemini-raw.md, summary-gemini.md) со статусом not run.

Что важно по смыслу доклада

Главная мысль этого talk: AI действительно хорошо ускоряет локальную разработку — прототипы, простые сервисы, тесты и разбор старых кодовых баз, — но это не отменяет техдирскую функцию, а делает её заметнее. Центральные опоры доклада: - скорость генерации кода не равна способности долго и предсказуемо доставлять результат; - AI может ускорить вход не только в продукт, но и в legacy / техдолг; - тесты, staging, CI/CD, ограничения доступа и модульная архитектура становятся не менее важными, а важнее; - главная человеческая ценность смещается к ответственности, постановке задач, принятию результата и разговору с бизнесом о форме решения.

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

  • В описании YouTube для этого ролика явно указана презентация 3.3.pdf, так что в отличие от talk 10 здесь привязка слайдов выглядит твёрдой.
  • youtube-transcript-api на этом ролике сработал успешно (1434 сегмента, длительность около 00:55:04).
  • yt-dlp --list-subs показывает длинный список автоматических caption languages, но в конце одновременно пишет has no subtitles; для этого доклада это не блокер, потому что основной transcript-слой уже удалось получить через youtube-transcript-api.
  • В сыром transcript заметен небольшой хвостовой шум автосабов в самом конце, но он не мешает semantic-pass'у.
  • Gemini-pass здесь сознательно не запускался; вместо выдуманного слоя зафиксированы честные placeholders not run.

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

Для staged-логики проекта talk сейчас выглядит примерно на 90–93% готовым: - артефактный слой собран; - основной semantic-pass закрыт; - незакрытый хвост — только optional enrichment (реальный Gemini-pass, второй проход по цитатам/чату), а не structural gap.

Выжимка

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

Самат Галимов берёт провокационный заголовок «ИИ справляется, техдир не нужен» и довольно быстро разворачивает его в обратную сторону: AI отлично ускоряет локальную разработку, прототипы, тесты и разбор старых кодовых баз, но именно поэтому роль техдира и сильного инженерного управления не исчезает, а становится жёстче и заметнее.

Это не доклад в жанре «AI всё заменит» и не доклад в жанре «ничего не меняется». Скорее это трезвый разбор того, где AI уже даёт реальную производительность, а где он так же быстро разносит систему, если нет архитектуры, ограничений, девопс-контуров, тестов и людей, которые умеют держать обещания и разговаривать с бизнесом.

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

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

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

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

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

Но это только конфетно-букетный период. Главная проблема начинается потом: - растёт legacy; - ухудшается предсказуемость сроков; - любое изменение начинает ломать соседние части системы; - без тестов и staging каждый шаг дорожает; - без нормальной постановки задач команда начинает делать «не то, но формально по запросу».

И вот здесь AI не лечит фундаментальную проблему сам по себе. Более того, он её ускоряет.

Самый полезный образ доклада: AI как спидран в legacy

Один из лучших фрагментов — аналогия со speedrun из игры: путь, который раньше занимал сотни часов, теперь можно «заглючить» и пролететь за минуты.

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

Но расплата в том, что в legacy, техдолг и неуправляемость команда тоже влетает намного быстрее. Раньше до такого состояния можно было добираться полгода-год. С AI — за дни, а иногда за часы.

Отсюда и разворот к теме техдира: чем быстрее система разгоняется, тем важнее тот, кто держит рамку и ограничения.

Где AI уже реально полезен по версии Галимова

1. Прототипы и маленькие новые продукты

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

При этом он отдельно подчёркивает: не так важно, какой именно моделью пользоваться. Важнее: - не брать совсем слабую; - давать модели удобный стек и framework-friendly окружение; - нормально проговаривать задачу; - заставлять модель сначала уточнять и пересказывать понимание, а не сразу бежать кодить.

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

2. Чтение и разбор больших старых кодовых баз

Вот здесь доклад становится особенно сильным. Галимов говорит не только про генерацию кода, а про ускорение понимания legacy-систем.

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

Тонкий, но важный тезис: нельзя просто скормить 10 ГБ репозиториев и ждать ответа. Нужен подготовительный слой, структурирование и guiding. То есть AI работает не вместо инженерного мышления, а как его усилитель.

3. Генерация тестов

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

Галимов прямо связывает старую инженерную дисциплину с новой волной инструментов: - тесты уменьшают риск плохого slop-кода; - тесты позволяют быстрее принимать или отклонять машинные изменения; - тесты дают хоть какую-то защиту при росте скорости генерации.

При этом он не идеализирует результат: AI может написать красиво выглядящий тест, который не проверяет суть. Значит, программист всё равно нужен как редактор и контролёр смысла.

Что AI не решает и что делает даже опаснее

1. Безопасность и цена ошибки

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

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

Это подводит к важному тезису: безопасность нельзя решать промптом “никогда не делай деструктивных действий”. Нужны инфраструктурные ограничения: - отдельные read-only пользователи; - жёсткие контуры доступа; - staging; - devops и системная админская работа.

То есть ответственность техдирского уровня здесь даже не уменьшается, а вылезает наружу намного сильнее.

2. Архитектура и модульность

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

Поэтому Галимов возвращает в центр старые инженерные добродетели: - loose coupling; - нормальный deployment-контур; - CI/CD; - staging; - управляемые миграции; - понятная инженерная структура.

Это почти антихайповый тезис: будущее почему-то всё равно требует скучной взрослой базы.

3. Разговор с бизнесом о том, что дешёво, а что ломает систему

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

То есть не просто принимать запрос, а объяснять: - какие варианты похожи по смыслу, но сильно отличаются по цене реализации; - что почти бесплатно ложится в текущую архитектуру; - а что требует переделывать половину системы.

Галимов подчёркивает: нейросеть пока не умеет по-настоящему держать эту переговорную позицию. Она не отвечает за долгосрочную форму системы и не ведёт сложный разговор о компромиссах. А человек — должен.

Это и есть один из его главных аргументов против тезиса «техдир больше не нужен».

Что остаётся сугубо человеческой работой

1. Давать обещания и выполнять их

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

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

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

2. Создавать среду, а не только нанимать умных людей

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

Это уже чистая руководительская функция. AI здесь вообще не субъект. Он ничего не строит и не удерживает — он лишь увеличивает скорость всех процессов, в том числе плохих.

3. Ставить задачи и принимать результат

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

Отсюда его практическая формула: - сначала план; - потом исполнение; - план можно прогонять на более умной модели; - исполнение — на более дешёвой; - всё это должен контролировать человек.

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

Что он думает про «остриё прогресса»

Галимов отдельно обсуждает две модные зоны: - automated research / auto-optimization по метрикам; - agentic programming, где нейросети ставят задачи нейросетям.

Он не отрицает, что это интересно и потенциально мощно. Более того, кейс с Shopify и ускорением template-языка на хорошо тестируемом контуре он явно считает серьёзным сигналом.

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

Это хороший докладчик не про frontier-for-frontier’s-sake, а про инженерную экономику внимания.

Что меняется в роли техдира

Если собрать доклад в ответ на заголовок, то получится примерно такая схема.

Техдир не исчезает, а сдвигается из роли «главный человек, который понимает технологию и иногда кодит» в роль человека, который: - помогает команде научиться ставить задачи AI-инструментам; - выращивает практики принятия и проверки результата; - задаёт безопасные и управляемые контуры для автоматизации; - строит правила, чтобы ускорение не разнесло компанию; - удерживает разговор между кодом, инфраструктурой и бизнес-смыслом.

Иными словами, AI уменьшает ценность голого ручного набора кода, но повышает ценность инженерного руководства как системы ограничений, ответственности и смысла.

Где доклад особенно силён

1. Он не врёт про скорость и не врёт про расплату

Галимов одновременно признаёт реальную пользу AI и очень внятно показывает цену этой пользы. Не «всё плохо» и не «всё решено», а нормальная двусторонняя картина.

2. Он хорошо заземляет разговор в production reality

Это не теоретизирование снаружи индустрии. Доклад построен на опыте аудитов, legacy-систем, багов, staging-проблем, доступов и слабой инфраструктурной дисциплины. Поэтому он полезен именно командам, которые живут не в идеальном AI-demo-мире.

3. Он правильно возвращает в центр скучные инженерные основы

Тесты, CI/CD, staging, модульность, ограничения доступа, нормальный devops — всё это у него не старьё, а prerequisites для безопасного AI-ускорения.

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

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

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

1. Местами он опирается на сильные интуиции больше, чем на формальные данные

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

2. Линия про «людей можно выбирать, но трудно менять» звучит жёстко

В ней есть жизненная правда, но формулировка довольно категорична. Для части аудиторий она может звучать слишком фаталистично.

3. Некоторые frontier-направления он сознательно недооценивает для массовой практики

С его позиции это рационально, но через год-два часть из этих направлений может стать более прикладной, чем ему сейчас кажется. То есть это сильный тезис именно на текущем срезе времени.

Что даёт Q&A

Секция вопросов не ломает основную рамку, а укрепляет её.

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

Хороший добавочный нерв Q&A: AI не просто ускоряет разработку, он беспощадно проявляет внутреннюю незрелость инженерной системы.

Сухой вывод

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

  • AI уже отлично ускоряет маленькие продукты, прототипы, тесты и разбор legacy;
  • при этом он же резко ускоряет накопление техдолга, вероятность ошибок и цену слабой инженерной дисциплины;
  • безопасность, архитектура, CI/CD, staging и ограничения доступа становятся не менее важными, а более важными;
  • техдир нужен не как тормоз прогресса, а как человек, который делает ускорение управляемым;
  • главная человеческая ценность смещается от голого кодинга к ответственности, постановке задач, принятию результата и разговору с бизнесом о правильной форме решения.

Моя оценка

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

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