Соцсети доживают свой век
Всё чаще замечаю, что листать динамическую ленту на ютубе, в твиттере, инсте и тиктоке в последнее время становится невыносимо, cоцсети завалены низкокачественным нейроконтентом.
Заметная часть коротких видео это говорилка в стиле озвучивателя местности, треш на тему популярных киновселенных, песенки среднего качества, ожившие картинки и прочий ai slop разного пошиба.
Площадки, на которых доминируют текстовые сообщения, заполнены пресным и безэмоциональным текстовым нейрослопом, в котором авторы даже не стараются почистить текст, убрав из него клише, присущие нейросетям. Каждый второй пост это лонгриды, каждый первый пост раздутая вода на киселе. Да даже мемчиков новых почти не появляется, а то, что попадается на глаза, лишь переосмысление древних скрижалей.
Соцсети, в которых доминируют картинки, заполнены людьми с "идеальными" фигурами, "идеальными" снимками идеальных "отпусков", сгенерированных зверей, детей и так далее.
Это я к тому веду, что настоящего как будто ничего не осталось. Отсюда возникает вопрос, а нужны ли социальные сети в эпоху ai slop в принципе? Какой от них прок, если пока значительная часть, а скоро и вовсе почти вся, контента будет сгенерирована модельками? Для кого публикуется весь этот контент, для других нейросетей, а как же реклама? Заметен ли уже негативный экономический эффект от засилья нейрослопа?
Подводя итог, хочу сказать, что мне кажется, что соцсети в привычном нам виде уже почти изжили себя, если так дальше пойдёт дело, то скоро их ждёт закат, и мне очень любопытно, что будет дальше.
Всё чаще замечаю, что листать динамическую ленту на ютубе, в твиттере, инсте и тиктоке в последнее время становится невыносимо, cоцсети завалены низкокачественным нейроконтентом.
Заметная часть коротких видео это говорилка в стиле озвучивателя местности, треш на тему популярных киновселенных, песенки среднего качества, ожившие картинки и прочий ai slop разного пошиба.
Площадки, на которых доминируют текстовые сообщения, заполнены пресным и безэмоциональным текстовым нейрослопом, в котором авторы даже не стараются почистить текст, убрав из него клише, присущие нейросетям. Каждый второй пост это лонгриды, каждый первый пост раздутая вода на киселе. Да даже мемчиков новых почти не появляется, а то, что попадается на глаза, лишь переосмысление древних скрижалей.
Соцсети, в которых доминируют картинки, заполнены людьми с "идеальными" фигурами, "идеальными" снимками идеальных "отпусков", сгенерированных зверей, детей и так далее.
Это я к тому веду, что настоящего как будто ничего не осталось. Отсюда возникает вопрос, а нужны ли социальные сети в эпоху ai slop в принципе? Какой от них прок, если пока значительная часть, а скоро и вовсе почти вся, контента будет сгенерирована модельками? Для кого публикуется весь этот контент, для других нейросетей, а как же реклама? Заметен ли уже негативный экономический эффект от засилья нейрослопа?
Подводя итог, хочу сказать, что мне кажется, что соцсети в привычном нам виде уже почти изжили себя, если так дальше пойдёт дело, то скоро их ждёт закат, и мне очень любопытно, что будет дальше.
❤24👍5
Forwarded from Поляков считает: AI, код и кейсы
Три протокола агентной коммерции: кто кого контролирует
За полгода появились три протокола, позволяющие ИИ покупать товары от имени человека: ACP от OpenAI и Stripe (сентябрь 2025), UCP от Google и Shopify (январь 2026), и вчера — YCP от Яндекса. Плюс десятки MCP-серверов для отдельных магазинов (вроде ВкусВилл).
Когда я вижу новый протокол, я не читаю пресс-релиз. Я смотрю на роли: кто покупатель, кто продавец, а главное — кто между ними и сколько власти у каждого.
🎭 Роли в агентной коммерции
В обычном e-commerce всё просто: покупатель и продавец (иногда мёрчант и платежная система). В агентном — между ними появляются посредники:
🔸 AI-провайдер — чей ИИ общается с покупателем (ChatGPT, Gemini, Алиса)
🔸 Платёжный провайдер — кто проводит деньги (Stripe, Yandex Pay, Visa)
🔸 Платформа — где живёт магазин (Shopify, KIT, 1С-Битрикс)
🔸 Владелец протокола — кто написал правила игры
🔸 Разработчик агента — кто-то кто создал своего агента поверх протокола
И вот тут начинается самое интересное.
🔍 Кто совмещает роли
В ACP роли формально разнесены: OpenAI делает ИИ, Stripe — платежи, Shopify — платформу. Спека открыта (Apache 2.0). Но нюанс: Instant Checkout в ChatGPT — только для одобренных партнёров, платёжный токен пока только через Stripe, а механизма discovery для внешних агентов ещё не существует. Спека открытая, канал — «по приглашениям».
В UCP Google разделил роли сильнее: 4 транспорта (REST, MCP, A2A, крипто-мандаты), 20+ партнёров включая Visa и Mastercard. Мерчант публикует манифест на /.well-known/ucp — это как robots.txt, только для ИИ-покупателей (пример https://store.moma.org/.well-known/ucp). Архитектурно — самый открытый. Но в продакшне пока тоже только Google AI Mode.
В YCP Яндекс — одновременно AI-провайдер (Алиса), платёжка (Yandex Pay), платформа (KIT) И владелец протокола. Четыре роли в одном. Спека закрыта, MCP не поддерживается, внешних агентов нет даже в теории.
⚡ Три вопроса, которые всё решают
1️⃣ Могу ли я подключить своего бота?
ACP — спека открыта, но в продакшне работает только ChatGPT, и мерчанты сертифицированы под него. UCP — архитектурно да (четыре транспорта, Agent-to-Agent), но в дикой природе тоже пока один канал. YCP — нет, только Алиса. По факту ни один протокол сегодня не даёт тебе взять спеку и запустить своего shopping-агента «из коробки».
2️⃣ Могу ли я влиять на то, как ИИ выбирает мой товар?
ACP вообще не покрывает discovery — только чекаут. UCP даёт мерчанту манифест возможностей. А в YCP Алиса сама решает: у неё агент «Найти дешевле», индикаторы цен и персональные скидки. Продавец не контролирует ранжирование.
3️⃣ А если я — не продавец, а покупатель-гик?
Допустим, я хочу агента для себя. Который покупает продукты по моим правилам, а не по правилам рекомендательной системы.
ACP и UCP теоретически это позволяют — спеки открыты, бери и пиши. На практике — discovery нет, оплата только через определенную платежную систему, работающих примеров ноль. YCP — даже теоретически не подключить.
А ведь еще предстоит решить вопрос возврата заказов (доступен только в UCP), работы с отзывами, ограничением возможностей скрапинга контента.
А вы ждёте агентную коммерцию? И что важнее — чтобы подключение было гарантированно простым, или чтобы можно было гибко настроить под себя?
----
Поляков считает — AI, код и кейсы
За полгода появились три протокола, позволяющие ИИ покупать товары от имени человека: ACP от OpenAI и Stripe (сентябрь 2025), UCP от Google и Shopify (январь 2026), и вчера — YCP от Яндекса. Плюс десятки MCP-серверов для отдельных магазинов (вроде ВкусВилл).
Когда я вижу новый протокол, я не читаю пресс-релиз. Я смотрю на роли: кто покупатель, кто продавец, а главное — кто между ними и сколько власти у каждого.
🎭 Роли в агентной коммерции
В обычном e-commerce всё просто: покупатель и продавец (иногда мёрчант и платежная система). В агентном — между ними появляются посредники:
🔸 AI-провайдер — чей ИИ общается с покупателем (ChatGPT, Gemini, Алиса)
🔸 Платёжный провайдер — кто проводит деньги (Stripe, Yandex Pay, Visa)
🔸 Платформа — где живёт магазин (Shopify, KIT, 1С-Битрикс)
🔸 Владелец протокола — кто написал правила игры
🔸 Разработчик агента — кто-то кто создал своего агента поверх протокола
И вот тут начинается самое интересное.
🔍 Кто совмещает роли
В ACP роли формально разнесены: OpenAI делает ИИ, Stripe — платежи, Shopify — платформу. Спека открыта (Apache 2.0). Но нюанс: Instant Checkout в ChatGPT — только для одобренных партнёров, платёжный токен пока только через Stripe, а механизма discovery для внешних агентов ещё не существует. Спека открытая, канал — «по приглашениям».
В UCP Google разделил роли сильнее: 4 транспорта (REST, MCP, A2A, крипто-мандаты), 20+ партнёров включая Visa и Mastercard. Мерчант публикует манифест на /.well-known/ucp — это как robots.txt, только для ИИ-покупателей (пример https://store.moma.org/.well-known/ucp). Архитектурно — самый открытый. Но в продакшне пока тоже только Google AI Mode.
В YCP Яндекс — одновременно AI-провайдер (Алиса), платёжка (Yandex Pay), платформа (KIT) И владелец протокола. Четыре роли в одном. Спека закрыта, MCP не поддерживается, внешних агентов нет даже в теории.
💡 Все три протокола — lock-in, вопрос лишь в жёсткости замка. YCP — железный засов (только Алиса). ACP — дверь открыта, но на защелке. UCP — ближе всех к реальной открытости, но пока тоже один работающий канал.
⚡ Три вопроса, которые всё решают
1️⃣ Могу ли я подключить своего бота?
ACP — спека открыта, но в продакшне работает только ChatGPT, и мерчанты сертифицированы под него. UCP — архитектурно да (четыре транспорта, Agent-to-Agent), но в дикой природе тоже пока один канал. YCP — нет, только Алиса. По факту ни один протокол сегодня не даёт тебе взять спеку и запустить своего shopping-агента «из коробки».
2️⃣ Могу ли я влиять на то, как ИИ выбирает мой товар?
ACP вообще не покрывает discovery — только чекаут. UCP даёт мерчанту манифест возможностей. А в YCP Алиса сама решает: у неё агент «Найти дешевле», индикаторы цен и персональные скидки. Продавец не контролирует ранжирование.
3️⃣ А если я — не продавец, а покупатель-гик?
Допустим, я хочу агента для себя. Который покупает продукты по моим правилам, а не по правилам рекомендательной системы.
ACP и UCP теоретически это позволяют — спеки открыты, бери и пиши. На практике — discovery нет, оплата только через определенную платежную систему, работающих примеров ноль. YCP — даже теоретически не подключить.
А ведь еще предстоит решить вопрос возврата заказов (доступен только в UCP), работы с отзывами, ограничением возможностей скрапинга контента.
🎯 Вот главный гэп: все три протокола заточены под связку «продавец → ИИ → покупатель». Но никто не строит протокол от лица покупателя — чтобы мой агент ходил по магазинам с моими требованиями и договаривался на моих условиях. Пока ближе всех к этому UCP с его Agent-to-Agent транспортом, но реализаций я пока не видел.
А вы ждёте агентную коммерцию? И что важнее — чтобы подключение было гарантированно простым, или чтобы можно было гибко настроить под себя?
----
Поляков считает — AI, код и кейсы
❤6
Поляков считает: AI, код и кейсы
Три протокола агентной коммерции: кто кого контролирует За полгода появились три протокола, позволяющие ИИ покупать товары от имени человека: ACP от OpenAI и Stripe (сентябрь 2025), UCP от Google и Shopify (январь 2026), и вчера — YCP от Яндекса. Плюс десятки…
Тоже много вожусь в последнее время с протоколами ACP и UCP, пока что чем-то более менее полезным кажется только UCP. Ну а протокол Яндекс это я так понимаю закрытая история и для моих кейсов не подходит.
Пока что кажется что выживет история вида WebMCP с тулами поиска и покупки на сайте, так как контроль над транзакциями и оплатами на стороне продавца будут, потому что то что есть сейчас делает из магазина просто базу данных с товарами, ценами и поиском, это имхо никуда не годится.
Пока что кажется что выживет история вида WebMCP с тулами поиска и покупки на сайте, так как контроль над транзакциями и оплатами на стороне продавца будут, потому что то что есть сейчас делает из магазина просто базу данных с товарами, ценами и поиском, это имхо никуда не годится.
❤4
Хабр
Инженер будущего не пишет код. Он строит обвязку для агентов
OpenAI 5 месяцев строили продукт без единой строчки ручного кода. Миллион строк, 1500 PR, 7 инженеров. Я разобрал их подход и понял - я уже так работаю. И вы тоже можете. Недавно OpenAI выложили...
Хабравчане не оценили пост Никиты @atlfreedom (моего коллеги по SGR Agent Core), про будущее разработки при помощи ИИ-агентов к которому мы неизбежно придём, и накидали ему кучу минусов, по мне так статья годная и очень хорошо описывает разработку через эдак полгода-год, а критика в массе своей притянута за уши.
Давайте накидаем Никите плюсиков, от нас не убудет.
Давайте накидаем Никите плюсиков, от нас не убудет.
1👍34💩8❤7🤮6🔥5👎4
Попробовал свежайшую Qwen 3.5 35b a3b, занятная моделька, единственный нюанс это количество ризонинга, которое она генерит на любой запрос, процитирую на этот счёт колкое замечания Валерия @neuraldeep в формате музыкальной картинки #meme
2❤11😁7👍3👏3
Pavel Zloi
Попробовал свежайшую Qwen 3.5 35b a3b, занятная моделька, единственный нюанс это количество ризонинга, которое она генерит на любой запрос, процитирую на этот счёт колкое замечания Валерия @neuraldeep в формате музыкальной картинки #meme
Оказалось, что чтобы qwen3 35b a3b отвечала быстро (без длинного ризонинга) на простые вопросы ей надо дать хотя бы один тул, пусть она его даже тригерить не будет.
1🔥21🤣19
Steampowered
Data Center on Steam
Build, cable, and automate. Assemble racks, servers, and switches, connect enough capacity for each app, earn money from processed data, and unlock gear and bigger customers with XP and reputation. Follow colored data packets as your center comes to life.
Внезапно в Steam вышел симулятор сетевого инженера Data Center, пока что доступна только демка, но 31го марта должна выйти полная версия.
🔥19😁6
В IDE от JetBrains добавили поддержу Cursor Agent через протокол ACP (Agent Communication Protocol), так что теперь можно пользоваться нормальной средой типа PyCharm, а не пародией на IDE на базе VS Code.
Инструкция как настроить тут, но перед тем как пробовать стоит обновить IDE до версии 2025.3.3, иначе не будет кнопочек нужных.
Из замеченных особенностей:
- Три основных агента (Agent, Plan, Ask) есть
- Можно выбрать любую модель, но Auto one love
- Нельзя разрешить выполнять все команды (типа Allow all как Cursor)
- Недостаёт вывода выполняемых команд через тул Run Command
- Недостаёт информации о заполненности контекста
- Нельзя отредактировать нужное сообщение. можно только сделать stop а потом rollback
PS. Помимо курсора можно добавить в этот плагин и многие другие кодовые агенты, например qwen code или goose, или opencode и так далее.
Инструкция как настроить тут, но перед тем как пробовать стоит обновить IDE до версии 2025.3.3, иначе не будет кнопочек нужных.
Из замеченных особенностей:
- Три основных агента (Agent, Plan, Ask) есть
- Можно выбрать любую модель, но Auto one love
- Нельзя разрешить выполнять все команды (типа Allow all как Cursor)
- Недостаёт вывода выполняемых команд через тул Run Command
- Недостаёт информации о заполненности контекста
- Нельзя отредактировать нужное сообщение. можно только сделать stop а потом rollback
PS. Помимо курсора можно добавить в этот плагин и многие другие кодовые агенты, например qwen code или goose, или opencode и так далее.
1👍13🔥9❤4🤡4
Вокруг
Например, у @gonzo_ML был хороший разбор статьи Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (arxiv:2602.11988). Если совсем кратко, то вывод там неприятный, но логичный - автоматически сгенерированные контекстные файлы на уровне репозитория часто не помогают, а скорее мешают. Они снижают долю успешно решённых задач и одновременно увеличивают стоимость инференса. Модель вместо решения задачи уходит в блуждание по кодовой базе и бесконечное "изучение архитектуры", порождая галюнчики.
Из свеженького, что меня побудило написать этот пост:
- в мой любимый KodaCode добавили поддержку
- @max_about_ai была здравая мысль про документацию в эпоху AI
- а у @countwithsasha был пост про то, как вообще собирать агента из скиллов
То есть с моей точки зрения рынок постепенно обрастает всем этим зоопарком форматов, манифестов и "магических" markdown-файлов.
Проблема не в том, что агенту не нужен контекст (без контекста, увы, никак). Проблема в том, что люди пытаются запихнуть в один файл вообще всё подряд - архитектуру, команды запуска, ограничения, стили кодинга, особенности тестирования, бизнес-логику, карту директорий, описание CI, правила коммитов, правила работы с миграциями, требования к безопасности и ещё сверху тысячу строк "полезных пояснений". В итоге на каждом запросе в контекст летят тысячи, а на сложных проектах и десятки тысяч токенов текста, большая часть из которых в конкретный момент просто не нужна.
И вот тут у меня каждый раз возникает простой вопрос - а кому вообще выгодна эта мода на огромные универсальные
Поэтому на мой взгляд куда более практичный путь давно уже показал Cursor со своими Cursor Rules. Не потому что это какой-то идеальный формат, а потому что там хотя бы немного подумали над логикой динамического наполнения контекста в процессе работы кодового агента.
В Cursor правила можно дробить на небольшие, специализированные и адресные кусочки. Какие-то применять всегда, какие-то только по glob-маскам, какие-то подключать вручную, какие-то держать на уровне монорепы, а какие-то внутри конкретного подпроекта. То есть вместо одного аморфного
Чуть более подробно почитать про Cursor Rules можете тут, там я рассказываю как раскладывать правила по
Подытожу, документация агентам нужна, правила нужны, скиллы нужны, но всё это должно быть модульным, иначе вместо управляемого контекста вы просто сжигаете токены.
AGENTS.md и всяких "универсальных" файлов для агентов в последнее время как-то слишком много разговоров. Особенно забавно это выглядит на фоне того, что рядом уже начали появляться вполне трезвые наблюдения о том, что польза таких файлов слегка преувеличена.Например, у @gonzo_ML был хороший разбор статьи Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (arxiv:2602.11988). Если совсем кратко, то вывод там неприятный, но логичный - автоматически сгенерированные контекстные файлы на уровне репозитория часто не помогают, а скорее мешают. Они снижают долю успешно решённых задач и одновременно увеличивают стоимость инференса. Модель вместо решения задачи уходит в блуждание по кодовой базе и бесконечное "изучение архитектуры", порождая галюнчики.
Из свеженького, что меня побудило написать этот пост:
- в мой любимый KodaCode добавили поддержку
SKILLS.md, и AGENTS.md- @max_about_ai была здравая мысль про документацию в эпоху AI
- а у @countwithsasha был пост про то, как вообще собирать агента из скиллов
То есть с моей точки зрения рынок постепенно обрастает всем этим зоопарком форматов, манифестов и "магических" markdown-файлов.
Но лично мне вся эта практика с одним условным большим `AGENTS.md` на 10к токенов кажется порочной.
Проблема не в том, что агенту не нужен контекст (без контекста, увы, никак). Проблема в том, что люди пытаются запихнуть в один файл вообще всё подряд - архитектуру, команды запуска, ограничения, стили кодинга, особенности тестирования, бизнес-логику, карту директорий, описание CI, правила коммитов, правила работы с миграциями, требования к безопасности и ещё сверху тысячу строк "полезных пояснений". В итоге на каждом запросе в контекст летят тысячи, а на сложных проектах и десятки тысяч токенов текста, большая часть из которых в конкретный момент просто не нужна.
И вот тут у меня каждый раз возникает простой вопрос - а кому вообще выгодна эта мода на огромные универсальные
AGENTS.md? Разработчику точно нет. Агенту тоже не особо. Зато очень выгодно вендору, который продаёт доступ к моделям по API. Чем больше токенов вы стабильно прокидываете в каждый запрос, тем больше вы тратите токенов, тем больше зарабатывает вендор.Поэтому на мой взгляд куда более практичный путь давно уже показал Cursor со своими Cursor Rules. Не потому что это какой-то идеальный формат, а потому что там хотя бы немного подумали над логикой динамического наполнения контекста в процессе работы кодового агента.
В Cursor правила можно дробить на небольшие, специализированные и адресные кусочки. Какие-то применять всегда, какие-то только по glob-маскам, какие-то подключать вручную, какие-то держать на уровне монорепы, а какие-то внутри конкретного подпроекта. То есть вместо одного аморфного
AGENTS.md вы получаете управляемую систему контекста с дюжиной небольших файлов, из которых подтягивается только то, что действительно относится к текущему файлу, текущей задаче или текущему этапу работы.Не "один файл, в котором описана вся подноготная проекта", а "набор маленьких правил, каждое из которых отвечает за свою область".
Чуть более подробно почитать про Cursor Rules можете тут, там я рассказываю как раскладывать правила по
.cursor/rules/, как ссылаться из них на документацию и почему такой формат удобнее в реальных проектах, а вот тут ещё один пост, где я показывал как использовать правила, документацию и TDD/BDD-подход в связке с агентом.Подытожу, документация агентам нужна, правила нужны, скиллы нужны, но всё это должно быть модульным, иначе вместо управляемого контекста вы просто сжигаете токены.
5🔥21💯8❤6👍5🥱1🤣1😴1
Pavel Zloi pinned «Skills это как MCP-сервер, но... Давненько у меня в голове назревала эта публикация. Чем больше пользуюсь Skills и MCP-серверами, тем больше понимаю, что по сути они очень похожи, хотя по форме есть нюансики. Сходства 1. Есть некая сущность (Skill/MCP);…»
С огромным удовольствием прослушал аудиокнигу Сценарии будущего. Как жить и работать в мире захваченном нейросетью и роботами за авторством Руслана Юсуфова.
В ней автор выступает в роли футуролога и представляет нашему вниманию возможные варианты технологического будущего, есть сценарии утопичные, есть антиутопичные, про засилие нейросетей, про киборгизацию, про генную инженерию, про сегментацию общества, про применение нейросетей в экономике, социологии и так далее.
Мне книга очень понравилась, рекомендую её всем, кто задумывается о вероятных сценариях развития нашего мира и общества.
В ней автор выступает в роли футуролога и представляет нашему вниманию возможные варианты технологического будущего, есть сценарии утопичные, есть антиутопичные, про засилие нейросетей, про киборгизацию, про генную инженерию, про сегментацию общества, про применение нейросетей в экономике, социологии и так далее.
Мне книга очень понравилась, рекомендую её всем, кто задумывается о вероятных сценариях развития нашего мира и общества.
books.yandex.ru
Аудиокнига Сценарии будущего. Как жить и работать в мире, захваченном нейросетью и роботами, Руслан Юсуфов — слушать бесплатно…
Аудиокнига «Сценарии будущего. Как жить и работать в мире, захваченном нейросетью и роботами» Руслан Юсуфов слушать полную версию онлайн бесплатно в исполнении Руслан Юсуфов на сайте электронной библиотеки Яндекс Книг.
2❤16👍8👎2
Хабр
L в аббревиатуре LLM означает «ложь»
Если верить хайпу, та отрасль разработки ПО, к которой мы привыкли, уже мертва. Однако странно, что, несмотря на годы работы с ИИ-инструментарием, результаты выглядят, ощущаются и работают примерно...
Нейросети захватывают мир - что делать?
Прочел на Хабре пост "L в аббревиатуре LLM означает «ложь»" и там в очередной раз поднимается популярная в узких кругах тема. Автор рассуждает о том, что нейросети никуда не годятся, что они лишь переосмысляют уже придуманное до них, что разработчики с ИИ только плодят технический долг, а самый правильный путь это отказаться от агентов, вайбкодинга и прочих новых инструментов разработки.
Самое забавное тут вот что, текст ИМХО местами очень уж похож на сгенерированный, я конечно не эксперт по детекту, но глаз уж дюже цепляется за характерные клише, которыми грешат модельки. Может не весь текст, а лишь часть, но диссонанс имеется, кажется будто одной рукой автор критикует нейросети, другой, вероятно, ими же и пользуется.
Другой забавный момент в том, что у данной публикации очень большое количество положительных реакций и комментариев, автор прям очень удачно попал в сердечко читателей Хабр. Нюанc только в том, что он не предложил альтернативу, что делать на меняющемся рынке?
И вот это, на мой скромный взгляд, показательная история.
Потому что перед нами нео-луддиты. Не в старом смысле, где люди шли и ломали станки, а в новом. Очень легко ворчать, писать осуждающие тексты, делать вид, что прогресс переоценен, а все новое - это игрульки и ерунда. Суть, впрочем, не меняется. Когда технология начинает резко менять рынок, всегда находятся те, кто пытается не адаптироваться, а объявить саму перемену ошибкой, а создателей виноватыми (в силу возраста или из-за страха потерять уютное место, не суть важно).
И особенно занятно наблюдать это в моей любимой АйТишечке, инженеров годами учили быть (почти) машиной, учили писать (почти) "идеальный" код максимально быстро, вписываться в процессы, ревьюить перфоманс, где-то даже строками кода. А потом внезапно пришли настоящие машины и выяснилось, что они это делают быстрее и в умелых руках даже лучше. И тут у части людей вместо рефлексии началась teh drama.
Хотя для меня решение очевидно. Если значимую часть рутины теперь можно спихнуть на агентов и нейронки, то это не горе, а радость. Можно меньше заниматься механической работой и больше думать, проектировать, проверять, собирать системы, делать продукты, строить агентов, автоматизировать свою работу. То есть заниматься как раз более интересными вещами, а не вот этим вот всем. Кстати, очень рекомендую почитать пост "[Bus Factor] Почему ваша незаменимость — это архитектурная уязвимость (SPOF), а не повод для гордости" на Хабр.
Страдают ИХМО от этого, как мне видится, прежде всего те, кто пришел в IT только ради денег или привык к уютному месту, где можно было делать минимум работы и при этом жить очень неплохо, а прогресс постучал в дверь и намекнул, что так будет не всегда, и вероятность того, что первым делом заменят самых незаменимых с каждым днём всё выше и выше, и вот похоже это многих беспокоит сильнее всего.
Поэтому вся эта риторика про "не надо ваших агентов", "откажитесь от новых инструментов", "все это ненастоящая разработка" звучит не столько как взвешенная критика, а скорее как страх перемен. В этом смысле происходящее очень хорошо ложится на темы из книги "Сценарии будущего", о которой я рассказывал намедни. Там как раз много про то, что вероятные сценарии развития технологий сопровождаются социальными потрясениями, попытками объявить новый этап неправильным и бороться с ним. Но при этом важно осознавать, что прогрессу в целом абсолютно все равно, нравится он кому-то или нет, он просто есть.
Лично я стараюсь смотреть на тенденцию трезво, не быть незаменимым и заранее стелить себе соломку, да, мир меняется, да, общество меняется, всё меняется, что делать? Мой выбор учиться, учиться учиться, перестраиваться, заходить в новые инструменты и осваивать нейронки на уровне практики и теории.
Прочел на Хабре пост "L в аббревиатуре LLM означает «ложь»" и там в очередной раз поднимается популярная в узких кругах тема. Автор рассуждает о том, что нейросети никуда не годятся, что они лишь переосмысляют уже придуманное до них, что разработчики с ИИ только плодят технический долг, а самый правильный путь это отказаться от агентов, вайбкодинга и прочих новых инструментов разработки.
Самое забавное тут вот что, текст ИМХО местами очень уж похож на сгенерированный, я конечно не эксперт по детекту, но глаз уж дюже цепляется за характерные клише, которыми грешат модельки. Может не весь текст, а лишь часть, но диссонанс имеется, кажется будто одной рукой автор критикует нейросети, другой, вероятно, ими же и пользуется.
В комментариях подсказали, что этот пост перевод The L in "LLM" Stands for Lying, поэтому вопрос про похожесть текста на сгенерированный снимается.
Другой забавный момент в том, что у данной публикации очень большое количество положительных реакций и комментариев, автор прям очень удачно попал в сердечко читателей Хабр. Нюанc только в том, что он не предложил альтернативу, что делать на меняющемся рынке?
И вот это, на мой скромный взгляд, показательная история.
Потому что перед нами нео-луддиты. Не в старом смысле, где люди шли и ломали станки, а в новом. Очень легко ворчать, писать осуждающие тексты, делать вид, что прогресс переоценен, а все новое - это игрульки и ерунда. Суть, впрочем, не меняется. Когда технология начинает резко менять рынок, всегда находятся те, кто пытается не адаптироваться, а объявить саму перемену ошибкой, а создателей виноватыми (в силу возраста или из-за страха потерять уютное место, не суть важно).
И особенно занятно наблюдать это в моей любимой АйТишечке, инженеров годами учили быть (почти) машиной, учили писать (почти) "идеальный" код максимально быстро, вписываться в процессы, ревьюить перфоманс, где-то даже строками кода. А потом внезапно пришли настоящие машины и выяснилось, что они это делают быстрее и в умелых руках даже лучше. И тут у части людей вместо рефлексии началась teh drama.
Хотя для меня решение очевидно. Если значимую часть рутины теперь можно спихнуть на агентов и нейронки, то это не горе, а радость. Можно меньше заниматься механической работой и больше думать, проектировать, проверять, собирать системы, делать продукты, строить агентов, автоматизировать свою работу. То есть заниматься как раз более интересными вещами, а не вот этим вот всем. Кстати, очень рекомендую почитать пост "[Bus Factor] Почему ваша незаменимость — это архитектурная уязвимость (SPOF), а не повод для гордости" на Хабр.
Страдают ИХМО от этого, как мне видится, прежде всего те, кто пришел в IT только ради денег или привык к уютному месту, где можно было делать минимум работы и при этом жить очень неплохо, а прогресс постучал в дверь и намекнул, что так будет не всегда, и вероятность того, что первым делом заменят самых незаменимых с каждым днём всё выше и выше, и вот похоже это многих беспокоит сильнее всего.
Поэтому вся эта риторика про "не надо ваших агентов", "откажитесь от новых инструментов", "все это ненастоящая разработка" звучит не столько как взвешенная критика, а скорее как страх перемен. В этом смысле происходящее очень хорошо ложится на темы из книги "Сценарии будущего", о которой я рассказывал намедни. Там как раз много про то, что вероятные сценарии развития технологий сопровождаются социальными потрясениями, попытками объявить новый этап неправильным и бороться с ним. Но при этом важно осознавать, что прогрессу в целом абсолютно все равно, нравится он кому-то или нет, он просто есть.
Лично я стараюсь смотреть на тенденцию трезво, не быть незаменимым и заранее стелить себе соломку, да, мир меняется, да, общество меняется, всё меняется, что делать? Мой выбор учиться, учиться учиться, перестраиваться, заходить в новые инструменты и осваивать нейронки на уровне практики и теории.
❤20👍14💯9👎1🤡1🥱1😴1
YouTube
Pax Historia Introduction
Official Pax Historia Statistics Video for Investors
#history #historia #games #introduction #video #youtube
#history #historia #games #introduction #video #youtube
Песочница
Похоже я нашёл первый случай когда несколько агентов работающих параллельно это хорошая идея, встречайте игру Pax Historia.
Данная игра реализована в виде песочницы, навевает вайбы Hears of Iron, при запуске пользователь задает стартовый сценарий, далее выбирает страну за которую будет играть и модель под капотом агентов, при этом каждой страной управляет свой полноценный агент, с памятью, моделью и так далее, смотрите мой пост на тему агентов.
Далее перед пользователем открывается игровая политическая карта и слева чатик, пользователь пишет своё действие, потом нажимает кнопку промотки времени, происходят события и можно почитать, что получилось и как наши действия повлияли на политическую карту. Самое занятное, что другие страны (агенты) тоже живут своей жизнью и одновременно с вашими действиями выполняют какие-то свои (у них происходят разные события укладывающиеся в парадигму данного агента и его сценария).
Очень любопытный проект, рекомендую ознакомиться.
Похоже я нашёл первый случай когда несколько агентов работающих параллельно это хорошая идея, встречайте игру Pax Historia.
Данная игра реализована в виде песочницы, навевает вайбы Hears of Iron, при запуске пользователь задает стартовый сценарий, далее выбирает страну за которую будет играть и модель под капотом агентов, при этом каждой страной управляет свой полноценный агент, с памятью, моделью и так далее, смотрите мой пост на тему агентов.
Далее перед пользователем открывается игровая политическая карта и слева чатик, пользователь пишет своё действие, потом нажимает кнопку промотки времени, происходят события и можно почитать, что получилось и как наши действия повлияли на политическую карту. Самое занятное, что другие страны (агенты) тоже живут своей жизнью и одновременно с вашими действиями выполняют какие-то свои (у них происходят разные события укладывающиеся в парадигму данного агента и его сценария).
Очень любопытный проект, рекомендую ознакомиться.
7❤8🔥2
Прокачал за вчера coddy.
Запилил такие вот фичи:
- добавил в observer синхронизацию всех issues и pull_requests на старте системы
- переработал логику раскладывания issues и pull_requests по разным папкам (рис.2)
- добавил флоу автоматического тестирования PR
- флоу автоматической простановки git tag при мердже PR
- флоу, который запускает сборку docker-образа и пушит на docker hub
- и много других небольших правок и оптимизации.
Исходники тут::
https://github.com/coddy-project/coddy-bot
Готовые образы тут:
https://hub.docker.com/r/evilfreelancer/coddybot
Там же на Docker Hub будет подробная инструкция как запустить контейнер.
Запилил такие вот фичи:
- добавил в observer синхронизацию всех issues и pull_requests на старте системы
- переработал логику раскладывания issues и pull_requests по разным папкам (рис.2)
- добавил флоу автоматического тестирования PR
- флоу автоматической простановки git tag при мердже PR
- флоу, который запускает сборку docker-образа и пушит на docker hub
- и много других небольших правок и оптимизации.
Исходники тут::
https://github.com/coddy-project/coddy-bot
Готовые образы тут:
https://hub.docker.com/r/evilfreelancer/coddybot
Там же на Docker Hub будет подробная инструкция как запустить контейнер.
1🔥13❤4👍1
GitHub
GitHub - sipeed/picoclaw: Tiny, Fast, and Deployable anywhere — automate the mundane, unleash your creativity
Tiny, Fast, and Deployable anywhere — automate the mundane, unleash your creativity - sipeed/picoclaw
Crab People
Последовал примеру Валерия @neuraldeep и поднял себе на домашней малинке PicoClaw, решил начать с простых задач, типа работы с github и поиска в сети, очень приятно и легко всё настраивается, хотя возможно людям без опыта работы с linux будет местами сложновато, так как надо будет прописывать allow list команд который можно выполнять, но это в любом случае в разы более качественный и удобный проект нежели OpenClaw.
Запустил всё ессно в docker-конейнере.
Чуть поразбирался с этим проектом, он состоит из 3х контейнеров:
- onboard - хитрый контейнер который генерит пустой конфиг
- gateway - контейнер который запускает ботов, без web-интерфейса
- launcher - контейнер который включает в себя все функции gateway, плюс имеет web-интерфейс
В админке (launcher) скажем так не очень много возможностей предусмотрено, хотя вполне достаточно и наверно больше и не требуется, однако, авторизации нет, так что его в формате сайтика за пределы сети выпускать не стоит, поэтому я пока еду на клиенте (gateway).
Ещё пока разбираюсь, но пользоваться приятно.
Последовал примеру Валерия @neuraldeep и поднял себе на домашней малинке PicoClaw, решил начать с простых задач, типа работы с github и поиска в сети, очень приятно и легко всё настраивается, хотя возможно людям без опыта работы с linux будет местами сложновато, так как надо будет прописывать allow list команд который можно выполнять, но это в любом случае в разы более качественный и удобный проект нежели OpenClaw.
Запустил всё ессно в docker-конейнере.
Чуть поразбирался с этим проектом, он состоит из 3х контейнеров:
- onboard - хитрый контейнер который генерит пустой конфиг
- gateway - контейнер который запускает ботов, без web-интерфейса
- launcher - контейнер который включает в себя все функции gateway, плюс имеет web-интерфейс
В админке (launcher) скажем так не очень много возможностей предусмотрено, хотя вполне достаточно и наверно больше и не требуется, однако, авторизации нет, так что его в формате сайтика за пределы сети выпускать не стоит, поэтому я пока еду на клиенте (gateway).
Ещё пока разбираюсь, но пользоваться приятно.
👍16
Обычно я редко пишу про релизы новых языковых моделей, но это случай выдающийся, вчера компания Nvidia зарелизила NVIDIA Nemotron v3, это линейка MoE моделей, на 120B параметров всего и 12B активных.
Нашему внимания представлены несколько вариантов сжатия, самый любопытный из них лично для меня nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4, так как этот формат является почти полным аналогом MXFP4 (подробнее тут).
Позиционируется данная модель как решение для продвинутых on-prem агентов (циферки и правда впечатляют), а так же как конкурент:
- openai/gpt-oss-120b (MoE, у которой лишь 5B активных и только MXFP4)
- Qwen/Qwen3.5-122B-A10B (MoE у которой 10B активных, но нет MXFP4 версий, только BF16, F16 и FP8)
Ну и так вот, примечательно в новом Немотроне то, что у неё 12B активных, что почти является рубиконом эмерджентности (13B параметров), плюс нативная поддержка FP4, а это значит для её запуска на контексте в 128к (но продел до 1m) токенов хватит 86Гб VRAM, почти как gpt-oss-120b.
Нашему внимания представлены несколько вариантов сжатия, самый любопытный из них лично для меня nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4, так как этот формат является почти полным аналогом MXFP4 (подробнее тут).
Позиционируется данная модель как решение для продвинутых on-prem агентов (циферки и правда впечатляют), а так же как конкурент:
- openai/gpt-oss-120b (MoE, у которой лишь 5B активных и только MXFP4)
- Qwen/Qwen3.5-122B-A10B (MoE у которой 10B активных, но нет MXFP4 версий, только BF16, F16 и FP8)
Ну и так вот, примечательно в новом Немотроне то, что у неё 12B активных, что почти является рубиконом эмерджентности (13B параметров), плюс нативная поддержка FP4, а это значит для её запуска на контексте в 128к (но продел до 1m) токенов хватит 86Гб VRAM, почти как gpt-oss-120b.
👍13❤3
О чём молчат Антропики (про скилы, опять)
Концепция Skills, которую предложили Антропики не так давно, мне очень нравится, я несколько раз писал на эту тему (раз, два, три), часто пользуюсь готовыми скилами, а какие-то пишу сам, но есть у них один фатальный недостаток, о котором, к моему большому удивлению, мало кто задумывается, эту проблему можно описать как кроссплатформенность компилируемых бинарных файлов.
К примеру, у меня есть скил, который вызывает некий бинарник, скомпилированный под x86/64, и есть Raspberry Pi на процессоре ARM64, допустим, я хочу установить этот скил, он устанавливается, но по факту бесполезен, так как архитектура бинарника и моего процессора не совпадает, можно придумать и другой пример, скажем, бинарь собран под Linux, но пользователь хочет установить скил на Windows.
Из вероятных решений, которые приходят на ум, это процедура установки, когда агент сам скачивает бинарник через условный curl/wget под нужную архитектуру (в момент первого вызова), сам закидывает в папку с бинарниками и выполняет полезную работу, но что-то подобных скилов мне ещё пока не попадалось, все, что видел, предлагают отдельно выполнить установку бинаря и отдельно ставить скил на систему, в которой нужный бинарь уже есть.
А как вы решаете эту проблему?
Концепция Skills, которую предложили Антропики не так давно, мне очень нравится, я несколько раз писал на эту тему (раз, два, три), часто пользуюсь готовыми скилами, а какие-то пишу сам, но есть у них один фатальный недостаток, о котором, к моему большому удивлению, мало кто задумывается, эту проблему можно описать как кроссплатформенность компилируемых бинарных файлов.
К примеру, у меня есть скил, который вызывает некий бинарник, скомпилированный под x86/64, и есть Raspberry Pi на процессоре ARM64, допустим, я хочу установить этот скил, он устанавливается, но по факту бесполезен, так как архитектура бинарника и моего процессора не совпадает, можно придумать и другой пример, скажем, бинарь собран под Linux, но пользователь хочет установить скил на Windows.
Из вероятных решений, которые приходят на ум, это процедура установки, когда агент сам скачивает бинарник через условный curl/wget под нужную архитектуру (в момент первого вызова), сам закидывает в папку с бинарниками и выполняет полезную работу, но что-то подобных скилов мне ещё пока не попадалось, все, что видел, предлагают отдельно выполнить установку бинаря и отдельно ставить скил на систему, в которой нужный бинарь уже есть.
А как вы решаете эту проблему?
❤7🤣2💯1