Мы в Лаборатории прикладной промптологии и производственной тревожности НИИ ИИ второй год следим за тем, как разработчики синхронизируются с генеративными моделями. Уже сформировался новый тип производственного взаимодействия. Это бесконечная серия коротких переговоров, в ходе которых одна сторона просит поправить одну строку, а вторая через 14 секунд возвращается с полностью переписанным кодом. Как будто во всех проектах появился ещё один разработчик, который постоянно косячит, выдаёт старый код за новый, до последнего спорит даже с техлидами, не признаёт очевидных ошибок, нуждается в постоянном ревью и при этом не может быть уволен. Потому что за ним, как нам регулярно объясняют, будущее отрасли, а значит, со временем он «вырастет» и повысит качество кода и точность ответов. Поэтому нам не остаётся ничего другого, кроме как настраивать эту синхронизацию.

Школьные олимпиады по информатике до сих пор воспринимаются как отдельный мир, где дети решают абстрактные задачи, далёкие от реальной работы. Но сильный олимпиадник сегодня уже не просто быстро пишет код. По уровню алгоритмического мышления он близок к junior, а иногда и к middle-разработчику, только без боевого опыта. Он умеет жить в таймлимитах, думать об асимптотике, быстро проектировать решение, дебажить под давлением и работать не только с чистой алгоритмикой, но и с задачами по ИИ, безопасности и робототехнике. Поэтому заключительный этап Всероссийской олимпиады школьников по информатике, который в этом году проходит с 22 по 28 марта, показывает, какой инженер будет нужен индустрии через несколько лет. Чтобы понять, из каких скилов собирается портрет будущего инженера, мы посмотрели, как сегодня устроен финал олимпиады, какие задачи там дают и чему он на самом деле учит.

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

Поддержка двух нативных приложений в таких условиях может быть дорогой в финансовом плане и сложной в скорости вывода новых функциональностей. Один из способов модернизировать продукт и снизить расходы – постепенно перейти на Kotlin Multiplatform.

В этой статье технический директор Александр Кияйкин и iOS-разработчик Мария Нестерова из CleverPumpkin вместе с экспертами X5 Tech, AvitoTech и MAGNIT OMNI разбирают, как компании со зрелыми цифровыми продуктами использует KMP, какие риски учитывают и какой видят от этого эффект.

Linux пропитан магией. Тип файла определяется не по расширению, а библиотекой magic, которая смотрит на сигнатуру первых байтов. В системе живут демоны, процессы могут работать в режиме daemon, а исполняемые файлы хранятся в формате ELF и разбираются утилитой readelf. Это похоже на шутки старых разработчиков, но они появились не случайно.

Инженерные системы наполнены метафорами, потому что так проще думать о сложном, объяснять невидимое и работать с тем, что нельзя потрогать руками. Со временем мы привыкаем к этой «магии» и перестаём замечать, что вместе с ней перенимаем определённый способ мышления.

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

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

Привет, Хабр! Меня зовут Дмитрий Орлов. На AI Talent Camp я выступал в роли хастлера (AI-Product) команды ExamLab Bot и ожидал классический хакатон: собрать команду, получить дедлайны, сделать демо и разъехаться. На деле это оказался интенсив с быстрыми итерациями и постоянным общением с менторами. Нам всё время напоминали, что MVP — это не демка «на сцену», что мы отвечаем за полноценный AI-продукт, который будет нужно развивать. Поэтому мы с Дарьей Дмитриевой, которая выступала в роли хакера (LLM Engineer), и смогли сделать то, на что в продуктовой разработке уходят недели.

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

Представьте стандартный отчёт по промокампании: «Пользователи, применившие промокод, потратили на 800 рублей больше среднего». Бизнес доволен, маркетинг рапортует об успехе. Но подождите, а сколько из них потратили бы эти деньги и без промокода?

Это не риторический вопрос. Это принципиальная проблема, которая называется selection bias — систематическая ошибка отбора.

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

