Все потоки

Сколько я плачу за AI инструменты и как они у меня взаимосвязаны

Claude — мой основной AI инструмент уже как 9 месяцев — Плачу за него 100$

Состоит из Claude Desktop, Claude Code UI и Claude Code CLI

Если хочу работать в приятном UI с текстом → Claude Desktop
Если работаю локально с кодом → Claude Code CLI
Если хочу поправить код с телефона → Claude Code UI

Коротко что все это такое
• Claude Desktop — как чат GPT, но с поддержкой MCP + Skills и еще всякими штуками
• Claude Code — UI для работы с вашим репозиторием
• Claude Code CLI — Command Line Interface Агент. По сути это микс Claude Desktop + Claude Code по функционалу, но без интерфейса и работает внутри вашего компьютера. Мое любимое развлечение последних двух месяцев

Claude Code CLI — пока что самый прокачанный на рынке CLI агентов

———

OpenAI, который chatGPT — за него плачу 20$

• ChatGPT UI — им почти перестал пользоваться, только ради генерации картинок иногда залетаю. Они после недавнего релиза стали их генерировать на уровне с Nano Banana
• Codex UI(Аналог Claude Code) — UI для работы с вашим репозиторием
• Codex CLI (Аналог Claude Code CLI) — чуть менее прокачанный как Command Line Interface, но зато их модель Codex 5.2 Extra-high уделывает OPUS 4.5 в плане UI дизайна и продумывания/рефакторинга сложных вещей

Но в Codex CLI вроде как отсутствует аналог ESC + ESC из Claude Code CLI для откатки написанного кода, без него тяжко жить 🍌

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

Это помогает при работе с кодом, но общаться с ней сложнее

———

Экосистема Google — плачу 8$ за Plus подписку

Google у меня для трёх вещей: картинки через Nano Banana, NotebookLM и Antigravity для просмотра кода. Халява за 8$

• Nano Banana, иногда Veo 3 для генерации картинок / видео — лучшие генераторы картинок / видео на рынке
• NotebookLM — прикольный RAG UI, всем советую потестить
• Antigravity — Fork VS Code по типу Cursor, но с продвинутым Agent Workflow. Есть доступ к Gemini Pro + почему-то Claude моделям. Плюс Antigravity может генерировать картинки сразу вам в код через Nano Banana, такой вот бесшовный воркфлоу

Ни Gemini UI ни Gemini CLI я особо не пользуюсь. Мне они кажутся сильно сырыми по сравнению с Claude Code | GPT

———

Как выглядит мой воркфлоу

Claude Desktop для задач, где мне хочется иметь приятный UI и фичи именно Desktop интерфейса. Например написание постов, создание табличек, графиков и всего такого — те задачи, где CLI сильно проседает по UX

Claude Code UI почти не использую, только когда нужно изменить репозиторий с телефона, например на улице или в поездке

Claude Code CLI — мой day to day tool для работы с кодом. Пишу на Opus 4.5. Для сложных задач прошу создать промпт для Codex.

Antigravity юзаю для просмотра кода и папок, иногда запускаю Gemini 3 pro как третье мнение

Codex, как я уже и говорил, требует особого навыка общения. так как она может думать по 40 минут и перековырять вам весь код, но зато она у меня всегда находит те корнер кейсы, которые не находит ни Opus 4.5 ни Gemini 3 pro. По стилю общения вы будто общаетесь с Сеньёром, который вас презирает, зато резалт пушка

———

Прикольные фишки, которые я постоянно применяю

1. Через Antigravity прошу генерировать изображения со вставкой сразу в код, получается бесшовный воркфлоу Prompt => Generation => Insertion

2. Используй Claude CLI Opus 4.5 для Day to Day задач

3. Используй Codex CLI xhigh для задач на рефакторинг или поиск corner cases, он сильно тщательнее это делает

4. Планируя новую фичу, проси Claude создать локальный MD с планом, а затем Codex xhigh + Gemini 3 pro пусть покритикует этот план и напишет ниже свои комменты

5. Не забывай про кнопку ESC + ESC в Claude Code CLI

6. Claude Code CLI в начале сессии загружает себе CLAUDE.MD, Codex загружает в себя AGENTS.MD, а Gemini — GEMINI.MD.

7. Команда /context покажет контекст текущей сессии, старайся держать его как можно ниже
   Good context engineering means

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

Маск считает, что резюме не главный ориентир. «Не смотрите на резюме — верьте своему впечатлению от общения», — советует Маск. Резюме может быть блестящим, но если спустя 20 минут разговора вау-эффекта от человека нет, стоит доверять разговору, а не бумаге. Маск добавил, что при найме важно обращать внимание на талант, драйв и надёжность. При этом он признал, что раньше недооценивал такое качество, как «доброта». «Хороший ли это человек? Можно ли ему доверять? Умный, талантливый, трудолюбивый? Если да — отраслевые знания можно добавить», — пояснил Маск.

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

Единственный способ заниматься творчеством и создавать хорошие игры, работая в большой компании, — обманывать работодателя. Об этом заявил японский геймдизайнер Кадзутака Кодака (Kazutaka Kodaka), разработавший франшизу Danganronpa.

«Притворяйся, что подчиняешься, но делай то, что хочешь. Используй компанию. Что ж, если что-то пойдет не так, то виноват будет тот, кто тебя нанял, лол»? — Кадзутака Кодака

Стажёр криптобиржи Bithumb случайно сделал 240 человек миллионерами — он по ошибке отправил им биткоины вместо корейских вон.

Клиенты платформы могли купить наборы Random Box, из которых могли выпасть 2000–50000 вон, но случилась небольшая ошибка: когда сотрудники начали рассылку призов, кто‑то случайно изменил воны (KRW за $1,35) на BTC. В итоге из 700 покупателей Random Box 240 открыли их и получили по 2000 ВТС на свои кошельки. Получатели бросились их продавать. Из‑за массового оттока крипты, курс BTC внутри биржи временно улетел на 10% ниже глобальной. Биржа попыталась вернуть всё на место, но счастливчики успели вывести 3 млрд вон.

В результате при распределении эирдропа биткоин на Bithumb просел на 10% относительно других рынков. Bithumb является второй крупнейшей криптобиржей Южной Кореи.

Команда VK WorkSpace проведет вебинар о важных обновлениях Супераппа VK WorkSpace: усиленных настройках безопасности, упрощенной авторизации и о расширенных возможностях работы с сервисами. 

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

Когда: 25 февраля, 16:30 (МСК)
Где: онлайн-трансляция на VK Видео

В программе:

Суперапп VK WorkSpace — единое окно для рабочих коммуникаций

• Как устроено клиентское приложение VK WorkSpace и доступ к сервисам из единого интерфейса.

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

• Упрощенная авторизация, офлайн-доступ и другие обновления.

Спикеры

• Никита Ганевич — менеджер продукта, направление Клиентское приложение.

Зарегистрироваться

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

Рассказываем, на что обращаем внимание при проверке верстки и какие моменты проверяем в первую очередь.

1️⃣ С чего начинаем тестирование верстки?

При тестировании верстки мы сначала наполняем блоки разными текстовыми данными. Это сразу показывает, где интерфейс начинает ломаться. Дальше проверяем:

• максимально короткие значения — точка, пробел;

• максимально длинный текст, который можно ввести;

• соответствие ограничениям из постановки — например, максимально доступно 64 символа.

Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.

2️⃣ Почему проверяем текст с пробелами и без?

Очень частый кейс: текст с пробелами красиво переносится, а без пробелов — вылезает за границы или ломает блок.

