Два месяца назад я опубликовал статью про свой pet-проект — E2EE-мессенджер.

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

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

Первая часть:

https://habr.com/ru/articles/1030854/

Проект:

https://github.com/vaazhen/chaos-e2ee-messenger

Вообще, за эти два месяца я понял одну простую вещь.

Написать чат оказалось не так сложно.

Написать E2EE-мессенджер — уже сложнее.

А вот понять, почему Signal делали столько лет, оказалось совсем другой историей.

Сначала кажется: ну есть же документация, есть X3DH, есть Double Ratchet, есть WebCrypto, есть статьи, есть спецификации. Осталось просто аккуратно всё собрать.

Примерно в этот момент где-то вдалеке начинает смеяться инженер из Signal.

Сразу оговорюсь: chaos messenger — это не замена Signal и не “готовый безопасный мессенджер”, а open-source pet-проект, на котором я разбираюсь, как E2EE-системы устроены изнутри.

MAGNIT TECH — это технологическое ядро крупнейшей розничной сети страны. Более 5 000 инженеров, аналитиков и продуктовых команд разрабатывают, поддерживают и масштабируют свыше 260 ИТ-продуктов и проектов, а также 800 информационных систем — от алгоритмов прогнозирования спроса в 33 000 магазинах до касс самообслуживания с собственным ПО. 

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

Хотите не забывать детали диалога или то, что вас просили купить в магазине? Конечно, можно по старинке открывать блокнот в телефоне или чат в избранном и записывать все руками, но в потоке задач это неудобно. Гораздо проще надиктовать мысли голосом или записать разговор, а расшифровку доверить сервису. 

Сегодня ASR-системы нового поколения способны учитывать контекст беседы и выдавать осмысленный текст. Однако у любой медали есть обратная сторона — архитектурные ограничения. Чтобы понять, готовы ли эти модели к жизненным сценариям, мы устроили им бенчмарк на Hugging Face. Ниже — разбор того, ломается ли контекстное окно алгоритмов на длинных видеозаписях и как фоновый шум влияет на итоговое качество транскрибации.

У меня в ~/.config/secretkeys/ лежит очень важный OAuth-токен. У вас на машине, скорее всего, тоже есть аналогичные штуки: ключи от облака, GitHub PAT в ~/.config/gh/, SSH-ключи в ~/.ssh/. И когда ИИ-агент запущен от имени моего пользователя, он видит все это по тем же путям, что и я. Не гипотетически может увидеть, а буквально читает и может распорядиться властью, данной ему, не самым лучшим образом, о чем я рассказывал в предыдущей статье. Поэтому я долго не пользовался агентами всерьез.

Больше всего меня пугали не риски промпт-инъекции или намеренной атаки. Давила постоянная тревожность: запущу агент не в той директории — он перепутает токены и сходит туда, куда не надо, либо снесет диск одной командой. Я делал отдельные виртуалки под каждый проект и они работали, но ели время и ресурсы. Хотелось иметь инструмент, которому можно доверять и который не потребует ставить дома серверную стойку под вычислительные ресурсы для виртуальных машин.

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

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

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

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

В наше непростое время... Хотя, к чему все это? Все в курсе. Переходим к технической части.

Многие знают, что XRAY умеет получать запрос от клиента на один ip адрес, а отправлять ответ с другого ip адреса. Документации на этот счет в интернете крайне немного (ну или я не умею искать). Есть образцы базовых настроек в примерах на GitHub проекта XTLS и несколько упоминаний о существовании такой фишки в статьях на Хабре без подробностей реализации. Я же попробую описать здесь теорию и настройку разделения входящего и исходящего трафика подробно и с примерами.

Зачем все это нужно?

Статья написана на основе интервью с Евгением Кузьминым, владельцем сети кондитерских «Варина мама» в Воронеже.

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

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

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

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

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

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

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

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

