Тимлиды, мы в настоящем аду

Неспокойный во всех отношениях 2026 год. Мы, как самые большие молодцы, стараемся вывезти на себе всё возрастающую сложность перемен. Как лидеры наших команд, мы должны показывать пример, воодушевлять других, и конечно, быть в основных трендах профессии.

Все пишут, как ИИ поменял жизнь разработчика. Наш коллега IC стал эффективнее, он стал быстрее доносить пользу до продакшена, он настраивает себе все эти скиллы и MCP. В тысячах статей и сотне тысяч комментариев под ними программисты ведут бесконечный холивар: надо использовать ИИ всегда или только по особому случаю, тупеет ли человек от частого употребления ИИ или нет, больше стало багов или меньше.

Но что с управлением процессом производства ИТ-содержащего продукта на уровне команд? Понимаем ли мы реально, на каком вулкане сидим?

Я долгое время кодил, а теперь управляю командами в ИТ уже 5-й год. Мне, как и многим другим, сначала казалось, что процесс перехода на AI-driven development будет медленный, и мы всем сообществом что-нибудь придумаем. Но сейчас, в конце 2026, я стою и смотрю на эту картину, как тот зевака на балконе бейрутского отеля, который уже увидел взрыв в порту, но ещё не ощутил приход воздушной волны.

Давайте поговорим об этом?

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

1. Планирование

Раньше я как разработчик в прошлом и как тимлид понимал, сколько стоит программирование того или иного модуля, той или иной фичи. Программист писал код сам. Я примерно знал, чего это ему стоило по времени, в случае сомнений задавал вопросы, чтобы уточнить детали и сделать более адекватный прогноз. Также по каждому подчинённому у меня была статистика, насколько точно он попадает в собственные оценки. В итоге, если нам нужно написать типовой модуль, то мы с программистом решали, сколько это займёт времени в часах, плюс я накидывал его личный коэффициент и буффер запаса.

То же с тестами. Качественные unit-тесты добавляли 20-30% времени к разработке. С интеграционными чуть больше. У нас был простой выбор: хотим качества - закладываем коэффициент 1,4 к скорости разработки.

Теперь всё смешалось. ИИ может написать простой модуль за полчаса. Может написать сложную систему за час. Результаты не воспроизводимы раз к разу, когда его надо поправлять чаще, когда реже. Постоянно выходят новые модели, постоянно прибавляется новый контекст к уже имеющемуся проекту. Что теперь будет обещать программист в качестве срока разработки? - Он сам не до конца понимает эту магию. Совершенно точно, стало быстрее. Но насколько? И с какими trade-offs?

Раньше программист мог добавить 30-50% времени, чтобы допилить удовлетворительный код до состояния хорошего. Теперь кто ответит, сколько ему надо, чтобы довести работающую только по happy path систему до того же самого хорошего состояния? - Бог его знает, ведь код пишет ИИ.

2. Найм

Стало непонятно, как и кого нанимать. Раньше на собеседованиях мы предлагали выполнить задачи, просили предложить конкретные решения, поразмышлять об отличиях библиотек. Было видно, как быстро человек решает, насколько он в теме и, соответственно, на какой грейд может претендовать.

Теперь к нам приходят люди, которые не пишут код руками уже год или два. Естественно, на сессии live-coding у них получается так себе. Различия в инструментах, библиотеках? - Сейчас та же ИИ-шка распедаливает за минуту-другую основные преимущества и недостатки, никто уже не держит в голове все тонкости и различия. Что мы будем спрашивать у кандидата?

Говорят, больше внимания стало уходить в архитектуру. Но нужно ли нам, чтобы каждый первый был архитектором? Нам по прежнему нужно, чтобы каждый маленький и большой модуль был сделан хорошо, чтобы каждый алгоритм в системе меньше кушал памяти и быстрее выдавал результат. Могут ли “архитекторы”, которые рисуют свои стрелочки с помощью всё тех же ИИ, помочь нам в этом? Как мы поймём, что у кандидата достаточно навыков, чтобы контролировать то, что поставляет ему модель? Просим написать решение самому, и попадаем в начало: руками уже мало кто пишет.

