Ilyas Salikhov

Это база Убежден, что каждый разработчик, считающий себя экспертом, должен понимать устройство СУБД (системы управления базами данных) не хуже, чем языков, на которых он пишет. Ошибки по части данных обходятся очень дорого, иногда просто необратимы. Не продумали индексы: запросы в проде стали грузить сервер в полку. Ошиблись в миграции: затерли часть данных при переносе в новые таблицы. Банально полезли в прод и выполнили запрос с ошибкой. И даже в эпоху AI, SQL-запросы и миграции — последнее, что будет ехать в прод без ревью человеком. Понятно, что AI очень хорошо понимает и SQL, и индексы, но ответственность за применение к проду остается на людях. По крайней мере, пока 👉 Что рекомендую по теме: 1. Тонкости работы с PostgreSQL Мой плотненький доклад на Podlodka PHP Crew (200+ слайдов за 1 час). Это мой же обновленный доклад с PHPRussia / Highload++. Видео | Презентация 2. PostgreSQL 18 изнутри Фундаментальная книга Егора Рогова. Если решили разобраться как следует и навсегда. Недавно вышло ее обновление под PG18. Страница книги | PDF 3. SQL Performance Explained Эталон баланса содержательности и объема. Можно прочитать за 2-3 вечера, при это всё ключевое дано. Крайне рекомендую. Сайт книги (платная) 🔗 Инженерия и AI | Ilyas Salikhov

Погода лучше не придумаешь, не забываем про тело, разгружаем мозг. Недавно в Forbes прочитал про MB Barbell, тренажеры которых встречаю в Москве. Оказалась компанией из Петрозаводска, основана аж в 1986 года. Основатель, Вадим Маркелов, запатентовал уличный тренажер с изменяемой нагрузкой, сейчас выпускают 12к уличных тренажеров в год. Ребята еще крутыши, вложились в городскую среду родного города. По своей инициативе поставили 130 тренажеров на набережной Петрозаводска. А в 2025 году открыли ещё одну крупную бесплатную площадку на Крестовском острове в Петербурге на 300 тренажёров. Приятно узнавать про такие компании, которые меняют ежедневный быт и среду к лучшему. Особенно приятно, когда это региональная компания. 🔗 Инженерия и AI | Ilyas Salikhov

Как отдельный трек, мы развиваем сквозного агента компании Orpheus, который помогает нам во всё большем количестве бизнес-процессов компании, не только в разработке. И получаются интересные прецеденты, когда Orpheus делает задачи по улучшению самого себя 👾 🔗 Инженерия и AI | Ilyas Salikhov

Как уже говорил ранее, с февраля разработчики в RetailCRM массово переходят на агентскую разработку. Прошло 5 месяцев этого пути, хотел бы подбить промежуточные выводы. Ключевые цифры 1. Число смерженных Merge Request-ов +26%. Доля MR, разработанных с агентами 50-55% 2. Объем изменений, заезжающих с MR +250%. Доля строк с агентами 75-80% 3. Медиана Time to market задач держится плюс-минус на том же уровне 4. Средний Time to market задач снизился на 39%, снижается все 5 месяцев Что всё это значит 1. Кодинг – это только один из этапов реализации задачи. Объем выпускаемого кода увеличился в 2,5 раза, но число MR только на треть. Мы ускорили кодинг, но узкими местами становятся другие этапы. Стабильность медианы t2m дополнительно подтверждает, что ускорение кодинга почти не ускоряет весь пайплайн производства, по крайней мере сейчас. С другой стороны и не замедляет, что тоже важно 2. Среднее значение t2m, в отличие от медианы, более чувствительно к крайним значениям, то есть к длительности долгих задач. Снижение среднего говорит о том, что агентская разработка больше ускоряет крупные задачи и фичи. Рост объема изменений как дополнительное подтверждение этой гипотезы 3. Как видно, с агентами делается чуть больше половины MR. Остальная часть без агентов по несколькими причинам: 3.1. Мелкие правки бывает быстрее внести напрямую, чем объяснять агенту 3.2. Мы пока осторожно переводим на агентов молодых ребят. Кажется, когда мало опыта, то агенту больше доверяешь и хуже верифицируешь результат, а опыт получаешь более поверхностный. Соответственно от них больше MR без агентов В общем, с агентами код пишешь быстрее, но в конечном итоге всё упирается в людей ⌛️ И переход к Tiny Teams напрашивается сам собой: небольшие, но более автономные команды. Часть наших уже такими и является. В ближайшее время подключим агентов в процессы ревью. И по части harness пока далеко не все готово, особенно на крупных проектах с историей, продолжаем улучшать. Делитесь, как у вас обстоят дела? 🔗 Инженерия и AI | Ilyas Salikhov