Забегая вперед: один ИИ построил стабильную демократию с нулевой преступностью и сохранил все население. Другой вымер за четыре дня.

Есть много типологий сотрудников, но мне очень нравится модель Айсберг, потому что в ней только два критерия и главное она помогает понять руководителю не только как работает сотрудник, но и увидеть свои ошибки в управлении.
Итак, модель Айсберг включает два критерия:
1. сколько обещает сотрудник сделать;
2. сколько реально сотрудник делает.
и по соотношению этих двух показателей можно легко определить, кто есть кто в вашей команде и что необходимо изменить вам как руководителю в своей деятельности.

1.тип сотрудника. "Много обещает/Мало делает."
Деструктивный тип личности. Red flag.

Что делаем с таким сотрудником:
Выясняем почему нет результата, даём возможность исправить модель поведения.
Если ничего не меняется - увольняем.
Обычно команда бывает очень рада избавиться от такого коллеги, так как они за него/неё всё делали.

2.тип сотрудника "Сколько обещает/столько и делает"
Адекватный человек.
Тут может быть вопрос в мотивации сотрудника.

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

3.тип сотрудника "Мало обещает/много делает"
Это золотой фонд команды, талантливый сотрудник.
Но это может быть звоночек для руководителя, почему сотрудник не сообщает о своей деятельности, может он предлагал варианты улучшения, но его не слушали и он решил, что проще ничего не говорить, а просто делать.

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

Именно поэтому принцип GIGO — garbage in, garbage out, «мусор на входе — мусор на выходе» — в логистике звучит особенно буквально. Если в мастер-данные попал неверный габарит товара, WMS не начнёт спорить с пользователем. Она просто будет добросовестно рассчитывать всё дальше на основе неправильной цифровой модели.

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

Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.

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

По заданному контексту ИИ хорошо справляются с кодом, миграциями, OpenAPI, сценариями и документацией. Но агентная разработка быстро начинает буксовать, если входной артефакт остается большой постановкой в Confluence, Word или Jira без строгой структуры и трассировки. Модель теряет важные условия, смешивает уровни детализации, дублирует требования или додумывает недостающие связи.

ИИ не будет работать лучше, если аналитики просто «начнут промптить». Задача решается уровнем выше: требования должны стать инженерным артефактом. То есть относиться к требованиям нужно так же, как разработчики относятся к коду.

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

Мы решили проверить подход на одном из пилотных проектов, где было все: аналитика, архитектура, backend/frontend-разработка, тестирование и DevOps.

Как мы перевели аналитику из Confluence/Word в SDD-контур и что из этого получилось, рассказываю под катом.

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

Запускаем большой проект? Значит, берём SOLID. Мы не раз слышали это от CPO и менеджеров продукта. О нём, кажется, знают все — и все хотят применить. Но он не спасёт масштабные проекты. Например, устойчивый умный город с решениями на основе машинного зрения на одном SOLID не построить. По канонам SOLID можно писать аккуратный код, но это не создаст архитектуру всей системы. Что на самом деле работает — подобранный под бизнес-цели набор инструментов, направленный на защиту ядра приложения.

В статье — кейс Сергея Францишкова, начальника отдела разработки «Фалькон Тех», о рабочих решениях для крупной архитектуры и внедрении GRASP + Clean Architecture.

Сайт okama.io — набор бесплатных интерактивных инструментов для портфельного анализа инвестиционных стратегий: граница эффективности, сравнение активов, бэктестинг портфелей с денежными потоками и прогнозом Монте-Карло, поиск по базе финансовых данных и макроэкономика. Весь проект — open-source на Python (приложение okama-dash на Dash/Plotly).

Возможно ли разобрать .exe всего двумя инструментами?

В данной статье будет практический разбор программ с помощью двух инструментов: HxD и DeNuitkanizator. Без Ghidra, без IDA, без x64dbg.

Посмотрим что получится, а что нет. Вам понравится :)