Кажется, нам ещё могут помочь всякие код-ревью и расспросы о подробностях лично выполненных проектов. Но настоящее знание кандидата оценить стало сложнее.

3. Качество продукта

На собеседованиях я стал спрашивать у кандидатов одну и ту же вещь: вот вы пишете код с помощью ИИ, а как вы теперь обеспечиваете качество решения? Люди, как правило, сами понимают, что это сложно. Кто-то даёт одному агенту проводить код-ревью результата работы другого, кто-то ещё толще обмазывает всё интеграционными и e2e-тестами. Но сами тесты тоже пишет ИИ.

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

Короче, у нас нет понимания, как точно повышать качество и предсказуемость продукта. Справедливо говорят, что и раньше говнокодили, без ИИ. Да, говнокодили. Однако был понятный путь: больше уделяешь времени проектированию, тестам, берёшь людей выше квалификацией, организуешь процессы вроде арх.комитетов и код-ревью, - и качество гарантированно становится выше. Теперь ничего не гарантировано, во всех элементах процесса SDLC присутствует наш непредсказуемый электронный помощник.

4. Все пишут собственные инструменты

Раньше были внешние инструменты, относительно которых мог быть достигнут консенсус. Условный Confluence плюс 2-3 альтернативы, и так в каждом из узких направлений применения ПО.

Теперь любой разработчик с помощью ИИ берёт и вайбкодит собственную точно самую лучшую CRM, точно самую крутую UI-библиотеку, самый отличный коннектор с логистическими операторами и так далее. Он проактивен, он хочет принести пользу, он хочет как лучше.

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

Раньше шутили, что перед создателями JS-фреймоворков стоит проблема, как назвать очередное 100500-е поделие. Теперь, кажется, эта проблема стоит перед всем ИТ-шным миром: настолько быстрее стали выходить новые сущности абсолютно по любой теме!

5. Люди те же, но ждут от них другого

Сначала заявлю о концепции "универсального IC", которая прочно поселилась в умах топов.

Сейчас многие компании ждут от исполнителей универсальности: в светлых корпоративных мечтах IC будет и сам договариваться с бизнесом, и сам ставить архитектуру, и сам приоритизировать требования, и контролировать качество и целостность продукта и т.д. и т.п. Работодателю проще, когда больше не нужно думать о специализации сотрудников, а иерархии управления становятся более плоскими: в теории это повышает скорость оборачиваемости информации и упрощает принятие решений!

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

И вот теперь корпорация объявляет, что ожидает от всех нас совсем другой работы. Мы теперь "исполнители с мышлением предпринимателя". Мы не халявщики, мы партнёры!

Естественно, люди не могут поменять свой стиль мышления так быстро. Кто-то вообще будет не в состоянии перешагнуть за рамки своего психотипа и адаптироваться. Огромное количество прежних хороших разработчиков просто не впишется во всё это. Вам и так непонятно, кого теперь нанимать (см. п.2). Но вы и не знаете, а существуют ли воображаемые руководством люди в достаточном количестве?

6. Тотальная эмансипация сотрудников от работы

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

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

Люди прекрасно понимают, что ещё год-два, и профессии "программист" в прежнем понимании не будет. Одни компании ждут, что у них вместо программистов появятся "универсальные IC" (см. выше), другие просто всех сократят. Сколько бы ты, тимлид, не старался вовлекать сотрудников, перед краем водопада большинству уже всё равно. Масштаб надвигающихся перемен таков, что ничто не может их залакировать. А главное, у тебя у самого нет никакого видения, как будет там, за границей нашей ИТ-шной технологической сингулярности. Говори что хочешь - ты со всеми в одной лодке.

Впереди неопределённое будущее, и это на самом деле очень плохо влияет на людей. 10 или 20 лет назад мы понимали Путь: есть новые языки, фреймворки, технологии. Можно спокойно двигаться по лестнице вверх в лиды или вбок в спецы, но заниматься тем, чем любишь. Сейчас у людей сильная тревожность, потому что никто не знает Пути. Всё привычное быстро рушится.