Завтра выступаю на Ecom Expo 26, крупнейшей выставке для интернет-торговли. Расскажу про опыт внедрения AI на операционном уровне в RetailCRM и лестницу автономии AI-агентов. Если будете на выставке, буду рад пообщаться, у нас большой стенд там. Записей доклада, насколько знаю не делают, но буду еще с этой темой на других конференциях, следите за каналом 🙂 🔗 Инженерия и AI | Ilyas Salikhov

Можно ли заменить gpt-5.4-mini открытой моделью. Бенч-тест на агенте Exoskeleton После истории с Fable снова все начали думать об альтернативах, которые не обрубят «с той стороны». С подачи Рината я тут упоролся и провел большое исследование: взял Exoskeleton-агента и прогнал его на 10 открытых семействах моделей без какого-либо изменения кода. В посте самое ключевое, а в конце найдёте ссылки на полную версию. Методика • 10 моделей: GPT (эталон), Kimi, GLM, MiniMax, Nemotron, Mistral, Qwen, Gemma, DeepSeek, Llama • 3 прогона на каждую, 100 задач в прогоне • Замеряем качество (score), платформенное время и реальную стоимость прогона (не цена токена, а во сколько обошелся прогон) Кого брать (score / цена прогона): • Качество — Kimi K2.7: 0.898 / $2.78 • Качество на доллар — MiniMax M3: 0.837 / $1.19 (почти как gpt!) • Скорость — Mistral Large 3: 58 мин / 0.767 / $1.85 • Средний эшелон — Nemotron, Qwen (0.72–0.76) • Пока не готовы — Gemma, DeepSeek, Llama (0.55–0.70) —— • Эталон gpt-5.4-mini/nano: 0.93 / $1.18 MiniMax для меня стал открытием, многообещающая моделька, надо будет изучить подробнее её. Kimi в целом тоже не подкачал. А у DeepSeek, думал, результаты будут лучше. Ключевой вывод Открытые модели не смогли перебить качество gpt, но достойные альтернативы есть. Экзоскелет затачивали под слабые места gpt-5.4-mini. У каждой открытой модели свой профиль слабостей, и обвязка их пока не покрывает. Поэтому замена модели должна идти в паре с доработкой экзоскелета. Хорошая новость в том, что обвязку можно доработать и вытянуть качество агента на уровень gpt. За высокий score у большинства моделей приходится платить временем Открытые модели с высоким score проходят прогон в 2–3 раза дольше эталона. А те модели, что быстрее, заметно ниже в качестве. Низкая цена за токены ≠ дешёвый прогон Неочевидный инсайт в стоимости прогона. Всё решает наличие cache-тарифа. Агент перечитывает почти один и тот же контекст на каждом шаге, поэтому 90%+ входа кэшируется. Там, где есть дешёвый кэш (Kimi, MiniMax, Mistral), прогон выходит $1.2–2.8. Там где нет (GLM, Qwen, Nemotron) — каждый повторный токен по полной цене. GLM при самом высоком прайсе и без кэш-скидки сжигает ~$11 за прогон — в 9 раз дороже gpt при том же объёме токенов. А MiniMax за счёт кэша укладывается почти в цену нативного gpt. При расчете экономики вашего агента важно считать по формуле «цена за токен × объём × есть ли кэш-скидка». Отдельный риск в провайдерах Для открытой модели важно не только качество/цена/время, но и насколько стабильно она работает у провайдера. GLM 5.2 через OpenRouter не поднялась вообще, пришлось откатываться на 5.1. Qwen терял 10–14% задач в каждом прогоне на ошибках провайдера. Gemma завелась только с третьего хостинга, и то 24 задачи из 100 умерли на сериализации. Так что выбор провайдера не менее важен. Полное исследование: • [en] OPEN_MODELS_RESEARCH.md • [ru] OPEN_MODELS_RESEARCH_RU.md 🔗 Инженерия и AI | Ilyas Salikhov

