ИИ поедает мидлов? Он бы съел и джунов, но их больше нет

11 августа 2026 года Флориан Херренгт, инженер, который каждый день работает с ИИ-агентами и пишет об этом в своём блоге, опубликовал текст, разошедшийся по англоязычным лентам: AI is removing the middle class of software engineering. Статья крайне рекомендована к прочтению, но если времени нет - не переживайте, всё важное я разложу ниже. Название я перевёл немного вольно, но в целом тезис короткий и неприятный - ИИ уничтожает средний класс разработчиков. Дальше не перевод, а спор:

• где автор несомненно прав,

• где я с ним не согласен,

• что из его выводов у нас в стране работает иначе.

Начнём с тезисов источника - в том числе с тех, которые обычно теряются при пересказе.

Основной тезис автора оригинальной статьи

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

Before AI, a bad engineer would struggle to produce code that even compiled. <…> Now a bad engineer can produce 10,000 lines of working code before lunch.

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

Отсюда напрашивается вывод, что речь про сеньоров, и именно так текст обычно и пересказывают. Сам автор этого вывода не делает. Это важная деталь, и при пересказе её теряют, потому что спрятана она в спойлерах с ответами на возражения. Граница у Флориана проходит не по грейду. То есть это не вопрос - джун или сеньор. Он прямо пишет, что предпочёл бы работать с двумя джунами, которые стараются разобраться, а не просто выдать код, чем с сеньорами, которые попросту махнули рукой и перестали пытаться понять код. Цитата:

I have also worked with senior developers who basically gave up and stopped trying to understand the code. They became much worse engineers as a result.

Речь не о том, чтобы нанимать дорогих. Речь о том, чтобы нанимать тех, кто хочет понимать код на уровне всего проекта.

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

Сначала о том, где прав Флориан

Самая сильная его метафора не про код, а про технический долг:

You don’t see the debt. You just see the car that looks great.

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

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

Первое: агенты зачастую структурно не видят собственных ошибок, например - в правах доступа. Они проверяют свою работу под администратором, потому что это тот доступ, который у них есть. Роль-специфичный баг из админской сессии не виден в принципе: под администратором ограничения не срабатывают, потому что администратора они не касаются. Агенты не врут, когда пишут «права работают, проверено». Он просто физически не может увидеть, что они не работают.

Второе: одна и та же дыра в правах доступа в экперименте вылезала на голом стеке в каждом заходе без исключения. Не иногда. Каждый раз.

Это ровно то, о чём пишет Флориан, только в виде бенчмарка: машина выглядит отлично, едет быстро, поверхностную приёмку по функциональности проходит. Долг не виден. Но по факту - код не работает как должен (под простым пользователем), а тесты зелёные. Сколько подобных дефектов в коде слабого инженера? Сколько неправильных решений? Сколько другого кода сломается?

Но прежде чем идти дальше, посмотрим на рынок труда: именно он объясняет, почему у нас из того же диагноза следует другое лечение.

Рынок в России сжался, а дефицит сильных остался

Февраль 2026 к февралю 2025, по данным HH - вакансий в ИТ стало на 36% меньше, резюме на 30% больше. Индекс в ИТ-отрасли, то есть число резюме на вакансию, вырос с 9,6 до 19,6:

В феврале 2026 года к февралю 2025 число IT-вакансий в России сократилось на 36 процентов

индекс hh в информационных технологиях подскочил с 9,6 до 19,6 резюме на вакансию

Это уже не рынок кандидата, а борьба за место.

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

В деньгах расслоение видно прямо

Медианы Хабр Карьеры за первое полугодие 2026:

Разрыв между верхом и низом пятикратный, и растёт быстрее всех именно та роль, которая отвечает за понимание системы целиком, а не за производство кода. Тезис Флориана подтверждается на российских данных без всякой натяжки.

Джунов не берут, но причина у нас другая

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

Сотня откликов без единого ответа - это средняя статистика по рынку джуниоров в 2026 году

Причём до живого человека эти отклики чаще всего не доходят: 76 процентов компаний просеивают их автоматикой, и на этом шаге, по оценкам сервисов подбора, отсеивается до трёх четвертей резюме. Бюджеты найма при этом смещаются в сторону удержания middle+, а не набора начинающих.

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

By reducing the number of entry-level engineering roles, the industry is sabotaging its own future. Fewer people learning means fewer people capable of maintaining systems down the line.

А следом ставит холодную точку:

But the industry does not really owe people opportunities.

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

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

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

