Руководители решили, что AI заменит разработчиков. Кажется, они перепутали код с продуктом

Недавно наткнулся на короткую заметку NDTV о разговоре разработчика со своим руководителем.

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

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

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

Для руководителя фича иногда выглядит довольно просто:

Есть задача в Jira. На выходе должен появиться работающий функционал.

Если AI прочитал задачу, изменил несколько файлов, написал тесты и создал pull request, со стороны кажется, что работа закончена.

Но разработка начинается раньше Jira и заканчивается намного позже merge.

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

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

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

На Reddit уже обсуждают компании, которые замораживают найм разработчиков и направляют освободившийся бюджет на AI-инструменты. В одном из таких постов сотрудник компании примерно на 5000 человек рассказал, что руководство остановило инженерный найм на год. Командам предложили писать код с помощью AI и временно «одалживать» специалистов друг у друга.

В другом обсуждении среди инженерных руководителей описан уже почти автоматический конвейер: агент читает Jira, ищет нужные места в репозиториях, составляет план, запускает тесты, создаёт pull request и обновляет статус задачи.

Звучит впечатляюще. И я не сомневаюсь, что такие системы ускоряют часть работы.

Но у них появляется новое узкое место: кто-то должен проверить весь произведённый код.

Stack Overflow приводит показательный пример. Один разработчик начал писать в семь раз больше кода, причём вполне качественного. Однако остальные участники команды тратили большую часть времени на его проверку. Производительность одного человека выросла, а производительность системы — уже не так очевидно.

Поэтому сегодня дефицитом становится не код, а инженерное суждение. Хороший разбор этой проблемы есть в статье Stack Overflow о «перегрузке решениями» при работе с кодинг-агентами.

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

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

Думаю, что должность не исчезнет за одну ночь. Но содержание работы действительно изменится.

Раньше разработчик получал задачу и писал код. Теперь он всё чаще будет:

То есть писать руками он, возможно, будет меньше. Но принимать решений придётся больше.

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

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

С измерением производительности тоже всё неоднозначно.

В 2025 году исследователи METR обнаружили, что опытные разработчики в знакомых open-source проектах с AI выполняли задачи на 19% медленнее, хотя сами были уверены, что работают быстрее.

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

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

Скорость генерации кода и скорость выпуска надёжного продукта — разные показатели.

Самый опасный сценарий выглядит так:

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

AI не создаёт эту проблему с нуля. Плохие команды производили неподдерживаемый код и раньше. Просто теперь они могут делать это намного быстрее.

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

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

Поэтому я бы не ставил вопрос так: «Заменит ли AI middle-разработчика?»Более точный вопрос звучит иначе: Сможет ли компания превратить разработчиков в операторов AI и при этом сохранить людей, которые действительно понимают продукт и его код?

В Paladin Engineering мы не считаем, что AI нужно бояться. Игнорировать его возможности было бы не менее странно, чем полностью доверить ему продукт.

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

Поэтому главный вопрос звучит не так: Заменит ли AI разработчика? Гораздо полезнее спросить:Как построить процесс, в котором AI ускоряет команду, но не лишает её понимания продукта и ответственности за результат?

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