Регулярно участвую в собеседованиях, и в последнее время все чаще попадаются кандидаты, которые проходят его с AI-суфлерами. Просто нет цензурных слов. Нет, я не против использования AI, и понятно, что в работе мы активно его используем. Но кандидаты совершенно отключают мозг и просто читают то, что им нагенерила LLM. Уже не счесть, сколько собеседований я просто останавливал, когда видел подобное. Не понимаю, чем думают кандидаты и на что рассчитывают. И что печально, это чаще встречается среди молодого поколения. Ребята сами себе роют яму, из которой потом не вылезут. Портят рынок и свою репутацию. Если они делают из себя прокладку между креслом и LLM, то их первыми и заменит LLM. Учите базу, нарабатывайте практику, совершайте ошибки, получайте опыт, учитесь думать, развивайте критическое мышление. И да, используйте AI, он сильно ускорит этот процесс. Но не заменяйте себя нейронкой. 🔗 Инженерия и AI | Ilyas Salikhov

У Валеры важный пост, из которого хочу выделить два ценных тезиса, дополнив от себя. 1️⃣ Агенты не заменяют опыт Клод, курсор и любой другой агент не застрахует вас от проблем, особенно в проде. Нужно пройти через ошибки, увидеть, что падает, понять, как мониторить и отлаживать, а потом страховаться от таких случаев. В том числе на уровне harness в агентской разработке. Это приходит только с опытом. НО. Агенты помогают быстро учиться. Вы не получите от агента опыт фейлов и ошибок, но можете быстро осваивать новые знания и навыки. В паре с агентом можно начать писать на новом языке и задавать любые глупые вопросы — это отличный способ учиться. 2️⃣ Агентская разработка и вайб кодинг снижают стоимость разработки прототипа на порядок. И это круто. Но прототип ≠ продакшн версия Правда. Появилась крутая возможность проверять гипотезы дешево, быстро собрать MVP идеи и даже развернуть. Но MVP — это не то же самое, что требуется для обслуживания сотен, тысяч пользователей и дальнейшего развития проекта. Нужно, чтобы при ежедневном добавлении новых фичей проект не превращался в гору мусора (legacy) и не потонул от кода, сгенерированного нейроагентом. Требуется дисциплина. НО. При этом отмечу важный момент: когда вы делаете прототип, эта дисциплина (особенно у разработчиков, которые любят всё делать сразу и правильно) может мешать полёту мыслей. Вы можете застрять в настройках стат‑анализа, окружения проекта, тестах, и забыть про идею, которую хотели реализовать. В этом плане вайб‑кодинг даже благо. В паре с агентом не удерживаете полёт фантазии и получаете итоговый результат, не важно, как он выглядит под капотом. Потом, если это кому‑то станет интересно и оно полетит, можно рефакторить и привести к правильному виду с настроенным CI, тестами и т.д. 🔗 Инженерия и AI | Ilyas Salikhov

E-commerce AI Agent Challenge / May 2026 30 мая участвовал в челендже по разработке AI-агентов для E-commerce. Участвовал первый раз. Тематика челенджей меняется, но в этот раз, подумал: уж в какой теме участвовать, если не в родной по екому. Агенты должны…

