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

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

Компания может нуждаться в инженерах и одновременно пересматривать, сколько их ей нужно. Чтобы поставить под вопрос следующую вакансию, ей совершенно необязательно изобретать ИИ, который самостоятельно заменит весь отдел.

Профессию защитили. Что со штатным расписанием?

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

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

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

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

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

Почему ИИ так быстро полез именно в код

В другом посте я писал, что разработка стала удобной площадкой для проверки возможностей LLM. У ИИ‑лабораторий здесь собственные задачи, знакомая среда и возможность организовать обратную связь. Код можно выполнить, подать на вход данные и сравнить результат с ожидаемым. Для части задач это очень удобное устройство мира.

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

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

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

Возьмём обычный возврат платежа

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

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

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

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

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

В комментариях я сформулировал это проще: «Фонтан кода сам по себе ещё не продукт». Нужно понимать, куда всё это льётся и кто будет разбираться с последствиями.

Хорошо, а где весь прекрасный софт?

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

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

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

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

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

Ответственность легко оставить. Полномочия сложнее

В комментариях к моему посту пошутили, что ИИ нельзя посадить, хотя на вопросы следователя он ответить способен. Я ответил, что убедительность вообще стоит записать первым пунктом в риски. Особенно когда за ней стоит доступ к деньгам.

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

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

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

Я бы не спешил объявлять оставшегося проверяющего главным победителем ИИ‑революции. Если через него пропустили весь поток без права его ограничить, ему досталась довольно паршивая работа.

Новые продукты могут создать новую работу. Но где именно?

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

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

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

При этом требование срочно стать целым ИТ‑отделом тоже выглядит сомнительно. Безопасность, например, не становится простым занятием оттого, что её добавили в обязанности разработчику с подпиской на Claude. Вести задачу через полный цикл можно вместе с другими специалистами (для сложной системы иначе и не получится). Нужно понимать, где заканчивается собственная компетенция и чья проверка ещё потребуется. Длинная должностная инструкция этого понимания не заменяет.

Что я предлагаю делать с этой грустной мыслью

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

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

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

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