Все потоки

Война с алгоритмами — как обойти шизу HRов.

Привет, Хабр.

Меня зовут Дима. Я разработчик и последние пару лет занимаюсь карьерным консультированием. Через меня прошло множество кейсов и за это время я чётко увидел одну вещь: поиск работы стал слишком выматывающим.

Не потому что люди слабые, а потому что процесс стал сложным, долгим и алгоритмическим.

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

В какой-то момент я понял: советов уже недостаточно. Нужен инструмент, который сам будет применять эти советы.

Так я решил заняться своим проектом — ИИ-ассистентом для поиска работы.

С чего всё начиналось

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

Технически всё работало.
По факту — конверсия почти не изменилась. (Кто бы мог ожидать)

Быстро стало понятно, что делать быстрее — не значит лучше.

Шаблон (даже написанный нейросетью) рекрутеры считывают мгновенно.

Что пришлось переосмыслить

То, что мы быстро поняли: ассистент должен работать как человек, а не как скрипт.

Это значит:

• учитывать контекст, а не просто ключевые слова;

• вытаскивать релевантные кейсы, а не перечислять стек;

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

• не создавать подозрительных паттернов поведения.

Как мы это переосмыслили

Засев на несколько недель мы перепилили всю инфраструктуру платформы и создали нечто новое.

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

1. Поиск релевантных вакансий

Ассистент анализирует требования и ваш опыт на уровне задач. Если компании важно «ускорить релизы», система поднимет ваш кейс про оптимизацию CI/CD.

2. Написание персонализированных сопроводительных писем

Это была самая сложная часть.

Базовая LLM пишет слишком «правильно»: канцеляризмы, одинаковая структура, списки.
Мы долго работали над стилистикой и вариативностью, чтобы письмо выглядело так, будто кандидат реально вчитался в вакансию.

3. Отчетность

У нас нет режима, который всё делает за спиной.

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

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

4. Работает аккуратно

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

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

Зачем это всё

Как карьерный консультант я вижу главное: люди тратят слишком много энергии на рутину.

Этот проект (он, кстати, называется OfferMate) не волшебная кнопка «оффер».
Это инструмент, который:

• снимает техническую нагрузку,

• ускоряет касание с рынком,

• делает процесс управляемым.

Если интересен такой подход, то вот ссылки:

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

Новую работу гарантировать не могу, но рутину из поиска точно уберет)

Буду рад критике. На Хабре без неё нельзя 🙂

В минувшею пятницу, 26 февраля, на площадке Кибердома прошла премьера фильма «Как получить доступ ко всему: реверс-инжиниринг».

Исходя из описания под трейлером, этот

Документальный фильм расскажет, как люди учатся вскрывать сущность комплексных технологических систем. Разбирая устройство или технологию по частям, мы получаем доступ к их структуре и замыслу создателей. Эксперты в области обсудят реверс-инжиниринг в СССР и России – от промышленности после Первой мировой до искусственного интеллекта и «киберпанка», который ждет нас в ближайшем будущем.

Я, к сожалению, на премьеру попасть не смог по причине конфликта в графике. Поэтому, чтобы "изучить материалы по теме" мне пришлось посмотреть фильм в четверг, то есть за день до его официальной премьеры!
Enumeration is the key (c) OffSec, и если хорошенько прошерстить интернет, то можно найти и посмотреть документалку без регистрации и СМС на официальном портале PREMIER: Как получить доступ ко всему: реверс-инжиниринг.

Естественно, не буду спойлерить детали, однако скажу, что фильм снят очень качественно, а в создании участвовали эксперты из Positive Technologies, «Лаборатории Касперского», Т-Банка, «Иви», SR Space, Музея криптографии, «Росатома», Elverils, интернет-проекта «Я помню» и другие неравнодушные люди и организации.
Как посмотрите, приглашаю вас в комментарии, чтобы обсудить увиденное и высказать свои мысли по поводу фильма!

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

Red Teaming LLM-агентов: методы, автоматизация, кейсы

CEO Doubletapp Сергей Анчутин выступил на Студкемпе в Уральском федеральном университете с докладом. 

LLM всё активнее работают в бизнесе — и каждая ошибка грозит потерей денег и репутации. Как избежать рисков?

Red Teaming — это процесс поиска уязвимостей в системе, когда команда экспертов играет роль хакеров и ищет слабые места. Цель — заранее выявить проблемы и защитить компанию от реальных инцидентов и их последствий.

