Проект Udaff.com прекратил работу. Старперской ностальгии пост.
26 апреля на сайте было опубликовано прощальное сообщение:
«Эпоха Udaff.com окончена. Проект закрыт. Мы и так уже тянули дольше, чем это было нужно. Спасибо, что были с нами все эти годы».
Помните интернет, который не был вежливым, комфортным и для детей?
Когда заходишь и там не алгоритмы, не «вам может понравиться», а просто стена текстов. Где можно было нарваться на шедевр, а можно на полную дичь. Где могли нахуй послать. И никто не извинялся.
Udaff был как раз таким местом.
Не удобным. Не красивым. Но настоящим что ли. Там не пытались нравиться. Если «аффтар жжот», то значит реально жжот, а не потому что так решил алгоритм.
Если «в топку», то без объяснений и дискуссий на 200 комментариев про токсичность. А если и комментарии, то нельзя было отмазываться «вот ты душный». Это не комментатор душный, это ты необразованный идиот, который не мог парировать.
Сейчас всё аккуратнее. Удобнее. Быстрее. Экологичнее.
Но почти нигде не осталось этого ощущения, что ты попал в чужую, но живую среду. Тебя тут не ждут, но только твои знания и интеллект помогут стать здесь своим.
Закрытие Udaff — это минус ещё один кусок интернета, который не пережил превращение в платформу.
Эпоха закончилась.
Аффтар… ну вы поняли. RIP
26 апреля на сайте было опубликовано прощальное сообщение:
«Эпоха Udaff.com окончена. Проект закрыт. Мы и так уже тянули дольше, чем это было нужно. Спасибо, что были с нами все эти годы».
Помните интернет, который не был вежливым, комфортным и для детей?
Когда заходишь и там не алгоритмы, не «вам может понравиться», а просто стена текстов. Где можно было нарваться на шедевр, а можно на полную дичь. Где могли нахуй послать. И никто не извинялся.
Udaff был как раз таким местом.
Не удобным. Не красивым. Но настоящим что ли. Там не пытались нравиться. Если «аффтар жжот», то значит реально жжот, а не потому что так решил алгоритм.
Если «в топку», то без объяснений и дискуссий на 200 комментариев про токсичность. А если и комментарии, то нельзя было отмазываться «вот ты душный». Это не комментатор душный, это ты необразованный идиот, который не мог парировать.
Сейчас всё аккуратнее. Удобнее. Быстрее. Экологичнее.
Но почти нигде не осталось этого ощущения, что ты попал в чужую, но живую среду. Тебя тут не ждут, но только твои знания и интеллект помогут стать здесь своим.
Закрытие Udaff — это минус ещё один кусок интернета, который не пережил превращение в платформу.
Эпоха закончилась.
Аффтар… ну вы поняли. RIP
❤🔥9
По поводу снятия с проката «Метод-3».
Там надо было с «Метод-2» начинать.
Там надо было с «Метод-2» начинать.
😡2
Как я перестал жечь токены на одних и тех же ресёрчах
Возвращаемся к ИИ. Работа практически всех моих агентов для создания контента начинается с исследования: WebSearch, 15 источников, конспект на 8 000 символов. Но вот сегодня ты пишешь статью про PostgreSQL в облаке, а через неделю просишь дайджест на базам данных. И ресёрчер каждый раз собирает одни и те же цифры. Дорого по токенам, дорого по времени.
Поэтому я сделал базу знаний исследований и добавил три простых правила.
1. Автосохранение не «по запросу пользователя»
Обычно агенты сохраняют только когда попросили. Для исследований исключение. Конспект ресёрчера сохраняется автоматически, до передачи автору.
Тут ещё дополнительный плюс: исследование — самый ценный промежуточный артефакт по токенам и времени. Если автор зависнет на генерации, то ресёрч потеряется. Если же его сразу сохранить, то можно открыть новую сессию и продолжить с готового конспекта.
2. Каждое исследование тегируется
Файл лежит в базе с YAML-frontmatter. Минимум 2 тега (домен + тип), максимум 7. Каждый факт в исследовании обязан иметь URL, название источника, tier и дату публикации.
3. Перед каждым ресёрчем проверка базы
Оркестратор обязан сначала прочитать базу исследований, отфильтровать, посмотреть теги в frontmatter. Это секунды против минут нового исследования.
На скрине YAML-frontmatter к ресёрчу релиза по нашему VK AI Space для разработки и запуска ИИ-агентов.
#ai_agents
Возвращаемся к ИИ. Работа практически всех моих агентов для создания контента начинается с исследования: WebSearch, 15 источников, конспект на 8 000 символов. Но вот сегодня ты пишешь статью про PostgreSQL в облаке, а через неделю просишь дайджест на базам данных. И ресёрчер каждый раз собирает одни и те же цифры. Дорого по токенам, дорого по времени.
Поэтому я сделал базу знаний исследований и добавил три простых правила.
1. Автосохранение не «по запросу пользователя»
Обычно агенты сохраняют только когда попросили. Для исследований исключение. Конспект ресёрчера сохраняется автоматически, до передачи автору.
Тут ещё дополнительный плюс: исследование — самый ценный промежуточный артефакт по токенам и времени. Если автор зависнет на генерации, то ресёрч потеряется. Если же его сразу сохранить, то можно открыть новую сессию и продолжить с готового конспекта.
2. Каждое исследование тегируется
Файл лежит в базе с YAML-frontmatter. Минимум 2 тега (домен + тип), максимум 7. Каждый факт в исследовании обязан иметь URL, название источника, tier и дату публикации.
3. Перед каждым ресёрчем проверка базы
Оркестратор обязан сначала прочитать базу исследований, отфильтровать, посмотреть теги в frontmatter. Это секунды против минут нового исследования.
На скрине YAML-frontmatter к ресёрчу релиза по нашему VK AI Space для разработки и запуска ИИ-агентов.
#ai_agents
🔥3❤2
О пользе логов
В моей системе агентов после генерации практически каждого материала остаётся отчёт: какие факты переделывались, какие источники подтянулись и тд. И вот в ожидании своего рейса обратно в Калининград в пятницу вечером я сел изучать эти отчёты и вносить изменения. В первой части (будет и вторая про изменения в воркфлоу) расскажу про галлюцинации и как я стараюсь их сократить ещё на этапе написания, а не проверки. Например, обнаружилось, что 5 из 6 явных выдуманных фактов были в темах кибербезопасности. Покопавшись в отчётах, понял — субагент-автор охотно берёт цифры из агрегаторов и кладёт в текст без проверки первоисточника. Для кибербеза такое, конечно, совсем моветон.
Что изменил для всех агентов:
Атрибуция источников. Полная атрибуция теперь = первоисточник + год + ФИО/должность/компания + URL. Чёрный список вводных: «по данным экспертов», «исследования показывают», «по оценкам аналитиков» — без конкретики не принимается. Запрет на цифры из агрегаторов без раскрытия первоисточника. Проверка текущей должности спикера (а не прошлогодней).
Доменное правило для ИБ — белый список и чёрный список агрегаторов. Правило подключается по триггерам (атака, ransomware, утечка, CVE, 152-ФЗ). Чек-лист фактчекера на статус ransomware-групп и актуальность регуляторики.
Свежесть данных по типам. Жёсткие лимиты: рынок — 12 месяцев, MAU — 6, GitHub stars — 3, статус ransomware-группы — 6. Обязательная пометка года для цифр старше года. Запрос WebSearch с явным указанием года в строке.
Через месяц-два повторю ревью и посмотрю, изменилась ли частота неверной атрибуции. Если правила за месяц не упоминаются ни в одном отчёте — значит, не срабатывают на этапе написания текста, переформулирую, доработаю.
#ai_agents
В моей системе агентов после генерации практически каждого материала остаётся отчёт: какие факты переделывались, какие источники подтянулись и тд. И вот в ожидании своего рейса обратно в Калининград в пятницу вечером я сел изучать эти отчёты и вносить изменения. В первой части (будет и вторая про изменения в воркфлоу) расскажу про галлюцинации и как я стараюсь их сократить ещё на этапе написания, а не проверки. Например, обнаружилось, что 5 из 6 явных выдуманных фактов были в темах кибербезопасности. Покопавшись в отчётах, понял — субагент-автор охотно берёт цифры из агрегаторов и кладёт в текст без проверки первоисточника. Для кибербеза такое, конечно, совсем моветон.
Что изменил для всех агентов:
Атрибуция источников. Полная атрибуция теперь = первоисточник + год + ФИО/должность/компания + URL. Чёрный список вводных: «по данным экспертов», «исследования показывают», «по оценкам аналитиков» — без конкретики не принимается. Запрет на цифры из агрегаторов без раскрытия первоисточника. Проверка текущей должности спикера (а не прошлогодней).
Доменное правило для ИБ — белый список и чёрный список агрегаторов. Правило подключается по триггерам (атака, ransomware, утечка, CVE, 152-ФЗ). Чек-лист фактчекера на статус ransomware-групп и актуальность регуляторики.
Свежесть данных по типам. Жёсткие лимиты: рынок — 12 месяцев, MAU — 6, GitHub stars — 3, статус ransomware-группы — 6. Обязательная пометка года для цифр старше года. Запрос WebSearch с явным указанием года в строке.
Через месяц-два повторю ревью и посмотрю, изменилась ли частота неверной атрибуции. Если правила за месяц не упоминаются ни в одном отчёте — значит, не срабатывают на этапе написания текста, переформулирую, доработаю.
#ai_agents
1👍2🔥1👌1🆒1
Forwarded from VK Tech
Сегодня, когда обсуждали влияние ИИ на бизнес, всплыла такая тема: нужно ли вводить в штатное расписание новую роль — ИИ-директора.
Потому что ИИ — это уже не ИТ-задача. Это вопрос стратегии, процессов, экономики и организационной модели компании. Компаниям нужен тот, кто свяжет бизнес, данные, инфраструктуру и реальные бизнес-метрики. Эдакий переводчик между бизнесом и ИТ-отделом. Тот, кто будет отвечать не за эксперименты, а за масштабирование эффекта.
Или не нужен? И уметь использовать ИИ должны абсолютно все сотрудники на любых уровнях?
Вот как считает Дмитрий Лазаренко, руководитель направления облачных сервисов VK Tech.👇
Media is too big
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🤬1
Недавно рассказывал про компакцию контекста и порог в 85% и получил вопрос: "а как это применять в обычном чат-боте, не в Claude Code?"
Сначала теория:
Так вот: автоматики в обычном чате нет, как нет настроек порога, нет хуков, нет офлоада. Но проблема та же: контекст заполняется, модель начинает «забывать» что было в начале разговора. Особенно заметно, когда работаешь с длинными редакционными сессиями, разбираешь большие тексты или итерируешь статью в несколько заходов.
Решение — делать компакцию контента ручками:
Каждые 15-20 сообщений просишь модель сделать конспект: что решили, какой голос выбран, какие источники использованы, что осталось. Копируешь. Открываешь новый чат. Первое сообщение — этот конспект. Контекст свежий, все договорённости сохранены.
Не вставлять большие тексты целиком. Нужно разобрать длинный материал, давай резюме и говори «полный текст у меня есть, спроси конкретную часть когда нужно». Это ручная реализация того же принципа: в контексте только то что нужно прямо сейчас.
Системный промпт с якорями. Если работаешь через API или Projects — добавь в системный промпт что критично удерживать: голос, редполитику, запрещённые слова. Это не компакция, но снижает риск что важное потеряется при длинном разговоре.
#ai_prompts #ai
Сначала теория:
Компакция — это механизм управления контекстным окном когда оно заполняется. Модель не может держать бесконечную историю разговора, у неё есть лимит токенов. Когда этот лимит приближается, система автоматически сжимает старые части разговора: заменяет подробную историю переписки кратким резюме, убирает промежуточные шаги, оставляет только суть. Цель — освободить место для новых сообщений не теряя общего контекста задачи. Проблема в том что алгоритм компакции не знает что для тебя важно: он удаляет «старое» — а вместе с ним могут уйти ключевые решения, согласованный голос, верифицированные источники. Поэтому важно либо управлять этим вручную, либо явно указывать что должно выжить при сжатии.
Так вот: автоматики в обычном чате нет, как нет настроек порога, нет хуков, нет офлоада. Но проблема та же: контекст заполняется, модель начинает «забывать» что было в начале разговора. Особенно заметно, когда работаешь с длинными редакционными сессиями, разбираешь большие тексты или итерируешь статью в несколько заходов.
Решение — делать компакцию контента ручками:
Каждые 15-20 сообщений просишь модель сделать конспект: что решили, какой голос выбран, какие источники использованы, что осталось. Копируешь. Открываешь новый чат. Первое сообщение — этот конспект. Контекст свежий, все договорённости сохранены.
Сделай конспект нашего разговора для продолжения в новой сессии.
Включи: задачу, согласованные решения, использованные источники,
текущий статус, следующий шаг.
Не включай историю переписки и отклонённые варианты.
До 300 слов, сплошным текстом.
Не вставлять большие тексты целиком. Нужно разобрать длинный материал, давай резюме и говори «полный текст у меня есть, спроси конкретную часть когда нужно». Это ручная реализация того же принципа: в контексте только то что нужно прямо сейчас.
Системный промпт с якорями. Если работаешь через API или Projects — добавь в системный промпт что критично удерживать: голос, редполитику, запрещённые слова. Это не компакция, но снижает риск что важное потеряется при длинном разговоре.
#ai_prompts #ai
👌2
Forwarded from The Art Of Programming
DOOM жив!
Субботнее залипалово про одну из самых важных и страшних в моей жизни игр. Помню как мы мелкими сидели на табуретках перед монитором и адски боялись... такого накала была игра.
DOOM: изучил код и историю - помер от зависти
Субботнее залипалово про одну из самых важных и страшних в моей жизни игр. Помню как мы мелкими сидели на табуретках перед монитором и адски боялись... такого накала была игра.
DOOM: изучил код и историю - помер от зависти
YouTube
DOOM: изучил код и историю - помер от зависти
Kill the Bill: https://t.me/kill_the_bill_bot
-----
Мой телеграмм с постами про DOOM: https://t.me/kosmostars7403
Бусти: https://boosty.to/icher
-----
DOOM — история игры, которая в 1993 году не просто стала хитом, а перепрошила представление о компьютерных…
-----
Мой телеграмм с постами про DOOM: https://t.me/kosmostars7403
Бусти: https://boosty.to/icher
-----
DOOM — история игры, которая в 1993 году не просто стала хитом, а перепрошила представление о компьютерных…
❤1
Вторая проблема внедрения нейросетей. Первая, напомню, где взять новых мидлов, если джуны не нужны.
❤🔥1👍1
Forwarded from жЫсь ПиарЛись
Звериный оскал ИИ
Кажется таких чудных вакансий (Юля, спасибо за наводку) ближайшее время нас ждет все больше.
В ней прекрасно примерно все:
- паши один, весь комплекс маркетинга и пиар делай в одиночку в обнимку с ИИ (без подключения ИТ), но с KPI по продажам.
- в прямом подченении коммерческому (правда его мы тоже ищем) и доступом к акционеру
- нам 30 лет, маркетинга и пиар у нас все это время не было как класс, но мы хотим мидла из ит или финтеха, который сделает нам data-driven и AI-native систему
- скока денег платить хотим не скажем
Такое ощущение, что собственник сходил на все конфы по ии, послушал маркетинговых обещаний AI-бигтеха, записал умные слова и запихнул это все в вакансию.
Но проблема даже не в этом. Вполне вероятно, что они найдут какого-нить молодого амбициозного мидла, который возможно даже что-то построит.
Есть другая сторона, о которой такой бизнес не думает - безопасность
1️⃣ Чтобы ИИ-инструменты работали на нужном уровне за них надо платить. Причем, чтобы бы информацмя была во внутреннем контуре - платить дорого.
И еще не известно, что обойдется дешевли - люди или ИИ.
2️⃣ Зависимость от технологий.
Любой сбой полностью останавливает работу целой функции компании. А заодно и смежных.
3️⃣ Зависимость от 1 человека.
Даже если все аккаунты в ии-инстнументах будут куплены на фирму (что вообще не факт, многое официально не купить) и не уйдут вместе с человеком, то процесс все равно встанет, т.к. носитель знаний ушел.
Т.е в попытке сэкономить бизнес ставится в неустойчивое положение и весьма вероятно без сокращения расходов. Вот такие пироги
Кажется таких чудных вакансий (Юля, спасибо за наводку) ближайшее время нас ждет все больше.
В ней прекрасно примерно все:
- паши один, весь комплекс маркетинга и пиар делай в одиночку в обнимку с ИИ (без подключения ИТ), но с KPI по продажам.
- в прямом подченении коммерческому (правда его мы тоже ищем) и доступом к акционеру
- нам 30 лет, маркетинга и пиар у нас все это время не было как класс, но мы хотим мидла из ит или финтеха, который сделает нам data-driven и AI-native систему
- скока денег платить хотим не скажем
Такое ощущение, что собственник сходил на все конфы по ии, послушал маркетинговых обещаний AI-бигтеха, записал умные слова и запихнул это все в вакансию.
Но проблема даже не в этом. Вполне вероятно, что они найдут какого-нить молодого амбициозного мидла, который возможно даже что-то построит.
Есть другая сторона, о которой такой бизнес не думает - безопасность
И еще не известно, что обойдется дешевли - люди или ИИ.
Любой сбой полностью останавливает работу целой функции компании. А заодно и смежных.
Даже если все аккаунты в ии-инстнументах будут куплены на фирму (что вообще не факт, многое официально не купить) и не уйдут вместе с человеком, то процесс все равно встанет, т.к. носитель знаний ушел.
Т.е в попытке сэкономить бизнес ставится в неустойчивое положение и весьма вероятно без сокращения расходов. Вот такие пироги
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1🤔1
ИИ не заменил менеджеров. Он сделал их узким местом
Картинка из моей работы. Облачная конференция, сессии наших спикеров на других ивентах, лендинги, статьи в СМИ и блог, Хабр. При производстве практически каждой единицы контента используется ИИ — целая фабрика агентов. Но между ИИ и готовым результатом есть человек, в данном случая я. Человек смотрит, проверяет, принимает решение. И этот ресурс ничем не масштабируется.
И это не то, чтобы только у меня подгорает. На прошлой неделе в HBR вышел материал Managers Are Struggling to Keep Up with the AI Productivity Boom. Открывается цитатой менеджера: "каждые тридцать минут кто-то создаёт что-то, что я должен посмотреть". CIO в свежей колонке формулирует ещё жёстче: исполнение перестаёт быть ограничением, дефицитным ресурсом становится суждение. Производство чего либо-ускорилось в разы. Но при этом никто не перестраивает поток работы под ИИ, практически всегда остаются те же цепочки согласований, что были до.
Опять вернусь к своему опыту. Когда ревьюишь черновик от человека, то ловишь опечатки и логику. Когда ревьюишь то, что выдала модель — проверяешь каждый факт, каждую формулировку, каждую цифру. Ошибки модели уверенные, гладкие, правдоподобные, их не отловить, читая по-диагонали. ИИ снимает нагрузку с генерации и нагружает верификацию. Инженеры в опросах напрямую отвечают: проверять AI-код тяжелее, чем писать с нуля.
Короче, производство ускорили на порядок, а пропускную способность решений — процентов на двадцать. Разница оседает у тебя на столе. И, надо признать, в этом нет ничьего злого умысла. Просто индустрия выкатила инструмент, который сжимает один этап цепи, и почему-то решила, что от этого ускорилась вся цепь. Не ускорилась. Узкое место мигрировало. Сейчас оно сидит на менеджерском стуле и проверяет то, что выдала модель.
💡 Что могу посоветовать. «Делегируйте больше», «фокусируйтесь на главном», «приоритизируйте» — это всё сработает только, если у вас есть большая команда.
Первое — перенести принятие решений из своей головы в артефакты. Если ты ревьюишь каждый текст как индивидуальный кейс, ты держишь критерии в рабочей памяти и тратишь её на каждой итерации заново. Если эти же критерии оформлены как явный чек-лист, гайдлайн, или, в случае Claude Code, как скилл — половина решений принимается до того, как текст дошёл до тебя.
Второе — поменять метрику собственной нагрузки. Для контент-менеджера, например, это значит перестать мерить себя «количеством опубликованного» и начать мерить «сколько решений приняли за день» и «сколько из них пришлось переоткрывать». Это звучит абстрактно, но это единственная метрика, которая показывает, упёрся ли ты в производство (масштабируется ИИ) или в суждение (не масштабируется).
Третье — называть проблему вслух перед руководством. Не как жалобу, а как операционную диагностику: «У нас не дефицит производства, у нас дефицит пропускной способности решений. Можем обсудить, как её расширить — либо новый сотрудник с делегированной зоной ответственности, либо перенос части решений в политику агента».
Четвёртое — признать, что часть решений можно не принимать. Самое тяжёлое — это решения о пограничных кейсах, которые на самом деле не пограничные, а просто непривычные. Например, для контента: есть устоявшаяся редполитика и агент с явными правилами может выкатывать большую часть текстов в публикацию практически без ревью. А человек будет проверять только то, что реально спорно. Это страшно, кажется, что качество упадёт. Но на практике у команд, которые так сделали, качество не падает, потому что вариативность снижается. А время освобождается. Но страшно и есть риски для бренда.
#ai
Картинка из моей работы. Облачная конференция, сессии наших спикеров на других ивентах, лендинги, статьи в СМИ и блог, Хабр. При производстве практически каждой единицы контента используется ИИ — целая фабрика агентов. Но между ИИ и готовым результатом есть человек, в данном случая я. Человек смотрит, проверяет, принимает решение. И этот ресурс ничем не масштабируется.
И это не то, чтобы только у меня подгорает. На прошлой неделе в HBR вышел материал Managers Are Struggling to Keep Up with the AI Productivity Boom. Открывается цитатой менеджера: "каждые тридцать минут кто-то создаёт что-то, что я должен посмотреть". CIO в свежей колонке формулирует ещё жёстче: исполнение перестаёт быть ограничением, дефицитным ресурсом становится суждение. Производство чего либо-ускорилось в разы. Но при этом никто не перестраивает поток работы под ИИ, практически всегда остаются те же цепочки согласований, что были до.
Опять вернусь к своему опыту. Когда ревьюишь черновик от человека, то ловишь опечатки и логику. Когда ревьюишь то, что выдала модель — проверяешь каждый факт, каждую формулировку, каждую цифру. Ошибки модели уверенные, гладкие, правдоподобные, их не отловить, читая по-диагонали. ИИ снимает нагрузку с генерации и нагружает верификацию. Инженеры в опросах напрямую отвечают: проверять AI-код тяжелее, чем писать с нуля.
Короче, производство ускорили на порядок, а пропускную способность решений — процентов на двадцать. Разница оседает у тебя на столе. И, надо признать, в этом нет ничьего злого умысла. Просто индустрия выкатила инструмент, который сжимает один этап цепи, и почему-то решила, что от этого ускорилась вся цепь. Не ускорилась. Узкое место мигрировало. Сейчас оно сидит на менеджерском стуле и проверяет то, что выдала модель.
Первое — перенести принятие решений из своей головы в артефакты. Если ты ревьюишь каждый текст как индивидуальный кейс, ты держишь критерии в рабочей памяти и тратишь её на каждой итерации заново. Если эти же критерии оформлены как явный чек-лист, гайдлайн, или, в случае Claude Code, как скилл — половина решений принимается до того, как текст дошёл до тебя.
Второе — поменять метрику собственной нагрузки. Для контент-менеджера, например, это значит перестать мерить себя «количеством опубликованного» и начать мерить «сколько решений приняли за день» и «сколько из них пришлось переоткрывать». Это звучит абстрактно, но это единственная метрика, которая показывает, упёрся ли ты в производство (масштабируется ИИ) или в суждение (не масштабируется).
Третье — называть проблему вслух перед руководством. Не как жалобу, а как операционную диагностику: «У нас не дефицит производства, у нас дефицит пропускной способности решений. Можем обсудить, как её расширить — либо новый сотрудник с делегированной зоной ответственности, либо перенос части решений в политику агента».
Четвёртое — признать, что часть решений можно не принимать. Самое тяжёлое — это решения о пограничных кейсах, которые на самом деле не пограничные, а просто непривычные. Например, для контента: есть устоявшаяся редполитика и агент с явными правилами может выкатывать большую часть текстов в публикацию практически без ревью. А человек будет проверять только то, что реально спорно. Это страшно, кажется, что качество упадёт. Но на практике у команд, которые так сделали, качество не падает, потому что вариативность снижается. А время освобождается. Но страшно и есть риски для бренда.
#ai
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1
Звёздная гонка ИИ-агентов в мае 2026
Наткнулся на свежий разбор от Rost Glukhov, он 21 мая выгрузил через API число звёзд у 20 самых популярных опенсорсных фреймворков для агентов.
Что по цифрам:
→ OpenClaw — 373 тыс. звёзд. В апреле обогнал React и стал самым «звёздным» репозиторием в истории GitHub. Тот самый агент Штайнбергера, который живёт на твоём железе и общается через мессенджеры. Ритм — 62 релиза за месяц, по одному каждые 12 часов.
→ Hermes Agent от Nous Research — 160 тыс. за 12 недель. Растёт быстрее в неделю, чем OpenClaw в том же возрасте. Держит память между сессиями и сам пишет файлы навыков из успешных задач.
→ Середина таблицы спрессована между 26 и 43 тыс. — там позиции тасуются за сутки от одного поста на HN: Nanobot (Python, ~4 тыс. строк кода, от лаборатории HKU), AstrBot (самый активный по релизам), PicoClaw (Go, под встраиваемые устройства от Sipeed), AionUi (TypeScript, агентный UI) и ZeroClaw на Rust.
Что мне было интересно из выводов автора:
Во-первых, релизы и звёзды почти не коррелируют. OpenClaw выкатывает 62 релиза в месяц, а пара проектов с десятками тысяч звёзд — ноль.
Во-вторых — и это главное — звёзды измеряют любопытство, а не использование. Что люди реально запускают, показывают токены на OpenRouter, загрузки npm/PyPI и история CVE, а не счётчик в углу репозитория. Звезда стоит один клик; она не значит, что софт хоть раз запустили в проде.
Полезное напоминание перед тем, как в следующий раз выбирать стек по «самому популярному на гитхабе».
Оригинал и полный датасет: glukhov.org
#ai_agents
Наткнулся на свежий разбор от Rost Glukhov, он 21 мая выгрузил через API число звёзд у 20 самых популярных опенсорсных фреймворков для агентов.
Что по цифрам:
→ OpenClaw — 373 тыс. звёзд. В апреле обогнал React и стал самым «звёздным» репозиторием в истории GitHub. Тот самый агент Штайнбергера, который живёт на твоём железе и общается через мессенджеры. Ритм — 62 релиза за месяц, по одному каждые 12 часов.
→ Hermes Agent от Nous Research — 160 тыс. за 12 недель. Растёт быстрее в неделю, чем OpenClaw в том же возрасте. Держит память между сессиями и сам пишет файлы навыков из успешных задач.
→ Середина таблицы спрессована между 26 и 43 тыс. — там позиции тасуются за сутки от одного поста на HN: Nanobot (Python, ~4 тыс. строк кода, от лаборатории HKU), AstrBot (самый активный по релизам), PicoClaw (Go, под встраиваемые устройства от Sipeed), AionUi (TypeScript, агентный UI) и ZeroClaw на Rust.
Что мне было интересно из выводов автора:
Во-первых, релизы и звёзды почти не коррелируют. OpenClaw выкатывает 62 релиза в месяц, а пара проектов с десятками тысяч звёзд — ноль.
Во-вторых — и это главное — звёзды измеряют любопытство, а не использование. Что люди реально запускают, показывают токены на OpenRouter, загрузки npm/PyPI и история CVE, а не счётчик в углу репозитория. Звезда стоит один клик; она не значит, что софт хоть раз запустили в проде.
Полезное напоминание перед тем, как в следующий раз выбирать стек по «самому популярному на гитхабе».
Оригинал и полный датасет: glukhov.org
#ai_agents
👍2
На выходных нашёл статью про то, что давно крутилось в голове. Про петли обратной связи в агентах
Под «петлёй» имеется в виду контур обратной связи — замкнутый цикл, где результат работы агента кто-то или что-то измеряет, и это измерение возвращается обратно и меняет поведение системы. Не «модель стала умнее», а «вокруг модели крутится цикл: сделал → измерили → подправили → снова сделал».
В пост сюда объёмом не уложился, так что опубликовал на Хабре.
#ai_agents #habr
Под «петлёй» имеется в виду контур обратной связи — замкнутый цикл, где результат работы агента кто-то или что-то измеряет, и это измерение возвращается обратно и меняет поведение системы. Не «модель стала умнее», а «вокруг модели крутится цикл: сделал → измерили → подправили → снова сделал».
В пост сюда объёмом не уложился, так что опубликовал на Хабре.
#ai_agents #habr
🤯1