Перейти к содержимому

AI отнимает работу мидла, а не синьора – и почему это твоя проблема

· 14 мин
Software Engineer & Tech Lead · 11+ лет в .NET, опыт в FinTech, EdTech и Travel
Инженер и машина Часть 1 из 2
Содержание

TL;DR: Агенты уверенно делают "понятное по спецификации" – класс задач, на котором держался мидл-ярус и на котором индустрия выращивала синьоров. Синьора машина не заменяет – она делает его работу тяжелее: он становится источником спецификаций и последним, кто умеет растить людей.

Конец 2025-го. Контракт в лизинговой компании: делаю систему многоканального колл-центра для менеджеров по взысканию. Сервис – узловая точка интеграций, и мне нужен клиент к API колл-центра. Swagger'а у этого API нет. Документация – файл. За десять лет в интеграциях поменялось всё, кроме этого.

Я не сел писать клиент руками. Сначала описал агенту, как мы пишем код в этом проекте: как устроен API client поверх корпоративных cross-cutting библиотек, как делаем интеграции, как покрываем сценарии e2e-тестами. Потом дал доку и сказал, что хочу получить.

Агент вернул код, который я написал бы сам, плюс-минус. Из придирок – он упорно расставлял [JsonProperty] на DTO, хотя я просил использовать глобальные настройки сериализатора. Пару раз поправил – привык. Всё остальное, клиент, маппинг, тесты, читалось как работа крепкого мидла, которому дали внятную постановку.

И тут до меня дошло, на что это похоже. Я говорю, ЧТО хочу получить, и почти не говорю КАК. Именно так я ставил задачи мидлам, когда был тимлидом.

Только мидла в комнате нет.

Про этот момент сейчас пишут в двух жанрах: евангелисты обещают, что скоро не будет и синьоров, скептики успокаивают, что "настоящую инженерию" машина не возьмёт никогда. Я собираюсь сказать другое. AI действительно забирает работу – но не ту, о которой все спорят. Он забирает мидл-ярус. И для синьора это плохая новость, хотя и не та, которой он боится. Разбирать буду не на абстракциях, а на том, что видел сам: на своих проектах и на историях моих друзей, выросших у меня на глазах.

Что такое мидловая задача, и почему агент делает её так хорошо

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

Таких задач в индустрии большинство. И у этого есть прямое следствие: именно этот класс задач лучше всего представлен в данных, на которых учились модели. Миллионы API-клиентов, миллионы маппингов, миллионы CRUD-эндпоинтов и форм – самый калиброванный, самый частотный, самый воспроизводимый пласт инженерной работы. Агент генерирует усреднённый код индустрии – не гениальный и не мусорный, средний. А средний код индустрии – это и есть добротная мидловая работа.

Мой случай с [JsonProperty] – усреднение в миниатюре. Я попросил глобальные настройки сериализатора, агент согласился и всё равно первое время сползал в атрибуты на каждом проперти модели. Потому что в его обучающей выборке атрибуты встречаются на порядки чаще. Он не спорил со мной – его просто тянуло к среднему по индустрии, как гравитация. Про то, что из этого следует для архитектуры (спойлер: агент по умолчанию выдаёт анемичную модель, и это честное зеркало нас самих), будет отдельная статья – следующая в цикле.

Пока зафиксируем главное. Агент закрыл ровно тот ярус, на котором индустрия держала целый грейд живых людей, – а не "простые задачи" и не "рутину джуна".

Одна и та же задача: 2016 и 2026

В 2016-м я был мидлом-фуллстеком в business travel: автоматизированное рабочее место менеджера продаж билетов. Кассир, у которого по телефону или онлайн заказывали ж/д, авиа, трансферы и гостиницы – в основном b2b, командировки. Мои задачи того времени: добавить параметры в фильтры поиска, получить схемы вагонов, сделать автокомплит станций и аэропортов, расширить статусную модель брони, добавить составные маршруты с пересадками в одном заказе, сделать динамическую форму данных пассажира. И интеграции с GDS – много интеграций, в основном на SOAP XML.

