Все потоки

Топ-3 схемы фейковых рекрутеров — как их распознать и не попасться

Привет, Хабр! Я Ася Маркевич, HRD в Далее. Недавно ко мне в личку пришел кандидат со скриншотами переписки и вопросом: «Этот человек точно у вас работает?». Оказалось, некий рекрутер-мошенник от имени нашей компании вёл полноценный найм в Telegram — с тестовыми заданиями и живой перепиской. Я написала ему сама и спросила, что за вакансии он помогает нам закрывать. Ответ был исчерпывающий: «Ищу вам фулстек-уборщика». На этом разговор закончился.

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

🚩Схема 1. «Войдите в корпоративный iCloud»

Мошенники копируют вакансию реальной компании (иногда просто удваивая зарплату) и открывают найм в Telegram. Для кандидата всё выглядит убедительно: живая переписка с рекрутером, описание условий, тестовое задание.

Но есть одно но — тестовое можно выполнить только одним способом: выйти из своей учетки в iCloud и зайти в «корпоративную». После входа устройство блокируется. Следует требование выкупа — обычно несколько сотен долларов.

🚩Схема 2. Клон настоящего аккаунта

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

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

🚩Схема 3. Фейковая компания или дипфейк-руководитель

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

Как не попасться

1. Проверяйте профиль рекрутера в Telegram. Посмотрите дату создания и историю смены имени. Профиль младше недели или со свежим переименованием — почти всегда тревожный сигнал. Найдите рекрутера на странице компании: на Хабр Карьере, LinkedIn или корпоративном сайте. Фото и ник должны совпадать.

2. Сверяйте вакансию с официальными источниками. Найдите её на официальном сайте компании или HeadHunter. Если вакансия есть только в Telegram — стоит насторожиться. Сравните условия: мошенники часто берут реальную вакансию и просто удваивают зарплату.

3. Никогда не выходите из личных аккаунтов по просьбе рекрутера. Ни один нормальный работодатель не попросит выйти из iCloud, Google или других учеток.

4. Проверяйте компанию. ИНН, выписка из ЕГРЮЛ, отзывы, судебные дела — всё есть в открытом доступе. Компания зарегистрирована на прошлой неделе? Это серьезный повод насторожиться.

5. Если уже попались — не платите выкуп. Оплата на счёт мошенника несёт юридические риски для вас самих. Сообщите банку и напишите заявление в полицию — даже если сумма небольшая. Ваше обращение пополнит базу мошеннических операций, которую ведет Центробанк.

Больше реальных кейсов с комментариями юриста — найдете в большой статье. А если вы сами сталкивались с подобными случаями или знаете, как распознать их раньше — пишите в комментариях. 

В предыдущих сериях был реализован простейший движок на основе HashMap, в которой сохраняются данные key -> value, и в принципе была открыта дорога для написания сервера и клиента для тестов. Но я решил добавить в Space работу с распределенными (XA) транзакциями.

Наличие такого механизма обязательно приведет к деградации производительности. Закономерно возникает вопрос: для чего это было сделано? Memifydb - это распределенная БД и она должна обеспечивать конкурентный доступ к данным обеспечивая их целостность. Что проку если она будет работать быстро, но её содержимое будет - хаос? Ведь деже при создании простого приложения для обработки данных в нескольких потоках используется synchronized в java (и пр. механизмы синхронизации).

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

Итак, транзакционность добавил, пока что на уровне RAM без сохранения данных в долговременную помять для отката/восстановления. Следующий шаг это написание самого сервера, который будет управлять Space’ами и обработкой клиентских запросов.

👉 Telegram: https://t.me/memifydb 👉 GitHub: https://github.com/yourname/memifydb

Как находить инструкции быстрее на 40%

Одна из самых недооценённых вещей в базе знаний — нормальные названия статей.

Не AI, не «умный поиск», не модный second brain. Это всё здорово, но начинается взаимодействие с базой гораздо раньше.

Я как-то работал над скоростью поиска внутри БЗ и внезапно выяснил, что саппорты тратили огромное количество рабочего времени впустую просто потому, что документация называлась примерно так: «Новый процесс», «Финальная схема», «Инструкция updated», «Регламент 2»

И пользовательский путь в базе знаний выглядел так:
1. открыть статью,
2. понять, что это не то,
3. закрыть,
4. открыть следующую.
5. повторить 14 раз.

Причём самое полезное, что я тогда сделал, вообще не связано с написанием документации. Я просто сел рядом с саппортом и начал смотреть, как он ищет информацию. Не как казалось мне или его руководству, а как он реально это делал. И тут вскрылось прекрасное: оказалось, сотрудники почти никогда не ищут «правильными терминами».

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

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