И с такими растерянными людьми гораздо труднее делать что-то. Быстро набросали фичу ИИ-шкой, быстро задеплоили, ещё один день прошёл. Это не их вина как сотрудников и не твоя как тимлида. Никто не виноват.

Вторую группу я бы назвал так: работа с заказчиком и руководством.

7. Рефакторинг стало ещё труднее прятать

Раньше было относительно просто спрятать рефакторинг среди другой работы. Иногда даже начальство явно шло навстречу. У меня был один прекрасный директор, который сразу согласился, что 20% времени команда рефачит.

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

Серьёзный рефакторинг, перепроектирование теперь на фоне 1-2-дневных фич выглядит чуть ли не как преступление. Было: 3 недели мы делаем 6 фич, одну неделю рефачим, это вещи сопоставимые. Теперь: прежние 6 фич мы делаем за 3 дня, а на рефакторинг вы берёте пусть не прежнюю неделю, а те же три дня. Соотношение из 3 к 1 стало 1 к 1. WTF, тимлид, что у тебя творится в команде???

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

8. Что мы будем делать в час Ч?

Мне кажется, этот час неминуемо настанет. Сейчас я думаю, практически гарантированно будет какая-то мощная авария, связанная с ИИ. Просто слишком много данных течёт во все стороны, слишком напряжённая политическая ситуация в мире. Нельзя, чтобы такими возможностями никто не воспользовался. Либо даже что-то плохое произойдёт просто по глупости и расслабленности разработчиков, абсолютно всё доверяющих ИИ.

Представьте. Утром вы читаете в новостях, что ИИ страны N смог положить национальную систему здравоохранения (энергетики, транспорта, etc) страны K. Всё. Правительства, регуляторы обрубают любые доступы на сервера поставщиков, чьими услугами вы привыкли пользоваться. И ваши разработчики уже 3 года не писали код руками.

У вас есть, что предложить начальству? Почему фича теперь не будет выходить за 3 дня в прод, как раньше? Ведь вашим ребятам придётся не то чтобы стараться писать код с прежней скоростью, а вообще вспоминать, что такое "писать код". Или использовать гораздо менее продвинутые отечественные модели.

И нет, это не пугалка из серии "а что если отключат электричество, как вы будете тогда писать свой код?". То, о чём я говорю, произойдёт со 100%-ой вероятностью и достаточно скоро. Собственно, мы уже слышим этот приближающийся грохот в виде внезапных санкций и банов целых стран у разных поставщиков моделей. Пока не видно, почему ситуация не должна идти по этому пути и дальше.

Всё это мы, конечно, постараемся объяснить руководству. Но крайними будем всё-таки мы, т.к. отвечаем за процесс прозводства программного продукта. Тимлид - первый на роль козла отпущения!

9. Ускорение разработки не всегда ускоряет всё производство

Раньше разработка была часто самым медленным и дорогостоящим элементом всего производства в ИТ. Программистов долго нанимали, они съедали огромную часть ФОТ. Наконец, их всех собрали, организовали, и они сидят свои человеко-месяцы пилят продукт.

И вот настали славные времена, всё это можно значительно ускорить всего лишь за стоимость подписки в 500, 100 или даже 20 долларов. Уверен, что многие топы ожидали тут ускорение всего процесса доставки ценности для потребителя: как же, мы ускоряем самую медленную часть!

Неприятное открытие состоит в том, что если вы не позаботились о других частях, то расшивание одного узкого места открывает новые узкие места. Это банальное следствие системного подхода. Если у вас процессы не налажены, маркетинг постоянно ругается с финансами, продажи сами по себе, а CPO вообще думает уходить, то быстрое изготовление кода не спасёт дела всей фирмы.

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

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

Третью группу выделю как опасения тимлидов по поводу самих себя.

10. Тимлидов будут сокращать

В связи с ожиданиями от универсальности сотрудников (см. п. 5), роль тимлида ставится под сомнение. Раньше было понятно, зачем он нужен. Вот есть люди разных специализаций: бэки, фронты, QA, аналитики, проджекты, техписы и т.д. Всех их надо как-то координировать, обеспечивать правильный поток информации, проведение решений, согласованность.