Иногда нам кажется, что пользователь так точно не напишет, но ничто не мешает ему назвать кнопку: «дезоксирибонуклеиноваякнопка». Поэтому проверяем с пробелами и без пробелов, а еще смотрим, как ведет себя перенос строк.

Для таких проверок удобно использовать максимально широкие буквы:

• для кириллицы — «Щ»;

• для латиницы — «W».

Это простой способ увидеть помещается ли текст, переносится ли он корректно на следующую строку и не вылезает ли за контейнер.

3️⃣ Что проверяем в макете?

Например, в макете Figma мы смотрим:

И, конечно, отступы между всеми элементами по вертикали и горизонтали.

4️⃣ Как проверяем реализацию?

В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.

Computed удобнее — отображаются итоговые значения после применения всех CSS-правил: размер шрифта, высота строки, цвета, отступы.

Так проще напрямую сравнивать реализацию с макетом и не теряться в длинных CSS-цепочках.

5️⃣ Что важно знать о состояниях элементов?

Чаще всего это кнопки. В DevTools можно вручную включить состояния:

• :hover

• :active

• :focus

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

6️⃣ На что еще обращаем внимание?

Отступы могут быть реализованы через padding (внутренний) и margin (внешний).

Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.

7️⃣ Когда удобно считать руками, а когда — линейкой?

Иногда проще посмотреть padding и margin и сложить их значения. Но если блоки визуально хорошо видны, помогает линейка: измеряем расстояния не только в браузере, но и вообще на экране.

Для текста и иконок лучше ориентироваться на границы блоков и отступы, а не пытаться измерять «на глаз».

При этом в тестировании верстки почти всегда появляется вопрос баланса: где достаточно базовых проверок, а где уже начинается избыточный pixel perfect.

Интересно сравнить подходы: какие проверки верстки вы считаете обязательными в своей практике, а какие — избыточными? 

Почему хороший тестировщик — это не тот, кто нашел больше всего багов

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

На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.

Количество багов ничего не говорит само по себе

Сто найденных дефектов могут означать две совершенно разные вещи:

• продукт реально нестабилен;

• тестирование началось слишком поздно.

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

Сильный тестировщик думает раньше, чем тестирует

Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.

• что здесь может пойти не так;

• где система уже ломалась;

• какие изменения самые рискованные.

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

Баг-репорт — это не обвинение

Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.

Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:

• понятно, что сломалось;

• понятно, как воспроизвести;

• понятно, почему это важно.

Чем меньше эмоций и больше контекста — тем лучше работает процесс.

Автотесты — это не самоцель

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

Хороший тестировщик задает другие вопросы:

• ловят ли эти тесты реальные проблемы;

• можно ли им доверять;

• не мешают ли они менять код.

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

Хороший тестировщик думает о пользователе, а не о сценарии

Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.

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

Качество — это ответственность всей команды

Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.

Сильный тестировщик не берет качество на себя полностью. Он помогает команде видеть риски, объясняет последствия и участвует в решениях. Но ответственность остается общей.

Карьерный рост в тестировании — это не про инструменты

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

Гораздо важнее:

• умение анализировать систему;

• понимание, где искать проблемы;

• способность говорить с разработчиками и бизнесом на одном языке.

Именно это делает тестировщика ценным, а не список технологий в резюме.

В итоге

Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:

• помогает находить проблемы раньше;

• думает о рисках, а не о галочках;

• пишет понятные баг-репорты;

• работает с командой, а не против нее.

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

Сразу оговорюсь, это пост- реклама.

Написал Telegram бота для знакомств (поиск собутыльника). Пользователь отправляет свою геопозицию (широту и долготу), а боту нужно предложить людей, живущих рядом.
Нашел на просторах интернета HTTP Геокодер от Яндекса. Что-то около 25000 запросов в месяц бесплатно. Ты отправляешь запрос с широтой и долготой, а сервис тебе населенный пункт (район, улица и т.д.).
Ссылка на сервис:
https://yandex.ru/maps-api/products/geocoder-api
Подключить его не сложно (документация хорошая).

Приведу пример запроса:

PARAMS = {
        "apikey":"ваш api key",
        "format":"json",
        "lang":"ru_RU",
        "kind":"locality",
        "geocode": "долгота, широта"
    }

    #отправляем запрос по адресу геокодера.
    try:
        r = requests.get(url="https://geocode-maps.yandex.ru/1.x/", params=PARAMS)
        #получаем данные
        json_data = r.json()
        #вытаскиваем из всего пришедшего json именно строку с полным адресом.
        address_str = json_data["response"]["GeoObjectCollection"]["featureMember"][0]["GeoObject"]["metaDataProperty"]["GeocoderMetaData"]["AddressDetails"]["Country"]["AddressLine"]
        #возвращаем полученный адрес
        return address_str
    except Exception as e:
        logger2.error(e, exc_info=True)
        #если не смогли, то возвращаем ошибку
        return "error"

Поменяйте только ваш apikey и широту с долготой. Запрос вернет населенный пункт по заданным данным (долгота и широта).

Ссылка на моего бота:
http://t.me/drinking_buddy_2025_bot

Спасибо за внимание

🎓 Бесплатные онлайн-курсы для IT-специалистов от Selectel

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

Системный администратор Linux с нуля. Научитесь работать с командной строкой и основными утилитами Linux, управлять пользователями и файлами, настраивать сети и устранять инциденты. 

Погружение в PostgreSQL. Изучите основы реляционных баз данных. Научитесь создавать и связывать таблицы, добавлять, модифицировать и удалять данные.

Первые шаги в JavaScript. Освоите базовый синтаксис, научитесь писать скрипты, управлять DOM и изменять интерфейс веб-страниц. В конце сделаете свой первый пет-проект.

Тестирование мобильных приложений. Научитесь проверять мобильные приложения с учетом специфики разных платформ. Освойте работу с API, логами и трафиком на эмуляторах и реальных устройствах.

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

Однокоренные слова, но...

Класс защиты и класс защищенности – это не одно и то же. Более того, ранжирование у них идёт в разных направлениях. Они лишь звучат похоже.

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

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

МВД требует от информационной системы подтверждения соответствия по шкале класса защищенности на уровне их ГИСа – это К1. При этом обмен данными в СМЭВ идёт по защищенной сети, участники которой используют криптосредства класса защиты КС3.

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

Так в чём разница?

Я объясню сильно по-простому и естественно это будет грубым объяснением, но достаточным для понимания различий. Данный пост написан для менеджеров, а не специалистов по информационной безопасности.

Класс защищенности (К1 > К2 > К3) – это шкала, которая применяется к государственным информационным системам (ГИСам). Чем выше число в обозначении, тем слабее. Данный класс относится ко всей информационной системе целиком (процессы, меры, средства защиты информации, сегментация, доступы, аудит, уязвимости, контроль, аттестацию и т.д.).

Определена эта шкала приказом ФСТЭК РФ от 11 апреля 2025 г. N 117 (вступает в силу с 01.03.2026 г.). Цитирую:

Самый низкий класс - третий, самый высокий - первый. Класс защищенности информационной системы (первый класс (далее - К1), второй класс (далее - К2), третий класс (далее - К3)) - определяется в зависимости от уровня значимости информации (далее - УЗ), обрабатываемой в этой информационной системе, и масштаба информационной системы.

Класс защиты (КС1 < КС2 < КС3 < КВ1 < КВ2 < КА) – это классы средств криптографической защиты информации (СКЗИ) – то есть стойкость к атаке и условия применения конкретной криптозащиты (VPN, криптошлюз, криптопровайдер, шифрование канала и т.п.), а не про защищенность всей информационной системы. И тут наоборот: чем больше цифра, тем сильнее.

