В нашем найме я подключаюсь на финальном этапе. Техническая секция к этому моменту позади, её проводят инженеры команды, а я просто разговариваю с кандидатом про его опыт и взгляды. Ещё пару лет назад это был самый мягкий этап воронки, почти формальность после настоящей проверки. Сегодня он различает кандидатов лучше, чем техническая секция, и мне кажется, это многое говорит о том, куда движется профессия.
Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud. Раньше я рассказывал, как мы построили систему автотестов с 5 000+ проверками и как делаем визуализацию облака. Сегодня текст в формате мнения: про то, как LLM перекраивают профессию разработчика, а вслед за ней и требования к людям в командах. Покажу картину, которая складывается у меня из таких разговоров и ежедневной работы с командой, и расскажу, какие выводы я из неё делаю.
❯ Опыт состоит из двух разных вещей
То, что мы называем в резюме словом «опыт», всегда было смесью двух составляющих. Первая — насмотренность: «я видел, как это делается». Знаю API, помню подводные камни этой библиотеки, настраивал репликацию, встречал этот баг уже трижды.
Вторая — суждение: «я знаю, что здесь делать и чего делать не надо». В английском для этого есть точное слово judgment, по‑русски ближе всего именно «суждение», и дальше я буду пользоваться им. Это когда не переписывать легаси, хотя руки чешутся. Когда остановиться и выкатить неидеальное, потому что идеальное не нужно. Когда сказать, что фича не решит проблему пользователя, и предложить другую.
Годами эти составляющие продавались в комплекте. Суждение нарастало поверх насмотренности, и рынок платил за стаж, потому что стаж был единственным доступным прокси сразу для обеих. LLM разорвали комплект.
❯ Насмотренность подешевела
Модель видела больше кода, чем любой из нас увидит за всю карьеру, и продаёт эту насмотренность по цене подписки. Это видно изнутри команды каждый день: вопрос «как сделать X» закрывается за минуты, будь то настройка вебсокетов в конкретном фреймворке или типовая схема ретраев. То, что раньше было знанием, стало справкой.
Видно это и по коду. Джун с ИИ пишет код, синтаксически неотличимый от кода уверенного мидла: аккуратные абстракции, обработанные ошибки, тесты. Разница проявляется позже, когда выясняется, что аккуратно написана не та вещь.
На найме эффект ещё заметнее. Техническая секция у нас без лайвкодинга, код на собеседовании — лишний стресс. Это разговор про технологии: что человек использовал, как оно устроено, где какие грабли. Годами такой разговор надёжно разделял кандидатов, потому что проверял ровно насмотренность. Теперь пары вечеров с ИИ хватает, чтобы уверенно говорить почти о любом стеке, и своя насмотренность в таком разговоре перестала отличаться от заёмной.
Насмотренность при этом по‑прежнему нужна, без неё в профессии никуда. Она просто перестала быть дефицитом, а значит, и дифференциатором при отборе.
❯ Суждение осталось людям
ИИ блестяще отвечает на вопрос «как» и никак не отвечает на вопрос «зачем». Он напишет миграцию, но не остановит её выкатку в пятницу вечером. Сгенерирует фичу по ТЗ, но не заметит, что пользователь жалуется на другое. Предложит три варианта архитектуры, но не выберет тот, за который придётся отвечать перед конкретными клиентами.
Суждение — это осадок от личных последствий. Оно нарастает, когда чинишь прод в три часа ночи из‑за собственного решения, когда твоя быстрая правка ломает биллинг, когда фича, которую месяц пилил, оказывается никому не нужна. У модели нет шрамов.
Важно, что суждение не сводится к умению красиво говорить. Это вполне инженерные навыки:
Понять боль пользователя до того, как писать код. Задача в трекере описывает симптом, а лечить нужно причину, и они совпадают реже, чем хотелось бы.
Увидеть, что задачу не надо делать вообще. Отменённая задача экономит больше, чем оптимизированная, но для этого нужно понимать, зачем она появилась.
Вовремя остановиться. Не полировать, не перепроектировать, не тащить в решение ещё одну технологию, когда продукту нужно другое.
Принять решение без очевидно правильного варианта и подписаться под ним. Про этот пункт стоит сказать отдельно: он устроен иначе, чем остальные три.
❯ Имитировать можно даже суждение. Ответственность — нельзя
Тут нужно честное уточнение. Граница между «как» и «зачем» не высечена в камне: модели всё лучше говорят «не делай этого», предупреждают о рисках миграции и предлагают откатиться. Строить карьеру на ставке, что модель никогда не научится осторожности, я бы не стал.
Но у суждения есть составляющая, которую нельзя воспроизвести в принципе, потому что она не когнитивная, а институциональная: ответственность. Модель нельзя уволить, с неё нельзя спросить за инцидент, она не проснётся в три часа ночи и не будет объяснять клиенту, что случилось с его данными. Разница между советом и решением не в качестве, а в том, кто платит за ошибку.
Поэтому устойчивое ядро профессии я вижу именно здесь. Человек в команде нужен как точка, где рекомендация превращается в решение, у которого есть имя и последствия. Чем больше кода пишут агенты, тем дороже стоит тот, кто готов поставить под результатом свою подпись.
❯ Финальный разговор стал главным фильтром
Вернусь к разговору, с которого начал: последний этап, без кода и без вопросов на знание. Его смысл в том, чтобы понять, как человек рассуждает и впишется ли он в культуру команды.
То, что самый мягкий этап воронки стал главным фильтром, мне кажется закономерным. Разговор про технологии проверяет насмотренность и сломался вместе с ней, а разговор про опыт и взгляды всегда проверял именно суждение: просто раньше суждение шло приятным бонусом к дефицитным хардам, а теперь дефицит переехал.
Суждение в таком разговоре выдаёт себя деталями, которые не отрепетируешь. Человек, который принимал решения сам, рассказывает о них с оговорками и «тогда это казалось правильным», знает, что стало с его решением через полгода, помнит цену собственных ошибок. Человек, который выполнял таски, отлично говорит про технологии и теряется на вопросе, почему продукт был устроен именно так и что он сейчас сделал бы иначе.
Поэтому мои любимые вопросы давно не про то, что человек сделал, а про то, о чём он жалеет и от чего отказывался. У настоящего суждения всегда есть неудобные детали, которые не укладываются в красивую историю, и в живом разговоре они всплывают сами.
❯ Дешёвый код перекраивает профессию целиком
Всё, что я описал про найм, на самом деле вторично. Первично то, что меняется само содержание работы, а отбор лишь догоняет эти изменения.
Конвейер «аналитик пишет ТЗ, разработчик кодит, тестировщик проверяет» был спроектирован под мир, где кодирование стоит дорого и его нужно беречь: узкое звено обложили ролями, которые готовят ему вход и проверяют выход. Кодирование подешевело на порядок, и конвейер схлопывается. Передавать задачу по цепочке из трёх человек стало дороже, чем пройти её одному.
Для разработчика это означает, что пересобирается рабочий день. Набор кода занимает в нём всё меньше места, а всё больше занимает то, что раньше считалось чужой работой: понять проблему пользователя, сформулировать задачу, проверить, что результат её решает. Разработчик перестаёт быть звеном конвейера и начинает отвечать за отрезок целиком.
И это не эксклюзив разработки. Та же волна перестраивает работу аналитиков, тестировщиков, менеджеров: везде, где роль держалась на дорогом ручном звене, звено дешевеет и роль пересобирается вокруг того, что осталось. Просто разработку я вижу ближе всего.
❯ Требования смещаются к софтам, но не тем, о которых писали в вакансиях
Отсюда и сдвиг в требованиях. Разговоры про важность софт‑скиллов идут лет пятнадцать, и обычно под ними понимают что‑то из корпоративного тренинга: коммуникабельность, работу в команде, презентации. Качества, которые становятся ключевыми сейчас, другого рода и ближе к позиции человека, чем к навыкам общения. По сути это то самое суждение из первой половины текста: ответственность за результат, а не за таску, внимание к боли пользователя, готовность аргументированно отказаться от задачи. «Я сделал по ТЗ» перестало быть защитой, потому что сделать по ТЗ умеет и ИИ.
К этому добавляется погружение в домен: понимать не только код, но и бизнес вокруг него, почему эта метрика важна, кто платит и за что. Ни одно из этих качеств не новое. Новое то, что они перестали быть приятным дополнением к хардам и стали основным содержанием роли.
❯ Исполнитель по ТЗ и миф про интроверта
Есть привычный образ: разработчик‑интроверт, который молча и качественно делает задачи по ТЗ, и этого достаточно. Мне кажется важным не промахнуться с диагнозом, что именно в этом образе перестало работать.
Дело точно не в темпераменте. Молчаливый инженер с суждением ценнее говорливого без него, и так будет всегда. Интроверсия прекрасно совместима и с ответственностью, и с пониманием пользователя: чтобы почитать тикеты поддержки, душой компании быть не нужно.
Перестала работать позиция, которая часто маскируется под интроверсию: «моя ответственность заканчивается на границе таски». Получил задачу, сделал задачу, взял следующую, не спрашивая, зачем она нужна и жива ли предыдущая. Ещё недавно такой сотрудник был опорой команды: стабильно перерабатывает ТЗ в код, не отвлекает вопросами.
Проблема в том, что «стабильно перерабатывать ТЗ в код» — это теперь описание работы агента. Команда, где люди заняты машинной функцией, платит человеческую зарплату за то, что у конкурентов делает подписка, и проигрывает командам, где каждый инженер закрывает цепочку целиком: от боли пользователя до проверенного результата.
❯ Что я вижу у тех, кто растёт
Суждение звучит как что‑то врождённое, но по команде я вижу, что это навык, и нарабатывается он не курсами, а последствиями. У инженеров, которые в новых условиях растут быстрее остальных, я замечаю несколько общих привычек.
Они возвращаются к последствиям своих решений: проверяют, как живёт выпущенная фича, разбирают свои инциденты и ищут в них причину, а не виноватого. Решение, к которому не вернулся, ничему не учит, сколько бы их ни было.
Они просят решения, а не задачи. «Дайте разобраться, что тут делать» звучит страшнее, чем «дайте таску», но растёт человек именно в первом варианте. И они регулярно бывают там, где больно пользователю: полчаса в тикетах поддержки дают больше понимания продукта, чем день в таск‑трекере.
Отдельное наблюдение: быстрее всего суждение растёт у людей, у которых есть проект с живыми пользователями, где все решения и все последствия свои. Неважно, что это: собственный небольшой сервис или внутренний инструмент, за который человек отвечает один.
Здесь же живёт самый неудобный вопрос этого текста, и у меня нет на него ответа. Если суждение нарабатывается последствиями собственных решений, то раньше эти последствия добывались на простых задачах: джун набивал шишки на формах, миграциях и мелких багах, и через пару лет из шишек складывался сеньор. Теперь эту работу делает ИИ, и первая ступенька лестницы исчезает: непонятно, где следующее поколение возьмёт свои шрамы.
У нас пока рабочая гипотеза: давать начинающим не куски кода, а маленькие законченные вещи, с реальными пользователями и участием в разборе инцидентов, чтобы последствия у решений появлялись с первого дня. Подчеркну, что это гипотеза, а не проверенное решение, и с этим вопросом индустрии ещё предстоит разбираться всерьёз.
И харды при этом никуда не делись. Без них суждению не на чем стоять: невозможно решать, чего не делать, если не понимаешь, как оно делается. Харды остались входным билетом, просто перестали быть козырем.
❯ В заключении
Если сжать текст в одну мысль, получится так: раньше рынок платил за умение превратить ТЗ в код, теперь платит за умение превратить неопределённость в решение и ответить за него.
Профессия при этом не умирает, она в очередной раз меняет предмет. У соседей это уже случалось: Excel не убил бухгалтеров, но убил счетоводов, и ценность профессии переехала от умения считать к интерпретации цифр и подписи под отчётностью. В разработке ценностью успело побывать знание ассемблера, потом знание стандартной библиотеки, потом умение быстро искать ответы. Всякий раз казалось, что настоящую инженерию отменили, и всякий раз выяснялось, что настоящая инженерия — это следующий уровень.
Наверняка часть этих наблюдений устареет раньше, чем мне бы хотелось: индустрия меняется быстрее, чем мы успеваем о ней писать. Но пока каждый новый цикл найма скорее подтверждает картину, чем опровергает.
Спасибо, что дочитали до конца! Мне очень интересен ваш опыт: как изменились собеседования и требования у вас, и с какой стороны стола вы это почувствовали? Расскажите в комментариях.
Может быть интересно:
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram‑канале ↩
Комментарии (67)
Vartlok
28.07.2026 15:21теперь платит за умение превратить неопределённость в решение и ответить за него
Мне всегда казалось, что это и есть суть бизнеса, нести ответственность за всякие неопределенности и получать повышенную награду за этот риск, а в найме я сижу и примус починяю
Выглядит как попытка переложить риски бизнеса на работников(что не сильно удивительно, все так пытаются сделать), но если работник готов нести такие риски, зачем ему идти в найм вообще? Почему бы не создать свою компанию и получать награду за эти риски?
sim31r
28.07.2026 15:21Масштаб ответственности ниже. Это не крах дела жизни, а обычная зарплата или зарплата плюс премия.
edogs
28.07.2026 15:21Про риски уже выше сказали, абсолютно так. Есть разница - лишиться премии или встрять на компенсацию миллионных убытков.
Но добавим - компания это не в последнюю очередь привлечение клиентов (попробуй свежим соло анонимом взять заказ у газпрома допустим) и сопровождение (никому не нужен просто готовый софт, всем нужна его поддержка, доработка, исправление).
Ну а если все создадут свою компанию для получения наград, то кто работать-то будет?:)
VADemon
28.07.2026 15:21нести ответственность за всякие неопределенности
Это отличительная черта профессии будет. А даже не профессии, а градуса автономности у сотрудников, т.к. профессия (теперь) обязывает работать на верхних уровнях абстракций. Разница между фабричным рабочим, который надевает шестерню на вал и программистом, который фигачит за него просчитанные формулы в ассемблер (условно, 60 гг.) невелика. За одного подумал и подписал инженер, за другого математик.
Объясняя это с другой стороны: если бы LLM могла читать мысли, додумывать недостающее и генерировать ТЗ, то ни программирование, ни отвественность были бы не нужны.
ЗЫ: Жду оффера от Timeweb :]
vkni
28.07.2026 15:21Выглядит как попытка переложить риски бизнеса на работников
Ну это же давно переложили: too big to fail и т.д. Где вы были эти 100 лет?
а в найме я сижу и примус починяю
В найме вас, внезапно, могут уволить. И в местах совсем совсем диких просто одним днём. Впрочем, в любых местах, как только у бизнеса появляются проблемы, идут увольнения. Что это, как не перекладывание проблем бизнеса на работников? И так было, в общем, всегда.
Dmitry_604
28.07.2026 15:21Есть разница - вас уволят но вы не уйдете в минус или не попадете на штраф или того хуже уголовку. Так что да "примус починяю" вполне годится в данном случае. Ну примус отобрали пошел соседний починять.
И в местах совсем совсем диких просто одним днём.
Дикий запад Калифорнии? :)
vkni
28.07.2026 15:21Есть разница - вас уволят но вы не уйдете в минус или не попадете на штраф или того хуже уголовку.
Ипотека? Штрафы на работе, да и подставить вполне себе могут под уголовку материально ответственного. Кроме того, сейчас многие работают как ИП — это именно то, что вы рассказываете. А дейсвительно крупный бизнес обычно получает поддержку гос-ва и рискует меньше, чем наёмники.
Дикий запад Калифорнии? :)
Например. Хотя и более дикие места там есть. Чуть восточнее.
Dmitry_604
28.07.2026 15:21Ипотека - ну это вы сами влезли. Так можно много о чем говорить даже при наличии работы. Хотя ипотека это едсинтвенный кредит который я могу еще как-то понять для физ лица.
Штраф на работу - ну удачи его сделать официально. Да на отдельных должностях есть отвественность материальная но мы тут про IT кажется.
abbasov-alexander
28.07.2026 15:21Может потому, что на деле это почти непосильный труд? Навскидку потребуется: зарегистрировать юрлицо/ИП, найти деньги на разработку продукта, платить зарплату команде, мотивировать команду, заниматься маркетингом, уметь продавать, общаться с госструктурами по правовым и финансовым вопросам, нести ответственность за компанию в целом.
Любая приличная компания — это люди, процессы, клиенты, финансы и продукт/услуга. И в каждом направлении своя приличная глубина. Так что наивно полагать, что сидя внутри чужой компании и умея делать один этап, можно вот так легко выйти из нее и создать свою.
Кстати по статистике, к примеру, на ютубе 1% людей в мире создает контент, остальные потребляют … Говорят, что предпринимателей в мире — 10% в мире, остальные работают как наемные сотрудники.
В нашей стране 140 млн человек, но действующих организаций будет меньше 10 млн. Самозанятые не в счет — юридически они работают на себя и оборот максимум 2.5 млн рублей, что не подходит по условиям.
Проще говоря, капец это как сложно.
Wesha
28.07.2026 15:21Дешёвый код
...и быстрый.
Ну, вы понЕли.
vvzvlad
28.07.2026 15:21ЛЛМ ровно с тем же удовольствием будет писать вам быстрый код, если вы попросите. Или качественный, если у вас есть критерии и вы готовы тратить время на обкладывание тестами на эти критерии. И все еще будет делать это дешевле чем разработчик.
Antako
28.07.2026 15:21Собеседования безусловно поменялись, но я их раньше проводил методом решения сложной задачи, на словах, в диалоге, оценивал понимание задачи, умение схватывать на лету идеи или новую сложную информацию. Что часто бывает в рабочей задачи и показывает именно инженерную работу. И как оказалась работа с нейронками - это тот же самый формат)) и ребята слабее стали лучше проходить собесы, думал что такое... а их неплохо натаскивает аи на такие задачи и в целом это не плохо... их скилл то растет)
Bvrinoff
28.07.2026 15:21Скилл растет, правда, но не у всех. У нас много и обратных ситуаций, где новички нагенерить нагенерили тестовое, а пояснить - увы, не могут :D
0xInnominatus
28.07.2026 15:21Модель видела больше кода, чем любой из нас увидит за всю карьеру, и продаёт эту насмотренность по цене подписки.
Проблема в том, что она его увидела на момент обучения и застыла на определённом слепке существующего кода и библиотек из-за чего предложенные решения очень средние и устаревшие. Это крайне неприемлемо в сверхконкурентных областях типа маркет-мейкинга, трейдинга или кредитования, где всю вашу потенциальную прибыль сразу же заберут конкуренты, у которых код не средний и устаревший, а наиболее актуальный, производительный и эффективный. Возможно насмотренность того же кода, что видела LLM, уже не так ценится, но разработчик, внимательно изучающий ту же ленту GitHub каждую неделю обладает насмотренностью, которой нет у LLM, и может выбрать подходящие технологии, чтобы обойти конкурентов. Полезность LLM не отрицаю, но пока LLM не начнёт постоянно обновляться в след за изменениями в технологическом стеке так же, как это делает разработчик, полагаться только на насмотренность LLM неэффективно.
vvzvlad
28.07.2026 15:21Полезность LLM не отрицаю, но пока LLM не начнёт постоянно обновляться в след за изменениями в технологическом стеке так же, как это делает разработчик, полагаться только на насмотренность LLM неэффективно.
Проблема в том, что она его увидела на момент обучения и застыла на определённом слепке существующего кода и библиотек
Здрасте. Есть агенты-исследователи, которые пороются в гугле и вытащат вам внятный пересказ последних технологий и тенденций в области. Сервисы вроде context7 и требование сверяться с последней версией библиотек. Плюс никто не мешает вам брать и подпихивать агента в нужном направлении “а давай вот тут еще поотмизируем, а что тут, а давай вот еще тут замер сделаем, что время жрет, а проверь хвосты вот тут”. Человек-за-ллм все равно нужен, и он должен понимать пределы и ограничения, но “застывший слепок технологий” уже давно не очень актуален.
vanxant
28.07.2026 15:21Да вот как раз наоборот. Технологии замерли в момент смерти стэк оверфлоу. В гугле вы найдёте десятилетнее старьё, либо пятикратно пережеванный нейрокал из пересказа куцей документации
shut-down-now
28.07.2026 15:21>Технологии замерли в момент смерти стэк оверфлоу
ты просто шалобол. fable 5 лезет прям в исходники, если что-то редкое ковыряешь, (прям с твоего компа и разрешения) качает и их шерстит.
vanxant
28.07.2026 15:21исходники винды или гуглодоков прямо с трекера качает или как?
shut-down-now
28.07.2026 15:21тупой коммент, никак не связанный с "Технологии замерли в момент смерти стэк оверфлоу"
Dhwtj
28.07.2026 15:21Технологии замерли в момент смерти стэк оверфлоу
Раньше все гонялись за решениями. Завтра будут гоняться, искать реальные шрамы эксплуатации.
SabMakc
28.07.2026 15:21Модель видела больше кода, чем любой из нас увидит за всю карьеру, и продаёт эту насмотренность по цене подписки. Это видно изнутри команды каждый день: вопрос «как сделать X» закрывается за минуты, будь то настройка вебсокетов в конкретном фреймворке или типовая схема ретраев. То, что раньше было знанием, стало справкой.
Это и раньше решалось через гугл за минуты (ладно, десятки минут). Сейчас еще ускорилось, это да. Но именно большого вопроса в “а как это сделать” не было. ИИ скорее даже ухудшил - раньше находились разные решения и приходилось выбирать более подходящее, что хорошо прокачивало “суждение” (хотя шутки про разработку через Ctrl-C/Ctrl-V появились как раз с развитием интернета). С ИИ же просто получаешь готовое решение с минимальным личным участием.
Видно это и по коду. Джун с ИИ пишет код, синтаксически неотличимый от кода уверенного мидла: аккуратные абстракции, обработанные ошибки, тесты. Разница проявляется позже, когда выясняется, что аккуратно написана не та вещь.
Проблема скорее в том, что джун с ИИ решает проблемы нехарактерные для джуна. Раньше разница была в том, что джун/мидл/сениор на разных вещах сосредоточены. Если упрощать, то джун - “как написать код”, мидл - “как решить задачу”, сениор - “а какую задачу решаем”. Сейчас же ИИ очень хорошо скрывает эту разницу, “превращая” любого в опытного разработчика. Но это не опыт и не навык, а только видимость.
Дешёвый код перекраивает профессию целиком
С одной стороны да, код стал стоить примерно ничего. Но если брать именно “код, решающий твою проблему” - то скорость разработки выросла далеко не в 10 раз. И даже не в 2 раза. Не стоит забывать, что скорость написания кода никогда не была самой главной проблемой разработки. По крайней мере если говорить про ответственный подход к делу. Скорее значительно поменялось место приложения усилий - от написания кода к его ревью. Код стал дешевым, кода стало больше, сложность ревью выросла по экспоненте (вместе со сложностью ПО).
Если суждение нарабатывается последствиями собственных решений, то раньше эти последствия добывались на простых задачах: джун набивал шишки на формах, миграциях и мелких багах, и через пару лет из шишек складывался сеньор.
На мой взгляд, “суждение” нарабатывается опытом. Чем больше и разнообразнее опыт - тем лучше. Анализ проблемы, поиск путей решения - это один опыт. Написание/доработка кода - другой. Тестирование - третий. И так далее. Я бы не ставил “работу над собственными ошибками” во главу угла, хотя это и важно в том числе. Ошибки - это, в первую очередь, не неправильный выбор, а последствия выбора в условиях неполной информации.
masleshov
28.07.2026 15:21Модель видела больше кода, чем любой из нас увидит за всю карьеру, и продаёт эту насмотренность по цене подписки. Это видно изнутри команды каждый день: вопрос «как сделать X» закрывается за минуты, будь то настройка вебсокетов в конкретном фреймворке или типовая схема ретраев. То, что раньше было знанием, стало справкой.
Видно это и по коду. Джун с ИИ пишет код, синтаксически неотличимый от кода уверенного мидла: аккуратные абстракции, обработанные ошибки, тесты. Разница проявляется позже, когда выясняется, что аккуратно написана не та вещь.
На говнокод модель тоже насмотрелась. Потому по цене подписки зачастую можно купить отборную мешанину, кладущую прод при малейшей нагрузке, если не иметь достаточных навыков распознавать в генерируемом коде такие вещи. Но если вас в вашем процессе найма не интересуют такие навыки профессионала, то остается пожелать только всего наилучшего
poige
28.07.2026 15:21Но если вас в вашем процессе найма не интересуют такие навыки профессионала, то остается пожелать только всего наилучшего
Так оно уже много лет примерно в пожеланиях и гнездится. FAANG'ов на всех не хватит — да и там вакуумной изоляции от менеджерской гнили никто не обещал.
Есть банальная закономерность: чем слабее у человека собственное мышление, тем охотнее он принимает выхлоп LLM за мышление вообще. Я лично видел людей, которые использовали ChatGPT 4o — 4o, Карл — как советника и аналитика, хотя им уже была доступна o3. Отдельная хохма заключалась в том, что перейти на более подходящую модель можно было «на раз», но они этого не делали — просто, видимо, 4o про o3 советов не давала, лол. А сами они, похоже, разницы не замечали вовсе.
В этом, собственно, и проблема. ИИ — суррогат интеллекта, но нужен достаточный собственный интеллект, чтобы распознать в нём суррогат. Для человека, способного проверять предпосылки, замечать противоречия и понимать границы модели, это полезный инструмент. Для прочих — аппарат по производству нейрослопа в промышленных масштабах.
Люди этого уровня смотрят на реальность через экран разрешением 640 × 320 (пользуясь аналогией от проф. Савельева), не подозревая, что есть те, кто видят всё через Retina. И когда такие люди оказываются на управляющих позициях — слово «когда» здесь, пожалуй, честнее слова «если» — последствия ограниченности их экранов настигают и всех прочих — даже тех, кто смотрит на этот цирк с полным пониманием того, что происходит на арене. Им, похоже, больнее всего. ;) Их ещё часто называют «токсичными» — потому что нежные тушки с экраном 640 × 320 воспринимают любое зрение глубже собственного не как оптику, а как рентген — а то и вовсе как локальный Чернобыль.
Wesha
28.07.2026 15:21ИИ — суррогат интеллекта, но нужен достаточный собственный интеллект, чтобы распознать в нём суррогат.
sharpMouse
28.07.2026 15:21Согласен, но разрешение у вас странное ))
Классическими являются 320×200 (CGA) и 640x350 (EGA). У вас какая-то их смесь ;)
poige
28.07.2026 15:21\@
Ну вообще, если серьёзно на это отвечать (блин, зачем я это делаю) — в этой аналогии не требуется стандартность, более того, учитывая индивидуальную изменчивость … (всё, блин, этого достаточно)
хотя не — почитайте для кругозора про граф. адаптеры Hercules, например. :)
Moog_Prodigy
28.07.2026 15:21Он с х480 перепутал. Широкие экраны они такие...
poige
28.07.2026 15:21Широкие экраны они такие...
Особенно когда суть речи про DPI, а не соотношение сторон. Тупость — она вот именно такая, или по кр. мере, где-то рядом.
ToxaBes
28.07.2026 15:21Есть банальная закономерность: чем слабее у человека собственное мышление, тем охотнее он принимает выхлоп LLM за мышление вообще.
Лучше и не сформулировать. И ведь не объяснишь же.
(пользуясь аналогией от проф. Савельева)
Мне понравился его термин: педоморфоз сознания
Kealon
28.07.2026 15:21Я бы больше на распределение низкосортной работы смотрел. Вот там будет плохо.
CAHbKA_IV
28.07.2026 15:21На самом деле мы переживаем кризис на рубеже изменения инструмента, подобно тому, как ассемблер сменялся языками высокого уровня. Раньше программист досканально знал архитектуру и особенности ЭВМ с котороой приходилось работать. Знает ли современный программист на java или python в чём отличие кэша 2 и 3 уровня в процессоре? Сменилась парадигма, и для большинства прикладных задач это стало не нужно - компилятор собирает машинный код, который работает. Перестал ли от этого программист быть программистом? нет. Сейчас новый виток - агент переводит задание с естественного языка на язык программирования высокого уровня. Теперь не нужно разбираттся в синтаксисе конкретного языка, и ещё более становится заметным, что программист - это не только технические навыки, но и определённый склад ума: умение правильно понять и сформулировать задачу, разделить её на реализуемые и тестируемые этапы, увидеть возможные проблемы и граничные случаи. А как формулировать - в машинных кодах, на бейсике или техническим текстом для агента - не столь важно. В контексте "компьютер делает то, что ты ему сказал, а не то, что ты хотел" ничего не измннилось. Вопрос - "хард" или "софт" эти умения?
SabMakc
28.07.2026 15:21Знает ли современный программист на java или python в чём отличие кэша 2 и 3 уровня в процессоре?
Знает. И да, это почти не нужно. Или нужно? Как раз тут ответ “почему ArrayList быстрее LinkedList”.
Аналогия с ИИ сломана изначально. ИИ недетерминирован и невоспроизводим. ИИ одну и туже проблему может решить сильно по разному. А просто похожие - тем более. Это делает ИИ ненадежным. А значит ИИ надо плотно контролировать. Без знания языков программирования же контроль очень ограничен.
Компиляторы же детерменированы. Как только ИИ приблизится в надежности к компиляторам - да, знание языков программирования станет практически ненужным (хотя это и очень спорно - языки программирования гораздо детерминированнее естественного языка). Но до тех пор - это популярная, но сломанная аналогия.
oleg_go
28.07.2026 15:21Буд-то кожаные детерминированы и ведут себя как компиляторы - выдавая одно и тоже решение раз за разом?
У них даже когда одну и туже задачу делает один человек он зачастую решает её по другому как минимум потому что с последнего варианта решения прошло полгода и ему в голову пришёл другой, более "лучший" вариант. А как максимум потому что он забыл как решал эту задачу полгода назад и пошёл изобретать велосипед заново. Отдельные представители могут забыть даже за неделю - память то у некоторых как у рыбки...SabMakc
28.07.2026 15:21Да. Человек тоже недетерминирован. Но человек обучается, в том числе на своих ошибках. Человек несет ответственность. У ИИ ни того ни другого нет.
oleg_go
28.07.2026 15:21И часто ли кожанные "отвечают" в том числе за ошибки? На каком этапе становится понятно что это была ошибка, а не ошибочный выбор в условиях крайней неопределенности?
SabMakc
28.07.2026 15:21Да. Как минимум приходится переделывать. Как максимум - тебя уволят, а то и под уголовную ответственность есть риски попасть (пускай это и крайне специфичный случай).
oleg_go
28.07.2026 15:21Чего мелочится то - сразу к "высшей мере" наказания по "законам военного времени". В каких это структурах средний разработчик может за ошибки, не сознательные а по незнанию или лени, привлекаться? Какие это статьи и вообще есть примеры такого законоприменения?
Что за бред вообще тут - после разработчика ещё ревьювер, тестировщик, куча начальников всё это дело прямо или косвенно апрувят и т.д. Тут вообще вариантов нет под уголовку за непредумышленное привлечьсяSabMakc
28.07.2026 15:21Как я и говорил, это крайне специфичный случай. Обычно просто портится отношение коллег, начальства (ни кто не любит тех, чьи ошибки добавляют им головной боли), максимум по финансам можно просесть (или не попасть под повышение). Или просто при сокращении о вас вспомнят первым.
P.S. если ваша позиция “превращаю документацию в код, ни о чем не парюсь”, то у меня для вас 2 новости: хорошая и плохая.
Хорошая: ИИ отлично вам подходит!
Плохая: На ИИ заменят именно вас.
shut-down-now
28.07.2026 15:21>Человек несет ответственность
ну там где я работаю, прогерам НИЧЕГО не делают за баги.
гладя на современное ПО, я уверен на 80% что в большинстве мест точно такие же процессы.
microuser
28.07.2026 15:21Ответственность разная бывает, штрафовать и увольнять вас никто не будет, но упавший прод поднимать кроме вас некому, поэтому я думаю, что в ваших собственных интересах сделать так что бы он падал как можно реже.
aso
28.07.2026 15:21С кожаного можно спросить, а с кремниевого - взятки гладки.
oleg_go
28.07.2026 15:21Ага, над проектом работают 30 кожанных - изменения Васи на проде оказались несовместимы с изменениями Коли и всё это всплыло в месте, не покрытом автотестами и вообще в модуле, который вроде и не трогали и по нему ручное тестирование не сделали а регресс был рассчитан только на основную функциональность не затрагивая все функции модуля. А виноватым объявим Вову, потому что должность у него такая... К пуговицам претензий ведь нет, пришиты так что не оторвать.
SabMakc
28.07.2026 15:21Вся эта софистика хороша ровно до тех пор, пока не подсчитаешь процент ошибок ИИ и человека. И оказывается что человек просто на порядки лучше работает.
shut-down-now
28.07.2026 15:21>И оказывается что человек просто на порядки лучше работает.
кто же этот человек, который умнее клавы опусовны? на хабре все герои. а в жизни потом даже в коде операционок и гипервизоров выгребают тонны дебильных багов. молчу про мелкий и галерный софт (где погонщик с плеточкой требует ВЭЛЬЮ, а не красоту).
SabMakc
28.07.2026 15:21Вы про тот самый опус, который пилил-пилил компилятор C, но в итоге даже “Hello World” не запустился на нем?
Ну да, ну да. Прямо эталон качества. Особенно мне понравилась часть про “целью было скомпилить ядро linux”, которое после компиляции просто не работает. Так и вижу в ответе ИИ “просили скомпилить, про работоспособность ничего не было сказано”.
Ах да, они же взяли неправильную модель и не дали толкового промта для ИИ…
shut-down-now
28.07.2026 15:21>И оказывается что человек просто на порядки лучше работает.
>который пилил-пилил компилятор Cпринимаем всех кожмешков-программистов за 100% (включая делфи, react, sql и прочую хрень), а теперь расскажи сколько из них способны пушить что-то полезное в компилятор дыряшечки. 0.0001% или 0.00000001% ?
SabMakc
28.07.2026 15:21Если брать за эталон “компилится, но не работает” - то, думаю, практически все )
OldNileCrocodile
28.07.2026 15:21LLM и про кэш расскажет. Например, почему картинку в ASCII надо делать через массивы. Или почему надо всегда писать сдвиг вправо ">> 1" вместо умножения на два. Но чтобы она рассказала про это, нужно это знать - таки да.
* Компиляторы же детерменированы - мимо кассы, ибо оптимизация (он не всегда заменяет умножение на два битовым сдвигом, даже когда это очевидно).
Тот же компилятор как и ИИ может сгенерировать в нескольких прогонах код платформы с разной скоростью исполнения, т.к. стоимостные оценки одних и тех же операторов из-за контекста разные. Из-за чего люди научились хакать процессоры и превращать платы в кирпичи. Одна даже игровая фирма этим гордилась.SabMakc
28.07.2026 15:21И много компиляторов в одних и тех же условиях дадут разный результат? А принципиально разный?
Вся индустрия разработки ПО стремится к одному - предсказуемому и детерминированному выполнению программ. ИИ же детерминированным не будет никогда. Максимум - можно получить воспроизводимость результата. Но и это далеко не в приоритете у ИИ.
Если компилятор периодически выдает нерабочий код в зависимости от настроек, времени года, фазы луны - то это как минимум плохой компилятор, которым ни кто не будет пользоваться для чего-либо серьезного. В компиляторах тоже бывают баги - не спорю. Но это скорее исключительная ситуация, а не закономерность.
Если бы ИИ был компилятором - то при компиляции мы бы каждый раз получали совершенно новую программу, со своим собственным интерфейсом. Пускай и решающие одну и туже проблему.
P.S. К слову, сдвиг - далеко не тоже самое, что и умножение/деление на 2. Может для небольших значений это и работает, но по факту число сдвигаемых разрядов - это остаток от деления на разрядность регистра. Что может принести достаточно неожиданные результаты.
Moog_Prodigy
28.07.2026 15:21Текущий нынешний ИИ вполне себе детерминирован - его вывод определяет seed. Если сид одинаковый, и все остальное - он будет выдавать ровно одно и то же с точностью до байта. Хоть тыщу раз.
BugM
28.07.2026 15:21Нет. Шумы и флоат арифметика всегда дают недерминированный результат.
SabMakc
28.07.2026 15:21В данном случае “нет” скорее из-за параллельного выполнения. Может помяться порядок операций и float даст чуть другой результат. Или в целом получится другой порядок чисел в результате.
Сам по себе float достаточно детерминирован - если речь идет об одной и той же платформе и одном и том же порядке операторов без гонок (т.е. в одном потоке).
microuser
28.07.2026 15:21формально так и есть, а по сути нет, достаточно в промпт добавить одну запятую и результат будет совершенно другой
Moog_Prodigy
28.07.2026 15:21Согласен, но "друговость" результата зависит еще и от качества нейронки. Например, на запрос "напиши телеграм бота с библиотекой telebot" она выдаст разный по написанию код, но делающий одно и то же. Чем больше температура - больше разбег, вплоть до бреда, но для кодогенератора температуру ставят поменьше. Так и с качеством модели - 8b напишет работающий код примерно в 2 случаях из десяти, а громадный дипсик - в 9 из 10. Это как экспонента, никогда не касающаяся оси. Но таки 9 из 10 программ будут работать, они могут быть разные - где то с безопасностью косяки, где-то производительность. А по сути одна запятая мало что изменит, если это не "казнить нельзя помиловать".
Tochoz
28.07.2026 15:21Спасибо за статью!
Несмотря на то, что она направлена в основном на участвующих в найме разработчиков, мне как джуну многое откликнулось. Особенно о том, на чём сейчас набивать шишки для развития суждения, когда ии самостоятельно может закрывать мелкие задачи
TechExpert
28.07.2026 15:21Искать из неопределенности заказчика решение, ну такое себе. Потом он скажет это не было обговорено, я хотел другое. Я заплачу только за то, что указано в тз. Суть бизнеса такая, что должно четко указываться, что должно в итоге получиться, чтобы был четкий критерий, по которому можно понять что задача решена. Если вы за заказчика сами знаете в чем он неопрелелился и как должно быть, то вы должны с ним внести это в договор, перед тем, как начать делать.
Я представляю какой будет каламбур, когда каждый разработчик далекий от обсужления дооовора с заказчиком начнет проецировать своё видение.
odobryabov
28.07.2026 15:21«Я сделал по ТЗ» перестало быть защитой
Применительно к отбору новых кандидатов это сработает. Но, к сожалению, с ИИ агентами поведение "я сделал по ТЗ" стало ещё больше нормой для некоторых, кто уже в ИТ. Пофигизм окреп ещё сильнее.
visttt
28.07.2026 15:21Спасибо за статью!
Тенденция хорошая, ИМХО. Ответственность за решение должны нести все, а не только аналитик. Это исключит ситуации, когда разработчик видел, что решение неправильное, но всё равно сделал по ТЗ, потому что "так было написано в постановке".
microuser
28.07.2026 15:21Получается разработчик освободился от написания кода и должен взять часть обязанностей аналитика и продукт овнера. А чем тогда будут заниматься аналитики и продукт овнеры?
SabMakc
28.07.2026 15:21Хороший разработчик всегда был чем-то средним между аналитиком и продукт-овнером. Сейчас грань стирается еще сильнее. Хотя я с этим тезисом не согласен - не на столько можно ИИ код доверять, а в итоге производительность растет не так уж и сильно.
coolerian
28.07.2026 15:21То есть теперь все разработчики, не зависимо от стека, приходят к тому, чем всегда занимались 1Сники, которые бегали от бухгалтерии к своему столу и обратно в бухгалтерию. И проблему они из первых уст перенимали, и презентовали сразу заказчику. Никаких лишних рук
black_warlock_iv
28.07.2026 15:21К сожалению именно ту. Суть программирования — написание кода — потерялась, а всякая муть, не имеющая отношения к программированию, осталась.
Переопределять понятие программиста можно как угодно, но попробуйте спросить себя, что бы вы сказали 10 лет назад о программисте, который не пишет код? Вы бы сказали “он кто угодно, но не программист”. Устами невинного глаголит истина и все попытыки сохранить звание программиста в новых условиях — это натягивание совы на глобус.
Если вы действительно хотите остаться достойным высокого звания программиста, не занимайтесь подгонкой решения под ответ. Ищите реальные возможности. Ищите компании, не использующие ИИ. Боритесь с внедрением ИИ на всех уровнях. И самое главное — не забывайте как писать код, пишите код. Написание кода — это то, что делает нас лучше других.
evtomax
28.07.2026 15:21Боритесь с внедрением ИИ на всех уровнях.
Без профсоюзов, решениям которых подчиняется значительная часть программистов, всё решать будет бизнес. А кто против бизнеса - останется за бортом, если только не является суперзвездой программирования.
mstkachev
Спасибо за статью! Многое откликается, особенно про "сделать по ТЗ" и "дайте таску".
У меня опыт скорее не классической разработки, а больше на стыке разработки и консалтинга, когда помимо сервисов для пользователей команда делает еще немало исследований и проектных эдхоков от сбора/обработки данных до разработки прототипов. Но изменения требований в схожем направлении: человек, который разрабатывает что-либо в рамках задачи, все больше отвечает за достижение первостепенной цели клиента, которая не всегда конкретизирована и может расходиться с первоначальным ТЗ.
Это главный сдвиг, но на операционном уровне тоже есть изменения. Во-первых, ребята на младших позициях часто пытаются "выжать" из ИИ сверхрезультат, что выражается объемом текстов/таблиц/кода/чего угодно. Во-вторых, с развитием агентов можно поручать ИИ все более сложные и, соответственно, долгие по времени задачи. Мы обучаем сотрудников эффективно использовать свой когнитивный ресурс, не сидеть и не ждать 2 часа ответа агента, и в то же время ставить себя на место заказчика, готовить емкие и структурированные артефакты по своей задаче. Мы не требуем от сотрудников делать по десять задач параллельно и потом все переписывать за агентом, но мы требуем работать над эффективностью и сохранением ценности при использовании ИИ.
Про собесы. В основном у нас старшие специалисты ищут человека в команду к себе, поэтому на технических этапах собеседований сначала проверяется база, а дальше проверяется не столько насмотренность человека, сколько то, может ли он что-то додумать вместе со своим потенциальным руководителем, прийти к правильному решению при наводящих вопросах. Все ответил - погенерить вместе, не ответил - попробовать навести. До проникновения ИИ это тоже учитывалось, но сейчас уделяем отдельное внимание при принятии решения.