Выглядит не очень героически, зато поиск информации ускорился почти на 40%. Сами понимаете, что в этом времени — не только качество и количество обработанных тикетов, но и коэффициент удовлетворённости клиента.

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

Заменит ли автопилот человека?

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

В середине апреля Tesla получила первое в мире одобрение на использование софта для беспилотного управления автомобилем в Европе — в Нидерландах. Компания надеется, что это позволит в будущем запускать беспилотники по всей Европе. Но прогресс нелинеен — в конце прошлого месяца Китай ограничил регистрацию новых машин с автопилотом после хаоса, устроенного такси компании Baidu. Что сложного в управлении автомобилем?

В 2004 году DARPA, отвечающая за поддержку новых технологий в Пентагоне, устроила конкурс DARPA Grand Challenge, в ходе которого беспилотным автомобилям надо было проехать всего 230 км. Не справился ни один из участников. Но бурное развитие искусственного интеллекта (ИИ), и в частности систем распознавания изображений, позволило Tesla начать его внедрять в серийные автомобили всего через 10 лет.

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

В Китае производители автопилотов смогли договориться с регуляторами о полностью беспилотных авто — можно заказать такси без водителя. И Ухань знаменит не только коронавирусом — по городу курсирует более 500 беспилотных авто. И вот 31 марта сотни машин Baidu внезапно остановились. Это произошло посреди потока, и некоторые машины остановились на скоростных магистралях: пассажиры не решались выбраться, но и разработчик не мог решить проблему.

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

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

Сервер для PyTorch: как выбрать конфигурацию под обучение и инференс

PyTorch запустится почти на любом сервере, но между «запустится» и «работает стабильно под нагрузкой» — большая разница. Частая ошибка — выбирать VRAM по размеру модели, но видеопамять занимают контекст, KV-cache, размер батча и служебные расходы фреймворка. 

В новой статье разобрали, когда хватает CPU и в каких сценариях нужен GPU. Показали, как заранее проверить совместимость драйвера NVIDIA и версии CUDA, как эмпирически измерить фактическое потребление VRAM и сколько RAM закладывать под DataLoader с несколькими воркерами. И собрали ориентиры по конфигурациям — от прототипирования и небольшого инференса до обучения на 2–4 GPU и больших моделей.

Все подробности — в блоге Рег.облака.

Как можно ошибиться при обработке ошибок в Go

Tе, кто до Go писал на языках с конструкциями try/catch, таких как Java и C#, наверняка испытывают легкое замешательство. Руки так и тянутся к try/catch заменителю — использованию recover в связке с defer — как к самому очевидному аналогу. Но это плохая практика и так делать не стоит. Давайте разберёмся, почему и как можно ошибиться при обработке ошибок в Go.

SAST: с чем сталкиваются команды и как это решать

Сегодня поговорим про статический анализ кода (SAST) — одну из самых важных практик анализа безопасности приложений, которая помогает находить уязвимости на ранних этапах разработки.

▶️ Основные проблемы, которые беспокоят разработчиков:

• долгие сканирования на крупных кодовых базах;

• большое количество ложных срабатываний (False Positive);

• недостаточное покрытие технического стека правилами (False Negative).

▶️ Как решать:

• выбирайте инструменты, которые отвечают требованиям вашей компании и отрасли;

• разработайте набор правил под конкретный проект;

• редактируйте встроенные правила в продукте;

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

▶️ Что лучше выбрать: коммерческий или некоммерческий SAST- сканер?

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

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

Обычно, чтобы определиться с выбором SAST-инструмента, команды проводят пилот: сравнивают решения по функциональности и качеству детекта. Максимальный эффект от решения достигается тогда, когда выстроен процесс тестирования с настройкой правил, метриками и понятными критериями эффективности.

Демонстрация low-code коннектора к «1С:Шине» от «Денвик»

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Пока «Фирма 1С» не выпустила поддержку «1С:Шины» в БСП, мы тестируем партнерские решения. Недавно в статье на Хабре я пригласил к сотрудничеству компании, у которых уже есть готовый коннектор, и первым откликнулся «Денвик».

«Денвик» — российский продукт для автоматизированной выгрузки данных из 1С во внешние аналитические базы и BI-системы. Кроме экстрактора есть инжектор — инструмент обратной загрузки данных в 1С. Оба инструмента имеют low-code интерфейсы. За счет этого типовые сценарии выгрузки из 1С и загрузки в 1С можно настраивать через интерфейс, без привлечения разработчика.