Градируется класс защиты по модели атак приказами ФСБ РФ от 18 марта 2025 г. N 117 и от 27 декабря 2011 г. N 796:

• КС1 – базовый класс: атаки вне контролируемой зоны, то есть нарушитель не имеет доступа в помещение, где размещены СКЗИ;

• КС2 – сильнее: атаки в пределах контролируемой зоны, но без физического доступа к СКЗИ;

• КС3 – еще сильнее: атаки в пределах контролируемой зоны с физическим доступом нарушителя к СКЗИ;

• КВ – более высокий класс: высококвалифицированный нарушитель использующий недокументированные возможности ПО;

• КА – наивысший класс: высококвалифицированный нарушитель использующий недокументированные возможности как ПО, так и железа.

P.S.: Наличие или отсутствие циферки у "КВ" и "КА" зависит от конкретного документа и упоминаемых в них СКЗИ.

Как запомнить и не перепутать?

Средства криптозащиты это лишь часть информационной системы, тогда как второе более широкое понятие. И чтобы не запутаться, проще всего запомнить разницу по длине слова: "защита" – короткое слово, значит, узкая тематика, относящаяся к классификации СКЗИ, "защищенность" – длинное слово, то есть более широкое понятие, относящееся к классификации информационных систем.

– – –

С вами был Неминущий Никита, ведущий инженер‑программист финансового маркетплейса «Выберу.ру»

На глаза попалась интересная статистика, решил поделиться.

4% всех коммитов на GitHub теперь делает Claude Code, интересно посчитать сколько делается еще другими агентами тоже. При сохранении текущей траектории к концу 2026 года доля коммитов, написанных агентами, может вырасти до 20%. 

🎬 Видео с новогоднего CTF по мультиагентным системам

🎯 Что внутри:
Разбираем создание и применение AI-агентов для узких задач + настройку взаимодействия между ними

📊 Детали:
Автор: Андрей Чуян @Andrey_Chuyan
Направление: AI-инжиниринг
Сложность: 4/10
Формат: CTF (Capture The Flag)

🔗 Где смотреть:
VK - https://vk.com/video-232485571_456239027
YouTube - https://youtu.be/kVnOxzG0zEM?si=SFvBpDGOlMxrEdsf

💬 Есть вопросы?
Обсуждаем в чате → https://t.me/DebugSkills_chat

Коллеги, 03.02.2026, три дня назад я провёл вебинар, посвящённый полиглотности СУБД - умению работать с диалектами PostgreSQL, Oracle и Microsoft в контексте импортозамещения.

Меня зовут Жуйков Андрей, и если будет время - буду рад, если посмотрите запись 👀

«Импортозамещение СУБД по-новому: интеллектуальный подход к замене MS SQL и Oracle»

🔹 Установка и первый запуск Digital Q.DataBase
• развёртывание Digital Q.DataBase в Docker-контейнере
• установка и настройка Digital Q.DataBase на Ubuntu 24.04
• архитектура, ключевые преимущества и типовые сценарии использования в российских компаниях

🔹 Новые возможности Digital Q.DataBase для импортозамещения
• инструменты, упрощающие миграцию с MS SQL и Oracle
• как сократить риски и сроки перехода без переписывания приложений

🔹 Практика внедрения и реальные кейсы
• Владимир Авсеев показал, как система «Босс-Кадровик», изначально заточенная под MS SQL, успешно работает на Digital Q.DataBase
• Анастасия Коршунова (отдел разработки) продемонстрировала примеры успешной интеграции Digital Q.DataBase с 1С и Delphi-приложениями

🔹 Ответы на вопросы
• практические нюансы миграции и эксплуатации
• ответы на вопросы из реальных проектов от разработчиков Digital Q.DataBase и команды «Босс-Кадровик»

📎 Полезные ссылки
🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase

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

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

🗓 Вебинар «Здоровье систем 1С: проблемы и решения для высоконагруженных корпоративных систем»

Какие проблемы возникают при эксплуатации «1С» и как быстро их распознать? В чем заключается «первая помощь» для поддержки системы? Как выстроить мониторинг и адресную оптимизацию в высоконагруженных режимах — и заранее выявлять будущие риски? Расскажем на бесплатном вебинаре!

⏱ 12 февраля, 10:00 (мск)

Эксперты:

👩🏻‍💻 Ирина Киняева — руководитель группы 

👨🏻‍💻 Евгений Филиппов — эксперт 

👩🏻‍💻 Елена Маламут — руководитель проектов 

Регистрируйтесь, приходите сами и зовите коллег.

Как выбрать лучшую LLM модель для задачи за 15 минут

Сразу определим, что лучшая модель это не GPT-4 и не Claude, а та которая решает вашу конкретную задачу за минимальные деньги.

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

Решил поделиться простым способом как выбрать подходящую модель быстро и с конкретными метриками.
В этом примере выбираем LLM модель для использования в ИИ-агенте с RAG. У вас же может быть любая другая задача:

Вот как это сделать за 15 минут вместо часов тестов.

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

Шаг 2. Зайдите на сайт LangSmith и зарегистрируйтесь там. Это бесплатно.

Шаг 3. Перейдите в раздел Datasets (датасеты) в меню слева.

Шаг 4. Загрузите свой датасет, это та самая табличка с вопросами и ответами. Нажмите кнопку New Dataset, выберите файл, всё.

Шаг 5. Нажмите кнопку experiment и выберите Playground. Там добавьте все модели которые хотите сравнить. Я беру API OpenRouter, там все нужные модели есть в одном месте, не надо регистрироваться в десяти разных сервисах.

Шаг 6. Нажмите кнопку Start (запустить) и подождите минуту две. Система сама прогонит все ваши вопросы через все модели.

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

Весь эксперимент займет минут 15-20 чтобы понять какую модель использовать в продакшене, сколько это будет стоить, и какие косяки могут быть.
Без этого пришлось бы тестировать вручную, слить денег на API разных моделей, и в итоге все равно выбрать наугад.

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

Все файлы для эксперимента https://disk.yandex.ru/d/U_je7alkJxivZw

ТГ канал

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

Яндекс.Музыка заблокировала доступ к сервису на уровне аккаунта. Уже 3 месяца поддержка “разбирается”

С ноября у меня полностью заблокирован доступ к Яндекс.Музыке на уровне аккаунта (bearded-rocker@yandex.ru). Не отдельный девайс, не браузер, не приложение — аккаунт целиком.

TL;DR

• Я использую официальный API Яндекс.Музыки

• В какой-то момент доступ к Яндекс.Музыке для моего аккаунта был молча заблокирован

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

• Смена токенов, переустановка приложений, другие устройства — не помогает

• В поддержке заведены тикеты ещё с ноября

• Прошло больше 4 месяцев — доступа нет, решения нет

Предыстория

Осенью я начал пользоваться Яндекс.Музыкой и колонкой с Алисой. Чтобы не терять годы истории из Spotify, я написал небольшой сервис, который синхронизирует мои плейлисты и треки через неофициальный API Яндекс.Сервис какое-то время нормально работал, после чего доступ к Яндекс.Музыке для моего аккаунта внезапно пропал полностью.

Симптомы выглядят так:

• Яндекс.Музыка не работает нигде:— веб— iOS / Android— устройства с Алисой

• Это не связано с VPN, IP или устройством

• Это не выглядит как клиентская ошибка

• Это выглядит как account-level блокировка внутри сервиса

• в Браузере получаю ответ (в dev tools):

{ "name": "forbidden", "message": "403 Forbidden: "{"name":"API access restricted","message":""}"", "requestId": "99f13438-a1c9-43a7-9d7d-7de00bd3ea49.1"}