А теперь появляется простой и понятный соблазн: если исполнители в связке с агентами умеют весь процесс делать сами, то зачем им координатор, мотиватор и контролёр? В умах рисуется прекрасная картинка: есть топы, есть IC, вооружённые самыми умными электронными помощниками, а весь средний слой "дармоедов" сокращён ради экономии ФОТ и "обеспечения гибкости".

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

11. Тимлиду некуда бежать

Но и на рынке теперь сложнее. Раньше для уставших тимлидов был ясный и понятный путь - обратно в сеньоры. Это было сплошь и рядом. Человек залетел на управленческую должность, понял, что не его, что не хочет он сидеть на 10 совещаниях в день и решать человеческие проблемы, а хочется ему обратно в кодинг. Если он не забрасывал полностью написание кода, то обратный переход производился практически безболезненно.

Теперь всё сложнее. Вы не можете просто взять и вернуться к написанию кода руками - программисты уже сами не пишут код руками! Мало того, и само программирование может быть далеко не единственным занятием разработчика - смотри тезис выше про ожидания компаний по поводу "универсальных солдат" (п.5).

И потом. Даже если вам всё таки дадут место программиста, а не универсального исполнителя на все руки, то инструментарий в этой среде меняется с бешеной скоростью. Раньше было всё примерно то же самое: IDE, консоль, браузер и docker. Теперь же за год поменялось буквально всё: какие-то харнесы, какие-то MCP-сервера, всё это само себя контролирует, пушит в репу, делает ревью и рефакторинг... Лично я, активно писавший код ещё 3 года назад, понимаю, что многие мои навыки можно забыть, сейчас так уже никто не делает! Придётся как минимум сильно переучиваться.

12. Тимлид теряет ориентиры

У среднего и нижнего слоя управленцев в любой компании есть одна очень важная функция: доводить политику партии до исполнителей. Тимлид должен понимать, куда примерно движется компания, департамент и отдел и в нужном компании русле транслировать правильные установки ниже.

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

Да, и топам тяжело в этом всё ускоряющемся мире инноваций, и они не знают, что транслировать вниз, потому что каждый год меняется очень многое. Но нам, тимлидам, от этого не легче: честно говоря, нет ни сил, ни времени на свой страх и риск и только под свою ответственность заниматься ещё и стратегией. А люди приходят на 1:1 и спрашивают: куда же всё это движется? Нет ответа...

13. Бутылочное горлышко при повышенном давлении

Last, but not least. И что характерно, пункт с самым "счастливым" номером. Во многих командах, чего уж греха таить, тимлиды являются т.н. "бутылочным горлышком" - элементом цепи, который загружен больше всех.

В связи с вышеперечисленным нагрузочка на нас возросла ещё. Сможем ли мы её хоть как-то перераспределить на другие звенья? - Это большой вопрос. Но пока всё ложится на старый паттерн, где тимлид в итоге отвечает почти за всё на производстве ПО. И поэтому у статьи именно такое заглавие...

Завершение

Для иллюстрации я выбрал картину Константина Юона "Новая планета". Она была написана в 1921 году, во времена, когда наше общество переживало огромные перемены.

Сейчас мы тоже переживаем большие изменения, это невозможно отменить. Но на что можно положиться нам, тимлидам? У меня есть ответ.

Я думаю, что самое главное в работе руководителя всегда и везде, на любом уровне - это работа с людьми. Что может быть автоматизировано, будет автоматизировано. Но отношения человек-человек всегда безграничны. Пока существует человечество, люди будут находиться в отношениях.

Тимлидам можно и нужно углублять свою экспертизу в части взаимодействия с другими людьми. Пока некоторые странные работодатели до сих пор спрашивают на собеседованиях тимлидов особенно высокие навыки написания кода (может быть даже фломастером на флипчарте). Но в итоге правы будут те, кто вручает тимлидам самую ответственную часть - people management. Очень быстро, по историческим масштабам мгновенно профессия программиста как изготовителя кода исчезает. Но никуда не исчезают люди, которые собираются в компании и делают что-то новое.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку