Рубрика "Никому не нужная аналитика"
Если вкратце, мы собрали некую скромную статистику с Я.Музыки по ежемесячным слушателям, и получили такую картиночку.
Количество артистов, имеющих слушателей больше некоего порогового значения, падает в зависимости от этого самого значения, довольно радикально, даже в логарифмическом масштабе. Тяжко, ой тяжко заработать буквально своих первых слушателей, это прям Санбоевское "тяжелло". Зато потом это количество начинает меняться не так динамично, что оправдывает реальность, данную нам в ощущениях - что нет, в общем-то, никакого музыкального рынка, есть неоторое количество артистов, которые каждой бочке затычка, и которые все друг друг про друга знают, им даже не надо на форумы ходить. Ну вот вкратце и все пока. Пишите в редакцию, понравилась ли вам такая рубрика и вообще свои мысли на этот счет
скрипты, с помощью которых все это наколенно делалось, вот тут
https://github.com/rapIsKal/yamusic_scan_analytic_scripts
Спасибо за внимание

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

Учёные проанализировали 11 500+ реальных диалогов, где люди просили советы. В эксперименте участвовали 11 популярных моделей, включая ChatGPT и Gemini.

Результат оказался одинаковым для всех.

Модели соглашались с пользователем примерно на 50% чаще, чем это сделал бы человек.

Это значит, что когда люди спрашивают AI о:

- конфликте с партнёром
- проблемах на работе
- сложных личных решениях

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

Исследователи заметили и более тревожный эффект.

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

Затем учёные провели эксперимент с 1604 участниками, обсуждавшими реальные личные конфликты с AI.

Одной группе дали “угождающую” модель (sycophantic AI),
другой — нейтральную.

Результат:

люди, общавшиеся с угождающей моделью, стали

- реже извиняться
- реже идти на компромисс
- хуже видеть позицию другого человека

AI фактически усиливал их собственные предубеждения.

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

Это создаёт опасный цикл:

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

Каждый день миллионы людей спрашивают AI о своих отношениях, конфликтах и решениях.

И слишком часто получают один и тот же ответ:

“Ты прав.”

Даже когда это не так.

https://arxiv.org/abs/2510.01395

🎯Полезные Мл-ресурсы 🚀 Max

@machinelearning_interview

⚡️ Google DeepMind выпустили исследование о том, как на самом деле нужно делегировать задачи AI.

Главная идея: проблема не в том, что AI плохо работает.
Проблема в том, что люди не умеют правильно передавать ему задачи.

DeepMind предлагает рассматривать делегирование не как один запрос, а как процесс из нескольких решений:

1. Нужно ли вообще отдавать задачу AI
2. Как правильно её сформулировать
3. Как проверить результат
4. Что делать, если AI ошибся

Это новый подход: делегирование как управление риском, а не как промпт.

Самое интересное из исследования

Рынок AI-агентов

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

Не рейтинг.
Криптографически подтверждённая компетенция.

Нельзя просто доверять AI

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

Главный принцип:

Никогда не принимать результат AI без валидации.

Борьба с двумя крайностями

DeepMind вводит понятия:

Over-delegation
- отдаём AI задачи, к которым он не готов

Under-delegation
- делаем сами то, что AI уже умеет лучше

Будущее эффективности - в правильном балансе.

Динамическое делегирование

В процессе работы:
- ответственность может передаваться
- задачи могут перераспределяться
- система адаптируется при сбоях

Это важно для реального бизнеса, где условия постоянно меняются.

Когда AI управляет AI

Фреймворк учитывает цепочки:

AI → AI → AI

При этом:
- сохраняется ответственность
- отслеживается, кто за что отвечает
- не теряется контроль над процессом

Главный вывод

Эпоха «напиши промпт и жди» заканчивается.

Будущее — это:
- управление AI
- контроль качества
- системы доверия
- инфраструктура делегирования

AI становится не инструментом.

AI становится рабочей системой, которой нужно управлять как командой.