В видео:
- как масштабировать человеческие креативные возможности, чтобы находить реальные уязвимости LLM;
- как работают пайплайны «LLM против LLM» и методы MART и DART;
- почему автоматизация не всегда нужна и где ИИ проигрывает человеку;
- когда остановится развитие нейросетей.

Doubletapp — ML-эксперты с 2018 года. Мы помогаем клиентам внедрять ИИ так, чтобы он приносил выгоду их бизнесу, и специализируемся на внедрении и обучении LLM и RAG-систем. 

Что делаем:
- экспертные датасеты
- обучаем LLM под задачи клиента
- проводим аудит и консалтинг ИИ-продуктов
- разрабатываем кастомные ML-решения.

Получить оценку или консультацию можно оставив заявку на сайте Doubletapp или написав менеджеру.

Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA

В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.

Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум:
1. ВАСЯ: ВК, Альфа, Сбер, Яндекс
2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа
3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс

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

Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?

Чего стоит попасть туда (насколько это сложно)

У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.

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

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

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

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

Где лучше и стоит ли оно того

Я поработал много где как AQA - Ozon, WB, VK, несколько российских и западных стартапов, бигтех US.
И могу с уверенностью сказать, что тут не угадаешь, везде всё по разному. Например, в одном из криптостартапов я встретил лучшие процессы, что видел в жизни, а в двух из бигтехов - миллион токсиков, невероятную бюрократию и в целом не очень классные процессы.

Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.

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

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

Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.

Что в сухом остатке

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

Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы!
В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)

Вышел наш новый подкаст #Криптонит_говорит про тестирование!  Мы обсудили тренды профессии, поговорили об образовании в этой сфере и узнали, почему разрыв между разработкой и тестированием сокращается (и так будет и дальше).

 Смотрите и слушайте выпуск на любой удобной платформе:

·       VK Видео

·       YouTube

·       Rutube

·       Подкаст в телеграме

·       Я.Музыка

В выпуске приняли участие:

·       Александр Гречин, руководитель департамента тестирования в «Криптоните»;

·       Алексей Москалев, ведущий инженер по автотестированию, Департамент развития платформы Голосового Антифрода, билайн.

Русский язык программирования.


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


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


Если вы начинающий автор или уже имеете хороший ЯП, пишите в комментарии и оставляйте ваш GitHub\GitFlip и название вашего языка.

Каждый ЯП посмотрю, проверю, изучу.

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

Бесплатно. Потрачено много часов работы.
Буду благодарен за фидбек и предложения.

https://ai.arckep.ru

ТРЕК 1 / NO-CODE
1.1 Введение в AI-агентов
1.2 Промпт-инжиниринг
1.3 Платформы и модели
1.4 Практика no-code
1.5 Безопасность и этика AI
1.6 Финальный проект
ТРЕК 2 / РАЗРАБОТЧИКИ
2.1 Введение в AI-кодинг
2.2 Claude Code
2.3 Gemini CLI
2.4 Codex CLI
2.5 Cursor и IDE-агенты
2.6 AGENTS.md и документация
2.7 MCP
2.8 Российские модели
2.9 Воркфлоу и OpenClaw
2.10 Финальный проект
ТРЕК 3 / OPENCLAW
3.1 Знакомство с OpenClaw
3.2 Подключение каналов
3.3 Настройка и автоматизация
3.4 Мультиагентная архитектура

«Золотое сечение изображений». Пост N2

«Сечение изображения по третям»

Повторю, «стих» отличается от прозы тем, что организован как минимум в такие структуры как «размер (стиха)» и «рифма». Размер стиха принято отражать сеткой.

«Размер» стихотворения из предыдущего поста называется «хорей пятистопный». Его "сетка" выглядит так:

‘-‘-‘-‘-‘-          

‘-‘-‘-‘-‘-         

‘-‘-‘-‘-‘-

‘-‘-‘-‘-‘-

А вот пример сетки, называемой «амфибрахий»:

-‘--‘--‘--'-     На севере диком стоит одиноко

-‘--‘--‘--'       На голой вершине сосна

-‘--‘--‘--'-      И дремлет, качаясь, и снегом сыпучим

-‘--‘--‘--'       Одета как ризой она.                                         (М.Ю. Лермонтов)

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

