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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🐞 Вайбкодинг атакует или как мы потеряли 50к рублей в YeaHub

Вполне себе реальная история нашей ошибки в YeaHub.

Есть у нас senior Java developer, спец своего дела, опыт 8 лет, работает в Биг Тех. У нас он как один из руководителей по бекенду и занимается в основном инфраструктурой. Но есть одно «но» — проект у нас на Node.js. Учить Node, конечно, зачем? Если умеешь писать код, можно чисто вайбкодить. Но Java и JavaScript, кроме первых четырёх букв, сильно отличаются: асинхронность, подходы, методы, обработка ошибок.

И вот что произошло.

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

Оказалось, что мы формировали заказ, но не тригерили списания денег у пользователя. Визуально выглядело так: «Заказ сформирован, но не оплачен».

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

Наш джавист не учёл особенности асинхронности и обработки ошибок в JavaScript: один заказ мог быть «битым», и тогда весь цикл списания останавливался. Использовался forEach с async/await и обработкой ошибок, но в Node.js такой подход не ждёт асинхронные операции корректно. В итоге каждый день мы формировали заказы, пытались списать деньги, но застревали на одном висяке, и остальные оплаты просто игнорировались. В Java такие сценарии работают иначе, и привычные подходы к потокам не переносились напрямую.

Этот код полностью писала нейронка, потому что бэкендер не знал нюансов Node.js и не привык к его асинхронности.

В итоге больше 100 пользователей пользовались сервисом месяц бесплатно, а мы потеряли 50к рублей.

Вывод: даже опытный Java-разработчик может наткнуться на особенности другого языка, особенно в асинхронных сценариях, а нейронка может генерировать код, который кажется рабочим, но ведёт себя иначе на практике.

А у вас были интересные кейсы? 🔍

💪 Попал в рейтинг Telegram-каналов лидеров IT-индустрии

Сейчас на 12 месте 😁

Приятно иногда оказываться в таких подборках — хороший маркер, что двигаюсь в правильном направлении.

https://kokoc.tech/ratings/?tab=development&period=2026

🌐 Нетворкинг и социальные связи

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

Помню, когда я ещё был обычным разработчиком и гонял в офис на трамвае — я реально любил трамвай. Почему? Потому что пока ехал, постоянно читал. Для меня это был ритуал. Одна из книг — «От нуля к единице» Питера Тиля. Он рассказывает про свой опыт в PayPal, про стартапы… Но мало кто знает, что на самом деле это всё ещё круче и поучительнее. Питер Тиль входит в так называемую PayPal mafia — вместе с ним там были ребята, которые потом сделали Tesla, YouTube, LinkedIn и ещё кучу продуктов.

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

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

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

Познакомились на моке — стали периодически созваниваться, решать задачи, вместе откликаться на рынке, рефать друг друга рекрутерам. Как минимум четыре человека устроились в марте благодаря таким связям. Кто-то устроился раньше, кто-то через месяц вышел на рынок. Тот, кто трудоустроился — рефералит своего товарища, с которым успел познакомиться и подружиться за время обучения. Вот вам наглядный пример, как всё работает, на нашем IT-рынке и трудоустройстве.

Мораль? Общение. Чтобы добиться успеха, нужно быть везде и сразу, быть активным, строить свои социальные связи. Бесплатно — идите на митапы и конференции (благо их пруд пруди), общайтесь, знакомьтесь. Ищите чаты: я, например, сижу в Threads, там часто зовут вступать в чаты «Вашего города для тусовки», «Основатели стартапов», «Кто ищет работу — давайте вместе». Есть чаты разных блогеров и IT деятелей. Есть платные сообщества — вступай, общайся, знакомься. Это может реально во что-то вылиться.

Всем успехов, друзья ✊🏻

💸 Финансы и расходы проекта: путь к COO

Честно говоря, самая сложная для меня тема в бизнесе — это финансы. Не техническая часть, не маркетинг, не продукт, а именно финансовая модель и управление деньгами. Интуитивно я понимаю, как продвигать проект: можно нанять маркетолога, SEO-специалиста, монтажёра, контентщика. С технической частью тоже проще — если ты сам сильный специалист, то в целом понимаешь систему на верхнем уровне, а при наличии сообщества разработчиков всегда можно найти нужных людей.

Но с финансами у меня долгое время были серьёзные проблемы.

В YeaHub, например, довольно долго работало два дизайнера — и это при том, что это стартап. Сейчас один дизайнер справляется со всеми задачами. Долгое время добавление контента на платформу обходилось нам в 80–100 тысяч, пока спустя 4–5 месяцев я не внедрил автоматизацию. Сейчас это стоит в разы дешевле.

Были и необдуманные фичи. Например, аналитика «сложных вопросов» и различная статистика, которой пользователи почти не пользовались. В теории мы могли бы просто раз в месяц с аналитиками собирать данные и оформлять их в красивую инфографику, вместо того чтобы тратить три месяца разработки на полноценную систему (эх, раньше бы пойти на курсы в Стратоплан..)

Были и фичи сообщества — возможность добавления вопросов и ресурсов, заявки от пользователей. Это действительно важный элемент коммуникации и наполнения контента, но не на ранней стадии проекта. Все эти решения требовали ресурсов, и это, по сути, ошибки в бюджетировании.

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

Дальше я начал усиливать продукт через дополнительные инициативы: пет-проекты, внутренние инструменты, расширение инфраструктуры практики, курсы, гайды и боты. Многие идеи на старте выглядели очевидно полезными — как “это точно усилит результат”.

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

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

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

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

https://stratoplan-school.com/coo/

Было интересно, но местами очень сложно. Тем не менее, записи и конспекты есть — я планирую пересматривать их и постепенно переносить всё на модель YeaHub и других проектов. Хочу пройтись по всем подходам из лекций, применить их на практике, собрать финансовую карту, отчёты по расходам и бюджету. Займусь этим в отпуске 😁

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

Мысли, которые заставляют работать больше:

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