Типовая интеграция выглядела так. Утро начинается не с кода, а с PDF на 150 страниц: описание методов, XML-схемы, заголовки, коды ошибок. Читаешь, выписываешь нужные вызовы, руками собираешь первый тестовый запрос – копипастой из PDF, потому что машиночитаемого контракта нет. Запрос падает. Не потому что ты ошибся: в PDF поле называется PassengerDoc, а реальный сервис ждёт PassangerDoc, с опечаткой, и так уже 5 лет, и никто не поправит, потому что на опечатку завязаны все существующие клиенты.

К обеду – переписка с саппортом поставщика и тыканье запросами вслепую. Вечером маппишь их XML на свою модель брони, дописываешь ветку в статусную модель, правишь SQL, накидываешь тесты на маппинг. Деплой полуручной: собрал, залил, проверил на стейдже.

Неделя-две такой работы – и интеграция готова. Понятная по спецификации, насколько PDF можно назвать спецификацией. Объёмная по механике. Без единого архитектурного решения. Чистая мидловая работа, и я делал её старательно и с удовольствием.

Теперь 2026-й, тот самый колл-центр. Типовая интеграция – api-клиент, маппинг, тесты, дебаг – занимает от 3 часов до дня. Против недели-двух. И моя роль в ней другая: я не воюю с PDF за каждое поле. Я готовлю агенту контекст, ревьюю его концепт, проверяю крайние случаи – и замечаю то, что машина не пометит как проблему. Опечатку в чужом контракте агент честно воспроизведёт в коде и пойдёт дальше. Заметить, что PassangerDoc – не баг, а чужая реальность, с которой придётся жить, по-прежнему моя работа.

Вот сам сдвиг, прямым текстом. Раньше цепочка выглядела так: синьор пишет постановку → мидл делает → синьор ревьюит и добивает крайние случаи. Теперь: синьор пишет постановку → агент делает → синьор ревьюит. Из цепочки выпало звено, но не работа. Работа синьора сместилась от ревью кода к ревью решений – и к производству спецификаций. Спецификация стала исходником: чем она точнее, тем лучше результат генерации.

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

Три ловушки, в которые синьор наступает по дороге

Ловушка первая: "я ускорился"

Ты действительно ускорился. Вопрос – в чём. Интеграция за день вместо двух недель – это ускорение мидловых задач, и оно реальное. А вот архитектурные решения, разбор трейд-оффов, выяснение, что бизнес имел в виду на самом деле, – всё это занимает столько же, сколько раньше. Ускорилась одна половина твоей работы. Та, которая и так была дешевле.

Индустрия уже прошлась по этим граблям на уровне целых компаний: исследования DORA зафиксировали, что взрывной рост AI-adoption сначала вообще не ускорил поставку ценности – код писался быстрее, а показатель end-to-end delivery не рос, потому что узкое место было не в кодинге. Телеметрия Stanford показала выросший revert rate: написали, обрадовались, потом сами же переписали. А эксперимент METR получился совсем неудобным: опытные разработчики на собственных, хорошо знакомых кодбазах решали задачи с AI медленнее, чем без него, – и при этом были уверены, что ускорились. Личное ощущение скорости и системная скорость – разные величины, и путать их дорого.

Ловушка вторая: стать самому себе мидлом

На проекте колл-центра я посчитал: интеграции с 8ю подсистемами, api-клиенты, маппинги туда-сюда, бэковая инфраструктура – и 3-4 действительно сложных бизнесовых алгоритма с развилками. Процентов 90 работы на живом проекте – мидловая по форме. Так было всегда, просто раньше её размазывали по команде.

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

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

Ловушка третья: "я больше не пишу код"

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

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

Что на самом деле защищает синьора

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

Твой домен. Опечатка PassangerDoc, на которую завязаны все клиенты поставщика. Знание, что "бронирование" в travel – это три разные сущности, смотря кого спросить, и правила взыскания, которые менеджер колл-центра рассказывает голосом, потому что ни в одном документе их нет. Всё это не лежит в training data – оно лежит в головах, и переносится в постановки только через тебя.

Трейд-оффы. Агент крут в задачах с известным ответом и беспомощен там, где ответ надо выбрать и за него отвечать. Взять ли готовую библиотеку с лицензионным риском или написать своё за неделю; резать ли фичу под дедлайн; какой из трёх компромиссов переживёт следующий год. Это решения, которые не выводятся из спецификации – они спецификацию создают.

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

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