Работа в России другого типа, и это главное

Флориан пишет про мир, где команды делают в основном новые продукты. У нас основная масса инженерного труда сейчас в другом.

Больше половины компаний всё ещё сидят на SAP. Типичная миграция ERP занимает десятки месяцев - обзор импортозамещения ERP за август 2026 формулирует это так:

58% компаний по-прежнему остаются на SAP

типичная миграция занимает 18–36 месяцев

Haulmont меняет иностранные системы на отечественные: SAP, Salesforce, Pega, IBM FileNet, Lotus Notes, Documentum, Alfresco, OpenText, SharePoint, Visual FoxPro и так далее. И трудность там не в том, чтобы написать новое:

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

Вот эти «уникальные кастомизации» и есть та работа, которую нельзя ускорить скоростью набора текста. В цифрах это выглядит так: замена CRM в ЕвроХиме - 650 с лишним фич за восемнадцать месяцев. За такими системами стоят сотни человеко-лет разработки, и прежде чем заменить, надо понять, что именно там накопилось.

Сотни человеко-лет. Не «набросать сервис за выходные».

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

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

Где я позволю себе поспорить с автором

Флориан заканчивает тем, что ценность смещается к людям, которые понимают систему:

At some point, someone still has to know what is going on. And that’s the most valuable person on the team.

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

С этим невозможно спорить, и я не буду. Спорить я буду с тем, что этого достаточно.

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

Возражение второе, и оно интереснее. Желание понимать не помогает, если инструмент показывает неправду.

И вот тут у меня есть данные, которых нет в оригинальной статье.

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

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

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

И ещё один поворот, который у Флориана только намечен. Он хвалит джунов, которые используют ИИ, чтобы разобраться, а не чтобы вайбкодить просто писать код. У нас это приобретает дополнительный смысл: если вход в профессию перекрыт, а наставника не выдают вместе с оффером, потому что оффера нет, то ИИ остаётся единственным доступным собеседником для того, кто учится сам. Инструмент, который сократил число позиций для входа, оказывается единственным входом для тех, кто всё же лезет. Насколько это работает, мы узнаем лет через пять, когда эти люди начнут чинить то, что мы сейчас переносим с SAP.

Что это значит для конкретного человека

Коротко, потому что это тема отдельного разговора.

Если вы в середине. Ваша защита не в том, чтобы печатать быстрее агента, эту гонку вы проиграли в прошлом году, если не раньше. Она в том, чтобы быть человеком, который понимает систему целиком: почему она такая, что сломается при изменении, где зарыта собака, так сказать. Заметьте, что растущая быстрее всех роль в таблице выше называется «архитектор», а не «разработчик, который пишет много кода».

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

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

• Права проверяются входом под каждой ролью, а не под администратором. Это не «желательно», это единственный способ увидеть роль-специфичный дефект. Агент структурно не может сделать это сам, если ему не выдать учётки и не потребовать отчёт по каждой роли отдельно.

• Приёмка идёт по списку, написанному до задачи. Иначе принимающий читает отчёт исполнителя и находит там ровно то, что исполнитель решил показать.

• Хотя бы один сценарий проверяется в обход интерфейса. Спрятанная кнопка выглядит как работающее ограничение прав ровно до первого запроса напрямую к API.

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

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

Если же права в вашем стеке объявляются, а не пишутся руками в каждом обработчике, вопрос меняется. Ответ на «что видно этой роли» лежит в одном месте, его можно прочитать целиком и проверить автоматически, а не выяснять, зайдя под каждой учёткой и потыкав интерфейс. Роль-специфичный дефект тогда не прячется - его негде спрятать.

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

И если вы решаете, брать ли джунов. Наш рынок отличается от западного тем, что легаси у нас надо тащить ещё несколько лет. Тащить его будет то поколение, которое сегодня не берут на работу. «Индустрия никому ничего не должна» звучит убедительно ровно до того момента, когда через пять лет некому окажется чинить систему, которую сегодня переносят с SAP

Вместо вывода

Флориан прав в главном: ИИ действительно ускорил производство кода и не ускорил его понимание, поэтому цена непонимания выросла. Прав он и в том, что делить людей надо по желанию разбираться, а не по строчке в резюме. Плюс, у нас в стране сейчас, я уверен, можно найти на том же HH не один десяток, а то и сотню сеньоров, у которых полностью выдуманный, но непроверяемый опыт. Бедолаги вписались не туда в своё время. Кто понял - тот понял.

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

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

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

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

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