Можно ли экстрактор и инжектор использовать в качестве коннектора к «1С:Шине»? Да, можно. На вебинаре в этот четверг вместе с product owner «Денвик» Степаном Пыстиным покажем, какие задачи решаются с помощью инструментов «Денвика».

Спикеры:
— Сергей Скирдин, технический директор «Белого кода»
— Степан Пыстин, product owner «Денвик»

📅 Дата: 14 мая
🕛 Время: 12:00 МСК
📍 Формат: онлайн

➕ Для участников вебинара команда «Денвика» предоставит бесплатный тестовый доступ.

Регистрируйтесь на вебинар и приходите!

Приглашаем на вебинар: Как превратить BI в единое окно управления компанией: кейс компании «Синтека» на платформе Luxms BI

Дата: 14 мая, четверг
Время: 15:00

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

На вебинаре команда компании «Синтека», которая использует Luxms BI не только для создания аналитических решений для своих клиентов, но и как основу внутренней управленческой аналитики, расскажет, как они подошли к решению этой задачи у себя.

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

🔸Обсудим, как собрать данные из разных контуров в одну систему координат и договориться о едином подходе к метрикам

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

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

📍Предварительная регистрация
Вам придет напоминание, а после вебинара пришлем ссылку на запись:)

— Что общего у сотрудников-зумеров и AI-агентов?
— Не знаешь, чего от них ждать.

Тайм-менеджмент не спасёт тебя от выгорания. Никогда не спасал.

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

77% профессионалов столкнулись с выгоранием в прошлом году. Это не про «кто-то не справляется со стрессом». Это системный кризис. И три десятилетия исследований говорят одно: главная причина выгорания — не личность человека, а среда, в которой он работает.

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

Настоящий сдвиг — когда начинаешь управлять энергией, а не временем.

HBR фиксирует: работа с четырьмя видами энергии — физической, эмоциональной, ментальной и духовной — даёт рост продуктивности на 13–20% без единого добавленного рабочего часа.

Как это выглядит на практике?

Четыре раза в день — за 30 секунд — задай себе вопрос: как я сейчас по каждому из четырёх измерений? По шкале 1–10. Не чтобы себя оценить, а чтобы заметить паттерн. Когда ты на пике? Когда в яме? Тяжёлую задачу ставь на пик энергии — а не на свободный слот в календаре.

И вот контринтуитивная вещь.

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

Выгорание — это не финиш слабых. Это сигнал системы, что что-то сломано в среде.

🔥 МастерАп 262: AI-оркестрация, фронтенд, бекенд и системная разработка

Второй МастерАп в серии — живая встреча, рестобар, три доклада от практикующих экспертов.

В этот раз говорим про AI в разработке: вербализация как инженерный навык, оркестрация AI-систем и как AI меняет системную разработку Linux.

---

📅 12 мая, 19:00–22:00
📍 Рестобар Точка, 5 минут от м. Пионерская → Яндекс Карты

👉 РЕГИСТРАЦИЯ

🎟 Вход свободный — просто возьмите что-нибудь в баре

---

⚡️ Программа:

🚀 Андрей Ерёменок — «Вербализация как инженерный навык: от кода к тексту, от текста к дизайну»
CTO, сооснователь, AI-консультант с 20-летним опытом. Ведущий канала «Пикник Айтишника».

🐳 Андрей Чуян — «Оркестрация AI систем в разработке контента и решений»
FullStack-разработчик, автор канала «IT-волна» (ITChuyana). Основатель сообщества ПолныйСтек. Эксперт по автоматизации и AI.

🐧 Алексей Сапрунов — «AI в системной разработке Linux»
Системный разработчик Linux. Эксперт по AI в системной разработке, автоматизации и низкоуровневому программированию.

---

👥 Для кого:
Разработчики всех направлений, тимлиды, CTO, DevOps — и все, кто хочет живого общения про AI без воды

---

✅ Что будет:
— Три доклада от практиков
— Вопросы и дискуссия вживую
— Нетворкинг в неформальной обстановке

Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы

Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML. 

В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком. 

Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы: 

• «Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс) 

• «ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech) 

• «Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon) 

• «Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud) 

• «ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк) 

• «Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)

Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.

Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.

10 мая 2026 года OpenAI объявила Daybreak — связку GPT-5.5 и Codex, которая ищет уязвимости в репозитории, валидирует их в sandbox и предлагает патч в один клик.

