Все потоки

Считаем окупаемость WMS через бизнес-процессы: новый выпуск подкаста «Сначала процессы»

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

Это шестой выпуск подкаста INTEKEY «Сначала процессы» и второй в тематической серии про окупаемость WMS. Предыдущий выпуск серии считал окупаемость через персонал: зарплаты, текучку, стоимость найма. Этот рассматривает только механику складской рутины, без учёта людей.

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

Брак комплектации 1,5–2% на первый взгляд означает высокую точность. Полная стоимость одной ошибки складывается из нескольких шагов: повторная поездка, приёмка возврата, пересборка заказа, время менеджера на разговор с клиентом, корректировочные документы в бухгалтерии. Для российского B2B это около 4 000 ₽ за случай. При 500 отгрузках в день и 2% брака — больше 200 ошибок в месяц, около 800 000 ₽.

Товар физически лежит на складе, но недоступен для продажи, пока не отражён в системе. Приёмка на 150–250 строк силами трёх человек занимает около 4 часов: разгрузка, подсчёт, разбор накладных, звонки поставщику при расхождениях. Всё это время товар не виден отделу продаж. WMS с ASN (предварительным уведомлением об отгрузке) делает товар доступным к продаже в момент сканирования на воротах и сокращает процесс до 1,5 часов — около 460 000 ₽ в месяц освобождённого ресурса.

Инвентаризация с остановкой склада повторяется четыре раза в год. Прямые расходы на одну такую операцию — около 250 000 ₽ (переработки, доплаты, простои), то есть миллион в год. Цикличный фоновый пересчёт через ТСД убирает необходимость останавливать склад: расхождения фиксируются по мере появления, а не раз в квартал.

Точность остатков около 91% на ручном складе создаёт разрыв между системой и реальностью: закупщик видит в ERP отсутствие товара и заказывает новую партию, хотя старая лежит в другом углу склада. При запасе 90 млн ₽ разрыв 8,5% замораживает около 7,5 млн ₽. При стоимости капитала для бизнеса около 25% годовых это около 160 000 ₽ в месяц дополнительных расходов.

🎧 Выбирайте удобную для вас платформу для прослушивания: https://intekey.mave.digital/

📖 Статья, на которой основан выпуск: https://intekey.ru/articles/skolko-stoit-wms-biznes-processy/

Первая версия генератора кода готова. Сделал я его через IIncrementalGenerator и она очень сильно не оптимизирована, но да ладно он мне все ровно нужен был только ради следующей статьи про диагностику dsl

Русскоговорящий хакер использовал Gemini для контроля ботнета из восьми компьютеров стоматологических клиник

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

В понедельник, 20 июля, на известном новостном агрегаторе thehackernews.com вышла одноименная статья, основанная на исследовании японо-американской компании в сфере кибербезопасности Trend Micro. Как утверждают авторы статьи, исследователи обнаружили русскоязычного злоумышленника под псевдонимом bandcampro, который использовал Google Gemini CLI как полноценного помощника при проведении реальных атак. Анализ основан на более чем 200 логах сессий Gemini CLI за период с 19 марта по 21 апреля 2026 года.

Специалисты называют это одним из первых документированных случаев, когда LLM понимает существующую инфраструктуру атаки, самостоятельно пишет код, исправляет собственные ошибки и помогает администрировать действующий ботнет. По оценке Trend Micro, во время миграции инфраструктуры сам злоумышленник выполнил лишь около 11% действий, остальное сделал ИИ: во время подготовки инфраструктуры возникли ошибки (502 Bad Gateway, блокировка Cloudflare, проблемы с HTTP-заголовками), однако Gemini сам диагностировал проблемы, предлагал добавить нужные заголовки, определял необходимость User-Agent и корректировал запросы. По мнению исследователей, ИИ использовался уже не как генератор кода, а как инженер по эксплуатации инфраструктуры.

Ну и как вишенка на торте, все инструкции (ради чего и была, наверно, написана статья) были на русском языке.

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

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

п.с. Вопрос: насколько быстро удалось бы обнаружить активность bandcampro, если бы среди исследователей не оказалось специалистов, свободно читающих русскоязычные логи? ;)

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

С момента написания прошлой статьи про мою самописную товароучетную систему для работы с маркировкой «Честный Знак», я добавил новых фич и поправил существующие ошибки. Основные изменения следующие:

1. В Остатках в карточке товара появилась кнопка «Списать», позволяя сделать быстрое списание с нулевой ценой и выбором причины: утеря, собственные нужды, производственные цели, безвозмездная передача, отзыв с рынка. Данные нужно подавать также вручную, но для учета полезно.

