Разработка под e-commerce *

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

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

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

Всем привет! 

Меня зовут Дмитрий Шипилов, с вами команда поиска Uzum Market.

Мы уже рассказывали вам о нашем поисковом движке: о том, как вообще работает ранжирование и что у него под капотом и как мы получаем кандидатов с помощью векторного поиска. 

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

Началось с простого желания: чтобы Claude мог написать письмо коллеге, не заставляя меня переключаться в браузер. Готовые решения есть — Zapier, всякие облачные коннекторы. Но там моя переписка проходит через чужую инфраструктуру, а мне этого не хотелось. Значит, свой MCP-сервер: пара сотен строк, Gmail API, за вечер.

Вечер растянулся на несколько дней и 300 тестов не потому, что задача сложная, а потому, что почта оказалась минным полем, где каждая вторая мелочь ломает всё молча и не сразу. Собрал грабли в кучу. Если будете делать что-то похожее — сэкономите себе несколько вечеров.

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

Мы решили поручить анализ данных ChatGPT. И быстро поняли, что проблема вовсе не в модели. Оказалось, что LLM может красиво объяснять, но не должна считать. Ошибка была не в промпте, а в архитектуре системы.

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

Привет, на связи Рома Миронов из Авито. Я бывший — хотя бывших не бывает — фронтендер, а сейчас тим- и техлид. Ковыряю AI и больше ничем не занимаюсь — кроме команды, конечно :) В этой статье расскажу, почему фронтенд пока не умер, какие задачи уже можно отдавать агентам, где они красиво ошибаются и почему сначала от AI становится больнее, а не легче.

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

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

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

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

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

Откройте бэклог любого крупного магазина и найдите там задачу «поправить сортировку в блоке „с этим товаром покупают“». Обычная задача, полдня работы, идёт в общей очереди. Двадцать лет назад ровно эта штука была темой статей в IEEE, а до того темой диссертаций. Сейчас это один из блоков задач. Владельца у него нет, есть компонент в джире.

Ещё в том же бэклоге почти наверняка лежит «включить AI‑поиск», с приоритетом выше. Хотя поиск с исправлением опечаток и синонимами у вас работает с 2015 года и называется просто «поиск».

Вот про этот зазор я и хочу написать.

Представьте диалог c вашим любимым ИИ‑инструментом:

— Найди поездку в Казань на выходные, до 20 тысяч рублей и с нормальным отелем.

— Секунду, подбираю…

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

А вот чтобы это «подбираю» означало поиск по реальным ценам и наличию агент должен уметь обращаться к базе данных с билетами. Именно для этого мы вместе с командой Туту выпустили MCP‑сервер.

Я бэкенд-разработчик: пишу на Rust сервис аналитики для продавцов маркетплейсов. Одна из его частей — автоматический биддер, который превращает цель «ДРР не выше 12%» в непрерывное управление ставками. Внутри: контроллер с мёртвой зоной и клампами, per-token бакеты против 429 «Limited by global limiter, per seller», возобновляемые фоновые джобы и борьба с дедлоками параллельных писателей.

Привет, Хабр! Меня зовут Дмитрий, руковожу отделом рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Команда обычно тратит месяцы на проектирование и запуск. А за неделю до релиза выясняется, что не работает форма оплаты, сайт не проходит по мобильной версии или у него нет обязательных документов. Типовой чеклист запуска ограничивается дизайном, а техническую приемку и новые требования РКН он не покрывает. Есть и отдельная тема: поисковая выдача.

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

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

Инструменты статического анализа (SAST) лишь подсвечивают вероятные уязвимости, генерируя гипотезы. Динамическое тестирование (DAST) и фаззинг, напротив, выявляют реальные сбои на работающем приложении и фиксируют вектор атаки, но не указывают на конкретную строку в исходниках. Традиционно эти два подхода существуют в изоляции, образуя методологический разрыв, преодолеть который способен только AppSec-эксперт путем кропотливого ручного триажа.

В этой статье мы расскажем про то, как в INFERA AI.SafeCode уменьшаем поток ложных срабатываний в целом, зачем для этого формируем единый реестр знаний о проекте, и как строим мост от SAST к автоматически подтверждаемой уязвимости.

Классический подход к Application Security сегодня переживает кризис, ситуацию усугубляет бум AI-помощников (GitHub Copilot, Cursor, Claude). Разработка ускорилась кратно, но вместе с ней масштабировалась и генерация небезопасного кода. Разработчик теперь может сгенерировать за час то, что раньше писал день, при этом уязвимости тоже начинают появляться с такой же скоростью. Если процесс безопасности остался прежним, AppSec быстро превращается в узкое место.

В этой статье мы разберем архитектуру и механику работы INFERA AI.SafeCode – платформы непрерывного анализа кода, которая отказывается от концепции «просто показать список подозрений» в пользу автоматического доказательства уязвимостей и MLSecOps-подхода.

Решение объединяет SAST, SCA, Secrets, DAST, Pentest, Code Fuzzing и API Fuzzing в единый DevSecOps / MLSecOps-контур.

Статья продуктовая, но мы ее публикуем на HABR не как рекламную, а как концептуальную. Хотим показать, как меняются подходы к безопасной разработке и насколько неэффективным становится «разрозненный» AppSec в эпоху ИИ и вайб-кодинга.

Расширенное редактирование и продвинутые ИИ-функции

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

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

Привет, Хабр! Меня зовут Богдан Бурков, я старший инженер по тестированию в мобильном приложении для продавцов Ozon Seller. В этой статье я хочу поделиться историей, как мы с коллегой, ведущим инженером по тестированию Владиславом Поповым (привет, Влад!), улучшали наш релизный процесс и что у нас из этого получилось.

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

В статье расскажу, что именно мы автоматизировали, что получилось не сразу и как в итоге сократили релизное тестирование примерно с семи до четырёх часов.

Свежие статистические данные из обзоров hh, elama, АРИР. И тренды, которые я вижу на рынках разработки и digital-маркетинга.

Есть два способа лишиться контроля над собственным интернет-магазином.

Первый - это арендовать платформу (InSales, OpenCart, Битрикс, конструктор). Вы платите за тариф и приложения, а код, данные и правила здесь не ваши. Второй, менее очевидный - это заказать разработку «под ключ» и получить чёрный ящик, который знает только подрядчик. Формально код ваш, но тронуть его без той же команды нельзя. Лок-ин просто переехал с платформы на агентство.

Мы перевезли собственный магазин (fashion-бренд IWANT) с InSales на свой движок и на этом опыте собрали переиспользуемый пакет переезда. Один из принципов пакета, отдавать клиенту не «сайт», а agent-ready репозиторий: проект, устроенный так, что дорабатывать его можно самому через админку, силами AI-агента по инструкции в репозитории либо через нас. Ниже пишу что за этим стоит и где границы.

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