GPT-5.5, вышедший 23 апреля 2026-го, стал первой моделью OpenAI, перешагнувшей порог «High» по кибервозможностям согласно собственному Preparedness Framework компании. Поверх него — Codex как агентный harness, который работает напрямую с кодовой базой. Вместе они и составляют Daybreak.

Три уровня доступа и один жёсткий порог. Базовый тир — GPT-5.5 для общих сценариев, без особых ограничений. Средний — Trusted Access for Cyber (TAC): secure code review, triage уязвимостей, анализ малвари, detection engineering, валидация патчей. К моменту анонса в TAC уже числились тысячи верифицированных одиночных защитников и сотни команд.

Верхний тир — GPT-5.5-Cyber, представленный 7 мая 2026-го. Это «cyber-permissive» вариант флагмана: не умнее, но менее склонен отказывать на запросы про крафт пейлоадов, воспроизведение эксплойтов в лабораторных условиях и реверс бинарей. Выдаётся точечно. С 1 июня 2026 года потребуется phishing-resistant аутентификация — OpenAI явно не хочет, чтобы этот SKU воспринимался как обычная подписка.

Что это даёт в реальном pipeline. Если стек уже завязан на Codex или ChatGPT Enterprise, Daybreak встраивает непрерывный security-loop прямо в CI/CD: модель строит threat-модель из репозитория, валидирует уязвимости в sandbox, генерирует патч через Codex. Для open-source мейнтейнеров OpenAI обещает pro bono сканирование — по аналогии с Aardvark в private beta осенью 2025-го, которая дала 10 CVE по итогам responsible disclosure.

Контекст запуска не случаен: IBM X-Force в 2026 году зафиксировал рост атак на публичные приложения на 44% год к году, CrowdStrike — рост активности AI-усиленных противников на 89%. Anthropic продвигает Claude Mythos с фокусом на безопасность, но без публичного доступа; Google — CodeMender; стартап XBOW занимает свою нишу. Daybreak при этом позиционируется как первый массово развёрнутый агент для defense-команд от ведущего AI-вендора.

Интереснее всего здесь не сама модель, а архитектурное решение: OpenAI разделила «умеет» и «разрешено» на уровне продуктовых тиров с верификацией личности. Это прецедент — раньше ограничения были только техническими (system prompt, фильтры). Теперь доступ к определённым возможностям привязан к идентификации пользователя. Насколько это удержит модель от злоупотреблений — покажет практика.

TG @CIOlogia

Китайская робототехническая компания Unitree Robotics представила первого в мире пилотируемого робота-трансформера GD01, готового к массовому производству. Устройство весом ~500 кг с оператором. Рост робота более чем в два раза превышает рост взрослого человека. Внутри корпуса расположена кабина-клетка, где может разместиться человек. Робот способен менять вертикальное положение на горизонтальное и перемещаться на четырёх конечностях.

Unitree Robotics позиционирует новинку как гражданское транспортное средство. Его цена составит 3,9 млн юаней ($574 тыс.).

В опубликованном видео внутри трансформера находился глава Unitree Robotics Ван Синсин.

Новости законодательства: выходной для пострадавших в ЧС, лифты с 2027 года и праздники-2027

На этой неделе новостей не много, но есть кое-что интересное.

Дополнительный выходной и отпуск для пострадавших от чрезвычайных ситуаций

С 1 сентября 2026 года в ТК РФ закрепят гарантии для тех, кто фактически проживает в зонах ЧС природного и техногенного характера.

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

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

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

Документ: Федеральный закон от 09.04.2026 N 90-ФЗ

Запрет на испытательный срок при приёме на работу женщин расширен

С 1 сентября 2026 года не позволят устанавливать испытание женщинам, если у них есть дети до 3 лет. Сейчас запрет действует, если ребёнку не исполнилось полтора года.

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

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

Документ: Федеральный закон от 09.04.2026 N 91-ФЗ

Отложен срок вступления в силу новых правил обслуживания лифтов в МКД

Поправки к ЖК РФ о том, что обслуживать и ремонтировать лифты вправе только специализированные лифтовые организации, заработают с 1 сентября 2027 года. Изначально новшества должны были вступить в силу на год раньше.

С учётом переноса сдвинется срок, чтобы среди прочего закрепить в договорах управления МКД обязанность УК привлечь специализированную организацию. Дополнить договоры нужно не позже 29 ноября 2027 года.

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

Документ: Федеральный закон от 02.05.2026 N 131-ФЗ

Праздники и перенос выходных в 2027 году: проект Минтруда