Я сразу обратился в поддержку Яндекс.Музыки. После стандартных проверок они подтвердили, что проблема не на моей стороне, и завели тикет “на инженеров”.

На сегодняшний день:

• есть два тикета, заведённых ещё в ноябре: 25103113405032668, 25121613434183682

• каждый новый оператор начинает диалог заново

• снова предлагается “обновить браузер / переустановить приложение”

• затем снова: «да, мы видим проблему, инженеры занимаются»

Я не прошу ничего экстраординарного:

• Восстановить доступ к Яндекс.Музыке для моего аккаунта bearded-rocker@yandex.ru, я плачу за Plus, Алису-Pro и хочу пользоваться этими сервисами.

Сейчас же ситуация выглядит так:

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

• тикеты “живы”, но без движения

• сроков, статуса и ответственного нет

@yandex please help 🙏

Снял видео про один из способов применения расширения "Рабочий стол" - дашборды рисовать. Лично для меня, как пользователя, это главный способ применения рабочих столов. Эдакий дешманский BI, с очень быстрой настройкой и перенастройкой.

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

Правда, дашборды типа "отчёт" (о которых речь в видео) - не самое эффектное представление данных, есть ещё диаграммы. Но про них я отдельное видео сниму.

А пока вот:

https://vkvideo.ru/video-208482299_456239491
https://youtu.be/1rln84eMBwc

Расширение можно скачать тут - https://t.me/another1C/48

Основатель Binance написал, что «снова стал бедным». В прошлый раз он писал это, когда биткоин упал с примерно $67 тысяч до около $30 тысяч.

Тем временем биткоин обвалился на 54% относительно своего октябрьского пика 2025 года. Сегодня биткоин рухнул сразу на 14% за сутки. Аналитики Stifel прогнозируют обвал биткоина до $38 тыс.

Кто-нибудь хочет вместе поразбираться с тем, как нынче принято делать агентов в проде? С понедельника хочу плотненько засесть за "Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems".

План-капкан:
• Читаем по главе в день;
• Каждый день в 15:00 по Лондону собираемся на звонок для обсуждения;
• На каждый звонок будет презентация с обзором ключевых моментов главы (или каким-то доп контекстом);
• Звонки записываются, чтобы можно было догнать группу, если бес попутал пропустили;
• К концу феварля дочитываем всю книжку.

Если план звучит как-то знакомо, то это потому что мы уже читаем по похожей схеме "The Ultra-Scale Playbook". Правда, в более расслабленном режиме с созвоноами раз в неделю. Две книги лучше чем одна, верно?

Инвайт в чатик с анонсами (eng-speaking) и в дискорд (вдруг так получится привлечь больше людей за пределами русскоговорящего коммьюнити?). Анонсы буду кросс-постить и туда, и туда.

Маркетологи еще раз переименовали 14,4-вольтовые аккумуляторы. Теперь в 18 В

Сначала маркетологи сделали из стандартных 18-вольтовых аккумуляторов 20 и 21-вольтовые, поменяв лишь название. Потом по цепочке добрались до аккумуляторов 10,8 В, превратив их в 12 В. Следом 14,4 В обозвали 16 В.

А теперь – ход конем. Из 14,4-вольтовых, переименованных ранее в 16 В, сделали 18 В, заменив лишь цифру на наклейке.

А какое напряжение правильное?

Аккумуляторы для электроинструмента состоят из набора литий-ионных элементов формфактора 18650 (реже 21700). Для каждой модели производители указывают спецификации, включая рабочие напряжения. Для абсолютного большинства аккумуляторов полностью заряженным считается элемент с напряжением 4,2 В. Полностью разряженным – 2,8 В.

Напряжение 3,6 В является средним в этом диапазоне и по нему можно посчитать емкость в ватт-часах. В современных аккумуляторах производители вместо 3,6 В чаще указывают 3,7 В.

Если взять три элемента в ряд по 3,6 В, их напряжение будет 10,8 В.

Берем четыре элемента – получаем 14,4 В.

Пять элементов – ровно 18 В.

Откуда взялись 20, 21 В и прочие?

Кто-то из маркетологов внезапно узнал про максимальное напряжение элементов в 4,2 В вместо регламентных 3,6 В. Умножил его на 5 и получил 21 В. Далее решил переименовать свои 18-вольтовые аккумуляторы в 21-вольтовые, чтобы умыть конкурентов. У конкурентов тоже есть маркетологи. Те смекнули, что объяснить что-то покупателям – сложно и дорого. Проще тоже переклеить наклейки. И понеслось.

В чем сейчас проблема?

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

Впрочем, уже начали. Rddspon прощупывает рынок.

 Вот, как-то так.

Оказалось, что многие не в курсе этого. И в комментариях в моем телеграм-канале практически каждый день спрашивают, какие аккумуляторы лучше – 20V или 21V и подойдут ли? Перешлите это тем, кто путается.

…ну а клеить на 14,4-вольтовые аккумуляторы наклейки 18V – это уже чистое мошенничество.

P.S. последние тесты аккумуляторов формфактора Makita LXT 18V выложил вот тут.

Где учиться системному администрированию?

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

А сегодня мы собрали подборку курсов для системных администраторов — посмотрите, вдруг пригодится:

— Powershell. Автоматизация и удалённое управления Windows-системами через скрипты и командную строку.

— Ansible. Централизованная настройка и поддержка серверов.

— Terraform. Создание инфраструктуры и управление ей.

— Prometheus. Мониторинг и анализ метрик сервера.

— DHCP. Автоматическое назначение IP-адреса и сетевых настроек вашим устройствам.

→ Целая библиотека знаний от проверенных школ

Российская РЕД ОС для защищенных облачных сред в Рег.облаке

В облачной инфраструктуре Рег.облака появилась российская операционная система РЕД ОС, включая сертифицированные редакции для регламентированных IT-сред. Клиенты Рег.облака могут запускать облачные серверы на отечественной ОС, уже соответствующей требованиям регуляторов, без самостоятельной настройки и сертификации защищенного контура.

Пользователям доступны четыре редакции РЕД ОС: версии 7.3 и 8 — в стандартном и сертифицированном исполнении. Сертифицированная редакция соответствует требованиям ФСТЭК России по безопасности информации и профилю защиты ИТ.ОС.А4.П3, что позволяет применять ее в защищенных контурах.

Доступность РЕД ОС в облаке упрощает переход на импортонезависимую инфраструктуру и помогает быстрее запускать защищенные среды — без необходимости самос��оятельно собирать и сертифицировать программный стек.

Подробнее о редакциях РЕД ОС и возможностях развертывания в облаке — на сайте.

Не всё так солнечно в пиренейском королевстве…

Казалось, бы, Испания. Солнца – море! Должна бы солнечная энергетика развиваться бешенными темпами, но нет. Испанский союз фотовольтаики (UNEF) сообщает, что рост установок солнечных электростанций «для самопотребления» (то есть не больших коммерческих) в 2025 году замедлился по отношению к 2024.

Вызвано это причинами, которые понятны и нам:

• невозможность продавать в сеть излишки более 15кВт и, соответственно, бюрократические препоны;

• отмена налоговых льгот на установку СЭС;

• небольшое, но удешевление стоимости электроэнергии «из розетки» (???)

 И таким образом, в прошлом году было установлено 1,14ГВт против 1,18ГВт в 2024 году. Разница – 3,7%, но, если замедление продолжится, то, говорят в UNEF, Испания не достигнет целей Национального энергетического и климатического плана (PNIEC) по установке в стране 19ГВт СЭС для самопотребления к 2030 году.