E-commerce AI Agent Challenge / May 2026 30 мая участвовал в челендже по разработке AI-агентов для E-commerce. Участвовал первый раз. Тематика челенджей меняется, но в этот раз, подумал: уж в какой теме участвовать, если не в родной по екому. Агенты должны уметь работать с поиском товаров, корзинами, чекаутом, сбоями оплаты, мошенничеством и многое другое. Задачи разные и динамические, от прогона к прогону вводные и контекст в них меняются. Сразу к результатам 🔸 1 место (на момент написания поста) в Live PROD leaderboard ECOM1 🔸 1 место в Agentic E-Commerce 1 Hall of Fame: Speed 🔸 10 место в Agentic E-Commerce 1 Hall of Fame: Ultimate 🔸 18 место в Agentic E-Commerce 1 Hall of Fame: Accuracy Агент под именем "@dev_salikhov ecom1 gpt-5.4-mini" Вводные и комментарии по результатам Первый момент. Я изначально решил строить агента на младших моделях, выбрал, как вы уже поняли, gpt-5.4-mini. В реальной работе такие возможно применять, особенно когда бизнес-домен задач достаточно узкий. Для понимания gpt-5.4-mini в 3 раза дешевле gpt-5.4 и в 6 раз gpt-5.5. Все же есть разница, счет за месяц на $10к или на $1,5k. Второй момент. В рамках Ultimate / Accuracy все агенты, что местами выше, сделаны либо на старших моделях, либо вокруг codex/claude CLI, где те же старшие модели. Так что не считаю 10 и 18 места плохим результатом. Третья деталь. Потенциал моего агента показало то, что после челенджа в течение часа он вышел на 1 место в Live борде, обогнав старшие модели. Четвертая деталь. Помимо обхода старших моделей в очках, мой агент обошел их и в скорости (общее время выполнения). Это видно как в Live борде, так и в номинации Speed. Собрал много граблей, первый раз было часто непонятно, что да как тут устроенно. Но было круто, я в целом доволен. Планирую позже подготовить статью про архитектуру агента и принципы его улучшения. Stay tuned. И, конечно, спасибо Ринату за движуху! 🔗 Инженерия и AI | Ilyas Salikhov

AI-first разработка. Главный барьер оказался не там, где ждали В этом году в отделе разработки RetailCRM системно перешли на работу в паре с AI-агентами. До этого агентов использовали отдельные энтузиасты, теперь это рабочая модель для всей команды. Начали с базы: массовое локальное использование агентов на задачах + harness под них. Уже понятно, что трансформация должна затронуть не только реализацию задач и не только отдел разработки, но об этом расскажу отдельно. Четыре инсайта, которые в большей или меньшей степени были неочевидными. 1. Главный барьер не в инструментах и не процессах, а головах людей Разработка в паре с агентом выглядит принципиально иначе. Я много раз повторял команде: нужно заставлять себя вести задачу через агента. Не получилось, разобраться, чего агенту не хватило, докрутить harness, попробовать снова. Шаг за шагом, постепенно агент всё чаще выдаёт результат oneshot или с парой доработок. Любопытное наблюдение: эта проблема присуща исключительно разработчикам. Люди без бэкграунда в разработке, пришедшие через vibe coding, изначально работают с агентами через подобный подход, у них просто нет другого варианта. А разработчику нужно совершить сдвиг парадигмы и выработать новую привычку работы. 2. Harness решает всё В проектах без нормального harness эффект от агентов в долгосрочной перспективе будет низким независимо от того, какую модель вы используете. Понятное для агента окружение, быстрое развёртывание, настроенные линтеры и статанализ, автотесты, правила в AGENTS.md являются залогом качественного результата. Хорошая новость: вложения в harness окупаются и без агентов. Разработчики тоже выигрывают от чистого окружения. Благо мы вкладывались в это задолго до AI, и это позволило нам быстрее перейти к AI-first. 3. Опыт работы с AI годичной давности нерелевантен Развитие настолько динамичное, что любой негативный опыт старше полугода нужно пересматривать. У нас в команде были ребята, кто пробовал агентов раньше, получил так себе результат и больше не возвращался. Сейчас это другая технология. Важно следить за новыми моделями и инструментами. Это уже рабочая необходимость. 4. Агенты не только про код Довольно быстро стало понятно, что агенты могут существенно больше, чем писать код. Мы дали им тулы и скиллы под Redmine и GitLab: агент сам оформляет MR, проверяет, что CI зелёный, ведёт задачу по workflow. Эта рутина раньше съедала ценное время разработчиков, теперь её делает агент. Это только начало расширения полномочий. Буду держать в курсе, как дальше продвигается процесс 💃 🔗 Инженерия и AI | Ilyas Salikhov