Минтруд планирует сделать субботу 20 февраля рабочей, чтобы в этом месяце можно было отдохнуть три дня подряд (с 21 по 23 февраля). За счёт переноса выходных с 2 и 3 января (суббота и воскресенье) хотят удлинить отдых в ноябре, а также сделать свободным днём 31 декабря.

С учётом предлагаемых перестановок нерабочими будут:
⦁ с 31 декабря 2026 года по 10 января 2027 года;
⦁ с 21 по 23 февраля;
⦁ с 6 по 8 марта;
⦁ с 1 по 3 и с 8 по 10 мая;
⦁ с 12 по 14 июня;
⦁ с 4 по 7 ноября;
⦁ 31 декабря 2027 года.

Общественное обсуждение проекта завершат 15 мая.

Майские будут ровно такие же, как в этом году 🥲.

Документ: Проект постановления Правительства РФ

А что вы думаете об этих изменениях? Поможет ли новый выходной пострадавшим в ЧС? И как вам проект выходных на 2027 год? Делитесь мнением в комментариях 👇

Глава Google Cloud опубликован на GitHub свой личный сетап из лучших скиллов для ИИ‑агентов. Это ультимативная сборка для разработки от лучших разработчиков Google. Внутри — 19 навыков для ИИ и 7 слэш‑команд. Работает сборка в 6 этапов:

• Скилл Define — формулирует идеи, пишет спецификации, пока кодинг ещё на стартовал

• Plan — разбивает большую задачу на маленькие этапы

• Build — приступает к пошаговой разработке, учитывая контекст и подключая API

• Verify — тестирует результат через DevTools и фиксит баги

• Review — проверяет качество кода, чекает безопасность и улучшает производительность

• Ship — подготавливает продукт и релизит.

Сетап встраивается в Claude Code, Cursor, Antigravity, OpenCode, Gemini CLI и так далее.

Представлен бесплатный сервис Filescan, который работает прямо в браузере и проверяет любой сайт или файл на вирусы:

• работает со всеми типами файлов, включая картинки, видео, apk и exe;

• запускает приложения в песочнице и смотрит на его поведение;

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

• при этом работает быстро — разбор задачи занимает несколько секунд;

Хватает ли силы воли?

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

Так достаточен ли этот остаток? Тут – как с деньгами. Достаточно ли денег на счёте? Любой разумный человек задаст встречный вопрос – смотря на что. С силой воли точно так же. На что-то хватает, на остальное – нет.

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

Что входит в этот «план расходования»? У каждого – индивидуально.

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

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

Если взять некий средний день каждого человека, то к вечеру баланс его силы воли пустеет. Сделал всё, что «обычно делаю» - и на этом всё. Крайне редко человек вечером подскакивает и говорит – «так-с, что-то у меня энергии дофига осталось, и время есть, ну-ка я лесенку на перекладине сделаю».

Возвращаемся к исходному вопросу – хватает ли человеку силы воли? Да, конечно.
А на что хватает? На «мой обычный день».
А на что не хватает? На что-то ещё, на изменения, на всё, что за пределами «моего обычного дня».

Текст из Математики воли.

Вайбкодеру на заметку: как не сжечь токены на пустом месте

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

Код работал нормально. А вот агент нет. Жрёт токены как не в себя.

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

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

В этот раз у меня отличился DeepSeek. У Codex'а это тоже привычное занятие. Claude Code на моем опыте работает чуть поумнее.

Что делать? Даю рецепт.

Для долгих задач агент должен работать не как зритель у консоли, а как batch-runner.
🔤Запустил.
🔤Сохранил лог.
🔤Дождался завершения.
🔤Проверил exit code.
🔤На успехе прочитал summary.
🔤На ошибке прочитал только хвост лога.

Держите примерный шаблон промпта:

Работай в low-token batch mode.

Для долгих команд:
- не наблюдай за процессом в реальном времени;
- не используй tee, если вывод будет попадать в твой контекст;
- не читай progress output и промежуточные файлы во время выполнения;
- весь stdout/stderr перенаправь в лог-файл;
- дождись завершения команды;
- проверь exit code;
- если команда завершилась успешно, читай только итоговые summary/config/result-файлы;
- если команда упала, прочитай только последние 100-200 строк лога;
- твоя задача - не мониторинг процесса, а анализ результата после завершения.

✔️ Главное правило: агент должен тратить токены на выводы, а не на просмотр бегущей консоли.

До встречи!
Эдуард Ланчев.
Мой канал в Telegram — Ланчев PRO ИИ. Заходите, если так удобнее.