Конвейер остановился – и вот это уже твоя проблема

До сих пор новости для синьора были сносные: работа меняется, но не исчезает. Теперь плохая.

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

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

Лёха – это "было". Мой близкий друг, в IT пришёл из отдела безопасности торгового центра – прошёл курсы по основам HTML, CSS и JS, после которых до разработчика ещё расти и расти. Мы почти год в свободное время делали ему учебный проект на Angular – настоящий, для портфолио. Потом я взял его на подхват в проект онлайн-школы: сам закладывал базу в фичи и пускал его по протоптанной тропинке, постепенно усложняя задачи. Когда он застревал, устраивал парное программирование: обычно он делал под моим присмотром, иногда я показывал ход своих мыслей вслух. Полгода до полноценного джуна, ещё год до мидла, потом год вдвоём в стартапе, где он в одиночку тянул весь фронт. В итоге, через несколько лет – сильный самостоятельный мидл+ специалист.

Его типовая задача на этапе роста в мидла – динамические формы с валидацией для инвест-калькуляторов, "ипотека vs съём жилья" и ему подобные. Прочитай это ещё раз: та же задача, что растила меня в 2016-м на форме данных пассажира. Одна и та же задача вырастила два поколения инженеров. Сегодня агент делает её за полчаса. Лестница, по которой Лёха поднялся из "не-айтишника" в крепкого инженера, распилена – ступенька за ступенькой, тем же инструментом, которым я теперь делаю интеграции за день.

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

Серёга – это "стало". Познакомились в CloudPayments, он был сильным automation QA и очень хотел в бэкенд-разработку. Годы в автоматизации тестирования – фундамент, которого не бывает у джуна: человек уже насмотрелся, как и где ломаются системы. В конце 2024-го я позвал его на свой следующий проект, потом в стартап, где я соучредитель, – работаем вместе до сих пор. Сначала он делал руками, агентов тогда ещё не было: задачи по аналогии, потом инфраструктура бэкенда, перенос функционала с другого языка, много тестов. К лету 2025-го брал целые модули – поставки на маркетплейсы, аналитика, рекомендации. Осенью 2025-го делал это уже с агентами, а в этом году собрал собственный агентский пайплайн и работает полностью AI-augmented.

С Серёгой я не нянчился – моё менторство свелось к подбору разносторонних задач и валидации концепций, которые он составлял до того, как идти кодить. Обрати внимание на этот формат: я ревьюил не строки кода, а концепты. Говорил, ЧТО не так, и почти никогда – КАК исправить. Менторство мидла уже было работой с агентом – за год до того, как агенты появились. Разница обнаружилась позже, и она принципиальная: мидл на таком делегировании рос, а агент – нет. Серёга дорос до синьора. А агент завтра снова расставит [JsonProperty] вместо настройки сериализатора.

Честности ради, вопрос, на который у меня нет ответа: Серёга успел набить интуицию руками – агенты пришли, когда фундамент уже стоял, и легли на него усилителем. А если бы они были с первого дня? Вырос бы он – или научился бы виртуозно закрывать тикеты, так и не став инженером? Я склоняюсь к худшему варианту, но проверить это индустрия сможет только на живом поколении.

Сложи всё вместе. Лестница распилена. Джун с агентом не превращается в мидла сам собой. Рост, который случался как побочный эффект потока задач, теперь возможен только как штучная ручная работа синьора – как с Лёхой, как с Серёгой, только труднее, потому что "лёгких настоящих задач" для подопечного больше нет. Если тебе, техлиду, некогда этим заниматься – через несколько лет твоя команда состоит из тебя, агентов и джунов, которые так и не стали мидлами. И весь груз, который раньше несли мидлы и который не берёт машина, лежит на одном человеке. На тебе.

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

Ставка выросла

Соберу тезис целиком, без страшилок и без утешений.

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

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

Начнём со следующей статьи – с того самого усреднения, которое я поймал на [JsonProperty]: почему агент по умолчанию генерирует анемичную модель и что твоя архитектура должна уметь, чтобы это выдержать.

Обсуждаем в моём телеграм-канале.

Что почитать

ai career engineering-culture mentoring
Поделиться: Telegram X