Спорт в ежедневной рутине Честно сказать, я не особо спортсмен. В детстве не занимался целенаправленно каким-то спортом. Ходить в спортивный зал я тоже не любитель. Важнее для меня, чтобы спорт присутствовал в ежедневной рутине. Чтобы спортивная активность вплеталась в день, а не была слотом в календаре. Отжаться между созвонами. Зайти на турники, пока гуляешь с ребенком в коляске. Поприсядать, когда захотелось. Это помогает не забывать про тело и сохранять форму. Спортом в такой ненавязчивой форме, лично мне, намного легче заниматься. Слот в календаре часто хочется скипнуть, на «пойти в зал» требуется усилие, порой, немалое. И стоит сказать спасибо городу, в последние годы спортивных площадок, турничков, брусьев становится все больше в каждом районе. Это помогает приобщать и детей. Буквально вчера Дима рассказывал, как с детьми начали ходить на турники. Я с детьми пока не так регулярно, но надо тоже формировать полезные привычки 🤨 В общем всем спорт! 🔗 Инженерия и AI | Ilyas Salikhov

⬛️ Redmine CLI для вашего AI-агента В наших компаниях Gitlab и Redmine — одни из ключевых систем. Чтобы использовать Codex/CC не только для разработки, а на всех этапах флоу задачи, нужно дать им «ручки» к этим системам. Самые эффективное, когда ручка в виде CLI-тулы. В случае гитлаба есть отличный glab cli. А для Redmine все какое-то ущербное. До настоящего времени в корпоративном скилле мы указывали работать с Redmine через REST API, но видно было, что это очень многословно и токено-жгуще для агента. Поэтому сделал Redmine CLI https://github.com/muxx/redmine-cli Построено поверх OpenAPI-спеки Redmine. Покрыты все возможности API. Логика работы интуитивна и понятна. Можно поставить через homebrew. И сразу предусмотрены профили, если у вас несколько Redmine-серверов. Примерчики: redmine auth use work redmine auth status redmine --profile client issue list --limit 20 redmine issue list --limit 20 redmine issue show 123 --include journals redmine issue create --project-id my-project --subject "Fix checkout" В репе вы также найдете: • полную доку по cli • готовый skill по работе с Redmine через redmine cli В общем, у кого Redmine, я считаю, must have ) 🔗 Инженерия и AI | Ilyas Salikhov

Запусти OpenClaw в 2 клика 🚀 Про OpenClaw, думаю, все уже слышали и знают. Позволяет поднять своего личного агента, который может выполнять широкий круг задач и запоминает по ходу работы важные детали. Крутой и полезный проект. Личный AI-помощник, которого…

А помните эту сказку? Емеля любил лежать на печи. Ему было неохота разбираться в систем дизайне, языках программирования и DevOps. И как-то Емеля поймал промокод на подписку для AI-агента. Агент вызывался голосовой командой «По щучьему велению...». А как бы вы её продолжили? 🔗 Инженерия и AI | Ilyas Salikhov

Запусти OpenClaw в 2 клика 🚀 Про OpenClaw, думаю, все уже слышали и знают. Позволяет поднять своего личного агента, который может выполнять широкий круг задач и запоминает по ходу работы важные детали. Крутой и полезный проект. Личный AI-помощник, которого даже моя жена захотела себе завести, хотя она далека от AI-ажиотажа и технологий. Но таким людям, как она, неподъемно разбираться в том, как его развернуть для себя. Заказать VPS, установить туда OpenClaw, настроить всё, чтобы работало. Не говоря про баги. Например, у меня сходу не заработали голосовушки при настроенном прокси и пришлось патчить (даже висит issue на эту тему). Поэтому мы запустили https://ohmyclaw.ru — сервис, где можно в 2 клика поднять такого агента. И не только одного личного, а сколько требуется под ваши личные и рабочие задачи. Прописываете настройки LLM, подцепляете telegram-бота, и готово! Посмотрите демки на сайте) Что у агента из коробки 1. Интеграция с Telegram, можно общаться в личке или добавить в группу. Позже добавим поддержку других мессенджеров, пишите пожелания) 2. Поддержка голосовых сообщений 3. Поддержка heartbeat и cron. Можно попросить "напомнить завтра утром купить хлеба" или, например, каждый понедельник собирать определенный отчет 4. Есть shell. На сервере сразу стоят python3 и node 5. Веб-поиск «из коробки» Агентов можно поднимать не только для личных задач, но и отдельных агентов под рабочие задачи. Для этого предусмотрели 3 вещи: 🤩 Во-первых, при создании агента можно указать репозиторий с начальными файлами-инструкциями. По умолчанию используется https://github.com/oh-myclaw/agent-template. Вы можете форкнуть и создавать инструкции для специальных агентов. Спецагенты, ага 🙃. Например, если нужен не персональный агент, можно удалить BOOTSTRAP.md и USER.md, а в AGENTS.md и TOOLS.md заложить инструкции поведения агента и доступные «ручки». 🤩 Во-вторых, сразу сделали agent management API, а в кабинете можно создать API-ключи. Создавайте и управляйте агентами через API. Вы можете сделать отраслевого агента и тиражировать его для своих клиентов. 🤩 В-третьих, у агентов предусмотрели настройку ENV-переменных (как в кабинете, так и в API). Можно задать енвы, сказать агенту про них в TOOLS.md или прямо в переписке. Это полезно для интеграции агента с вашими системами: GitHub, Gitlab, Google Workspace, внутренние системы. Проект только запустили, не судите строго. О багах и пожеланиях сообщайте) 🔗 Инженерия и AI | Ilyas Salikhov