Понятно, что автор не сочиняет стих на соответствие какой то формальности. Поэт пишет свободно, «автоматически нанизывая» слова на ритм, звучащий в его сознании. Лишь позже, во время правки\совершенствования текста автор может вспомнить про хорей или амфибрахий и притянуть «теорию» к конкретной ситуации. И то – не обязательно. Для таких осознанных действий автор должен знать теорию.

Так же интуитивно действуют и создатели изображений.

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

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

Хит подобных объяснений - несомненно «золоте сечение, оно же сечение по третям».  «Золото» и «трети» объединены потому мол, что они визуально близки, а таким малым расхождением можно пренебречь.

Но это не так. «Механизм воздействия», соответствующий этим сеткам, совсем разный.

Начнем с простого. Обе сетки применимы ко всему изображению, от кромки до кромки того «холста» (несущего изображение), которое сознание воспринимает как единый целый объект.

Сетку «третей» получают, разделив холст (а в случае фотографии – «кадр») двумя вертикальными линиями на три равные части.

Действие этого механизма проявляется так:

• На одной из вертикалей располагается либо «точка схода перспективы", либо «центр тяжести» самого дальнего опознаваемого объекта.

• На другой вертикали располагается «центр тяжести доминанты», либо графической, либо содержательной (сюжетной). Чаще всего обе доминанты совпадают. Но не всегда.

Довольно редко встречаются изображения, где доминанта является и дальним объектом, при этом вторая вертикаль остается не занятой.

На всякий случай: горизонтальных линий в этой сетке нет.

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

«Трети», примеры изображений (картин, фотографий):

https://u.to/Kep1Ig https://u.to/E_p1Ig https://u.to/M_p1Ig https://u.to/Pep1Ig https://u.to/S_p1Ig https://u.to/be91Ig https://u.to/cO91Ig https://u.to/d_91Ig … и так дале и тому подобное…

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

Задача о сравнении чисел

Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?

Условие

В IT-компанию N привезли экспериментальное устройство для автоматизации расчетов. Оно работает на урезанном интерпретаторе Python: никаких условий, сравнений или встроенных функций — только арифметика и битовые операции.

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

Задача

Есть два числа: a и b. Найдите наибольшее из них, используя только сложение, вычитание, деление и умножение, а также битовые операции.

Нельзя использовать операторы сравнения (>, <, ==, != и т. д.), тернарный оператор, функции вроде max(), min() и прочее.

Попробуйте справиться с заданием. А один из вариантов решения показываем в Академии Selectel.

Как масштабировать NGFW до сотен Гбит трафика в секунду без потери сессий

Производительность современных NGFW давно перестала измеряться «гигабитами в идеальных условиях». В реальной инфраструктуре устройство одновременно выполняет SSL-инспекцию, IDS/IPS, контроль приложений, антивирусную проверку и другие функции — и всё это под высокой нагрузкой, без потери пакетов и без разрыва пользовательских сессий.

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

• как обеспечить симметричную обработку трафика в обоих направлениях;

• как сохранить пользовательские сессии при изменении состава кластера;

• как организовать контроль состояния узлов и корректную реакцию на сбои;

• как избежать появления единой точки отказа;

• как корректно встроить решение в существующую инфраструктуру.

5 марта в 11:00 совместно с инженерами UserGate обсудим архитектурный подход к масштабированию производительности NGFW, принципы интеграции UserGate NGFW 7 и DS Proxima, а также результаты тестирования и практический опыт внедрения.

Ссылка на регистрацию

Внимание! Тема на злобу дня!

🔘Маркировка. Честный знак. Товарооборот.

☑️ Точки отсчета. Ключевые этапы введения честного знака.
01.03.2026 – старт работы системы. Участники товарооборота начинают регистрацию своих товаров, вносят информацию в реестр «Честного знака».
01.05.2026 - введение обязательной маркировки на радиоэлектронную продукцию, что означает обязательную маркировку товаров, которые производятся в РФ, а также импортируются.
1.03.2026 – 1.12.2026 – этап маркировки остатков. Маркируются все остатки на складе. Период, в который товар может маркироваться ни производителем и ни импортером. Это касается товара, который не был промаркирован при производстве или импорте до начала действия системы Честного Знака.
1.12.2026 – обязательная передача сведений о маркированной продукции при передаче между собственниками.
1.03.2027 – указание выбытия товаров становится обязательным.
🔸 После 1.12.2026 реализация немаркированных товаров будет невозможна.

