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

Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud. Раньше я рассказывал, как мы построили систему автотестов с 5 000+ проверками и как делаем визуализацию облака. Сегодня текст в формате мнения: про то, как LLM перекраивают профессию разработчика, а вслед за ней и требования к людям в командах. Покажу картину, которая складывается у меня из таких разговоров и ежедневной работы с командой, и расскажу, какие выводы я из неё делаю.

❯ Опыт состоит из двух разных вещей

То, что мы называем в резюме словом «опыт», всегда было смесью двух составляющих. Первая — насмотренность: «я видел, как это делается». Знаю API, помню подводные камни этой библиотеки, настраивал репликацию, встречал этот баг уже трижды.

Вторая — суждение: «я знаю, что здесь делать и чего делать не надо». В английском для этого есть точное слово judgment, по‑русски ближе всего именно «суждение», и дальше я буду пользоваться им. Это когда не переписывать легаси, хотя руки чешутся. Когда остановиться и выкатить неидеальное, потому что идеальное не нужно. Когда сказать, что фича не решит проблему пользователя, и предложить другую.

Годами эти составляющие продавались в комплекте. Суждение нарастало поверх насмотренности, и рынок платил за стаж, потому что стаж был единственным доступным прокси сразу для обеих. LLM разорвали комплект.

❯ Насмотренность подешевела

Модель видела больше кода, чем любой из нас увидит за всю карьеру, и продаёт эту насмотренность по цене подписки. Это видно изнутри команды каждый день: вопрос «как сделать X» закрывается за минуты, будь то настройка вебсокетов в конкретном фреймворке или типовая схема ретраев. То, что раньше было знанием, стало справкой.

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

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

Насмотренность при этом по‑прежнему нужна, без неё в профессии никуда. Она просто перестала быть дефицитом, а значит, и дифференциатором при отборе.

❯ Суждение осталось людям

ИИ блестяще отвечает на вопрос «как» и никак не отвечает на вопрос «зачем». Он напишет миграцию, но не остановит её выкатку в пятницу вечером. Сгенерирует фичу по ТЗ, но не заметит, что пользователь жалуется на другое. Предложит три варианта архитектуры, но не выберет тот, за который придётся отвечать перед конкретными клиентами.

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

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

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

• Увидеть, что задачу не надо делать вообще. Отменённая задача экономит больше, чем оптимизированная, но для этого нужно понимать, зачем она появилась.

• Вовремя остановиться. Не полировать, не перепроектировать, не тащить в решение ещё одну технологию, когда продукту нужно другое.

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

❯ Имитировать можно даже суждение. Ответственность — нельзя

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

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

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

❯ Финальный разговор стал главным фильтром

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

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

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

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

❯ Дешёвый код перекраивает профессию целиком

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

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

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

И это не эксклюзив разработки. Та же волна перестраивает работу аналитиков, тестировщиков, менеджеров: везде, где роль держалась на дорогом ручном звене, звено дешевеет и роль пересобирается вокруг того, что осталось. Просто разработку я вижу ближе всего.

❯ Требования смещаются к софтам, но не тем, о которых писали в вакансиях

Отсюда и сдвиг в требованиях. Разговоры про важность софт‑скиллов идут лет пятнадцать, и обычно под ними понимают что‑то из корпоративного тренинга: коммуникабельность, работу в команде, презентации. Качества, которые становятся ключевыми сейчас, другого рода и ближе к позиции человека, чем к навыкам общения. По сути это то самое суждение из первой половины текста: ответственность за результат, а не за таску, внимание к боли пользователя, готовность аргументированно отказаться от задачи. «Я сделал по ТЗ» перестало быть защитой, потому что сделать по ТЗ умеет и ИИ.

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

❯ Исполнитель по ТЗ и миф про интроверта

Есть привычный образ: разработчик‑интроверт, который молча и качественно делает задачи по ТЗ, и этого достаточно. Мне кажется важным не промахнуться с диагнозом, что именно в этом образе перестало работать.

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

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

Проблема в том, что «стабильно перерабатывать ТЗ в код» — это теперь описание работы агента. Команда, где люди заняты машинной функцией, платит человеческую зарплату за то, что у конкурентов делает подписка, и проигрывает командам, где каждый инженер закрывает цепочку целиком: от боли пользователя до проверенного результата.

❯ Что я вижу у тех, кто растёт

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

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

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

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

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

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

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

❯ В заключении

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

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

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

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

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram‑канале ↩