🤖 Фронтенд vs Бэкенд — кого ИИ заменит первым?

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

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

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

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

Отсюда и возникает популярный вопрос — если наша работа во многом состоит из повторяемых задач, кого же тогда ИИ заменит первым: фронтендера или бэкендера?

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

Но есть один интересный момент — количество кода.

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

На бэкенде эта же задача часто сводится к одному endpoint’у, модели и базовой обработке ошибок. Условно это может быть несколько десятков строк.

Поэтому логично задать вопрос: где больше пространства для ошибок — там, где 50 строк кода, или там, где 400?

При этом мой личный опыт показывает, что ИИ довольно хорошо справляется и с бэкенд-задачами. Например, когда я делал бота для менторства и бота для постинга в каналы, практически все SQL-запросы я генерировал через ИИ. Я просто описывал сущности и условия, копировал результат — и запросы работали без проблем.

То же самое можно сказать про оптимизации. Если дать модели структуру базы, эндпоинты и спросить, как ускорить запросы, она вполне может предложить добавить индексы или изменить структуру запроса.

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

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

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

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

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