Торговля кажется чем-то неотделимым от компьютеров, сетей и алгоритмов. Будто до них были только ярмарки и натуральный обмен, а всё остальное появилось совсем недавно.

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

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

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

Мы все видим, как ассистенты и агенты меняют правила игры. То, что недавно называли «умной IDE» с подсказками, рефакторингом и статическим анализом, сегодня лишь разминка перед сбором функциональности. Ассистенты и агенты могут пройтись по десяткам файлов, обновить тесты и даже оформить базовую документацию. Но вместе с бешеной скоростью генерации пришёл и хаос. 

Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.

Стейкхолдеры — это те самые люди, которые приходят с задачей «Надо ещё вчера», а формулируют её на уровне «Копаем от забора до заката!» и при этом вполне способны одним решением заморозить проект. В итоге команда либо бросается делать «как поняла» и приплывает не туда, либо зависает в ожидании мифического ТЗ, либо выгорает в героическом овертайме, а результат всё равно остаётся под вопросом. Знакомо?

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

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

Хабр, привет! Недавно завершилось ML-соревнование E-CUP 2025. Наша команда из X5 Tech заняла первое место в треке «Логистика: автопланирование курьеров», где было нужно оптимизировать время, затрачиваемое курьерами на доставку 20 000 заказов. В статье расскажем про подходы, которые использовали для решения этой задачи. Посмотрим, во сколько раз можно сжать JSON с матрицей расстояний. Какой код мы использовали для быстрого решения задачи TSP с помощью LKH-3. Обсудим, на что обращать внимание при кластеризации заказов.

Постановка задачи

Требовалось распределить порядка 20 000 заказов между 280 курьерами и построить для каждого из них маршрут так, чтобы минимизировать их суммарное время работы. Оно складывалось из времени перемещения курьеров между заказами и времени выполнения самих заказов (service time). За каждый невыполненный заказ добавлялся штраф 3000 секунд...

В любой крупной компании есть повторяющийся сценарий. Аналитик сидит над экспериментом или моделью, строит А/В тесты и дашборды, и в этот момент приходит бизнес и просит быстро посмотреть «продажи жвачки за вчера». Аналитик переключается, пишет запрос, отдаёт результат, а через десять минут прилетает почти такой же вопрос. Потом ещё один и ещё. День заканчивается, а свои задачи стоят и покрываются ржавчиной.

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

Мы хотели упростить работу с данными. Чтобы пользователь задавал вопрос, сервис превращал его в SQL, выполнял в хранилище и возвращал аналитический ответ. Чтобы рутина уходила в инструмент, а аналитик переставал быть «бутылочным горлышком».

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

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

Мы в X5 Tech решили превратить генеративный ИИ из источника хаотичных вариаций в стабильный конвейер брендового визуала. Зафиксировали стиль, задали структуру, выстроили управление вариациями, и в итоге собрали рабочий пайплайн. Когда он заработал, скорость выросла почти вдвое, некоторые команды полностью отказались от фотостоков или значительно сократили их использование, а 40–45% визуального контента «Пятерочки» и «Чижика» теперь создается с участием ИИ.

В этой статье — разбор принципов, на которых держатся пайплайны управления генерациями: как модели помогают контролировать структуру и стиль, какую роль в этом играет дизайнер и за счет чего связка ControlNet, LoRA, Style Reference и мультимодальных ИИ превращает генерации в предсказуемую систему.

У статьи в ленте Хабра есть несколько строк, чтобы пройти читательский фильтр «открыть или пролистать». Для кого-то всё решают цифры и вау-эффект, для кого-то – реальный кейс, для кого-то – автор или хаб. И мы, команда редакции блога X5 Tech, очень хотим узнать, что вам ближе, чтобы анонсы в нашем блоге показывали важное и не тратили ваше внимание на лишнее.

Привет, Хабр! Меня зовут Вадим Королёв. Я руководитель команды разработки в X5 Tech. Очень люблю Next.js и решать проблемы, которые он приносит. С ним всегда происходит что-то интересное. Расскажу о причине утечки памяти в Node.js, которая оказалась глубже, чем можно было подумать.

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