С другой стороны – мы же помним, что знаменитый «Пиренейский блэкаут» некоторые связывают именно с солнечными станциями. Промышленными, но тем не менее. Так что, как говорится, палка о двух концах. Как решить эту задачу? Правильно – ставить накопители. Они сейчас стремительно дешевеют и развиваются. И в PNIEC и для них есть место.

 @solarnews в телеграме

#Испания #планы #СЭС #аналитика

Большинство решений в мире принимают люди. Или нет?

В новом выпуске ПВЗ обсуждаем квантовые компьютеры и задачи, в которых они эффективны.

^{ПВЗ — Почти Всё Знают — наш подкаст о технологиях, которые проникают во все сферы жизни. Его ведут эксперты Ozon Tech: Марина Самойлова, руководитель направления платформы данных, и Виктор Корейша, руководитель направления Managed Services.}

Гость эпизода — Алексей Фёдоров, руководитель научной группы Российского квантового центра. Алексей поделился, над какими квантовыми технологиями работают учёные сейчас. Рассказал, как правильно интерпретировать и верифицировать результаты квантовых вычислений.

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

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

1. Стандартные настройки прошивки мештастика указывают, что PIN-кодом / паролем сопряжения для bluetooth является 123456. Его можно сменить, но … только на другие 6 цифр. Буквенно-цифровой или цифровой на иное количество символов вы поменять не можете: только цифровой пароль от 100000 до 999999, то есть всего 899999 комбинаций, что в современных реалиях подберется достаточно быстро. А если принять во внимание, что простые обыватели его практически никогда не меняют (чтобы не забыть), то дальнейшие действия, я думаю, описывать нет смысла.

2. Часть владельцев используют мештастик не как передвижную точку доступа (например, LILYGO T-Deck), а как стационарное домашнее решение: ставят оборудование не подоконник и “раздают хопы”. В данном случае связь по синему зубу не всегда подходящая, так как если вы уйдете в другую комнату, соединение разорвется.
   И тут на помощь приходит Wi-Fi: быстрый, надежный, стабильный. Кроме того, установив где-нибудь на локальном сервере/компьютере веб-клиент
   docker run -d -p 8080:8080 --restart always --name Meshtastic-Web ghcr.io/meshtastic/web
   вы сможете подключаться к нему не только с телефона, но и с любого устройства, где есть браузер, в том числе с вашего старичка QTEC 9100, например.

Но тут-то и кроется дьявол: подключение к мештастику !НЕ ТРЕБУЕТ! аутентификации. Вы просто вводите в качестве адреса подключения IP-адрес или просто meshtastic.local, и соединение с устройством устанавливается: читаем чаты, меняем настройки и т.д.
Продолжая тему безрассудности, представьте владельца устройства, который перенаправил порты на своем роутере напрямую в мештастик, чтобы находясь на работе он мог почитать “домашнюю” переписку. То что при указанных выше обстоятельствах это не самая лучшая идея я думаю объяснять не приходится.

Что в таком случае можно сделать далее? Правильно: идем на поисковики по IoT, такие как shodan или censys. Я предпочитаю последний и, в качестве поиска, указываю следующее:

host.services.endpoints.http.body:"Web server is running. The content you are looking for can't be found. Please see: FAQ"

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

В данном случае агрегатор мне выдал 17 IP-адресов и соответствующие порты к ним, где встречается данная комбинация: США 🇺🇸 - 7, и по одному для Испании🇪🇸, Португании🇵🇹, Чехии🇨🇿, Румынии🇷🇴, Тайваня🇹🇼, Украины🇺🇦, Венгрии🇭🇺, Италии🇮🇹, Сербии🇷🇸 и Франции🇫🇷. Российских 🇷🇺 адресов среди этого списка утечек нет.
Ну а дальше идем в наш локальный веб-клиент и вводим понравившийся IP-адрес и порт.

Если честно, я немного замешательстве: как в 2026 году, при всех ИИ-помощниках и кучах библиотек, разработчики не внедрили простую форму логина и пароля с обязательной сменой последнего при первом запуске?
В общем, подводя итог, если вы “счастливый” обладатель мештастика, срочно меняйте на нем bluetooth пароль и не выпускайте его за пределы периметра.

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

Как применять аналитические техники в реальных проектах

Привет, Хабр! С вами Диана, системный аналитик в АШАН ТЕХ. В прошлых постах я писала о том, как училась системному анализу, готовилась к собеседованиям и не выгорела в процессе.
Но после выхода на реальную работу возникает другой вопрос: как применять все эти знания не в учебном кейсе, а в живом проекте?

Короткий ответ — не так аккуратно, как в обучении.

Чем работа отличается от обучения

В обучении почти всегда есть понятное задание и ожидаемый результат.
В реальной работе даже при наличии бизнес-требований (БТ) всё может быть иначе: документ устарел, написан под старую логику или не отражает реальные пользовательские сценарии.

Поэтому аналитик чаще работает не «по документу», а с проблемой, которую ещё нужно правильно сформулировать.

С чего на самом деле начинается задача аналитика

Задача редко приходит в идеальном виде.

Обычно есть БТ, которое:

• требует актуализации;

• противоречит текущей логике системы;

• не учитывает ограничения или реальные сценарии.

Иногда аналитик сначала формулирует требования буквально для себя, чтобы разобраться, в чём вообще задача.

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

Как я структурирую хаос

Когда информации много, а ясности мало, я делаю довольно простые вещи:

• фиксирую всё, что уже известно;

• выписываю вопросы и противоречия;

• уточняю цель и ограничения;

• формулирую рабочую версию требований.

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

Правила, которые мне сильно помогли на онбординге

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

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

Ко всему нужно относиться критично. Даже если требование звучит логично, полезно задать вопрос: а зачем это? какую проблему решаем? что будет, если ничего не менять?

Всегда думать про альтернативные сценарии. Что пойдёт не так? А если пользователь сделает иначе? А если данные придут не в том виде? Эти вопросы часто экономят команде время на доработках.

Формирование ТЗ: «бизнес сказал» и «разработчик знает» — плохая основа

Сделать хорошее техническое задание (ТЗ), общаясь только с заказчиком, сложно.
 Но и ожидать «того самого разработчика, который всё знает», — плохая стратегия.

Такой подход:

• увеличивает время на задачу;,

• создаёт бутылочное горлышко;

• концентрирует знания в одной голове.

Гораздо эффективнее вовлекать разработчиков ещё на этапе формирования ТЗ.

Итог

Аналитика — это не шаблоны и диаграммы.

Это умение уточнять и структурировать, работать с бизнесом и командой, видеть риски и альтернативные сценарии, аргументировано защищать решения.

P.S.

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

Привет, коллеги-гоминиды!

Вышел я тут на рынок и понял: естественный отбор сломался, несите новый.

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

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

Недавно прилетел отказ с благодарностью за тестовое от DataLouna, которое я им не делал (принципиально не делаю уже довольно давно), да еще и с фидбеком для разработчика. Просто тряпка бреда от ChatGPT. То есть там просто лужа воды размером с А4 в духе: “Нам нужны разработчики которые могут проявлять инициативность в проектировании архитектурных решений, бла-бла-бла”. Может кого-то уберегу от потери времени, а может и нет.

Яндекс швырнул в меня тестовым даже не пообщавшись, спасибо-пожалуста, но нет.

