Директор департамента разработки AGIMA предлагает «карту автономии» — способ решить, что AI-агенту можно делать без человека. Ключевой тезис: автономия относится не к модели, а к конкретной паре «действие + объект», поэтому бессмысленно спрашивать «насколько умный агент» — важно, что именно ему разрешено, какова цена ошибки, кто увидит отклонение и можно ли отменить результат. Один и тот же агент может сам читать данные и готовить сводку, но никогда не отправлять письмо клиенту без человека — это не «недоделанная автономия», а нормальная архитектура.
Вводятся четыре режима: A0 — человек решает и делает сам (AI лишь справка); A1 — AI готовит, человек подтверждает (важно, чтобы подтверждение не превращалось в автоматический клик, а валидатор видел источники); A2 — AI выполняет ограниченное действие через явный контракт, код проверяет схему, права, бизнес-ограничения, результат фиксируется фактический, человек сверяет каждую операцию или партию; A3 — агент действует сам в заданной политике (лимиты, запрещённые классы, условия остановки, владелец инцидента, метрики, выборочный контроль). A3 подходит не для «самых умных» задач, а для хорошо ограниченных повторяемых действий с наблюдаемым состоянием.
Перед повышением уровня предлагается пройти четыре гейта: контекст и права (агент получает только нужные данные, права проверяет доверенный код, а не промпт); проверки качества на трёх уровнях (навык, траектория, бизнес-результат) плюс регрессионные сценарии; цена ошибки и обратимость (худший правдоподобный исход, обнаружимость, скорость заметности, отменяемость, максимальный масштаб); владелец, остановка и откат (владелец со стороны процесса, отдельно проверяются остановка новых действий и восстановление уже изменённых данных, два интервала — от сбоя до сигнала и от сигнала до остановки). Единственная метрика уверенности ничего не говорит о цене оставшихся процентов ошибок.
Далее — примерная матрица стартовых режимов: чтение данных A1–A3; подготовка предложения A1; создание записи A2 (защита от дублей, сверка результата); изменение значимого поля A2 (журнал, откат); отправка наружу A1 по умолчанию; удаление A0, A2 только для обратимого. Подчёркнуто, что это пример, а не готовая политика.
Карта должна храниться рядом с кодом или конфигурацией, версионироваться и сверяться с фактическими правами, иначе на бумаге агент ограничен, а в системе права уже выданы. Для A2/A3 нужен слой связанного контекста (сущности, связи, роли, актуальность, права) — не обязательно графовая модель.
Шесть анти-паттернов: прыжок из демо сразу в A3; одна оценка уверенности вместо бизнес-правил; человек, который ничего не успевает проверить; молчащий контур (алерт не доходит до ответственного — автор рассказывает реальный случай, когда проблему нашли по жалобе); рассуждение модели вместо журнала состояния; одинаковый уровень для всех действий. Приводятся и собственные инциденты: tool-call-фильтр блокировал по имени инструмента, включая запуск субагента и удаление временного файла; участок проверки не контролировал часть потока, а оповещение не сработало. Упоминается, что исключённый из проверки трафик нельзя записывать в успешно проверенный, иначе метрика покрытия врёт.
Финальный рецепт: взять один повторяемый процесс с владельцем и наблюдаемым результатом, нарисовать путь рабочей единицы, выписать действия с внешним эффектом, назначить текущий режим, описать минимальный следующий переход, зафиксировать запреты, лимиты, владельца остановки и отрепетированное восстановление, сохранить решение в версионируемой политике и собирать не только качество ответа, но и долю ручных исправлений, неизвестные исходы, время проверки, инциденты. Ссылки на Anthropic (workflows vs агенты) и NIST AI RMF. Вывод: автономия — не медаль за точность модели, а конкретное право воздействовать на процесс, которое выдают отдельному действию и можно отобрать.
Материал содержательный и практический: даёт работающую рамку, гейты, матрицу и реальные разборы инцидентов, без воды и без прямой продажи услуг. Слабости — поверхностное упоминание внешних стандартов, продвижение собственных материалов AGIMA в конце и отсутствие количественных данных по эффектам. Тема актуальная и злободневная для инженеров, внедряющих агентов, но это не прорыв и не политэкономика.
Статья — кейс рекламного агентства по ведению контекстной рекламы для сервиса доставки воды «Новокурьинская» с 2018 года. Главное утверждение: за восемь лет удалось удерживать стоимость целевого обращения почти неизменной, хотя за пять лет CPC вырос примерно в четыре раза. Для этого использовали почти сквозную аналитику из коннекторов, облачного хранилища и BI-дашбордов без CRM, что дало единые отчёты и базу для экспериментов; непрерывно оптимизировали кампании, разделяя обращения на новых и старых клиентов, чтобы ориентироваться на тех, кто вероятнее окупится; постоянно тестировали новые инструменты Яндекса — поиск, РСЯ, товарные кампании, мастер кампаний — и переносили бюджет туда, где в данный момент лучше результат; отдельно внедрили фильтрацию фрода в РСЯ, так как множество площадок дают клики без конверсий. Вывод: стабильный результат даёт не разовая настройка, а системная работа, анализ, тесты и контроль качества. Конкретных цифр, методик и проверяемых данных почти нет, статья больше похожа на имиджевый кейс агентства, полезный узкому кругу performance-маркетологов, но не прорывной и не связанной с IT-политикой или остросоциальной повесткой.
Автор пять с половиной месяцев пишет с ИИ-агентами язык программирования Nova — Go/Rust-подобный язык для бэкенда, где функция прямо в типе объявляет эффекты (работа с сетью, часами, файлами; идея из Koka/OCaml 5). Эффекты можно подменять в рантайме, поэтому моки и тестовые движки не нужны. Есть два компилятора: Nova Oracle (на Rust, переходная альфа) и Nova Carina (написана на самой Nova). Спецификация — журнал из 300+ проектных решений.
Главный сюжет — тупик первого компилятора. В Oracle вывод типов дублировался: в чекере и как «запасной вывод» в генераторе C. Месяц ушёл на план «Одна правда» по сверке двух выводов, но запасной вывод не уменьшался, а вырос с ~4,9 до ~5,2 тыс. строк: счётчик мерил лишь одну из двух функций, а сложные случаи (дженерики) всё равно решал старый код. Отчёты были зелёными, прогресса не было. Блокеры до релиза сначала упали (67→36), потом выросли (44→62) — дефекты находили быстрее, чем чинили.
13 августа автор решил писать компилятор заново сразу на Nova (Carina), 9 сентября поставил выпуск Oracle на паузу. Архитектуру Carina собирали по донорам (rustc, Go, Roslyn, Zig, Carbon); CI жёстко проверяет, что типы пишет только чекер, и следит за зависимостями модулей. Отдельные агенты-«охотники» ищут дефекты. Всплыли показательные провалы: тест проходил, потому что проверял только целые (агент молча сузил интерполяцию строк до целых вопреки спецификации); «CI зелёный, кроме известного красного» — модульные тесты вообще не запускались минимум с 16 сентября, потому что падал предыдущий шаг; на CRLF результат проверки зависел от переводов строк. Были и «обходы багов Oracle» прямо в исходниках Carina (25 обходов шести багов, к релизу убраны).
Кульминация — самосборка: Carina 0.2.0 собрала себя дважды, C-код и бинарники совпали байт в байт (10 октября 2026), причём сравнение проверили в обратную сторону — испорченный байт дал «не совпадает» с номером байта. Автор честно оговаривает: совпадение копий не доказывает корректности языка, ~12% C — готовый снимок Oracle, часть примеров Carina ещё не принимает.
Масштаб и цена: ~19 тыс. коммитов, 300+ тыс. строк Rust (Oracle), ~64 тыс. строк Nova (Carina), ~65 тыс. stdlib, всего ~190 тыс. строк Nova с тестами; ~160 тыс. рублей на подписки (~30 тыс./мес), в основном Claude Code в нескольких параллельных сессиях, аккаунт один. Выпущены альфы Oracle 0.1.0 и Carina 0.2.0 (11 октября). В продакшен нести рано, но для эксперимента хватает.
Семь выведенных приёмов: мерить удаление запасного кода, а не отчёты о прогрессе; считать расстояние до цели, а не число закрытых дефектов; сверять реализацию со спецификацией даже при зелёных тестах; проверять, что CI реально запускает тесты; проверять саму проверку; ставить жёсткий порог приёмки, не пускающий «почти работает»; при красном пороге сначала диагностика, потом новые попытки. Яркий пример последнего — гонка в рантайме: семь попыток по ~10 часов каждая давали «почти работает», а диагностика нашла use-after-free и исправление заняло 30 минут.
Статья — не реклама, а честный, саморефлексивный лог разработки с конкретными метриками, ошибками и выводами. Полезна всем, кто ведёт крупные проекты с ИИ-агентами (проблема «зелёных отчётов без прогресса» и подмены заданий). Минусы: местами тяжеловесные внутренности компилятора, много деталей именно про Nova, что снижает универсальность.
Автор сравнил mypy 2.4.0 с двумя новыми тайпчекерами на Rust — ty 0.0.87 от Astral и Pyrefly 1.3.2 от Meta — на двух своих асинхронных бэкендах: 852 и 2161 файл, FastAPI/Litestar, SQLAlchemy, Pydantic, FastStream, APScheduler. Цель — понять, можно ли заменить mypy, ускорив проверку типов в CI без потери качества.
По скорости при холодном старте ty оказался быстрее mypy примерно в 29 и 16 раз, Pyrefly — в 17 и 12 раз. Но при повторной проверке с дисковым кэшем mypy сравнялся или даже оказался быстрее на большем проекте: 0,449 с против 0,661 с у ty и 0,931 с у Pyrefly. При этом ty и Pyrefly в измеренных CLI-запусках не переиспользовали кэш анализа между процессами.
По диагностике инструменты заметно расходятся. ty и Pyrefly нашли опечатку в имени параметра метода, которую mypy пропустил. Pyrefly нашёл мёртвое имя в $1, которого не было в модуле. Но были и ложные срабатывания: Pyrefly неверно ругался на Field(gt=0) для Decimal в Pydantic, а ty и Pyrefly ошибочно предупреждали о None в max(..., default=None), хотя key к default не применяется. Pyrefly дал много ложных срабатываний в SQLAlchemy с колонками из mixin через declared_attr, но там же нашёл и реальные неточности аннотаций: Decimal вместо float, отсутствие optional-типов. С ignore-комментариями mypy возникла отдельная проблема: ty не поддерживает их совместимость с mypy, а Pyrefly лишь сообщает о подавленной диагностике. Сообщения mypy подробные, но многословные; ty даёт контекст и ссылку на нарушение LSP; Pyrefly короче, но иногда менее последователен.
Главный вывод: заменять mypy пока рано. ty и Pyrefly быстрее на холодную и иногда находят полезные ошибки, но их вывод типов, поддержка библиотек и совместимость с существующими настройками ещё не готовы к безболезненному переезду. Автор рекомендует раз в месяц прогонять проекты через все три инструмента и вручную разбирать расхождения, а проблему скорости mypy в CI решил кэшем .mypy_cache. Статья приглашает читателей поделиться своим опытом.
Оценка: материал технически плотный, практический, актуальный для Python-разработчиков, без рекламы, с честными замерами и примерами, но узкий по теме и не претендует на окончательный отраслевой вывод.
Автор сравнил цены на звёзды Telegram у трёх сервисов (SMMESE, МТС, KUPIKOD) на 16 октября 2026 года: дешевле всех оказался SMMESE (1000 звёзд — 1491,72 руб. против 1615 у МТС и 1638 у KUPIKOD, разница до 146 руб.). Затем он разобрал техническую механику покупки звёзд через Fragment — что именно делает сервис-посредник после оплаты. Цепочка состоит из шести этапов: подключение к Fragment через Playwright с браузерной сессией и проверкой владения кошельком, поиск получателя по username (внутренний идентификатор recipient), создание заявки initBuyStarsRequest с параметрами recipient/quantity/payment_method (ton или usdt_ton), получение условий платежа через getBuyStarsLink (адрес, сумма, срок действия, payload), проверка лимитов/баланса/срока и подписание транзакции с сохранением BOC до отправки, и наконец подтверждение покупки у Fragment (статус completed только после ok: true). Показан код на Python (классы Fragment и Worker): обработка статусов заказа preparing → signed → paid → completed, защита от двойной оплаты при обрыве соединения, проверка курса валют и наценки при расчёте розничной цены. По сути это рецепт для создания собственного сайта по перепродаже звёзд, плюс явная реклама одного из сервисов в ценовом сравнении. Практическая ценность для разработчиков, интересующихся экосистемой Telegram/TON, есть, но материал узкий, содержит промо-составляющую аналогично сравнительным обзорам хостингов и не касается остросоциальных или прорывных тем.
Автор сделал локальную программу Report Slides на Python (Streamlit + python-pptx + XlsxWriter), которая еженедельный отчёт из CSV собирает в готовый PPTX: титул, таблицы, диаграммы. Мотивация — руками переносить план/факт из Excel в PowerPoint долго и легко оставить прошлые числа. Программа запускается только на 127.0.0.1, без модели и ключей, ничего не пишет на диск и не сохраняет историю.
Технически самое содержательное: строгий разбор CSV (UTF-8 с BOM, оба разделителя, проверка кавычек, таба и переводов строк, лимиты по размеру файла, числу строк, длине полей, границам чисел); расчёты на Decimal с округлением до 1 знака (ROUND_HALF_UP) и борьбой с отрицательным нулём; полезные сообщения об ошибках с номером строки и конкретным действием (убрать разделитель разрядов, убрать знак процента, убрать лишние колонки). Общая логика: программа ничего не «додумывает» за человека, сломанная строка отклоняет весь файл.
Инженерные детали: слайды считаются из данных (1 + ceil(строк/4) + сумма по группам единиц; группировка по единице, без синонимов), диаграмма — настоящая BAR_CLUSTERED, а не картинка, чтобы числа правились через «Изменить данные»; синхронизация кэша чисел в XML диаграммы и в встроенной книге Excel; отключение printf-формул и гиперссылок в XlsxWriter через strings_to_formulas/strings_to_urls; собственная логика шкалы (0 на оси, шаг 1/2/5×10ⁿ, минимум 0.01, подписи в два знака); пересчёт геометрии мастеров и макетов под 16:9; кнопка «Скачать» сбрасывается по SHA-256 файла и по изменению текста отчёта, состояние — в st.session_state. Ограничения честно названы: произвольный корпоративный PPTX не редактируется, XLSX/PDF/PPTX на входе не читаются, ручные правки в следующий экспорт не попадают, на Windows и в Microsoft 365 не проверялось, тестов 58 (unittest + Streamlit AppTest + Playwright), лицензия MIT.
Это не реклама и не кликбейт: подробный, местами избыточно детальный инженерный разбор своего проекта с честным перечнем непроверенного. Актуальности «злободневной» нет, тема узкая (автоматизация отчётности), но качество и полезность для разработчиков, работающих с python-pptx/Streamlit/валидацией данных, высокие. Прорывного или полит-экономического контекста нет.
Новым владельцем игровой студии «Леста» (издаёт «Мир танков» и «Мир кораблей») стала АО «Промышленные сооружения» — консорциум частных инвесторов. Управляющая команда и стратегия развития остаются неизменными. Новый собственник планирует за три года вложить до 10 млрд рублей в российскую игровую индустрию, включая венчурный фонд. Ранее «Леста» с лета 2025 года находилась в собственности Росимущества после ареста и обращения в доход государства. В сентябре 2026 года анонсировали продажу, сумма обсуждалась на уровне 50 млрд рублей, интерес проявляло АО «Дхамма» и, по данным Forbes, Никита Мазепин. АО «Промышленные сооружения» зарегистрировано в ноябре 2024 года, учредители скрыты, с 15 октября гендиректор — Захар Кислых, у компании один сотрудник и убыток 15 тыс. рублей.
План обучения сотрудников работе с ИИ за 30 дней по 20 минут в день, около 10 часов практики без внешних курсов. Логика: у компаний дефицит не доступа к ИИ, а навыков. По опросу BCG 2025 только 36% считают обучение достаточным, при этом 54% готовы пользоваться ИИ даже без разрешения компании, то есть запрет лишь уводит практику в тень. План разбит на четыре недели: правила работы с данными и структура запроса; тексты и коммуникации; анализ данных и границы возможностей модели; процессы, регламенты и закрепление. На каждый день дан готовый промпт, приведены ключевые кейсы и исследования: утечка исходного кода в Samsung в 2023, данные Harmonic Security о конфиденциальной информации в 4% запросов и 20% файлов, мета-анализ Cepeda 2006 о распределённой практике, полевой эксперимент BCG/Harvard/MIT/Wharton 2023 (758 консультантов, +12,2% задач, на 25,1% быстрее, качество выше более чем на 40%, но на задаче вне возможностей модели результат хуже на 19 п.п.). Предложены четыре метрики оценки: время на типовую задачу, доля ответов с правками, число ошибок на 10 ответов, доля задач с ИИ. Отдельно перечислены ограничения материала и типичные ошибки. Основной минус — материал написан как реклама конкретного сервиса-агрегатора нейросетей: в разделе о доступе к моделям продвигаются подписка, «собственные» модели под чужими именами, скидка и промокод, а также телеграм-канал и комьюнити. Сама методика полезна как готовый каркас корпоративного микрообучения, но ничего прорывного в ней нет, промпты стандартные, а большая часть цифр взята из вторичных источников.
Автор — менеджер с 10+ годами опыта построения команд — не проходит фильтр по «актуальному управленческому опыту». Он описывает свой путь: начинал в инфраструктуре, где понял, что развивать людей важнее, чем быть самым сильным инженером; затем ушёл в разработку (DevOps, релизы), изучил продуктовый менеджмент, Scrum, тестирование; руководил отделом в НИР-департаменте — выстроил кросс-функциональные команды, перевёл тестировщиков в команды разработки, внедрил грейды, сообщества практики, ускорил поставки в 2–4 раза и вырастил лидов. Потом новый владелец перестроил всё, менеджмент ушёл. В геймдеве на роли Delivery Director столкнулся с сопротивлением дисциплине поставок, культом выслуги лет, «не будем говорить о проблемах, просто работаем», плохим легаси-кодом — проект развалился через два года. В «самом гибком банке» обнаружил, что почти все скрам-мастера без опыта в ИТ и управления, разработчики их не воспринимают, реальная власть у техлида. В роли Software Engineering Manager по факту оказался менеджером проектов; собрал кросс-функциональную команду, внедрил Full stack QA, сократил задержку релиза с 9 до 3 месяцев, но после 2022 и резкого роста компании новые директора свернули Agile и его команды. Затем был руководителем группы системного анализа, а после — TPO в облачной платформе: координационный ад из пяти независимых команд, 90% времени на координацию чужих неэффективных процессов, разгружал себя разработкой AI-агентов. Итог: в резюме его путь читается как «метания», HR и ИИ-фильтры дают шаблонные отказы, живые люди ссылаются на отсутствие свежего продуктового опыта. Главный тезис: смежные компетенции делают менеджера сильнее в работе, но слабее на бумаге, и остаётся неудобный выбор — честный рассказ с отсевом или подгонка под фильтр, которую трудно защищать.
Статья не рекламная, написана живым языком, поднимает актуальные для IT темы: нелинейные карьеры и дискриминация их на рынке, формализм Agile и Scrum, девальвация ролей скрам-мастера и менеджера проектов, сопротивление корпоративной культуры изменениям, зависимость результата от поддержки сверху. Это ценное личное свидетельство о проблемах управления в российской IT-индустрии, хотя и не новость и не прорыв, и часть наблюдений субъективна.
Автор собрал локальный семантический поиск по личным заметкам в виде MCP-сервера и подключил его к Claude Code, чтобы искать по смыслу, а не по словам, и не отправлять заметки во внешние сервисы. Стек — два файла Python, модель эмбеддингов paraphrase-multilingual-MiniLM-L12-v2 (около 120 МБ, 50+ языков, векторы 384, работает офлайн), sentence-transformers, numpy, FastMCP; зависимости зафиксированы жёстко. Сервер отдаёт три read-only инструмента: семантический поиск по заметкам с лимитом, список заметок и чтение заметки по имени.
Главная техническая суть — три подводных камня. Первый: у MiniLM жёсткий лимит 128 токенов, и всё лишнее отбрасывается молча, без ошибки, поэтому нарезка делается в два прохода — сначала по строкам/предложениям с ориентиром 500–600 символов и перекрытием 80 символов, затем точная проверка через токенайзер модели с запасом 4 токена (потолок 124). На русском токенный лимит срабатывает раньше символьного: реальные фрагменты вышли 323–492 символа и 88–123 токена, без обрезания. Второй: любой лишний вывод в stdout ломает stdio-протокол MCP, поэтому отключены прогресс-бары, логи идут в stderr, предупреждения токенайзера приглушены. Третий: имя файла приходит от модели, поэтому путь нормализуется через resolve() и проверяется на принадлежность папке заметок (защита от ../), плюс ограничение по расширениям .md/.txt; подсказки при ошибках написаны так, чтобы модель могла исправиться сама (неоднозначное имя, список доступных заметок).
Отдельно описан кэш эмбеддингов (.index/cache.pkl): ключ — относительный путь плюс mtime, есть словарь параметров (версия, модель, параметры нарезки) для сброса при их изменении, атомарная запись через временный файл, устойчивость к битому кэшу, автоудаление исчезнувших файлов. Индексация инкрементальная: при добавлении четвёртой заметки пересчитался один файл из четырёх, при повторном прогоне — ноль. Поиск — косинусная близость через скалярное произведение нормализованных векторов, плюс фоллбэк по словам для коротких запросов (≤2 слов) или слабой близости (<0,35) с весом 0,15; точное слово даёт 1,0, подстрока от 4 букв — 0,5; в выдаче показывается только чистая близость. Корень проекта вычисляется от файла и переменной CLAUDE_PROJECT_DIR. Автор честно перечисляет ограничения: пороги проверены на четырёх тестовых заметках, pickle-кэш небезопасен для чужих файлов, mtime слабее хэша, ключевой поиск — цикл на Python, PDF/DOCX не читаются, только локальный stdio без веб-доступа.
Материал — не реклама, а добротный инженерный опыт с рабочим кодом и конкретными цифрами, полезный тем, кто делает локальный RAG/MCP-инструмент. Минусы: несколько десятков заметок, слабая проверка масштабируемости, часть приёмов (косинус, чанкинг, инвалидация кэша) известна, тема хоть и актуальная, но не политэкономическая и не остросоциальная.
Автор вел Дзен-канал для клининговой компании из Петербурга с марта по октябрь 2026 года с единственной целью — узнаваемость, без бюджета на продвижение. Итог: 185 статей, 1 035 539 показов, 83 205 открытий (8% от показов), 37 938 дочитываний (45,6%), 639 часов чтения, 238 подписок (осталось 206), 12 заявок от частных лиц, 800 лайков, 88 комментариев, 383 репоста. Контент уходил в Дзен автоматически через RSS из блога сайта, часть материалов — «Дзен-эксклюзивы». На сайт с канала пришло лишь 340 визитов.
Главная особенность площадки — лотерейная раздача трафика: половина статей не набрала и 700 показов, 80 из 185 — меньше 500, зато восемь материалов дали треть всего охвата. Автор сознательно сократил выпуск с 66 статей в июне до 30 в июле — месячный охват упал всего на 13%, но средние показы на статью выросли вдвое (3320 против 1616), медиана — с 61 до 856, дочитывания — с 51% до 57%. Вывод: массовость публикаций в Дзене не равна охвату.
Лучше всего работал кластер про обязательные нормы на массовых объектах: уборка детсада по СанПиН, подъезда для УК и ТСЖ, классы чистоты в медучреждениях, стандарты для отелей. Это четверть статей, но больше половины дочитываний и подписок; статья про детсад дала 22 подписки при дочитывании почти 9 из 10. Формула успеха: объект с обязательной нормой плюс массовая аудитория плюс конфликт «кто должен и кто платит». Та же формула на нишевых объектах (рестораны, склады, салоны) провалилась, как и оценочные материалы вроде «ошибки бизнеса при выборе клининговой компании». Отдельная ловушка — цены в заголовке: «Сколько стоит генеральная уборка в 2026» дала рекордный CTR (29% из 53 тыс. показов), но дочитывали меньше пятой части, так как цифра не видна на первом экране. Цена работает только внутри нормативной темы (85% дочитываний у статьи про стоимость уборки подъезда для УК).
При этом автор отказался от самого доходного кластера: нормативка требует точных ссылок на СанПиН, а ошибка в публичном тексте для компании, продающей уборку детсадов и клиник, — юридический риск. Канал переведен на бытовые темы (пятна, запахи, сезонная уборка): они тоже дают охват (статья про запах из стиральной машины — 68,7 тыс. показов), но меньше подписок. Это осознанный размен.
Самый ценный технический вывод — про SEO. Пять Дзен-эксклюзивов, закрытых на сайте мета-тегом noindex, follow, привели к тому, что на следующий день Яндекс выкинул из индекса 18 страниц сайта, включая лидера по кликам в Search Console. Санкцией это не было — SQI не изменился, — похоже на переоценку релевантности: follow пускал робота ходить по страницам, он видел дубли тем и решал, что оставить. Решение: перейти на noindex, nofollow, отправить страницы на переобход и не делать эксклюзивов на темы, уже присутствующие на сайте. Плюс мелкое наблюдение: Дзен кэширует обложку по адресу картинки, замена файла по тому же URL в ленте не обновится.
Общий вывод автора: Дзен — дешевый фон узнаваемости при уже готовом контенте, мерить его надо охватом и дочитываниями, а не заявками, и не рисковать ради охвата поисковой выдачей основного сайта.
Оценка: материал не рекламный в прямом смысле (ни хостингов, ни «промптов для нейросетей»), но это по сути кейс-самопрезентация специалиста по контенту с мягким намеком на его услуги, тематика узкая — SMM и контент-маркетинг для малого бизнеса. Ценность есть в конкретных цифрах, честном разборе провалов и особенно в нетривиальном наблюдении про noindex/follow и выпадение страниц из индекса; для широкой аудитории, интересующейся политикой, экономикой и IT, статья периферийна и не отличается злободневностью или прорывностью.
Статья разбирает вопрос, почему три известных межзвёздных объекта — 1I/«Оумуамуа» (2017), 2I/Борисова (2019) и 3I/ATLAS (открыта 1 июля 2025, перигелий 29 октября 2025 на расстоянии ~1,4 а.е. от Солнца) — ведут себя настолько по-разному. «Оумуамуа» озадачил вытянутой формой, отсутствием комы и негравитационным ускорением; Борисова выглядела как обычная комета, но с необычным содержанием угарного газа; у 3I/ATLAS телескоп «Джеймс Уэбб» зафиксировал в коме преобладание углекислого газа (более чем семикратный избыток над водой), заметные количества никеля и железа, а также экстремально высокую долю дейтерия в воде и необычные изотопные соотношения углерода. Последнее указывает на формирование в очень холодной среде, возможно, до 12 млрд лет назад, то есть до рождения Солнца.
Главная мысль: определять «уникальность» по трём объектам методологически некорректно. Кометы Солнечной системы сами по себе крайне разнообразны (67P/Чурюмова–Герасименко, Галлея), а межзвёздные объекты дополнительно проходят через два фильтра — их выбрасывают из родных систем гравитацией гигантских планет, то есть это не случайная выборка вещества системы, а то, что ей удалось выбросить; и затем они миллиарды лет подвергаются облучению и эрозии в межзвёздной среде, меняя поверхностные слои. Плюс наблюдения ведутся лишь короткое время на гиперболических траекториях со скоростями порядка 61 км/с, и картина активности сильно зависит от скорости, геометрии и тепловой истории. Негравитационные ускорения 3I/ATLAS укладываются в обычное газовыделение, ничего выходящего за известную физику нет.
Отдельно объясняется, почему объекты находят только с 2017 года: рост чувствительности обзоров (Pan-STARRS, ATLAS) и ожидаемое десятилетнее исследование LSST обсерватории имени Веры Рубин, стартовавшее в июне 2026 года, которое может обнаружить десятки межзвёздных объектов и перевести тему из единичных курьёзов в статистику. Перспектива — миссия Comet Interceptor (ESA/JAXA) с тремя аппаратами, способная впервые исследовать межзвёздную комету вблизи. Вывод статьи: странность межзвёздных комет может отражать не аномалии, а незнание того, как выглядит типичный галактический «гость».
По сути это добротный научно-популярный обзор без сенсаций и без собственных выводов, с корректными оговорками против поспешных интерпретаций; полезен для понимания темы, но не содержит новостного повода на дату прочтения, а в конце пришит рекламный блок Beget.
Яндекс официально опроверг публикацию «Ведомостей» о том, что часть инфраструктуры компании к моменту атак на дата-центры осталась без продленного страхования от террористических рисков. В компании заявили, что используют разные виды страхования для защиты активов и управления рисками, полисы покрывают в том числе террористические атаки, но детали покрытия и условия договоров не раскрывают. Ранее источники «Ведомостей» сообщали, что часть инфраструктуры была застрахована в «Согазе» и «Ингосстрахе», однако продлить покрытие от террористических рисков к моменту атак не успели. Будут ли страховщики участвовать в возмещении ущерба, зависит от договоренностей между компаниями.
Эксперты поясняют, что рынок страхования таких рисков сильно ограничен. Полис с покрытием террористических рисков можно оформить максимум на шесть месяцев, страховые суммы лимитированы, а перерыв в деятельности в покрытие не входит. По новой концепции РНПК, действующей с 1 августа, франшиза составляет 50 млн рублей, лимит — 10 млрд рублей, срок страхования — шесть месяцев. Убытки от простоя бизнеса по рискам терроризма, диверсий и атак БПЛА не покрываются. Базовый тариф на перестрахование ЦОДа по программе РНПК — 1%. По оценкам экспертов, действующий полис возместил бы «Яндексу» только часть потерь, а страховщики сейчас фактически не покрывают убытки от перерыва в деятельности из-за атак.
14 октября глава Минцифры Максут Шадаев сообщил, что ведомство помогло «Яндексу» найти дополнительные площадки для переноса ключевых систем после атаки на дата-центры. Компания оперативно перевела IT-системы на заранее подготовленные резервные площадки, чтобы сохранить доступность сервисов. Оставшиеся системы сейчас переносят на сторонние мощности. В «Яндексе» говорят, что много лет развивают распределенную инфраструктуру и резервирование, включая независимые площадки, но детали размещения мощностей не раскрывают. Ранее директор по стратегическому маркетингу «Яндекса» Андрей Себрант признал, что нынешний инфраструктурный сбой оказался серьезнее сценария потери одного дата-центра, который компания регулярно отрабатывала на учениях. Сервисы восстанавливают поэтапно, в ликвидации последствий помогают другие компании отрасли.
20 сентября в International Journal of Equine Science вышла работа британских учёных из Хартпери и Портсмута: 21 опытная наездница проехала шагом, учебной рысью и галопом на механическом тренажёре-лошади, а затем пробежала по дорожке — в четырёх вариантах белья (обычный на косточках, спортивный «для езды» с раздельными чашками, комбинированный беговой и вовсе без белья). Восемь инфракрасных камер снимали движение груди относительно корпуса (а не абсолютное, иначе измерялась бы качка лошади, а не работа бюстгальтера) и заодно симметрию посадки. Это первая работа, где грудь наездниц измерили в 3D и сравнили с их же бегом.
Ключевые числа: без поддержки вертикальный ход груди при беге — 5,6 см, на любом аллюре примерно вдвое меньше (шаг 2,3, рысь 2,5, галоп 2,2). Беговая модель на дорожке снизила вертикальный ход на 62%, на рыси на 29%, на галопе лишь на 8,5% (в пределах разброса); модель «для езды» на галопе по вертикали не дала ничего. Зато по боковой оси картина переворачивается: на галопе боковое смещение 1,76 см, и «ехательная» модель срезала его на 40%, а беговая только на 16%. Вывод: беговое бельё оптимизировано под одно вертикальное колебание, а в седле нагрузка разложена по трём осям, поэтому «меньше прыгает» и «ровнее сидится» — не одно и то же. По осанке оба спортивных бюстгальтера держали корпус прямее, тогда как обычный на косточках не отличался от полного отсутствия белья; самая симметричная посадка чаще выходила в модели для езды. Анкеты: три четверти ездят в спортивном белье, почти половина иногда чувствует боль в груди, обычный бюстгальтер не выбрал никто.
Автор (подборщица белья с 2019 года) даёт содержательную критику методики: заявленная корреляция боли и смещения (Спирмен 0,428, значимость лучше 0,001) при 19 степенях свободы на деле даёт p около 0,053, то есть на грани; заявленная значимость получается только если считать наблюдением каждую пару «участница–бельё–режим» (336 замеров), но такие замеры не независимы и завышают значимость. Даже в щедром прочтении смещение объясняет меньше пятой части различий в боли. Ограничения: маленькая выборка, женщин с чашкой D и больше всего восемь, тренажёр вместо живой лошади, по одной модели на тип белья, все подобраны специалистом, проценты считаны от медиан. Открытые вопросы — как должна выглядеть конструкция бюстгальтера под трёхосную нагрузку и можно ли заменить лабораторные камеры парой инерциальных датчиков на живой лошади.
Материал добросовестный, не рекламный, с самостоятельным пересчётом статистики, но тема узкая, к IT, политэкономии и остросоциальной повестке не относится — это популярная биомеханика и потребительский обзор нишевого товара.
Статья представляет собой конспект по низкоуровневой архитектуре x86: как процессор выполняет примитивные логические операции и инструкции, что такое машинное слово, шины данных и адреса, почему битность шины связана с режимом работы. Далее разбираются три основных режима. Real mode — 16-битные регистры и машинные слова, но 20-битная адресация через сегментацию, доступ к BIOS через прерывания, проблема A20 и её включение через порт 0x92. Protected mode — 32-битный режим, линейная адресация до 4 ГБ, защитная сегментация через селекторы и дескрипторы, обязательная GDT, появление paging с таблицами страниц. Long mode — 64-битный режим, сегментация почти не используется, кроме FS и GS для TLS, paging обязателен, адресация виртуальная, канонические адреса, разделение пользовательского и ядерного пространства, четырёхуровневая и потенциально пятии шестиуровневая страничная адресация. В конце перечислены условия переходов между режимами: GDT и бит PE в CR0, затем paging, CR3, PAE, LME и far jump.
Материал полезен в первую очередь новичкам в OSDev и системном программировании, но это не новость, не прорыв и не общественно-политическая тема. Рекламы нет. Статья актуальна как вечнозелёное объяснение основ x86, однако многие вещи сильно упрощены, местами есть огрехи форматирования и пропущенные формулы, а автор сам признаёт, что находится в начале пути и статья может быть «дырявой». Для широкого читателя ценность невысокая, для узкой аудитории — умеренно полезная.
Hinterland Games анонсировала дополнение Iron Road для режима выживания The Long Dark. Игроков отправят на остров Котёл, которого давно нет на картах. Главная механика — старый поезд, простоявший около века: его нужно восстановить, чтобы проехать более 100 километров по вулканической кальдере. По словам разработчиков, местная история заметно изменит привычное выживание. Идея железной дороги возникла при работе над пятым эпизодом сюжетной кампании, поезд понравился авторам и игрокам, поэтому под него сделали отдельное DLC. Выпускать контент частями не будут: после консультаций с Valve студия решила сразу запустить Iron Road в раннем доступе. Релиз — 27 октября 2026 года, полноценный трейлер и детали механик покажут перед самым выходом.
VK объявил новый JT Mobile Meetup. Он пройдёт офлайн в двух городах: 31 октября в Москве и 14 ноября в Санкт-Петербурге. В Москве будет два параллельных трека — iOS и Android, в Санкт-Петербурге один общий. Выступят разработчики из ВКонтакте, Дзена, MAX, VK Tech и других команд VK. В программе iOS: импакт-анализ UI-тестов, снапшот-тестирование в дизайн-системе, поиск визуальных регрессий и ИИ в тестах. В программе Android: достижение 120 FPS в сложных списках, анализ отклонений A/B-метрик через Tracer и ИИ, проектирование прерываемых систем и безопасная отмена цепочек операций, доставка изменений на Kotlin за несколько часов без нового релиза приложения. После докладов обещают интерактивы и афтепати. Участие только офлайн, нужна регистрация. Для мобильных разработчиков в Москве и Санкт-Петербурге новость практически полезна, для широкой IT-аудитории это в основном анонс мероприятия без содержательных деталей.
Автор — пользователь с личной системой питания (метаболическая тарелка по Обложко, нормы: до 1000 ккал, белок 78 г, жиры 30–37 г, углеводы от 70 г, клетчатка от 25 г) — рассказывает, как подключила официальный MCP-сервер ВкусВилла к Claude и автоматизировала сбор недельной корзины. До этого заказ продуктов занимал 30–40 минут, потому что фильтра по КБЖУ в магазинах нет и приходилось читать карточки вручную. Из российских продуктовых официальный MCP с КБЖУ и корзиной есть только у ВкусВилла; у Лавки — неофициальный через веб-API, у маркетплейсов — только сравнение цен.
Техническая суть: сервер mcp.vkusvill.ru умеет поиск по каталогу, карточку товара, аналоги, скидки, рецепты, магазины и создание ссылки на корзину (до 30 позиций). Личные инструменты (история заказов, персональные скидки, «Любимый продукт») требуют OAuth 2.0 с PKCE; вход через /mcp не работает из-за offline_access, поэтому токен получают отдельным скриптом с PKCE, а Claude Code подключается через headersHelper. Автор честно перечисляет ограничения: 10 товаров на страницу, пустой запрос не принимается, лимит 60 запросов в минуту (заголовки X-RateLimit), Qrator блокирует Python по User-Agent (помогает маскировка под curl), иногда «Ошибка создания ссылки» требует повторов с паузой. Через HTTP-обход собрала 7 222 уникальных товара, из них 2 005 до 150 ккал, но у 1 202 нет КБЖУ (включая многие овощи и фрукты). КБЖУ одного и того же товара у разных производителей различается в 2–3 раза — правило брать товары с узким разбросом.
Ключевая находка: ручная подгонка дня под 5 норм КБЖУ не сходится, поэтому Claude переводит задачу в линейное программирование (scipy.optimize.linprog, метод HiGHS) с ограничениями по калориям, белку, жирам, клетчатке и углеводам и узкими границами граммовки (30–180% от исходной). Итог — 8 корзин от ≈5 370 ₽ до ≈9 850 ₽ в неделю, каждая укладывается в нормы; в финальной версии — 4 корзины по способам готовки (духовка, мультиварка, рыба, котлеты), готовит два вечера в неделю. Есть артефакт-отчёт и готовый промпт для копирования. Отмечает, что персональные скидки дают мало эффекта, а цены — каталог на 13 октября 2026.
Оценка: не реклама (личный проект, не от ВкусВилла), максимально свежие данные, редкий практический разбор реального бытового применения MCP с кодом, скриптами обхода и честным перечислением грабель; при этом тема узкобытовая, без полит-экономического и остросоциального контекста, и часть трюков (обход Qrator, ручной OAuth) скорее для энтузиастов.
Статья — практическое руководство по усилению локальной безопасности на macOS с помощью Touch ID и Secure Enclave, без потери удобства. Автор исходит из типичной проблемы: разработчики отключают пароль на sudo, держат SSH-ключи незашифрованными и секреты открытым текстом в ~/.zshrc, потому что не хотят постоянно вводить пароли. Предлагается три решения.
Первое — sudo через Touch ID. Начиная с macOS 14 Sonoma в системе есть шаблон /etc/pam.d/sudo_local.template; достаточно скопировать его в /etc/pam.d/sudo_local и раскомментировать строку auth sufficient pam_tid.so. Таймаут авторизации настраивается через Defaults timestamp_timeout=0 в visudo. Внутри tmux/screen Touch ID не сработает, так как процесс-демон не привязан к GUI-сессии; лечится установкой pam-reattach из brew и добавлением его строкой выше pam_tid.so.
Второе — SSH-ключи в Secure Enclave. С macOS 26 Tahoe это поддерживается нативно: ключ создаётся командой sc_auth create-ctk-identity -l user@server -k p-256-ne -t bio, публичная часть выгружается через ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N "" или добавляется в ssh-agent через ssh-add -K -S. Файл id_ecdsa_sk_rk приватным ключом не является — это лишь ссылка на аппаратный ключ, скопировать и перенести его нельзя ни для бэкапа, поэтому нужен запасной доступ к серверам. Поле «Valid To» относится к автогенерируемому X.509-сертификату и для SSH неважно. Сервер должен поддерживать OpenSSH 8.2+ и алгоритм sk-ecdsa-sha2-nistp256@openssh.com (проверяется через ssh -Q key и sshd -T). Для старых macOS предложены Axo Pass и Secretive.
Третье — секреты в переменных окружения. Вместо открытого текста в ~/.zshrc используется подход 1Password CLI: файл .env хранит ссылки вида op://Vault/Item/field, а запуск идёт через op run --env-file=.env -- myapp. Автор нашёл менее известную альтернативу envrcctl (Python), хранящую секреты в Keychain: envrcctl secret set, запуск через envrcctl exec -- команда, экспорт в shell через eval "$(envrcctl inject --shell)" (обёртка senv), интеграция с direnv через envrcctl init --inject и direnv allow — тогда секреты подгружаются автоматически при входе в папку с запросом Touch ID. Честно отмечено, что экспорт секретов в текущий shell менее безопасен, чем запуск через exec.
Вывод автора: каждое из трёх решений внедряется за 5–10 минут, использует штатные средства macOS и пару утилит из brew; sudo больше не срабатывает молча, приватный SSH-ключ физически нельзя украсть, а .zshrc чист от секретов. Это не абсолютная защита, но заметный шаг вперёд малой ценой.
Слабые места: материал сугубо прикладной и macOS-специфичный, часть приёмов (pam_tid) широко известна, есть элементы продвижения конкретных утилит (envrcctl, brew-пакеты) — но это не прямая реклама платных услуг. Прорывных или общественно-политических тем нет, зато практическая ценность и актуальность для разработчиков на macOS высокие.
Статья — третья часть цикла о том, как пережить крупную облачную аварию, не потеряв безопасность. Основная мысль: во время сбоя нельзя просто отключить защиту ради скорости — её нужно перевести в заранее подготовленный аварийный режим с короткими процедурами, но чёткими границами, ответственными и сроками.
Ключевые тезисы. Во время аварии меняется модель угроз: одновременно исчезают привычные доказательства доверия (SSO, Vault, CI/CD, журналы), поэтому старую среду нельзя считать доверенной автоматически, а инцидент надо рассматривать по двум сценариям — технический отказ или компрометация. Для каждого решения автор предлагает пять вопросов: кто запросил, минимально нужный доступ, где останется след, когда доступ истечёт, что проверить после восстановления.
Разобраны конкретные ситуации. При падении внутреннего мессенджера нужен заранее выбранный внешний канал связи с MFA, подтверждённым списком участников и запретом на секреты (дана сравнительная таблица вариантов — от подготовленного чата до публичной страницы статуса). При отказе Vault — это циклическая зависимость, когда ключи нельзя достать из умершей инфраструктуры; нужны аварийный контур хранения секретов вне основного облака, разделение полномочий (два человека), краткоживущие реквизиты, независимый аудит; запрещено слать пароли в общий чат, почту, репозиторий. При отказе SSO/IAM — именованные аварийные учётные записи с независимым вторым фактором и оповещением о входе. При падении GitLab — сборка на ноутбуке допустима, но только в чистом окружении по принципу двух человек, с фиксацией коммита, зависимостей, подписью артефакта и последующей штатной пересборкой. При потере журналов и SIEM — локальная очередь плюс независимый внешний приёмник ключевых событий. При потере VPN — временный бастион с ограничением по IP, ключами, сроком жизни и записью сеансов, а не открытый всему миру SSH.
Отдельно даны обязательные AppSec-проверки перед переключением трафика (разбиты на блокирующие, допустимые временно и пост-запусковые), реестр временных исключений с крайними сроками, план подготовки до инцидента, действий в первые часы и после стабилизации, а также таблица распределения ответственности между DevOps, AppSec, ИБ, разработкой, юристами и руководством. Вывод: устойчивость и безопасность нельзя проектировать отдельно — зрелый DevSecOps сохраняет обе за счёт независимых каналов, минимальных прав, короткоживущих доступов, журналирования и учений. Ссылки на NIST SP 800-61, OWASP (секреты, журналирование, CI/CD) и HashiCorp Vault.
Материал практичный и насыщенный, без явной рекламы конкретных услуг (Vault упомянут как пример технологии, а не как продаваемый продукт), опирается на авторитетные источники. Не новость и не прорыв, но ценное методическое руководство по DevSecOps-реагированию; актуально для SRE/DevOps/ИБ.