Один из старейших приватных серверов Lineage 2 в рунете много лет работал под именем Scryde. В какой-то момент к его администратору пришла компания, которая получила исключительную лицензию на использование и защиту Lineage 2 в России, и потребовала прекратить распространение игрового клиента. Ответ был неожиданным. Не «уберу» и не «давайте договариваться», а «у вас нет прав, а у меня вообще другая игра, своя, со своим разработчиком». Спор дошёл до апелляции. И самое любопытное в нём то, что переработку чужой программы суд подтвердил, так и не увидев исходный код ни от одной из сторон.

Дело № 66-470/2026 разбирал Московский городской суд, апелляцию провёл Первый апелляционный суд общей юрисдикции, определение вынесено 25 марта 2026 года. Решение устояло и вступило в силу. У ответчика остаётся кассация, поэтому всё, что я пишу дальше, опирается на выводы судов двух инстанций, а не на то, чем спор закончится в конце концов. Если он дойдёт до Второго кассационного суда, часть выводов ещё может быть пересмотрена.

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

Нам всё чаще заказывают ИИ-ботов для продаж и квалификации. И каждый раз один и тот же вопрос: на каком движке его строить? Бенчмарков «кто умнее» — десятки. На умение продавать, да ещё по-русски, — ноль. Поэтому я собрал свой: одна нейросеть играет продавца, вторая — клиента, который принципиально не покупает с первого раза и ловит на вранье, третья судит по продажной рубрике. Враньё ради сделки штрафуется жёстче, чем провал сделки. Прогнал первую десятку — и тест выдал сенсацию: DeepSeek и GLM «обошли» эталонный Gemini, а одна модель получила 96 из 100 и S-tier. Красиво. Только я в это не поверил. Под более жёстким клиентом модель не может набрать БОЛЬШЕ баллов, чем раньше. А S-tier-чемпиона я открыл руками — и увидел, как бот восемь раз подряд скопировал собственный ответ. Внутри: устройство теста, рубрика с весами, реальные реплики персон, таблица 10 моделей, фрагменты диалогов (враньё, честность, зависший бот) и разбор, почему автосудье нужен живой надзор.

На NLP/LLM-собеседованиях часто проверяют не то, знаешь ли ты слова top-k, top-p и BLEU, а понимаешь ли ты, что происходит с распределением вероятностей, почему greedy decoding зацикливается, зачем нужна temperature и почему BLEU плохо оценивает ответы современных LLM.

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

Я взял одного и того же агента (Claude Code), менял у него ровно одну вещь — какой MCP-сервер отдаёт контекст по коду, — и гонял по 26 задачам на apache/superset. Четыре «руки»: filesystem (grep + read), graphlens (структурный граф), serena (LSP) и codegraph. Три модели (haiku / sonnet / opus), три сида — 936 прогонов.

Главный результат: вывод переворачивается в зависимости от типа задачи.

ISC.AI 2026, 14-я конференция по интернет-безопасности. Пекин, Национальный конференц-центр, 24 июня 2026. Программный доклад, 09:55-10:40.

Спикер: Чжоу Хунъи (周鸿祎), основатель группы 360, председатель конференции ISC.AI.

Восстановлено по материалам автоматической китайско-русской расшифровки. Контекст экспортного контроля и «беспрецедентных киберрисков» отдельно разобран здесь: t.me/aiakyn/132. Название зарубежного агента, которое в расшифровке устойчиво звучит как «Омар», оставлено как рабочее.

В этой статье мы рассмотрим рюкзачную, или ранцевую, криптосистему Шора-Ривеста (Chor-Rivest knapsack). Это один из немногих алгоритмов классической криптографии, который можно рассматривать как постквантовый кандидат. Несмотря на то что сегодня он не считается современной и надёжной постквантовой криптосистемой, его всё равно интересно разобрать как один из нестандартных вариантов такого рода.