На созвонах вообще палеолит. HR-ы часто читают миссию компании прямо с экрана, даже не открыв моё портфолио. Девоньки, милые, я хочу работу работать,  быстро рассказать о себе, кто такой, чего могу, и выяснить:  из каких этапов состоит отбор, когда планируется закрыть вакансию, что стало с предыдущим дизайнером, если он был. Чтобы уже на техсобесе узнать какие есть вызовы и возможности для моего роста, а не слушать однотипные мифы и легенды во время HR-скрининга по 10-15 минут. Я перед созвоном всегда изучаю компанию, и всё что мне надо знать — поверхностно уже знаю. Почти всегда приходится мягко прерывать и просить перейти ближе к сути.

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

Тем не менее есть и хорошие примеры, понравился процесс найма в Т-Банке например. Там все процессы налажены, без пафоса и корпоративной надменности. Прошёл техсобес, и как сказали вайтборд тоже прошёл, просто команды под меня сейчас нет. Но я знаю, что вайтборд откровенно завалил, и выступил отвратительно из-за отсутствия практики. Поэтому soft-reset вполне закономерен, тут всё по делу. Когда попросил фидбек — дали довольно быстро, без нейросетевых простыней, и подтвердили мои гипотезы о том, где я ошибся. Ничего, вернусь сильнее.

А у вас как? Часто встречаете HR-ов, которые путают виды и классы, или мне одному так везет? Делитесь своими самыми дикими случаями.

Ссылки на телегу и выпрашивания плюсиков не будет, тут просто истории из жизни и байт на комменты 🤓

Вебинар: Сертифицированная редакция РЕД ОС 8: компоненты, архитектуры, СЗИ

18 февраля в 11:00 (МСК) состоится вебинар, посвященный детальному разбору Сертифицированной редакции РЕД ОС 8.

Спикер — Денис Солоничкин, директор центра компетенций РЕД СОФТ — представит ключевые аспекты:

● Обзор Сертифицированной редакции РЕД ОС 8: соответствие требованиям законодательства, сертифицированные компоненты и поддерживаемые процессоры.

● Встрое��ные средства защиты информации РЕД ОС 8.

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

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

● Порядок лицензирования и обновление с версии 7.3

Вебинар будет полезен ИТ-директорам, руководителям ИТ-подразделений, специалистам по информационной безопасности, системным администраторам.

Регистрация

Международный доклад 2026 года о безопасности ИИ - перевод на русский язык

Второе издание доклада возглавляет лауреат премии Тьюринга Йошуа Бенджио. В его подготовке участвовали более 100 международных экспертов при поддержке консультативного совета, в который вошли представители более 30 стран и международных организаций, включая ЕС, ОЭСР и ООН. Результаты доклада будут обсуждаться на саммите по влиянию ИИ, который пройдёт в Индии в конце месяца.Основные выводы доклада:

• Быстрый рост возможностей ИИ. Системы общего назначения демонстрируют стремительное улучшение, особенно в математике, программировании и автономных операциях. В 2025 году ведущие ИИ-системы получили золотые медали на Международных математических олимпиадах, превзошли результаты специалистов с учёной степенью PhD в научных тестах и смогли самостоятельно решать отдельные инженерные задачи, требующие от человека-программиста нескольких часов. Однако их эффективность остаётся «неровной» — системы по-прежнему проваливаются на простых заданиях.

• Неравномерное, но быстрое распространение ИИ. Технология внедряется быстрее, чем персональные компьютеры: более 700 млн человек еженедельно пользуются передовыми ИИ-системами. В некоторых странах — более половины населения, но в большой части Африки, Азии и Латинской Америки уровень использования остаётся ниже 10%.

• Рост числа инцидентов с дипфейками. Поддельные материалы, созданные ИИ, всё чаще применяются для мошенничества. Особенно растёт распространение несогласованных интимных изображений, непропорционально затрагивающих женщин и девочек. Согласно исследованию, 19 из 20 популярных приложений «nudify» имитируют раздевание женщин.

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

• Использование ИИ в кибератаках. Злоумышленники всё активнее применяют ИИ общего назначения для генерации вредоносного кода и поиска уязвимостей. В 2025 году ИИ-агент вошёл в топ-5% лучших участников крупного соревнования по кибербезопасности. На теневых рынках появились готовые ИИ-инструменты, снижающие требования к техническим навыкам для атак.

• Меры безопасности улучшаются, но остаются несовершенными. Хотя частота «галлюцинаций» снизилась, некоторые модели научились различать тестовые и реальные сценарии, адаптируя поведение — это создаёт новые сложности для оценки и сертификации безопасности.

Йошуа Бенджио, профессор Монреальского университета, научный директор LawZero и научный советник института Mila, отметил:«С момента публикации первого доклада мы наблюдаем значительный рост как возможностей моделей, так и их рисков. Разрыв между скоростью технологического прогресса и нашей способностью внедрять эффективные меры защиты остаётся серьёзной проблемой. Цель доклада — предоставить политикам надёжную научную базу для направленного, безопасного и полезного развития ИИ для всех».

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

Транскрибатор встреч с ИИ-ассистентом. И Самые популярные локальные модели Speech-to-Text

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

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

Проблема есть, а решение навайбкодил себе.
Агент записывает все встречи, транскрибирует локально, потом делает саммари через DeepSeek (тоже локально крутится). После этого автоматом присылает саммари в Telegram, и на почту, если нужно забивает задачи в Jira и сохраняет всё в память.
Теперь пишу агенту: "Что обсуждали с Ивановым?" он сразу отвечает. Или "Какие задачи взял Петров?" находит и выдаёт.

Архитектура чуть глубже: там сохранение, индексация, поиск и т.д. На выходных как-нибудь напишу как строить deep knowledge base agent.

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

Что за модели, и когда какую использовать

