Почему AI не заменит разработчиков. Или заменит

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

Но я не встретил честной экспертной точки зрения с позиции бизнеса и разработки вместе. Были либо технарские, либо бизнесовые. 

Бизнес хочет либо “срезать косты”, либо “увеличить продажи”. Точнее даже так — об этом активно говорят бизнесмены, которые пытаются продать ИИ. От них только и слышишь маркетинговые лозунги. Написанные через ИИ.

А вот про риски никто не говорит! А это суть предпринимательства — работа с рисками. Сколько крупных игроков откатывают свои ИИ-стратегии сейчас? А ваш бизнес может позволить себе работать пару лет в дикий убыток ради эксперимента?

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

И где TRUE/FALSE?

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

Мы в Authoriza.ru используем AI при разработке сервиса, подготовке документации, написании тестов, рефакторинге, поиске вариантов реализации и анализе чужого кода. Как минимум. Это то, что вспомнил сходу. Он хорошо справляется с рутинными задачами и часто предлагает решения, до которых самому пришлось бы доходить значительно дольше.

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

Здесь о другом: наблюдение, которое интереснее обсуждений о том, «заменит ли AI программистов»:

Чем больше кода начинает писать искусственный интеллект, тем выше становятся требования к человеку, который этот код принимает в работу.

Код — это не продукт

Когда говорят о том, что AI скоро заменит разработчиков, почти всегда имеют в виду процесс написания кода. Ок, согласен, здесь прогресс впечатляет. Сегодня модель может за несколько минут написать REST API, SQL-запрос, React-компонент или тесты, на которые раньше уходили часы.

Но если посмотреть на любой коммерческий проект, окажется, что написание кода — далеко не самая дорогая часть разработки.

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

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

Написать функцию сегодня может и человек, и AI. Объяснить, почему она должна выглядеть именно так, — совсем другая задача.

Где AI действительно экономит время

За два года использования LLM я перестал воспринимать их как инструмент для генерации кода. Это слишком узкое применение.

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

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

ИИ хорош в аналитике, неплох в маркетинге, хорошо резюмирует большие объемы текста, ну и много где еще.

При работе над документацией Авторизы мы тоже используем LLM. Они помогают подготовить черновики, проверить структуру текста, найти неудачные формулировки или предложить более понятное объяснение. Но финальная версия всегда проходит ручную редактуру. Особенно если речь идёт о безопасности, OAuth 2.0, OpenID Connect или других темах, где неточность в одной формулировке может ввести читателя в заблуждение. Часть этой документации доступна публично: authoriza.ru/docs – можете посмотреть, что получилось в итоге.

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

Когда кода становится слишком много

Пожалуй, самое неожиданное изменение, которое я заметил за последние два года, связано не с качеством кода, а с его количеством.

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

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

Казалось бы, производительность команды должна вырасти пропорционально. На практике всё оказалось сложнее.

Если раньше Pull/Merge Request мог содержать 200–300 строк изменений, то сегодня легко увидеть две-три тысячи. И это не потому, что задача стала сложнее. Просто написать этот объём кода теперь значительно дешевле. (А вы любите ревьюить МР на 3000 строк? На какой строке вы забиваете на ревью или проклинаете асайни? А потом этот ревью ляжет в сотне таких же, и однажды кому-то, угадайте кому, придётся засучив рукава погружаться в многомегабайтный легаси. Потому что, если отдать его ИИ, то обратно рабочим точно не получишь. После такого люди увольняются.)

Но стоимость ревью почти не изменилась.

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

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

Читать и критически оценивать этот код по-прежнему приходится человеку.

Генерация почти ничего не стоит. Ошибки стоят дорого.

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

• Почему выбран именно такой алгоритм?

• Зачем здесь дополнительная абстракция?

• Что произойдёт при высокой нагрузке?

• Почему именно так организовано кэширование?

• А зачем подключена эта библиотека? Только ради одной функции в 5-10 строк кода?

• А не станет ли это проблемой при масштабировании через несколько месяцев развития проекта?

Эти вопросы не к синтаксису. Они к системе в целом. 

Другой нюанс в том, что БЯМ-ы хорошо умеют воспроизводить распространённые решения. Но реальный проект рано или поздно начинает отклоняться от «среднего случая». Какие-то ограничения бизнеса, особенности инфраструктуры, накопленный техдолг, обратная совместимость, требования безопасности. Всё это в промт не впихнешь, а значит, и в ответе не будет. Может размер контекста LLM скоро станет таким большим, что будет вмещать в себя всю кодовую базу проекта, аналитическую и другую документацию, да и вообще всё, что необходимо и тогда качество кодогенерации еще вырастет. Но мне кажется, быстрее ИИ-бум осядет, и токены придут к реальной стоимости. Да и всю систему кто-то должен оцифровать в совместимых форматах. Иначе говоря, утопия.

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

Что на самом деле делает разработчик

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

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

Значительная часть работы выглядит примерно так:

• понять, почему система ведёт себя именно так;

• найти причину ошибки, которая проявляется только при определённом сочетании условий;

• решить, можно ли изменить существующую архитектуру без побочных эффектов;

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

• объяснить коллегам, почему более простая реализация в данном случае окажется надёжнее.

Где здесь про количество написанных строк?

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

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

Самая дорогая работа — принимать решения

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

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

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

Именно на этих вопросах сегодня тратится большая часть времени опытного инженера.

Возьмем простой пример из области аутентификации. Реализовать обработку Refresh Token сегодня способен практически любой AI. Более того, скорее всего он предложит несколько вариантов реализации, соответствующих спецификации OAuth 2.0. Я недавно давал такую задачу ИИ-агенту для создания демо-приложения. В итоге я удалил ~30% его кода и часть переписал — он использовал хранение рефреш-токена в браузере, в обычных куках, создав критическую уязвимость. Потому ли, что он не знает OAuth 2.0 или OIDC, или принципов безопасности? Нет. Просто среди данных, на которых его обучали оказалось такое решение, может какое-то демо из открытых репозиториев, и что-то еще, я достоверно не угадаю. А общий вес этого решения оказался выше в рамках контекста моего агента.

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

Кто действительно рискует потерять работу

Из этого не следует, что AI никого не заменит.

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

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

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

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

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

Мне кажется, сегодня этот вопрос уже не самый важный.

Языки программирования меняются. Фреймворки появляются и исчезают. Инструменты, которые сейчас незаменимы, через несколько лет умрут или уступят место другим.

Гораздо медленнее меняются инженерные принципы.

• Умение проектировать систему.

• Умение читать чужой код и понимать, почему он устроен именно так.

• Понимание алгоритмов, сетей, баз данных и вопросов безопасности.

• Умение обучаться.

• Умение анализировать последствия своих решений.

• И, наконец, готовность отвечать за эти решения.

Именно эти навыки сложнее всего автоматизировать.

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

Если вы можете пользоваться ИИ, найти ошибку в сгенерированном коде и устранить, выбрать и обосновать архитектуру, оценивать решения системно, контролировать объем кода — вы нужны миру ИТ.

Заключение

AI действительно научился писать код быстрее человека. Но заказчику никогда не был нужен код сам по себе.

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

Пока ответственность за это несет человек, хороший разработчик останется востребованным. Просто его работа будет всё меньше связана с набором текста в редакторе и всё больше — с принятием инженерных решений. ИИ не отвечает ни за что. Если система упала, с Claude не спросишь — с ним где сел, там и слез. Бизнесу нужно контролировать риски, и он делегирует контроль технологических рисков разработчикам. Пока вы можете гарантировать стабильность своих систем — вы незаменимы.

Всем токенов и добра!