2. Добавлен вид документа в продаже: поле «Вид док-та» в шапке заказа (Прочее, УПД, Товарная накладная, Акт приёма-передачи, Кассовый чек).

3. Появилась кнопка «Скачать КМ в CSV» в корзине Продаж для скачивания КМ в формате «для ввода/вывода из оборота» для вставке в ЭДО при передаче УПД.

4. Дропдаун «Статус» теперь показывает статус ЧЗ для проданных товаров.

5. Появилась возможность выделить и произвести массовую проверку статуса ЧЗ для выделенных товаров (чекбоксы + кнопка) на вкладках Остатки, Продано, Вывод из оборота.

6. Появилась колонка «Статус в ЧЗ» в таблицах Остатки и Вывод из оборота

7. Сделано автоподтверждение отчёта о выбытии при статусе ЧЗ равном «Выбыл» (RETIRED/WITHDRAWN/WRITTEN_OFF)

8. Сделано сохранение активной вкладки при перезагрузке страницы

9. Введена новая логика быстрой продажи: в шапку заказа: номер заказа, склад списания, дата продажи, добавление нескольких товаров по КМ/артикулу/EAN-13 с ценой за позицию в корзину с одинаковым номером заказа, КМ для Маркетплейсов отображается в корзине и копируется кликом, сделан Live-поиск при вводе кода с полной информацией о товаре.

ПО я писал для своей товарной группы «Игры и игрушки», но оно должно подходить и для других товарных групп потребительских товаров.

Сразу напишу про API: авторизация по ЭЦП и получение общего статуса по КМ все еще ведется по 3 версии API Честного Знака, как и например работа с МОД, а что-то уже работает только по 4 версии API (например ввод-вывод из оборота).

Kubernetes к 2035 году: стандарт, невидимая инфраструктура или история?

Kubernetes уже выиграл войну оркестраторов. Но что происходит с технологией, когда она становится стандартом — она взрослеет или превращается в легаси, о котором все знают, но никто не хочет разбираться?

В новом выпуске «В SREду на кухне» вместе с Александром Невским, руководителем юнита k8s в Infrastructure Platform Авито, поговорили о том, куда Kubernetes движется дальше — и что это значит для инженеров, которые с ним работают сегодня.

Что на повестке

Становится ли Kubernetes проще или сложнее с каждым годом — и почему ответ неочевиден. Почему компании приходят к десяткам кластеров и как Fleet Management превращается в отдельную инженерную дисциплину. Заменит ли платформенная инженерия Kubernetes или просто спрячет его поглубже. Как LLM уже меняют работу DevOps и SRE — и кто вообще будет управлять инфраструктурой через десять лет.

Отдельно — прогноз на 2035 год. Без гарантий, но с аргументами.

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

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

День открытых дверей онлайн-магистратуры МФТИ «Разработка ИТ-продукта»

Приглашаем на открытый эфир, который будет полезен тем, кто планирует поступать на программу «Разработка ИТ-продукта» в 2026 году и хочет заранее разобраться, как устроены обучение, практика и процесс поступления.

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

На эфире обсудим:

— Как устроена программа «Разработка ИТ-продукта» и кому она подойдет.

— Какие навыки получают студенты и как проходит работа над практическими задачами.

— Как обучение помогает расти в разработке, переходить к проектированию архитектуры и запускать собственные ИТ-продукты.

— Как устроен процесс поступления в 2026 году: какие документы потребуются и как подготовиться к вступительным испытаниям.

К встрече присоединится выпускник программы, который поделится опытом обучения и расскажет, как полученные знания помогли ему в работе.

👥 Специальный гость: Антон Устинов — академический руководитель программы, директор по технологиям и информационным технологиям (CTO/CIO) с более чем 15-летним опытом в разработке и проектировании архитектуры финтех- и EdTech-продуктов (Сбер, Exante, Click и SmartBank), кандидат экономических наук и сертифицированный архитектор Сбера.

📅 Дата: 29 июля (среда)

⏰ Время: 18:00 (Мск)

🔗 Регистрация:

ВКонтакте: https://vk.com/app6379730_-224205661#l=30&auto=1

Telegram: https://t.me/mipt_events_bot?start=dl-1784623748d866ee49855e

Монитор CAN из Отладочной Платы JZ-F407VET6 и TFT экрана.

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