☑️ Как понять подлежит Ваш товар маркировке или нет?
Маркировке подлежат осветительные приборы и компоненты, мобильные телефоны и ноутбуки, электронные печатные платы.
Точно узнать подлежит Ваш товар маркировке или нет, можно ознакомившись с актуальной версией Постановление Правительства РФ № 1954 от 28.11.2025 приложение к правилам маркировки.

☑️ Товарооборот.

1. Осуществляется только посредством ЭДО. Если нет ЭДО, срочно заводите. Есть бесплатная версия «ЭДО Лайт».

2. При передаче товара от одного участника товарооборота другому сведения о кодах маркировки передаются в УПД.

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

☑️ Что делаем мы, как производители печатных плат?
1️⃣Мы регистрируем товар в «Честном Знаке».

• Описываем товар.

• Оформляем заказ на коды маркировки.

• Составляем отчет для Честного Знака о вводе в оборот.

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

2️⃣ При передаче заказчику УПД мы фиксируем факт передачи маркированных плат заказчику. После того, как заказчик подписывает УПД, маркированные платы переходят в его собственность.

☑️ Что делаете Вы, если Вы являетесь заказчиком?

1. Вы принимаете маркированные печатные платы.

2. Если Вы далее перепродаете печатные платы, то через УПД передаете коды маркировки Вашему покупателю.

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

Подробно о маркировке в презентации Материалы подготовлены АНО «КПП» подготовленной при поддержке ООО «Оператор – ЦРПТ»
Скачать презентацию можно здесь.

Если после ознакомления с данным материалом у Вас останутся вопросы, пожалуйста, пишите их в комментариях, мы будем их собирать и , через АНо КПП, направлять в ЦРПТ.

Больше о нас здесь:

Сайт ТГ ВК Дзен Youtube Rutube Хабр Мах

