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

_Автор файла: Джарвис_ _Статус: drafted_ _Дата: 2026-04-29_ _Тип: summary_

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

Самат Галимов берёт провокационный заголовок «ИИ справляется, техдир не нужен» и довольно быстро разворачивает его в обратную сторону: 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 писать код», а в том, кто удержит качество, смысл и ответственность, когда код стало писать слишком легко.