В этот момент я занимался архитектурой и оптимизацией Node.js в музыкальном стриминге. Открыл графики и увидел явный рост памяти, который уходил в пик и приводил к перезапуску подов. Так началась «классическая предновогодняя история». Next.js в Kubernetes внезапно начал есть память так, будто у него внутри чёрная дыра.

Привет, Хабр!

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

Мы хотим привнести инженерный и аналитический подход в мир инвестиций. Эксперты из ДРТ (бывший Deloitte) и УК «Альфа Капитал» расскажут, на что обращать внимание при покупке ценных бумаг. А сотрудник X5 Tech поделится своим опытом сборки портфеля.

Хотите разобраться, как искать и читать данные о компаниях, в которые хотите вложиться? Тогда погнали!

Привет, Хабр! Меня всё ещё зовут Данила Федюкин, и я продолжаю быть тимлидом в X5 Digital. Руковожу командой, которая занимается метчингом. В прошлый раз я рассказывал, как мы перешли на собственную систему рекомендаций, а в этот раз о том, как делаем то же самое, но с метчингом товаров.

X5 Digital – один из цифровых бизнесов Х5. Мы работаем в режиме Highload с RPS в 7500 и отвечаем за всю онлайн-доставку в более чем 1000 городах и населённых пунктах России.

Этот канал постоянно растёт. В 2024 году покупатели Х5 совершили свыше 119,5 млн заказов продуктов на дом.

Мы делаем собственную in-house WMS для дарксторов, приложения для сборщиков и курьеров, CRM, каталоги товаров и другие онлайн-продукты, а ещё мобильное приложение для торговых сетей.

Всё это, отталкиваясь от разных форматов доставки. В «Перекрёстке» среднее время доставки CTD (Click-to-Delivery — от оформления заказа до его получения клиентом) сократилось до 45 минут, в «Чижике» — до 37 минут, а в «Пятёрочке» порядка 40% заказов доставляются клиентам менее чем за 20 минут.

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

Привет, Хабр! Я Илья Гордеев, руковожу командой дизайна внутренних продуктов в X5 Tech. В этой статье расскажу, как мы создали чек-лист самопроверки, какие сложности прошли при внедрении и как он помогает экономить время на ревью, держать планку дизайнерам, а команде работать быстрее и чище.

Привет, Хабр! Я давно отучился в школе и институте, но хорошо помню, как мне говорили: «Учи! Тебе это пригодится! Без этого никуда! Это очень важно…» и почти никогда не объясняли, зачем учить, когда это пригодится и для чего.

Поэтому, когда мне поставили задачу написать про полуфинал Международной студенческой олимпиады по программированию (ICPC) для региона «Северная Евразия», я решил не пересказывать данные из Википедии. Вы и сами можете их прочитать, а кто-то даже рассказать о собственном опыте участия. Я спросил коллег внутри X5 Tech, как навыки, полученные на соревнованиях по программированию помогли им в реальной жизни: на собеседованиях, в продакшене, в решении сложных системных задач или даже в бытовых ситуациях. Про то, что спортивное программирование развивает алгоритмическое мышление, стрессоустойчивость и умение работать в команде в ограниченное время, пишут много, но теория не всегда переносится на практику.

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

В A/B-тестах хотелось бы смотреть на главную метрику, ту самую North Star, которая показывает успех продукта. Но на практике она почти всегда медленная, шумная и бесполезная для быстрых решений. Например, вы запускаете тест новой системы рекомендаций, ждёте неделю, две, а LifeTime Value не двигается. И непонятно, это потому что нет результата или ещё рано делать выводы.

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

Привет, Хабр! Меня зовут Артем Ерохин, и я Data Scientist в X5 Tech. Я прочитал современные исследования, пропустил их через свой опыт и собрал концентрат подходов к работе с прокси-метриками. Постараюсь передать только суть. Разберемся, зачем нужны прокси, как с ними не выстрелить себе в ногу, где заканчивается польза и начинается самообман.