Разработка систем электронной коммерции
Мы решили поручить анализ данных 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 площадок и посчитал, какая часть выдачи действительно отвечает на запрос пользователя. Отсюда родился рейтинг площадок по точности поисковой выдачи. Спойлер: у самых больших игроков мимо летит больше половины, а неожиданный лидер — вообще не маркетплейс. Полный рейтинг и методология — в статье.
Давайте сразу оговорюсь, дабы вы не судили меня строго. Я не программист, а скорее маркетолог с навыками программирования и некоторыми знаниями в IT. Но речь в этой статье пойдет далеко не о маркетинге, а о программе, которую мне довелось разработать. Для меня это было внезапно ;-)
Летом 2025 года мне мой муж начал рассказывать о проблемах своей компании. У них просто ужасно много времени уходило на внесение в 1С заявок клиентов. Настолько ужасно, что для этого держали 8!!! офис-менеджеров, при общем штате компании человек в 40. Это чтобы вы осознали масштаб проблемы.
Я хлопала глазами и предлагала воспользоваться стандартным функционалом сопоставления номенклатуры в 1С. Он крутил у виска и говорил, что это не сработает: клиенты любили очень причудливо описывать требуемые позиции.
Это статья о том, почему написать SaaS оказалось проще, чем превратить его в продукт.
После университета я начала искать первую работу разработчиком. Вакансии для начинающих почему‑то не выглядели вакансиями для начинающих. Я читала требования, понимала, что многого не умею, нервничала всё сильнее, а потом решила сделать собственный проект — конструктор магазинов.
Уже звучит как начало чего‑то плохого.
Идея была такой: владелец отправляет токен своего Telegram‑бота, мой сервис подключает к нему команды и витрину. Покупатели открывают его бот‑магазин внутри Telegram, собирают корзину, оформляют заказ. Владелец управляет всем через отдельный Mini App.
Уверен, у многих есть хотя бы один пет-проект, перспективный B2B SaaS, CRM, другими словами — сервис, который когда-нибудь обязательно выстрелит. В процессе разработки у многих стильных, модных и молодежных проектов рано или поздно появляется вопрос: «А что если добавить генерацию изображений или видео?». На первый взгляд все выглядит просто: берем Comfy UI, собираем workflow, выбираем модели — и готово. Локально все действительно можно собрать за один вечер.
Проблемы начинаются ровно в тот момент, когда решением пользуетесь не только вы. Первый пользователь ждет 20-30 секунд, второй стоит в очереди, остальные уже получили свои тайм-ауты, а вы внезапно ловите себя на том, что читаете документацию про Kubernetes и настраиваете балансировку запросов, вместо того, чтобы сконцентрироваться на развитии продукта... И вот тут уже развертывание Comfy UI кажется не настолько простой задачей как в начале.
Если вам знакома эта ситуация или вы только планируете добавить генеративный ИИ в свое приложение, эта статья для вас. Покажу, как превратить Comfy UI workflow в API, которым можно пользоваться из любого приложения, не поднимая инфраструктуру и не привлекая внимания санитаров.
Привет, Хабр! Это Сергей Перевозчиков, основатель агентства контекстной рекламы «КонтекстЛаб».
Когда ко мне обратился производитель хозяйственных металлоконструкций, у него уже был успешный опыт продаж на Wildberries. Но на Ozon всё оказалось совсем иначе: компания терпела убытки, несмотря на хороший ассортимент и опыт работы с маркетплейсами.
Разбираясь в ситуации, мы обнаружили сразу несколько проблем: слабые карточки товаров, непонимание принципов работы площадки и новые правила логистики, которые серьёзно влияли на экономику продаж.
Мы полностью переработали карточки товаров, улучшили их для поиска и сделали ставку на продвижение самых перспективных позиций, которые могли «потянуть» за собой остальные продажи.
В результате кликабельность карточек выросла в два раза, а компания получила дополнительно 3,8 млн рублей прибыли в месяц. В этом кейсе я покажу четыре шага, которые помогли перевести бизнес на Ozon из убыточного в прибыльный.