Экран подлючается по SPI, а на плате единственный порт выведенный на разъём SPI2. Также на разъёме платы P3 присуствует питание 3.3В, а кроме SCK и MOSI выведено еще 4 сигнала, задействуем их для CS, DC, RST экрана и на оставшийся сенсорную кнопку для отправки управляющей команды.

Проверяемое ЭБУ передаёт значения напряжения и тока АКБ, следовательно расшифровав их, можно вывести на экран значения в виде стрелочных приборов. Остальные параметры выводятся в окне статуса. В нижней части экрана выводятся принятые пакеты в шестнадцатиричном виде и общий счетчик пакетов.

В качестве основы проекта использовался pcan_pro_x, упомянутый в одной из публикаций Александра посвящённых этой плате, код инициализации и отрисовки экрана любезно предоставил Google Gemini.

Ссылки на матерьялы:

Обзор учебно-тренировочной платы JZ-F407VET6 (или электронная парта)

Переходник с USB на CAN из Отладочной Платы JZ-F407VET6

T-shaped снова в моде?

Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных.

В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов.

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

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

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

Через 5 лет мы будем оглядываться назад и говорить о том, как все было очевидно, вот это работает, а вот это бы не заработало никогда. Как говорится, знал бы прикуп жил бы в Омске

Как связать контейнеры Nginx и PHP в Docker Compose, чтобы Nginx мог проксировать запросы?

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

Чаще всего подобная проблема возникает из-за того, что контейнеры изолированы друг от друга на сетевом уровне, либо в конфигурационном файле веб-сервера некорректно указан адрес целевого хоста. В экосистеме Docker Compose встроенный DNS-сервер автоматически сопоставляет имена сервисов с их внутренними IP-адресами. Поэтому не нужно прописывать статические IP — достаточно правильно использовать имена, заданные в манифесте. 

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

Чтобы Nginx мог передавать запросы PHP-FPM, необходимо:

• убедиться, что оба контейнера находятся в одной сети (app_network),

• указать в конфигурации Nginx правильный адрес PHP-контейнера (в нашем примере это php:9000, где php — имя сервиса в docker-compose.yml).

Шаг 1: Проверка манифеста docker-compose.yml

Убедитесь, что для обоих сервисов явно выделена одна общая сеть. Пример корректной структуры:

version: '3.8'
services:
  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/html:/var/www/html
    depends_on:
      - php
    networks:
      - app_network

  php:
    image: php:8.2-fpm
    container_name: php
    volumes:
      - ./php:/var/www/html
    networks:
      - app_network

networks:
  app_network:
    driver: bridge

Шаг 2: Настройка конфигурации Nginx

В блоке location, отвечающем за обработку PHP-скриптов, в директиве fastcgi_pass вместо 127.0.0.1 или localhost необходимо подставить имя сервиса PHP из файла конфигурации:

server {
    listen 80;
    server_name localhost;

    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass php:9000;  # Связь с PHP-контейнером
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Директива depends_on в блоке Nginx гарантирует, что веб-сервер не начнет стартовать раньше, чем поднимется контейнер с PHP. Это предотвратит падение Nginx при первичном запуске окружения, если он не сможет сразу разрешить DNS-имя php.

Если вы хотите глубже разобраться в сетевых механизмах, управлении volumes и оркестрации контейнеров, читайте наш полный материал: Docker Compose и основы работы с контейнерами.

Поступить в магистратуру, чтобы запустить стартап: как это работает

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

28 июля проведем эфир «Запуск корпоративного стартапа во время обучения: как совместить работу и учебу с максимальной пользой».

На открытой встрече выпускники онлайн-магистратур Центра «Пуск» МФТИ и представители компаний расскажут, как развивали корпоративные стартапы во время обучения.

За три года наши студенты разработали и защитили более 50 проектов для Hoff, Сбера, билайна, НИИАС РЖД, НЛМК, Совкомбанка, МКБ, Zecurion, GreenData и других компаний.

В программе:

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

🔹 Какие задачи стояли перед командами и какие решения они предложили.

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

🔹 Как работа над корпоративным стартапом повлияла на карьеру и профессиональное развитие выпускников.

🔹 Как прийти в магистратуру с проектом своей компании или взять задачу от индустриального партнера и развивать во время обучения в магистратуре Центра «Пуск» МФТИ.

📅 28 июля (вторник)

🕖 19:00 (Мск)

💻 Онлайн

Участие бесплатное. Необходима регистрация.

ВКонтакте: https://vk.com/app6379730_-224205661#l=31&auto=1

Telegram: https://t.me/mipt_events_bot?start=dl-17846368420ebf8e1ae9f2

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

На этой неделе заказчикам нужны специалисты для следующих задач:

• Автоматическое определение договора при загрузке банковской выписки в 1С:Бухгалтерии 3.0.

• Настройка отображения остатков Центральной базы при подборе товара в УТ 11.5 РИБ.

• Перенос остатков по заказам из УТ 10 в УТ 11.5.

• Поиск и исправление ошибки закрытия месяца в 1С:Бухгалтерии ПРОФ.

• Разработка внешнего отчета для УПП 1.3.

• Интеграция существующей CRM с 1С:Управлением торговлей 11.

• Заказ по статье «Сверка документов между базами».

• Настройка пересчета закупочной цены из валюты в рубли без потери сумм из-за округления.

• Диагностика и устранение ошибок в 1С-Рарус: Учет ЦБ 3, связанных с купонами, РЕПО и загрузкой брокерских отчетов.

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

Для заказчиков доступны исполнители разного формата - от частных специалистов до проектных ИТ-команд. Можно напрямую обмениваться контактами, работать без комиссии площадки и при необходимости использовать безопасную сделку.

Как мы закрываем задачу: тесты, диптрак, аудит и ещё пара рубежей

Продолжение серии про работу с ИИ-агентом. В прошлый раз разбирали, где живёт задача. Теперь — что с ней происходит, прежде чем она станет done.

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

1. Автоформат — молча и сразу. После каждого Edit/Write срабатывает хук: Pint для PHP, Prettier для JS/TS правят изменённый файл. Не блокирует, ничего не спрашивает. Форматирование просто снято с повестки — про пробелы и переносы мы не спорим никогда.

2. Приёмка «прогнал — работает» (скилл verify-task). Финал задачи — не «по идее работает», а таблица. Перечитываем Definition of Done, по каждому пункту: как проверено → PASS/FAIL. Внутри:

• прогон тестов затронутой области (Pest/PHPUnit) — зелёные, а не «вроде есть»;

• smoke живого сценария через tinker или artisan-команду;

• корнер-кейсы: пусто, граница, null, таймаут внешнего сервиса;

• в diff нет ключей и .env.

Любой FAIL — задача не закрыта. Без «ну это мелочь, потом починим».

3. Deptrac — границы слоёв (Stop-хук). На попытке закрыть ход прогоняется анализатор архитектуры. Уехала логика из сервиса в контроллер, модель полезла напрямую во внешний API — exit 2, ход не закрывается, пока не переложишь код в правильный слой. Тот же гейт стоит в CI, а легаси-долг зафиксирован baseline’ом, чтобы старые грехи не блокировали новую работу. Правило в конфиге кажется неверным? Правь конфиг явно и объясняй — обходить молча нельзя.

4. Секреты не текут (guard-secrets). Отдельный хук стережёт, чтобы содержимое .env, ключей и дампов не улетело в чат: cat/grep по секретному файлу блокируются, Read на него — тоже. Править такие файлы можно (Edit/scp), а вываливать в переписку — нет.

5. Рефлексия — иначе не закрыть (guard-discipline). Код менялся, а записи в task/history за сегодня нет? Снова exit 2. Хук требует короткий разбор: что ставили, как решал, решено да/нет/частично, что можно было лучше. Следующая сессия начнёт с этих заметок и не наступит на те же грабли.

6. Независимый аудит — по коду, а не по рассказу. После нетривиальной доработки запускается отдельный агент, который не видел, как ты решал. Ему дают diff и чек-лист: все ли call-сайты покрыты, нет ли регрессий, есть ли тесты, скрытые баги, не уехали ли слои, не утекли ли секреты. Вердикт — APPROVE или CHANGES NEEDED со списком «файл:строка — почему». Нашёл проблему — не чинит молча, возвращает автору. Без аудита мёрдж не предлагаем.

7. И только теперь — в done и на мёрдж. Задача переезжает в task/done до открытия MR, в той же ветке. Прямой push в main закрыт хуком — только через merge request. А прод-pull делает человек: guard-prod fail-closed не пускает агента мутировать боевой сервер, агент лишь готовит команды.

Тут важно, кто есть кто. Автоформат, Deptrac, защита секретов, рефлексия, запрет пуша в main и защита прода — это хуки. Они срабатывают автоматически на события (после правки файла, при попытке закрыть ход, перед bash-командой) и возвращают exit 2, если что-то не так. Их нельзя «забыть» или уговорить — они не читают промпт, они перехватывают действие. А приёмка и аудит — это скиллы, процедуры, которые агент запускает сам: тут уже нужна голова, а не только стенка. Стенки ловят механику, скиллы — смысл.

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

«Готово» — не когда агент дописал код, а когда код прошёл все рубежи.

Почему «я знаю слова, но не могу говорить» — это не всегда проблема словарного запаса

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

Из этого следуют несколько простых правил для практики:

1. Проверять нужно не только узнавание, но и свободное извлечение: показать ситуацию и попросить сказать фразу без списка вариантов.

2. Голосовые попытки должны быть короткими. Пять минут каждый день дают более честный сигнал, чем редкая длинная сессия.

3. Ошибку полезно разбирать после попытки. Если останавливать человека до того, как он договорил, тренируется избегание, а не речь.

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

Я собираю KeelAI вокруг этой идеи: чтение, повторение слов и переход к спокойным голосовым ответам в Telegram. Сейчас особенно интересны менее популярные языки, где проблема не в отсутствии учебников, а в нехватке регулярной практики.

Текущая версия проекта доступна здесь: KeelAI.

Буду рад техническим замечаниям: какие метрики вы бы использовали, чтобы отличить «узнает в упражнении» от «может произнести в новом контексте»?

Математик Дмитрий Рыбин вместе с GPT-5.6 опроверг известную гипотезу, которую открыли ещё 30 лет назад — он попросил ИИ «совершить прорыв».

Серьёзно, никаких хитрых промптов для научного исследования не понадобилось: математик просто просил ChatGPT продолжить опровержение. После этого ИИ 80 минут выстраивал цепочку аргументов. Автор поделился чатом с моделькой и называет ситуацию «чистым мемом».

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

Вайб‑кодинг довёл: «сайт за ночь», сотый планировщик бюджета и клон Google Диска

Наблюдение за последние месяцы: слово «SaaS» на глазах становится ругательным. Треды забиты историями «создал продукт на миллион за сутки», и почти всегда это реклама аккаунта автора, а не продукт. Планировщиков бюджета, написанных с Клодом, я лично насчитал уже больше сотни. Но недавно встретился экземпляр покрепче: человек с помощью ИИ собрал аналог Google Диска. Всерьёз. Хранение чужих файлов — это юридика (персональные данные, DMCA, 152-ФЗ), это бэкапы, это аптайм, это поддержка на годы. Ничего из этого в промпте не было.

Параллельно из каждого утюга: ИИ заменит дизайнеров, копирайтеров, вообще всех.

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

Конкретика из моей ниши — SEO. Прежде чем подпускать ИИ к семантике, я несколько лет собирал её руками. Поэтому вижу, где модель реально ускоряет, а где уверенно гонит брак:

— ускоряет: рутина по кластеризации, черновики метатегов, шаблоны программатик‑страниц, техничка;

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

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

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

Интересно, у кого как: встречали «продукт за ночь», который прожил хотя бы год?

Must-read для Python-разработчика: 5 статей от практика с сотнями интервью за плечами 

Делимся подборкой статей от Евгения Бартенева, эксперта курсов Практикума и разработчика с 20-летним опытом. А ещё он активно занимается созданием образовательного контента: является автором и техлидом курса «Python-разработчик», пишет статьи и проводит бесплатные мок-интервью для всех желающих в рамках проекта Boreesych.

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

Особенности Python, о которых вас точно спросят на техническом собеседовании. Часть 2. Евгений выпустил продолжение, так как первая часть вызвала оживлённое обсуждение: в комментариях читатели делились собственным опытом и задавали отличные уточняющие вопросы. В этой части ещё больше подводных камней Python — уже традиционно без абстракций и банальщины.

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

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

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

Если хотите освоить профессию Python-разработчика с нуля, сделать это можно на курсе «Python-разработчик» в Практикуме. Первые 30 уроков доступны бесплатно: вы попробуете себя в роли разработчика, познакомитесь с образовательной платформой и поймёте, подходит ли вам курс.

Госдолг США в 2026 году достигнет $40,7 трлн. Это станет самым большим объёмом госдолга в мире. При этом самый высокий долг по отношению к размеру своей экономики зафиксирован в Японии: он составляет 204% ВВП. Несколько европейских стран также входят в число наиболее закредитованных по отношению к ВВП, хотя их общий объём государственного долга значительно уступает показателям США или Китая.

Прогнал официальный conformance suite OpenID Foundation против redb.Identity.

Basic OP: 35 модулей, 0 failures. Config OP: 0 failures.

Что нашли и исправили:

• PII утечка: scope-derived claims (phone, email) попадали в id_token — они должны быть только в UserInfo

• UserInfo возвращал внутренности OpenIddict через deny-list

• Отсутствовал Cache-Control: no-store на token endpoint (RFC 6749 §5.1)

• prompt=login / max_age ре-аутентификация была сломана

Одно WARNING осталось намеренно — два приватных claim в id_token с обоснованием.

Полный отчёт

Импортозамещение: «лишь бы российское» уже недостаточно

Наконец посчитали, что российский ИТ-рынок в 2025 году вырос на 13% и превысил 4 трлн рублей. Быстрее всего росли сегменты программного обеспечения и ИТ-услуг, а одним из главных драйверов оставалось импортозамещение.

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

Лицензия – только входной билет

Если ещё несколько лет назад основной вопрос звучал так: «Чем срочно заменить зарубежный продукт?», то сегодня заказчики оценивают уже не сам факт замены, а готовность решения к промышленной эксплуатации:

• Как решение встроится в существующую инфраструктуру?

• Кто отвечает за сопровождение при сбоях и обновлениях?

• Как система восстанавливается после ошибочного изменения?

• Можно ли масштабировать внедрение без роста операционных рисков?

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

Каталог как проверка зрелости внедрения

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

• создание резервных копий и восстановление отдельных объектов и атрибутов;

• сохранность прав доступа и членства в группах, корректность репликации;

• мониторинг массовых и ошибочных изменений;

• понятный порядок действий администратора после инцидента.

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

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

Зрелое импортозамещение начинается не с выбора продукта, а с продуманного внедрения: проверки совместимости, распределения зон ответственности, отработанных сценариев восстановления и понимания цены ошибки.

Пройди воркшоп по наблюдаемости ИИ-агентов с Langfuse

Привет! Меня зовут Филипп Бочаров, я CPO в МТС Web Services и член ПК HighLoad++. Мы с командой придумали воркшоп «Смотри, как думает агент: Observability AI-агентов с Langfuse». Его прошли уже более 60 человек на конференциях AIConf 2026 и Saint HighLoad++ 2026, а теперь он стал доступным публично всем желающим!

На примере демонстрационного ИИ-агента на Python вы узнаете:

• сколько могут стоить ошибки агента в рублях;

• как сломать продуктивный агент, не меняя ни строчки кода;

• что может пойти не так с MCP.

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

Что будет на воркшопе

Мы будем работать с демонстрационным ИИ-агентом Cookbook Agent. Он умеет создавать рецепты блюд и рассчитывать стоимость ингредиентов.

На каждом шаге воркшопа сымитируем различные нештатные ситуации, которые вам нужно будет найти и исправить с помощью open-source-инструмента Langfuse.

Демонстрационный ИИ-агент состоит из пяти частей:

• Cookbook-agent — агент на Python. Это основной проект, который мы будем изучать и изменять.

• MCP-server — MCP-сервер, к которому агент обращается за поиском рецептов и их стоимостью. Развернут локально, но вы считаете, что он находится где-то в облаке. MCP-сервер для вас — черный ящик.

• Qdrant — векторная база данных с рецептами.

• RAG-loader — утилита для загрузки рецептов в Qdrant при первом запуске.

• Redis — хранилище памяти для сессии агента. Изначально наш агент память не использует, но она будет добавлена на последнем шаге.

Зачем это нужно…

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

На этом воркшопе мы покажем, как можно диагностировать такие типовые проблемы. Цель — освоить инструмент для диагностики типовых проблем AI-агента.

Что такое Langfuse

Это open-source-платформа для разработки и наблюдения приложений на базе LLM. Ее ключевые функции:

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

• Возможность хранить промпты централизованно с контролем версий.

• Метрики качества: проверка ответа агента на корректность, безопасность и так далее.

Требования к участникам

• ноутбук с доступом в интернет;

• git, Docker v24.x+ и Docker Compose v2.22.x+;

• любой редактор кода, желательно с поддержкой Python;

• 500 рублей для оплаты LLM в сервисе MWS GPT Model Hub; 

• два часа свободного времени.

Как пройти воркшоп

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

• Сценарий — задание, в рамках которого имитируется проблема нужно сделать. 

• Решение — это ответ на задание с подробным разбором причин и способа исправления.

Старайтесь разобраться в задании самостоятельно, не забегайте вперед и не подсматривайте в решение.