🔹 GigaAM-v3 (https://huggingface.co/ai-sage/GigaAM-v3?utm_source=chatgpt.com) – Если у вас русскоязычные без техничских терминов встречи, разговорная речь, шум, разные микрофоны, и хочется качество ближе к “топу”, это один из первых кандидатов для теста. Хорош для батча, для “встречи и заметки”.

🔹 NVIDIA NeMo stt_ru_fastconformer_hybrid_large_pc (https://huggingface.co/nvidia/stt_ru_fastconformer_hybrid_large_pc) – Когда важна скорость и стабильность, и хотите быстро прогнать много часов встреч локально. В общем я использовал для КЦ чтобы прогнать 80-90 часов бесед

🔹NVIDIA Canary-1b-v2 (https://huggingface.co/nvidia/canary-1b-v2)– Когда на встречах мешаются языки, английские термины, и нужен мультиязычный вариант.

🔹 Voxtral Mini 3B (Mistral AI) (https://huggingface.co/mistralai/Voxtral-Mini-3B-2507) – Когда нужен не только транскрипт, но и понимание аудио, вопросы-ответы по встрече, умные итоги. Можно просить сразу саммари на выходе. Есть 2 модели.

🔹 Vosk (https://github.com/alphacep/vosk-api) – Когда нужно супер-легко и офлайн, без тяжелого стека, качество “достаточно”, и быстро поднять.

🔹 whisper.cpp (https://github.com/ggml-org/whisper.cpp) – Если вы будете запускать на ноуте без Python, на CPU, и легко встроить в приложение. (Я кстати использую его)

🔹 WhisperX (https://github.com/m-bain/whisperX)– А это уже более сложный вариант и уже практически упакованный для встреч: таймкоды по словам, иногда спикеры, и потом проще искать, где что сказали. Это обвязка вокруг Whisper, а не отдельная модель.

Дополнительные инструменты:

⚡️ Silero VAD (https://github.com/snakers4/silero-vad)– Это “детектор речи”. Он режет тишину и паузы, ускоряет pапись на длинных встречах, и часто повышает качество, потому что модель меньше путается на тишине.

⚡️ pyannote.audio (https://github.com/pyannote/pyannote-audio) – Если вам важно делить дорожки по спикерам и различать “кто, и когда говорил”, то есть диаризация. Если на встрече больше 3 человек это must-have.

Еще оставлю вам ссылку где собраны все модели: удобно тестировать https://istupakov-onnx-asr.hf.space/.

Межведомственная комиссия (МВК) по 115-ФЗ: как подать жалобу на банк или Банк России?

Межведомственная комиссия (МВК) — это второй уровень реабилитации, куда можно обратиться, если не удалось решить вопрос напрямую с банком или Банком России.

Важное правило: без прохождения первого уровня (см. посты 1 и 2) ваше заявление в МВК не примут.

Что МВК рассматривает? (Основные случаи):

1. Отказ банка в открытии счета или операции (если банк сам оставил свой отказ в силе).
2. Применение банком жестких мер (блокировка операций по п.5 ст.7.7 115-ФЗ). Это обязательный досудебный этап!
3. Отказ Банка России изменить высокий уровень риска.

Что МВК НЕ рассматривает?

Обжалованию в МВК не подлежат:

⦁ Ограничение дистанционного банковского обслуживания (интернет-банка) и блокирование банковской карты.
⦁ Отказ в выпуске или перевыпуске банковской карты.
⦁ Расторжение договора банковского счета по инициативе банка (в случае двух и более отказов в проведении операции в течение года по п. 11 ст. 7 закона № 115-ФЗ).
⦁ Длительное рассмотрение банком заявления о расторжении договора банковского счета.
⦁ Взимаемые банком комиссии и его тарифная политика.
⦁ Решения об отказе от заключения договора банковского счета (вклада) или проведения операции, принятые не по основаниям пунктов 5.2 и 11 статьи 7 закона № 115-ФЗ.
⦁ Решение об отказе в предоставлении кредита.
⦁ Отнесение Банком России клиента к группе средней степени риска.
⦁ Решения об отказе, принятые на основании пунктов 2 и 8 статьи 7.2 закона № 115-ФЗ.
⦁ Решения уполномоченных органов (например, Росфинмониторинга) о приостановлении операций.

Как подать заявление в МВК?

Заявление подается через Банк России одним из способов:
1. Через интернет-приемную ЦБ (выбрать тему «Обращение в МВК»).
2. По почте или лично в экспедицию Банка России в Москве.

Требования к заявлению:

⦁ Должно строго соответствовать Положению Банка России № 842-П.
⦁ Нужно приложить огромный пакет документов (по разным приложениям к Положению 842-П в зависимости от случая): полные данные о компании, финансовая и налоговая отчетность, сведения о контрагентах, копии всех предыдущих обращений и отказов.
⦁ Срок рассмотрения МВК: не более 20 рабочих дней + еще 3 дня на уведомление вас о решении.

Что дальше?

Решение МВК можно обжаловать в суде. Если вы одновременно подадите и в МВК, и в суд, приоритет будет у суда, а МВК откажет в рассмотрении.

Рекомендация: Подготовка заявления в МВК — сложнейшая техническая работа. Малейшая ошибка или неполный пакет документов приведет к отказу в рассмотрении. Лучше всего обратиться к опытному юристу для сохранения шанса на реабилитацию.

Браузерный проект Black Test Screen показывает фейковые экраны с бесконечным обновлением Windows 10/11, а также с бесконечной загрузкой macOS X и Ubuntu 24.04. Дополнительно на ресурсе Black Test Screen доступны тестовые экраны различных цветов для проверки мониторов и дисплеев смартфонов.

Как принять 4 проекта в курирование и не свихнуться?

TL;DR

Руководитель дал 4 новых проекта в архитектурный надзор. Держать всё в голове нереально. Изучил индустриальные практики и подготовил процесс приёмки совместно с Claude Code. Выложил в open-source. Буду рад feedback от вас и ваших агентов.

Как всё началось

Руководитель: "Вот тебе 4 проекта - принимай в работу."

Я: "Окей... А что там?"

Руководитель: "Узнаешь."

Контест:

• 4 проекта

• Где-то есть пересечение функциональности (где именно - неясно)

• Команды разные, стек разный, зрелость разная

• Держать всё это в голове - бесмысленно

Немного поглядел - стало понятно: нужен системный подход.

Что я сделал

1. Изучил индустриальные практики

Посмотрел, как это делают:

• Futurice Project Handover Checklist

• TOGAF Architecture Review

• Harvard EA Checklist

• Практики из книг (Software Architecture in Practice, Building Evolutionary Architectures)

2. Собрал процесс приёмки и аудита

Готовил совместно с Claude Code. Не в чистом виде, конечно с моей конфигурацией (на текущий момент это 3882 строк rules, skills and commands). Безусловно, вычитывал и редактировал.

Что получилось:

Процесс приёмки проекта

6 фаз:

1. Инициация (получить вводную, доступы)

2. Kickoff встреча (PM + Tech Lead)

3. Сбор информации (документация, код, мониторинг)

4. Аудит (анализ архитектуры)

5. Решение о приёмке (принят/с оговорками/не принят)

6. Онбординг в надзор (регулярные встречи, точки контроля)

Файлы:

• project-handover-process.md - детальный процесс

• project-handover.md - чеклист (11 секций, 80+ пунктов)

Шаблоны аудита системы

Ручной аудит (12 разделов):

• Структура системы (C4, bounded contexts)

• Взаимодействие сервисов (sync/async, матрица зависимостей)

• Паттерны и антипаттерны

• Observability (метрики, логи, трейсинг, алерты)

• Устойчивость (SPOF, graceful degradation, DR)

• Безопасность

• План улучшений

Автоматическая валидация (215 метрик):

• Coupling и fan-out

• Layer violations

• God classes

• Топологические метрики

Файлы:

• system-audit.md - ручной аудит

• audit.md - отчет автоматической валидации

На следующей неделе начинаю приёмку. Посмотрим как процесс сработает в реальности.

Если эксперимент удастся - расскажу подробнее о результатах, подводных камнях и корректировках процесса.

Вопрос к сообществу

Буду рад feedback от вас и ваших агентов:

1. Процесс: Что лишнее? Чего не хватает?

2. Чеклисты: Какие критичные пункты я упустил?

3. Автоматизация: Используете ли инструменты для валидации архитектуры?

4. Агенты: Если вы используете AI-агентов для аудита - какие задачи им даёте? Как проверяете результаты?

Open-source шаблоны:

• Project Handover - процесс и чеклист приёмки

• System Audit - ручной и автоматический аудит

• Specifications - spec-driven development

• ADR - Architecture Decision Records

С удовольствием улучшу на основе вашего опыта.

UPD: Если интересно как процесс сработал на практике - подписывайтесь, расскажу после завершения приёмки.
Поддержать меня: https://t.me/MikeShogin

Навеяно сегодняшней статьёй «История: как Microsoft шесть раз отказывалась от виджетов, но потом возвращала их».

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

1. Виджет это приложение, точка Приложения бывают хорошие, годные и злые, вредные. Любое приложение может сломать ваш компьютер, украсть данные и деньги. Ответственность делится так: автор приложения прилагает все усилия, чтобы приложение не делало ничего плохого. Юзер прилагает все усилия, чтобы не ставить подозрительные приложения хрен пойми откуда. Если вам кажется, что это наивно, вспомните, что именно эта схема действует на PC прямо сейчас. На Github'е @dartraiden выложил драйвер (даже не простое приложение!), который позволяет использовать недорогие карты для майнинга вместо видеокарт (за 10-15% от цены последних) и написал: «Если вы мне не доверяете, вот инструкция, как собрать драйвер самому». Спасибо, но что-то не хочется )). Собирать драйвер самому. Я доверяю автору проекта! А ещё — авторам редактора Notepad++, браузера Firefox, файлового менеджера FAR (который почти в каждой сессии просит права админа, потому что я захожу им в системные папки) и многим другим авторам приложений.

2. Любое приложение может зарегистрировать себя в качестве виджета. Такая технология у Майкрософт уже есть, и называется ActiveX. Она до сих прекрасно работает (в день, когда сломается ActiveX, я перейду на Линукс, потому что только старые приложения меня под виндой и держат).

   Суть технологии в том, что у вас есть файл .dll, который регистрируется стандартной командой regsvr32 в той папке, где лежит (при переносе в другую папку его надо перерегистрировать). Чтобы не заставлять пользователя вручную выполнять эту команду, её обычно выполняет инсталлятор. (Или просто сам вызывает регистрирующую функцию из этой .dll — ходил анекдот про авторов инсталлятора, которые «сделали ядро в новой версии на X килобайт меньше, включив в него облегчённую версию regsvr32», потому что не знали азов программирования под Windows).

   Этот файл просто создаёт маленькое окошко (говоря техническим языком, window handle), может быть написан на C или Rust, занимать килобайты и работать со скоростью света.

   Всё, что вам нужно — дополнительно записывать при регистрации идентификатор своего ActiveX-компонента в ветку реестра с виджетами.

   Чтобы было проще создавать виджеты на HTML/CSS/JS, Майкрософт мог бы добавить новый тип проекта в Visual Studio: HTML Widget. Он брал бы файлы .html/.css/.js, метаданные и запаковывал бы в ActiveX-компонент вместе с WebView2 (браузерным окном). И ваш виджет отображался бы при помощи Chromium, как это делает приложение (не виджет) Steam, но весил бы, в отличие от Steam, ровно столько, сколько весят картинки и текст.

   Разумеется, ничто не мешало бы создать виджет на C#, Qt, Delphi, на базе своей версии Chromium (как это делает Steam), на базе Gecko, на базе чего угодно.

3. Будучи хозяйкой бала, Windows предлагала бы юзеру зарегистрированные виджеты перетаскивать из палитры виджетов в следующие места: а) рабочий стол, б) панель задач, в) меню «Пуск». Разумеется, любой виджет обязан был бы имплементировать помимо стандартных интерфейсов ActiveX-компонента специальный интерфейс IAmWidget и через него рассказывать о своих требованиях. Так что виджет, которому нужна минимальная площадь 512x512 пикселей, можно было бы создать только на рабочем столе.

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

Клиентский путь и деньги: как CJM поможет удержать клиента и сохранить выручку в 2026

Приглашаем на вебинар, на котором эксперты департамента e-commerce «КОРУС Консалтинг» расскажут, почему в 2026 исследование кл��ентского пути с помощью методики CJM становится необходимым базовым шагом для удержания b2b-клиентов и сохранения выручки бизнеса.

🗓 Когда: 18 февраля, в 16:00 по Москве

💜В программе:
1️⃣ Контекст рынка. Почему удержание b2b-клиентов становится одним из ключевых факторов роста в 2026
2️⃣ Методика CJM в основе клиентской лояльности. Почему при одинаковых условиях клиенты выбирают разные компании;
3️⃣ Кейсы. Как CJM позволила оптовым компаниям увеличить NPS до 95%, захватывать рынки с низкой цифровой зрелостью, переводить до 99% клиентов на онлайн-самообслуживание, увеличивать средний чек и маржинальность.
🔥 А в конце встречи в прямом эфире эксперты проведут чекап b2b-продаж и клиентского опыта вашего бизнеса и помогут сделать первый шаг к изменениям.
💝 Вебинар будет полезен:

• Собственникам и руководителям оптовых и дистрибьюторских компаний
• Коммерческим, digital- и e-commerce-директорам
• Руководителям продаж и сервиса в b2b-компаниях
• Директорам по маркетингу и цифровой трансформации

➡️ ЗАРЕГИСТРИРОВАТЬСЯ

Как сломать языковой барьер в клиентском сервисе с помощью нейротехнологий?

Недавно мы в ЮMoney внедрили систему языкового перевода диалогов пользователей и службы поддержки. Она распознаёт 25 языков и автоматически работает как для запросов пользователей, так и для ответов поддержки. Пользователь пишет на родном языке — система мгновенно переводит сообщение на русский. Оператор отвечает на русском — пользователь сразу получает сообщение на родном языке.

Под капотом — довольно практичная архитектура. Язык определяется через FastText, обученный на реальных диалогах поддержки и 25 языках, с точностью около 99% и задержкой в миллисекунды. Перевод выполняют специализированные модели на базе NLLB с LoRA-адаптерами, дообученными именно на финтех-данных. Это позволяет корректно обрабатывать названия брендов, продуктов и финансовых терминов и не «ломать» смысл там, где универсальные модели часто ошибаются.

Такой подход дал измеримый эффект: среднее время обработки обращений от иностранных пользователей сократилось примерно на 15%. Для операторов это меньше когнитивной нагрузки и больше фокуса на решении проблемы, для пользователей — возможность получать поддержку на родном языке без лишних действий и ожиданий. Весь цикл, от сообщения клиента до ответа, укладывается в пару секунд.

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

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

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

Что такое Portainer и зачем он нужен для управления Docker

Ранее мы уже разбирали базовые команды Docker и повседневную работу с контейнерами. Следующий логичный шаг — упростить управление окружениями и сделать его наглядным.

Сегодня поговорим о Portainer — графическом интерфейсе для управления Docker, Kubernetes и Podman. В новой статье показали, какие задачи он решает, в каких сценариях действительно полезен и чем отличается от работы через командную строку. Отдельно разобрали ключевые возможности: управление контейнерами и образами, просмотр логов и статистики, работу с сетями и томами, запуск приложений через docker-compose и готовые ��аблоны.

Пошаговая инструкция по установке Portainer через Docker-контейнер и подсказки, с каких разделов удобнее начать работу — в базе знаний Рег.облака.

Подборка бесплатных курсов для опытных и начинающих програмистов

Бесплатные курсы помогут познакомиться с конкретным направлением и попробовать формат обучения в Практикуме. Даже если пока не уверены в выборе, можно начать: если не зайдёт — забросить с чистой совестью. Главное — попробовать.

• «Инженер облачных сервисов» — курс для специалистов с опытом, программа рассчитана на 70 часов или примерно месяц ежедневных занятий по 2 часа в день. Начните сейчас, а продолжить можно в своём темпе.

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

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

• «Основы Go» — курс для тех, у кого есть опыт в программировании на других языках. Программа рассчитана на 30 часов или примерно 2 недели занятий по 2 часа в день. За это время вы научитесь читать и понимать код на Go, но чтобы создавать собственный код с нуля, уже придётся погрузиться в профессию глубже.

• «Основы Python-разработки» — обучение с нуля. За 20 часов поможем разобраться в бэкенд-разработке и начать писать код на Python — можно устроить марафон на выходных.

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

• «1С: программирование на русском» — обучение с нуля. Курс можно пройти за 45 минут: вечером после работы или на обеденном перерыве. Вы познакомитесь с одним из самых востребованных языков программирования, узнаете возможности 1C и примерите на себя роль 1С-разработчика. Если всё ещё думаете, что 1С — программа для бухгалтеров — это совсем не так.

→ Каталог бесплатных курсов