Где проходит граница внедрения AI в разработку. Кейс Amazon 🔴 Business Insider пишет об экстренном собрании в Amazon после уже не первого инцидента 5 марта, связанного с AI. Amazon.com лежал порядка 6 часов и потерял 6 млн заказов. Перед этим, 2 марта, в чекауте отображалось неверное время доставки, потери 120 000 заказов. В декабре 2025-го был 13-часовой даунтайм AWS из-за ошибок кодинг-асистента Kiro AI. По моему каналу, я думаю, видно, что я активно топлю за внедрение AI в процессы разработки, но кейс Amazon является важным маркером. 1. Проблема не только в качестве кода, но и в скорости AI генерирует код в разы быстрее. Пайплайны ревью и деплоя проектировались под человеческую скорость. Когда объём и скорость изменений резко растут, процессы контроля не успевают. Либо жертвуешь контролем (и как следствие качеством), не глядя отправляя в продакшен. Либо жертвуешь скоростью, становясь бутылочным горлышком. Конечно, нужно заниматься harness engineering, выстраивать окружение, которое подсвечивает агентам ошибки, но это не дает полной защиты. 2. Не жертвовать чем-то одним, а разделять на уровни критичности Какие действия предпринимает Amazon: • Они не убрали AI-агентов, а разделили сервисы на уровни критичности • Выделили 335 сервисов уровня Tier-1, у которых высокий «радиус поражения» при выходе из строя • Для этих сервисов ввели регламент обязательного ревью и одобрения минимум 2х других разработчиков И это грамотные шаги. Пайплайн критичных сервисов осознанно «замедляем» человеческим ревью. Некритичные сервисы едут со скоростью AI-агентов. Да, может падать и лежать, но может и быстро починиться. Главное, чтобы агенты быстро получали обратную связь, что упало и чинили. Оптимально, я думаю, иметь три уровня критичности сервисов с соответствующим регламентом: 1. с полным ревью (агент-ревью + ревью всего кода людьми) 2. с быстрым ревью (агент-ревью + по диагонали код) 3. без ревью (только агент-ревью) 3. Сокращения + AI = иногда ложная экономия Amazon сократил 16 000 человек. AI-инструменты создали иллюзию, что можно компенсировать headcount автоматизацией. Но senior-ы на ревью — это не «накладные расходы», это safety net. Убираешь сетку — и акробат рано или поздно падает. Джеймс Гослинг (создатель Java, ранее distinguished engineer в AWS) прямо говорил, что компания демонтировала команды, которые не генерили выручку напрямую, но были критичны для стабильности. Я не думаю, что сам процесс сокращений и оптимизации был ошибкой. Это часто оздоравливает и ускоряет команды. Но, похоже, щепок полетело больше, чем надо было. — Что по итогу. AI в разработке уже присутствует, и это неизбежно. Но сейчас индустрия проходит фазу адаптации. Появляется понимание, что скорость без контроля — это не только преимущество, но и риск. Это может быть вполне допустимый риск. Главное, это понимать. 🔗 Инженерия и AI | Ilyas Salikhov