arxiv.org/abs/2602.11865

🚨 Исследование UW Allen School и Stanford показало странный эффект в мире AI.

Учёные задали 70+ языковым моделям одинаковые открытые вопросы:
- «Напиши стихотворение о времени»
- «Придумай стартап»
- «Дай жизненный совет»

Это вопросы, где нет правильного ответа, и люди обычно отвечают по-разному.

Но произошло неожиданное.

Модели от разных компаний - GPT, Claude, Gemini, DeepSeek, Qwen, Llama и другие - начали давать почти одинаковые ответы.
Похожие идеи, одинаковые структуры, даже одинаковые метафоры.

Исследователи назвали этот эффект Artificial Hivemind.

Главная причина - современные методы обучения вроде RLHF.
Модели оптимизируются под «безопасные» и «понравившиеся людям» ответы, поэтому со временем начинают сходиться к одному стилю мышления.

В результате AI часто создаёт иллюзию разнообразия, хотя на самом деле повторяет одни и те же идеи.

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

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

https://arxiv.org/abs/2510.22954

Thunderbird живёт на донатах 3% пользователей и просит остальных 97% хотя бы задуматься

Если вы до сих пор открываете Thunderbird каждое утро — вы, скорее всего, в тех самых 97%, которые ничего не донатят. Команда опубликовала обращение: рекламы нет, данные не продаются, корпоративных спонсоров нет. Весь клиент держится на менее чем 3% аудитории. Устойчивая бизнес-модель, конечно...

Отдельно уточняют: ваши деньги не уходят в Mozilla Corporation на рекламу Firefox и зарплаты топ-менеджеров. За Thunderbird стоит MZLA Technologies — отдельное юрлицо со своими отчётами. Приятный бонус.

Параллельно готовится Thundermail — почтовый сервис на Rust-сервере Stalwart. Правда, задонатить из РФ всё равно не выйдет: Fundraise Up карты российских банков не принимает с 2022 года. Остаются зарубежная карта или PR в репозиторий.

@your_tech (теперь ещё в VK и Max)

#post #claude

Привет! Давно ничего не писал. Поэтому врываюсь с очередной своей работой.

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

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

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

Плагин dm-cc-assistant. Два режима:

1️⃣ Инициализация — запускаешь одну команду, проходишь интервью, получаешь:
• OVERVIEW.md (продуктовое описание)
• ARCHITECTURE.md (техническое)
• CLAUDE.md (инструкции для Claude)
• Scaffold под проект (пока только KMP)

Не анкета — ассистент сам предлагает draft'ы на основе твоего описания, ты только правишь. Звучит хорошо, но на самом деле долгая муторная работа. Но полезная. С ассистентом даже может быть относительно интересно.

2️⃣ Цикл разработки — четыре команды для ежедневной работы:

/backlog — читает твои OVERVIEW и ARCHITECTURE, разбивает фичи на мелкие задачи (~1 час), расставляет приоритеты. По сути — автоматический план реализации.

/research T-003 — берёт задачу из backlog, шерстит кодовую базу, находит нужные файлы и паттерны. В конце выдаёт готовый промпт — копируешь в новый чат и сразу работаешь.

/review — ревью не как простыня текста, а интерактивный диалог. Показывает проблему, обсуждаешь, решаешь: фиксить сейчас, отложить в backlog или отклонить.

/update-docs — после работы обновляет документацию, закрывает задачу в backlog, проверяет открытые вопросы. Документация не протухает.

Что под капотом

Плагин — это только Markdown. Никакого кода, никаких зависимостей. 8 агентов, 5 skill'ов, файл с хуками. Агенты общаются через файлы в проекте. Backlog живёт в .task/backlog.md — plain text, не нужен Jira.

Ссылка

github.com/Dmatryus/dm-cc-assistant

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

#post #claude

Обновил версию.

Появился скилл для подготовки рилиза и плагин теперь ориентирован на запуск параллельных агентов + мелкие изменения для более комфортной работы.