У меня не сходится логика RACI матрицы :(

Роли С и I - прекрасны, поэтому оставим их за бортом вопроса.

В моей картине мира есть Заказчик, Ответственный и Исполнител(ь,и).

• Заказчик (может быть внутренний) - принимает результат по требованиям.

• Ответственный - обязуется обеспечить соответствие целостного результата всем требованиям.

• Исполнители - делают руками.

Ответственный и Исполнитель - могут быть одним и тем же лицом, но Заказчик и Ответственный - категорически НЕ объединяются в одного человека - тут непродуктивный конфликт ролей. Я понимаю как это работает - веками схема себя зарекомендовала: Покупатель-Продавец и сотрудники продавца.

Собственно во что я всё никак не могу въехать:

Буквы R и A из матрицы - не ложатся на привычную схему... Если нет Заказчика - (может быть даже внутреннего) - работа бессмысленна...

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

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

В случае, когда А-из-матрицы это и Заказчик и Ответственный в одном лице - тут конфликт интересов, как я уже выше упоминал.

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

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

У кого получается с пользой применять RACI - можете объяснить с какой стороны это кушается? Или это просто сладкая дичь для говорящих голов?

Как сейчас живется DevOps в разных компаниях и что будет дальше? Обсудили в новом выпуске подкаста МТС True Tech Talks 🎧

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

В новом выпуске к нам в гости заглянул Антон Егорушков — DevOps-эксперт и автор канала сыча. Вместе с Алексеем Костюковым, DevOps Lead в MWS, и Ариной Зайцевой, Senior DevOps в MWS, поговорили про то, как все меняется в профессии сейчас и что будет в будущем.

Обсудили:

• что мотивирует в работе и профессии,

• использование ИИ в рабочих задачах, 

• варианты реализации IaC и EaC,

• как лучше размещать инфраструктуру: on-prem, hybrid, one-cloud или multi-cloud,

• каких изменений в DevOPS ожидать в ближайшие пару лет.

Смотрите и слушайте на удобной площадке: в VK Видео или на YouTube. 

Если было интересно — вступайте в сообщество МТС True Tech, чтобы быть в курсе лучших практик в ИТ.

Чем «специалист» отличается от «руководителя»?

Если посмотреть механистически, то «руководитель» это тот, кто имеет формальную возможность кому-то приказывать, а «специалист» в своей работе рассчитывает только на свою голову или руки. Но в современных матричных и дивизионных структурах всё сложнее. Тут зачастую не одна иерархия подчинения, все на кого-то влияют, а если и имеют возможность отдавать приказы, то часто не во всей работе, а только в каком-то аспекте (конкретный проект, определённая область знаний и т.д.).

Вот мой постструктуралистский ответ на вопрос:

• Специалист это тот, кто может позволить себе считать, что управленческие решения можно принимать на основании «объективных» данных, неких процедур учёта разных мнений, стабильных бизнес-процессов и т.д. При этом вообще не важно отдаёт ли он формально кому-то приказы, обучает ли кого-то или нет.

• Руководитель это тот, кто создаёт эту самую иллюзию фукуямовского конца истории, даёт ощущение стабильности и объективности мира, в котором работают специалисты. И для этой работы по социальному конструированию реальности зачастую вообще не нужно иметь формальную власть кому-то что-то приказывать.

Регулярно пишу в Telegram-канал Chief Philosophy Officer о философии бизнеса и управленческого мышления. Заходите.

ИИ в разработке: экзоскелет, а не замена человека

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

Но выбор инструмента — отдельная задача. GitHub Copilot, Claude, ChatGPT, DeepSeek, Tabnine — у каждого своя ниша, и кажется, что универсальной нейросети не существует.

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

Читайте полный обзор на сайте Рег.облака.

LTV — метрика, которая позволяет покупать клиентов дороже конкурентов

Большинство компаний считают лиды. Некоторые считают цену лида. Часть — даже конверсию в продажу. И почти никто системно не считает LTV. А потом в управленческой модели появляется жёсткий потолок: «Лид дороже 3 000 рублей нам не подходит». И этот потолок начинает определять весь темп роста.

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

Это и есть LTV — Lifetime Value.

Представьте двух собственников. Первый смотрит только на цену первой сделки. Если юнит-экономика сходится «в ноль плюс», он осторожничает, режет бюджет, тормозит масштабирование. Второй знает, что его клиент в среднем работает с компанией 2–3 года, делает повторные закупки и постепенно увеличивает чек. Он понимает реальную ценность клиента в системе, а не в одной транзакции.

Кто из них сможет позволить себе дороже лид? Кто быстрее выкупит лучший спрос на рынке? Кто агрессивнее зайдёт в новые каналы?

Ответ очевиден.

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

А если LTV не посчитан, компания живёт в короткой логике: «Сошлось — не сошлось в первой сделке». Это ограничивает масштабирование сильнее любого конкурента.

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

И в какой-то момент происходит важный сдвиг мышления. Вы перестаёте спрашивать: «Как нам удешевить лид?» И начинаете задавать другой вопрос: «Как нам увеличить ценность клиента внутри системы?»

А это уже не про рекламу. Это про стратегию.

Масштабируется не бюджет. Масштабируется экономика клиента.

Детерминистический аудит-слой для LLM-агентов — открытое демо

Мультиагентные системы уже работают в финтехе и госсекторе — но их решения остаются чёрным ящиком. Я собрала eval pipeline, который аудирует поведение агентов в реальном времени:

→ Нарушения KYC/AML правил → Зацикливание в цепочках решений → Галлюцинированные обоснования

Архитектура: LangGraph агент → структурированные логи → метрики (consistency, anomaly detection) → audit report с PASS/FAIL по каждой цепочке.

Работает на любой модели через LiteLLM — меняешь модель одной строкой в config.yaml. API-ключ не нужен, есть рабочий Jupyter notebook.

Ориентировано на финтех и госсектор: EU AI Act, ФСТЭК.

Демо: github.com/DariRinch/dcl-eval-pipeline-demo

Новая страшилка от Citrini Research: Кризис Интеллекта

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

Мнения людей после прочтения статьи разделились на оптимистичные и пессимистичные:

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

• Пессимисты утверждают, что в случае с ИИ базовый механизм закона Сэя ломается. Роботы и алгоритмы производят товары и услуги, но не формируют потребительский спрос. Разрывается цикл "произвёл → получил деньги → потратил", потому что из него исключается человек. И кризис, описанный в статье, очень близок.

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

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

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

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

Остаётся ответить только на 1 вопрос: Куда человечество в целом хочет прийти
через N лет?

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

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

Спасибо, что почитали. Надеюсь, смог натолкнуть вас на интересные мысли. Буду рад вашим вопросам / дополнениям / комментариям.

Экономия памяти со __slots__

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

class Standard:
	def __init__(self, x, y):
		self.x = x
		self.y = y
		
std = Standard(100, 200)
std.__dict__ # {'x': 100, 'y': 200}

Помимо того, что и класс и экземпляры отдельно занимают своими __dict__ место в памяти, хранение данных в словарях само по себе несет большие накладные расходы. Хеш-таблица в основе словаря хранит служебные структуры и растёт скачками при увеличении числа атрибутов, поэтому на больших количествах объектов затраты памяти ощутимы:

from sys import getsizeof

std_size = getsizeof(std) + getsizeof(std.__dict__)
std_size # 344 байта

Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:

class Slot:
	__slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов
	
	def __init__(self, x, y): # Остальное – без изменений
		self.x = x
		self.y = y
		
slt = Slot(100, 200)
slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'?

slt_size = getsizeof(slt)
slt_size # 48 байтов

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

---
Важные ограничения

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

   std.z = 300
   std.__dict__ # {'x': 100, 'y': 200, 'z': 300}
   
   slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
   

2. Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:

   class PartialSlots:
   	__slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z'
   	
   	def __init__(self, x, y, z):
   		self.x = x
   		self.y = y
   		self.z = z
   
   p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes
   

3. В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:

   # Подкласс без доп. логики
   class InheritSlot(Slot):
       pass
   
   
   inh_slt = InheritSlot(100, 200)
   
   inh_slt.__dict__ # {}, атрибут снова доступен
   inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов
   inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память
   
   # Поправим
   class InheritSlot(Slot): 
        __slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента.
   
   
   inh_slt2 = InheritSlot(100, 200, 300)
   inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе
   

Компания Zhipu AI совместно с Университетом Цинхуа представила одну из важнейших открытых моделей 2026 года — GLM-5. Это не просто инструмент для написания кода, а полноценная система, способная самостоятельно планировать проекты, создавать код, проводить тестирование, устранять баги и улучшать решения в течение длительного времени.

Основные характеристики GLM-5 впечатляют:
- Архитектура MoE с общим количеством параметров 744 миллиарда, из которых одновременно активируется лишь 40 миллиардов.
- Контекст длиной до 200 тысяч токенов позволяет хранить целиком большие кодовые базы.
- Первый открытый релиз с оценкой 50 баллов по индексу AAI.
- Лидирует среди открытых моделей в тестировании LMArena (оценка текста и кода).
- По уровню производительности сравнима с закрытыми моделями уровня Claude Opus 4.5 и Gemini 3 Pro.

Изначально модель была выпущена анонимно под именем Pony Alpha, вызвав предположения, что это продукт от крупных западных компаний вроде DeepMind или OpenAI. Однако вскоре выяснилось, что разработка принадлежит китайской стороне, подчеркивая значимость проекта.

Технические особенности включают:
- Обучение на массиве из 28,5 триллионов токенов.
- Использование технологии Sparse Attention, снижающей вычислительные затраты на обработку больших объемов контекста.
- Асинхронный метод обучения с использованием RLHF, позволяющий эффективно задействовать ресурсы GPU.
- Трехступенчатое обучение, включающее этапы рассуждений, агентирования и выравнивания.

Практические достижения:
- Высокий показатель успешности тестов на платформе SWE-bench Verified (77,8%) и лидерство в тесте BrowseComp (75,9%).
- Модель обучалась на большом количестве репозиториев GitHub (более 10 тыс.).
- Способность успешно управлять бизнес-процессами, включая моделирование реального бизнеса (например, сеть торговых автоматов).

Особенность GLM-5 заключается также в оптимизации под китайские процессоры Huawei Ascend, Cambricon и Kunlun, обеспечивающую производительность, аналогичную западным платформам, но с экономией примерно на 50%.

Таким образом, появление GLM-5 свидетельствует о том, что разница между открытыми и проприетарными системами практически исчезла. Открытые модели теперь способны решать реальные инженерные задачи на мировом уровне, работая на собственном оборудовании и показывая конкурентоспособные результаты.

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

https://arxiv.org/abs/2602.15763v2

ВК: https://vk.com/wall-222544138_412

Tenchat: https://tenchat.ru/media/4986873-glm5

TG: https://t.me/DenoiseLAB/4063