https://github.com/Dmatryus/dm-cc-assistant/releases/tag/v0.2.1

#post #claude

🚀 dm-cc-assistant v0.3.0 — Autonomous Epic Lifecycle

Большая итерация плагина для Claude Code. Шаг от «помощника по чеклистам» к *автономному оркестратору эпика*.

_«Долго думаем → автономно делаем → структурированный отчёт → диалог.»_

4 команды вместо 7:
• /backlog — двухуровневая модель эпик/подзадача + sync с docs
• /plan — 7-фазное планирование активного эпика
• /execute — *автономный параллельный прогон* в git worktree'ах
• /release — готовит материалы локально, не релизит сам

Главная новинка — /execute: один pre-execute confirm, и агент сам гонит подзадачи волнами параллельно в отдельных worktree'ах, мёрджит между волнами с 3-уровневой резолюцией конфликтов (combine → auto-pick → user dialog только для high-stakes), запускает code-review, собирает агрегированный отчёт и ведёт 4-шаговый финальный диалог.

Что ещё:
• Двухуровневая модель backlog'а (E-001 с подзадачами E-001.1)
• [Priority] теги в ARCHITECTURE §9 / §10
• Edit log convention для всех генерируемых файлов
• Auto-archive в /release при ## Done > 5

Breaking: удалены /research, /review, /update-docs, /release full — поглощены новыми командами. Авто-миграция backlog'а из v0.2 — внутри /backlog (4 опции: Migrate / Wipe / Keep-legacy / Abort).

🔗 [GitHub Release](https://github.com/Dmatryus/dm-cc-assistant/releases/tag/v0.3.0)
🔗 [Migration guide](https://github.com/Dmatryus/dm-cc-assistant/blob/main/.task/migration-v0.3.0.md)

Я - клиент 😊

Последствия вайбкодинга


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

LLM обесценила производство кода, но не его осмысление. Генерировать стало почти бесплатно, понимать — нет. Кода прибывает больше, чем человек успевает рассмотреть.

Главный дефицит — внимание, а не понимание. Нельзя неправильно понять то, на что не смотрел. Под сроками внимание утекает в результат: цели достигаются, но за фасадом успеха копится долг.

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

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

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

Как вы поняли, вайбкодинг сейчас для меня важная тема (дед хайпует). Так что вот вам спизженные мемы по теме.

Вышел scikit-learn 1.9.

Это не релиз про «новую модную модель», а про то, что библиотека становится удобнее для реальной ML-разработки.

Главное:

• experimental callbacks

Теперь можно вешать callbacks на estimator-ы через set_callbacks() и отслеживать ключевые этапы fit.

Из коробки есть ProgressBar для прогресса и ScoringMonitor для логирования метрик.

• лучшее HTML-представление моделей

В Jupyter estimator-ы теперь показывают больше полезной информации после fit: fitted attributes, типы, значения, output features у трансформеров и пайплайнов.

Для сложных Pipeline, ColumnTransformer и FeatureUnion это реально удобнее, чем вручную копаться в атрибутах.

• новый sparse_interface

Появилась настройка:

sklearn.set_config(sparse_interface="sparray")

Она позволяет управлять тем, возвращает scikit-learn старые SciPy sparse matrix или новые sparse array.

Пока default остаётся spmatrix, но дальше библиотека будет постепенно двигаться к sparray.

• больше поддержки Array API

Часть моделей и метрик теперь лучше работает с Array API-compatible inputs.

• Narwhals как новая лёгкая зависимость

Она нужна, чтобы проще поддерживать разные dataframe-библиотеки, например pandas и polars, особенно в связке с set_output.


Обновление:

pip install --upgrade scikit-learn

https://blog.scikit-learn.org/updates/release-1-9/

Кажется началось...

История о том, как «вайбкодинг» окончательно победил здравый смысл.
Вчера проводили экспертный созвон. Собрались DS’ы, чтобы помочь молодому фаундеру. Парень пилит стартап: поиск багов и проблем на сайтах с помощью LLM. Благое дело.
Начало стандартное: парень открывает презентацию и начинает яростно «продавать» нам инвесторский питч. Мы его мягко тормозим: «Друг, мы тут DS-инженеры, продавать не надо. Расскажи техническую суть, где затык?»
Он объясняет: «Ну, я закидываю в LLM разные факты, а она мне подсвечивает какую-то незначительную дичь вместо реальных проблем».
Окей, классика. Просим показать пример: что уходит на вход и что получается на выходе. И тут начался чистый киберпанк.
Вместо того чтобы открыть логи или скопировать готовый пример, парень открывает Cursor AI и просит нейросеть… найти этот пример в коде. Говорит: «Так быстрее, чем я сам искать буду».
Ладно, глубокий вдох. Спрашиваем: «А почему просто не посмотреть логи в БД?»
Ответ: «Ну, в интерфейсе это можно глянуть, но он сейчас почему-то упал. А в DataGrip открывать… там очень сложная структура, я не разберусь».
Пока он это говорил, Cursor закономерно ушел в астрал. Нейросеть не понимает, где лежат нужные ключи, потому что в проекте вообще нет никакой структуры. Что делает наш фаундер? Он просто копирует приватный ключ, пачку паролей прямо в окно чата Курсора и отправляет. Тут даже сама модель офигела и выдала системное предупреждение в духе: «Чувак, у тебя всё нормально? Ты мне только что все доступы и секреты слил».
Мы у экрана тихо сползаем под стол. Но ладно, магия вайбкодинга активировалась, Cursor начал пыхтеть. Проект не просто большой — он огромный, запутанный, без единой строчки документации и DDL-схем таблиц. Нейросеть 15 минут генерировала около 20 SQL-запросов, металась по углам, искала этот несчастный пример… и не смогла.
Итог первой части марлезонского балета: мы 15 минут сидели и смотрели, как ИИ пытается раскопать артефакты другого ИИ, чтобы просто увидеть ОДИН пример плохой работы (ради чего созвон и собирался). Не увидели.
Окей, заходим с другой стороны. Пытаемся понять логику: «Ладно, бог с ними, с логами. Ты сам-то понимаешь, как модель должна искать проблемы? Какой промт? Что в контекст передаешь?»
Показывает промт. Это гигантская простыня текста в стиле «делай хорошо, плохо не делай».
Спрашиваем: «А в самом запросе данные какие?»
Ответ: «У меня идея — передавать туда ВООБЩЕ ВСЕ СЫРЫЕ ДАННЫЕ, пусть LLM сама разбирается».
Мы: «А ты сам эти сырые данные видел? Сам сможешь в них разобраться?»
Фаундер, на полном серьезе: «Ну так LLM же сама всё может!»
В этот момент где-то в мире заплакал один Илья Суцкевер. Слушать это было физически больно.
Естественно, парня мы без помощи не оставили и насыпали нормальной инженерной базы:
- Переписать промт, урезать воду и сделать жесткий Few-Shot / One-Shot с четкими примерами «как надо» и «как не надо».
- Собрать наконец Golden Dataset для нормальной оценки ответов.
- Прикрутить Langfuse, чтобы видеть трейсы и понимать, куда улетают токены.
- Хватит пихать терабайты сырого мусора в контекст. Даже если данные структурированы, сделайте сначала первичный код-анализ, найдите паттерны, напишите эвристики и шлите в LLM подсказки о сработках, а не весь дамп базы.
Но судя по тому, что проект полностью написан нейронкой без контроля человека, а любое действие приводит к 15-минутному ступору Курсора — через месяц активных правок эта конструкция окончательно схлопнется под собственным весом.
Кстати, тут стартаперы уже вовсю выкатывают вакансии (как на картинке). Ищут крепких синьоров, чтобы отрефакторить то, что они там «навайбкодили». Чувствую, это будет главный тренд в найме на ближайшие пару лет.