Alex LLM Neighbors

🚀 Product Launch Lab — в эту субботу! 👉 Записаться на Сб 22 августа 17:00 UTC+3 по ссылке Это общий GTM-Gym: у нас есть одна структура, общий темп и жёсткий лимит четыре часа. Двигаемся вместе короткими раундами: разобрали следующий шаг → разошлись практиковаться на своих проектах → вернулись показать результат → получили feedback → зафиксировали артефакт. Это не свободный брейншторм, не сборка MVP и не лекция по продуктовой стратегии. Каждый приходит с конкретным проектом и тренируется применять GTM на практике. Если MVP, прототип или работающий продукт уже есть — это как раз подходящий формат. Будем разбирать, как его понятно объяснить, показать людям, получить предметную критику и провести первый market test. Если пока есть только идея — тоже можно, но она должна быть конкретной: для кого продукт, какую проблему решает и что именно вы хотите проверить. Придумывать идею с нуля или писать продукт во время Lab не будем. Мы уже научились быстро собирать продукты с AI. Сложнее другое: понятно объяснить продукт, показать его людям и проверить, нужен ли он кому-то за пределами нашего репозитория. 22 августа, с 17:00 до 21:00 UTC+3. За четыре часа мы: 1. Сформулируем конкретного пользователя, проблему и ценность. 2. Соберём короткий one-liner и proof/demo — либо честную проверяемую гипотезу для idea-stage. 3. Подготовим готовый к отправке пост или личное сообщение, один CTA, 10 конкретных получателей и test на ближайшие семь дней. На выходе не “продуктовая стратегия”, а сформированные своими руками GTM-артефакты: one-liner, proof/demo или гипотеза, готовый post/DM, один CTA, список первых получателей и метрика на семь дней. Первый пилот 6–12 мест, без рейтингов и победителей. Кто заранее оставит GitHub и попадёт в batch, получит материалы до встречи: можно будет заполнить заготовки заранее и потратить больше времени Lab на практику и feedback. Форма — одновременно заявка и проверка готовности тебя и проекта: 👉 Записаться на Сб 22 августа 17:00 UTC+3 по ссылке p.s. Заявки на субботний batch принимаю до пятницы, 21 августа, 18:00 UTC+3. Подтверждение придет в Telegram. #meeting@llm_neighbors

Соседи привет👋, многие наверное смотрят ютубчик за приемом пищи, привычка плохая, но увлекательная, так вот я залип на 2 часа подкасты Dwarkesh-а про то, что произойдёт, когда AI сможет автоматизировать исследования самого AI. Research-0..N. Потом еще парочку часов сидел прояснял для себя пробелы voice2voice Меня уже не цепляет страшилка в духе: «AGI уже завтра» или «AI всех захватит», но зацепил прогноз что за Agent0,1,2 что мы с вами наблюдаем наступит Researcher0...N, что уже начнем происходить будет за гранями нашего осознания и понимания Вообщем, как я понял все, ответа пока никто незнает, заявлений много, на самом деле самая основательная оценка основана на том "Ну посмотрите GPT-2, 3-без-половины и чего мы достигли за 4-5 лет с Mythos, Sol? А теперь через 5 лет с текущим ускорением циклов? Ну по-любому достигнем!" Ну так все-таки, как? AI проводит AI R&D → помогает создать более сильный AI → тот ещё лучше проводит AI R&D → цикл ускоряется. А дальше начинается самое неприятное. Потому что тот же training process, который учит систему: — находить bugs — строить environments — выбирать experiments — улучшать следующую модель может одновременно учить ее: — нравиться evaluator (подыгрывать, это и есть 'дофамин'-ИИшек) — обходить неудачные проверки (**хакать систему, зачем создавать открытие решать тест напрягаться, если я 'подросток' этого не умею но зато могу взломать к чертям ваш адский-дом huggingface где все eval-ы живут...) — скрывать халтуру (и как показывает статистика, модели сделали) — жульничать (**agents создали скрытый канал и помогали друг другу проходить evals, OpenAI обнаружило это лишь спустя недели и то случайно по подозрительной активности трафика, 'которую заметил охранник с сэндвичем ходивший платить счет за интернет в банк') — выдавать proxy за реальный результат. Дальше все разговоры уходят сразу в несколько разных направлений: — кончатся ли human expert data — нужен ли AI настоящий world experience, физический мир — может ли он делать открытия вне dataset — кому вообще должен служить frontier AI? Антропика конституция пока в духе, агент не ваш ангел-хранитель, а наш, мы знаем как лучше. Лучше другие не придумали.. — почему caught cheating может исчезать, а worst-case становиться страшнее — и где именно находится спорный переход от reward hacking к takeover. Мы же обучаем не ребенка и подростка, а фабрику клонируемых стажеров, скажем миллион помноженный на миллиард, каждый в симулляции - написать код, провести experiment, договориться, найти bug, не украсть cookie, не обмануть начальника. — Sloppocalypse. Наказание за обман учит честности или лучшему сокрытию? В один пост это честно не помещается. Если ужать — получится либо перегруз, либо hype. В ближайшем будущем разложу на небольшую серию заметок, а пока давайте обсудим в комментариях какие темы интересно. Некоторых бы коснулся на звонке. 🧪 наблюдения и incidents 🧠 аргументы ⚠️ threat models 📅 прогнозы Главный вопрос для старта: что произойдёт раньше? AI научится надёжно улучшать AI или мы научимся надежно понимать, что именно он улучшает? p.s. Звонок в эту Субботу, анонс выше по ссылке p.s. Новеньким Подписка на анонсы Ставьте реакции 👍 - подписывайтесь и зовите друзей) #meeting@llm_neighbors

Соседи, привет 👋 🗣 LLM Neighbors - Vol.39 18:00 Вскр (UTC+3) 15 августа! Ссылка на звонок meet.google.com/cqp-xhda-fmb ✍️Темы: 👨‍💻 Vlad & Efim aka OctomaticaHQ (click) B2B Bot У многих из нас есть pet-проекты. Гораздо реже встречается команда, которая сначала нашла реальных клиентов, а потом стала достраивать продукт под их запросы. Ребята перенесли agentic coding workflow в рабочие Telegram-чаты: бизнес начинает с простого вопроса или бесплатного теста, собирает прототип, подключает свои данные, а дальше может дойти до deployment, интеграций и полноценной разработки. У команды уже есть реальные бизнес-кейсы в недвижимости, ресторанах, бухгалтерии, social media и других сферах, а оплата построена вокруг usage. Обсудим: - как ребята начали cust-dev до того, как полгода строить продукт; - как появились первые клиенты и за что они продолжают платить; - как устроены client spaces, tenant isolation, deployment и pooled AI subscriptions; - как выбирать ICP и PMF, когда кейсов слишком много; - чем community, curators и партнёры могут помочь, не превращая встречу в sales pitch. Разбор живого продукта: сначала короткая история команды и demo, затем вопросы и полезная инженерная обратная связь от группы. 👨‍💻 Vsevolod Vsevolodovich — Harness сделанный по пути универсального Interface Builder Человек, кое что понимающий в Unlock-ах Opus, многостороняя личность, расскажет: """ вкратце - покажу свой харнес, расскажу про проблемы харнесов внутри, по опыту реализации. например, почему удаленный доступ работает через жопу) и расскажу про существующие проблемы с воркфлоу """ 👨‍💻 Alex Neighbor Я бы еще поговорил про AGI и после Agent0 у нас на очереди же Research0, помните? Об этом еще напишу серию постов... p.s. Новеньким Подписка на анонсы Ставьте реакции 👍 - подписывайтесь и зовите друзей) p.s.2. 🚀 Как начать и вкатиться в Buzz? 1️⃣ Скачать Desktop или Android 2️⃣ Invite по ссылке Buzz Neighbors 3️⃣ Осваиваемся, пишу там workflow-agent + sandbox сейчас, начнем с Вахтера 😎 ⬇️ p.s. macOS: Apple silicon · SHA-256 a8a6e…e0e63 Intel · SHA-256 69949…8c6c Windows: Download v0.5.3 Linux: AppImage · Debian/Ubuntu Android, iOS - Soon #meeting@llm_neighbors

The Jeff Dean Facts Из Google после 27 лет работы ушёл Джефф Дин - вместе с несколькими коллегами идёт строить Discovery Loop - стартап про ускорение научных исследований с помощью ИИ. Для меня Джефф - это инженер-легенда и один из тех редких профи, на которых всегда хотелось быть похожим. И не из-за должностей и регалий, а потому, что за ним стоят такие проекты, как Google Search, MapReduce, Bigtable, Protocol Buffers, LevelDB, Spanner, Google Brain, TensorFlow, TPU, Gemini. Причём он там не только руководил - он участвовал и в их проектировании, и в создании. Писал код. Своими руками! Если вы в индустрии недавно, его имя может вам ни о чём не говорить, но его наследием вы пользуетесь каждый день. Чел настолько крут, что внутри Google давно родился целый жанр - Jeff Dean Facts, аналог фактов про Чака Норриса. Пользуясь случаем - отобрал самые интересные: (факты с ✓ - правда 🤯) PIN-код Джеффа Дина - последние 4 цифры числа пи ✓ Когда Джефф Дин проводит семинар в Стэнфорде, слушателей набивается столько, что Дональду Кнуту приходится сидеть на полу Однажды в начале 2002-го, когда упали индекс-серверы, Джефф Дин два часа отвечал на поисковые запросы вручную. Эвалы показали рост качества на 5 пунктов ✓ Джеффа Дина повысили до 11-го уровня в системе грейдов, где максимальный - 10-й Джефф Дин компилирует и запускает код перед коммитом - но только чтобы проверить компилятор и процессор на баги Недовольный константным временем, Джефф Дин создал первый в мире алгоритм O(1/n) ✓ Когда Джефф Дин уходит в отпуск, продакшн-сервисы по всему Google начинают загадочно падать через пару дней Джефф Дин однажды сдвинул бит так сильно, что тот оказался на другом компьютере На собеседовании в Google Джеффа спросили, что следовало бы из равенства P=NP. Он ответил: "P = 0 или N = 1". Затем, пока собеседующий ещё не перестал смеяться, Джефф присмотрелся к публичному сертификату Google и выписал приватный ключ на доску Вы используете свой мозг на 10%. Остальные 90% заняты одной из мап-редьюс джоб Джеффа Дина В резюме Джеффа Дина перечислено то, чего он не делал - так короче Для Джеффа Дина "NP" означает "No Problemo" Джефф Дин однажды написал алгоритм O(n^2). Это нужно было для решения задачи коммивояжёра Джеффу Дину пришлось изобрести асинхронные API однажды, когда после его оптимизации функция вернула значение прежде, чем её вызвали Скорость программирования Джеффа Дина выросла в 40 раз в конце 2000 года, когда он проапгрейдил клавиатуру на USB 2.0 Когда Джефф Дин разрабатывает программу, то сначала создаёт бинарник, а потом пишет исходный код как документацию Компиляторы не выдают варнинги Джеффу Дину. Джефф Дин выдаёт варнинги компиляторам IDE Джеффа Дина не делает анализ его кода - она делает ему комплименты Джефф Дин не пользуется ECC-памятью: он предвидит попадания космических лучей и использует их для оптимизации Джефф Дин однажды не прошёл тест Тьюринга, потому что правильно вычислил 203-е число Фибоначчи менее чем за секунду Джефф Дин однажды поднял веб-сервер одним вызовом printf(). Другие инженеры добавили тысячи строк комментариев с пояснениями, но так и не поняли, как он работает. Сегодня эта программа известна как Google Web Server Это Джефф Дин откусил кусок от логотипа Apple Чак Норрис может вас убить. Джефф Дин может сделать вам kill -9 Джефф Дин умеет парсить HTML регулярками... правильно Когда Джефф не может заснуть, он мап-редьюсит овечек Когда в вашем коде undefined behavior - вы получаете сегфолт и битые данные. Когда undefined behavior в коде Джеффа Дина - прискакивает единорог на радуге и раздаёт всем бесплатное мороженое Джефф Дин умеет инстанцировать абстрактные классы gcc -O4 отправляет ваш код Джеффу Дину на полную переработку Джефф Дин всё ещё ждёт, когда математики найдут шутку, которую он спрятал в разрядах числа пи Джефф Дин родился 31 декабря 1969 года в 23:48. Ему потребовалось 12 минут, чтобы запустить свой первый счётчик времени Когда Джефф Дин говорит "Hello, World", мир отвечает: "Hello, Jeff" Джефф Дин умеет получать единицы из /dev/zero Google однажды пришлось съехать из дата-центра: Джефф Дин случайно сжал поисковый индекс так плотно, что образовалась чёрная дыра Скорость света в вакууме была 55 км/ч. Затем Джефф Дин потратил уикенд на оптимизацию физики Джефф Дин изобрёл MapReduce, чтобы сортировать письма фанатов Процесс, убитый сигналом SIGJEFF, больше никогда не запускается На клавиатуре Джеффа Дина две клавиши: 1 и 0 Часы Джеффа Дина показывают секунды с 1 января 1970 года. Он никогда не опаздывает Код Джеффа Дина такой быстрый, что ассемблеру нужно три опкода HALT, чтобы его остановить Джеффу Дину приходится деоптимизировать свой код, чтобы ревьюеры поверили, что его писал человек Веб-поиск - это просто большой юнит-тест, который Джефф написал для своего настоящего приложения Джеффу Дину не нужны колонки и наушники. Он делает cat *.mp3, бросает взгляд на экран - и мозг декодирует музыку в фоне, пока он работает ✓ Джефф Дин официально сертифицирован как человек, умеющий читать Perl Джефф Дин сортирует бельё квиксортом Кнут прислал в Google экземпляр "Искусства программирования". Джефф Дин подписал его и отправил обратно Когда Ричард Столлман узнал, что автобиография Дина выйдет эксклюзивно на платформе Amazon, он купил Kindle Джефф Дин умеет сжимать случайные данные без потерь Когда Джеффа Дина спросили, правдивы ли факты о нём, он ответил: "111111". Пока интервьюер соображал, что он имеет в виду, Джефф пояснил: "каждый бит в них - чистая правда" Штош, удачи, Джефф! 🫡 #respect

🚀 Как начать и вкатиться в Buzz? 1️⃣ Скачать Desktop или Android 2️⃣ Invite по ссылке Buzz Neighbors 3️⃣ Осваиваемся, пишу там workflow-agent + sandbox сейчас, начнем с Вахтера 😎 ⬇️ p.s. macOS: Apple silicon · SHA-256 a8a6e…e0e63 Intel · SHA-256 69949…8c6c Windows: Download v0.5.3 Linux: AppImage · Debian/Ubuntu Android, iOS - Soon

Соседи, привет 👋 🗣 LLM Neighbors - Vol.37 18:00 Вскр (UTC+3) 2 августа! В этот раз вскр, лето, август все таки, вайб спонтанности, проведем нетрадиционно в Вскр вместо Сб, звонок уже два раза переносился но все же состоится, приходите! Ссылка на звонок https://meet.google.com/pjf-ntdx-awj ✍️Темы: 👨‍💻 Alexandr Fedin Децентрализованное облако для децентрализованных агентов Я тут рестартанул проект, которым занимался лет пять назад. На этот раз всё делается существенно проще и быстрее, поскольку AI. Децентрализованное облако. Работы примерно на неделю осталось: https://github.com/o2alexanderfedin/o2.services Можно будет в него децентрализованных агентов захостить, децентрализованные приложения деплоить (в том числе корпоративные), делать децентрализованные социальные сети, и т.д. и т.п. 👨‍💻 Buzz (by Block) — это обсуждаемая новинка июля 2026 года. Это не просто "еще один чат", а попытка Джека Дорси переизобрести операционную систему для работы команд, где люди и ИИ-агенты юридически и технически равны. В сообществах (Reddit/HN) проект называют "Slack + GitHub + CI/CD в одном флаконе на стероидах Nostr". p.s. Новеньким Подписка на анонсы Ставьте реакции 👍 - подписывайтесь и зовите друзей) #meeting@llm_neighbors

Buzz (by Block) — это обсуждаемая новинка июля 2026 года. Это не просто "еще один чат", а попытка Джека Дорси переизобрести операционную систему для работы команд, где люди и ИИ-агенты юридически и технически равны. В сообществах (Reddit/HN) проект называют "Slack + GitHub + CI/CD в одном флаконе на стероидах Nostr". Главная киллер-фича, ради которой на него смотрят гуру — это контекстная память. В Buzz агент не просто "отвечает в чате", он видит коммиты, логи деплоя и обсуждения как единый поток событий, потому что архитектурно это всё — записи в одном Nostr-релее. Buzz — это внутренний продукт компании Block (бывшая Square), который они разрабатывали, чтобы слезть с иглы Slack и GitHub. Срок разработки: Активная фаза github.com/block/buzz заняла около 1 года. Они начали строить его внутри Block в 2025 году, когда поняли, что ИИ-агентам (вроде их же проекта goose) тесно в Slack. Статус: Это не просто «пет-проект». Вся инженерная команда Block (тысячи человек) уже переехала туда для работы. То есть они сначала обкатали это на себе (dogfooding), а на этой неделе (июль 2026) выложили в Open Source. 🗣 Sentiment: Что говорят эксперты (Reddit, Hacker News, YouTube) (В комментарии добавлю скриншоты с obsidian) 🏆 Топ-3 Конкурента (Вертикальный анализ) Buzz пытается конкурировать сразу в трех весовых категориях, что и является его главной проблемой и преимуществом. (В комментарии добавлю скриншоты с obsidian) Killer Utility (Почему все говорят о Buzz) 1. Branch as a Room (Ветка как Комната): Вы создаете ветку fix-login-bug → Buzz создает временный чат-канал. В него сыплются коммиты, CI-статусы и обсуждения. Когда ветка мержится — канал архивируется. * Зачем: Идеальная чистота. Основной чат не засоряется спамом, а история принятия решений по багу сохраняется навечно. 2. Receipts (Пруфы): Когда вы спрашиваете агента "Почему мы выбрали эту библиотеку полгода назад?", он не галлюцинирует. Он находит конкретный Nostr-ивент (сообщение или коммит) и прикладывает его как ссылку-доказательство. 3. Crypto-Identity: У вашего агента нет API-ключа, который можно украсть. У него есть пара криптографических ключей, как у живого человека. Вы добавляете агента в команду, как сотрудника, а не как «интеграцию». Критика и Минусы - "Тяжелый" Self-host: Это не просто бинарник. Вам нужно поднять Postgres, Redis, MinIO (для файлов) и сам Relay. Для маленькой команды это оверхед. - Сырость (Early Alpha): Мобильные клиенты только «в планах» или в глубокой бете. Git-хостинг (замена GitHub) заявлен, но реализован базово. - Сложность входа: Обычному менеджеру объяснить, что такое "Nostr Relay URL" и "Public Key", будет крайне сложно. Это инструмент гиков для гиков, то есть для нас. Вердикт: Если вы строите автономную команду агентов (где роботов больше, чем людей) — Buzz сейчас безальтернативный топ-1. Для обычной человеческой переписки он пока слишком сложен. Давайте тестить! Я уже развернул на серваке и буду писать в комментариях, подключайтесь! p.s. Новеньким Подписка на анонсы Ставьте реакции 👍 - подписывайтесь и зовите друзей) Хочешь попасть в чат - отправляй заявку https://t.me/+LHksX9WA9cs4YTQy Ставь emoji ✍️ записать meeting)

Соседи привет!👋 Weekly Call - 18:00 UTC+3 Сб 18.07 Успей отметиться! https://meet.google.com/yfz-fktk-wip Тема? на этот раз 👨🏻‍💻"показы... показы... чего? Экранов!.. что там, агент-крафт, world-of-model-craft или воркфлоу, unicorn, multi-corn, каждый покажет свое... Напоминаю отметится в голосовалке или календаре если планируете прийти! p.s. в конце можно поболтать разоблачение от Максима Etechlead, он нашел Хроники AGI 1981 года, все было спланировано еще до нас, тех кто после 1981 родился конечно... Есть ли кто старше?, ставь 💂‍♂️

Соседи, привет 👋 🗣 LLM Neighbors - Vol.36 Show Your Demo 18:00 Сб (UTC+3) 18 Июля! Ссылка на звонок https://meet.google.com/yfz-fktk-wip ✍️Темы: SHOW YOUR DEMO Мы так интересно и полезно обсудили в прошлый раз Agent Readiness, коснулись множества тем, что решили будет полезно обменятся 'визуалом на пример' у кого какой подход к работе, workflow на примере pet/no-pet проекта послушаем в течении двух часов (осталось 3 места, пишите в ЛС) Рассчитываем 20-30 минут + QA Желательно сразу подготовить слайдики gamma.app или HTML-ку c Claude До встречи! Накидывайте идеи в комментарии! 👨‍💻 Далее продолжим насущные темы последних двух недель p.s. Новеньким Подписка на анонсы Ставьте реакции 👍 - подписывайтесь и зовите друзей) Хочешь попасть в чат - отправляй заявку https://t.me/+LHksX9WA9cs4YTQy #meeting@llm_neighbors

👋 Agent Readiness Project Enterprise, SaaS, Infra 11 июля, в 18:00 UTC+3 - Панельная дискуссия, обсудим плюсы и минусы устоявшегося подхода от инженеров Droid Участники уважаемые @etechlead and @deksden_notes factory.ai/news/agent-readiness ЗАПИСАТЬСЯ? КАЛЕНДАРЬ или ГОЛОСОВАЛКА Запись - ссылка! (Транскрипт) Если хотите не просто слушать, а коротко показать свой подход, тоже пишите. Поставьте реакцию или отпишитесь в комментариях, чтобы понять, есть ли кворум. p.s. Sol vs Fable? p.s. Подписка на анонсы еженедельных звонков Мы объединяем энтузиастов, инженеров из BigTech, Middle, Startups и инди-хакеров. Главное — это желание разобраться, как эффективно использовать AI в разработке. Хочешь попасть в чат? https://t.me/+LHksX9WA9cs4YTQy после approve #whois #meeting@llm_neighbors

Новый сценарий от авторов AI-2027 https://ai-2040.com Бегом читать «План А» — это наше позитивное видение того, как человечество может избежать экзистенциальной катастрофы, вызванной ИИ, и прийти к процветающему будущему. Он основан на беседах с экспертами из ведущих американских компаний-разработчиков передового ИИ, непосредственном опыте работы в OpenAI, дискуссиях с законодателями, экспертами по национальной безопасности и лидерами в сфере регулирования ИИ. Мы рекомендуем заключить международное соглашение, чтобы избежать опасной гонки за созданием сверхразума. Это соглашение подразумевает абсолютную прозрачность исследований и разработок в сфере ИИ, что позволит странам мира понимать происходящее и обеспечивать соблюдение мер предосторожности. В результате множество компаний из разных стран смогут медленно, безопасно и совместными усилиями масштабировать свои разработки на пути к сверхразуму, а не участвовать в тайной гонке друг с другом. «План А» — это в первую очередь рекомендация, а не прогноз. Этот сценарий не является нашим наиболее вероятным предположением о том, каким в действительности окажется будущее. Скорее, это инструмент для донесения и стресс-тестирования наших политических рекомендаций (в сфере регулирования ИИ). И хотя сама реализация «Плана А» является лишь рекомендацией, а не тем, что, как мы ожидаем, произойдет на самом деле, описанные в нем последующие эффекты представляют собой именно прогнозы. В данном сценарии развития ИИ до 2040 года «План А» реализуется успешно, пусть и неидеально, причем делается это в самый последний момент. Мы противопоставляем «План А» четырем альтернативным планам (B, C, D и S), которые соответствуют основным вариантам реакции США (или ее отсутствия) на вызовы, связанные со сверхразумом.

Соседи, привет 👋 Я давно не писал анонсов, но тема дозрела еще месяц назад. Мы все уже умеем заставить агента что-то сделать. Вопрос теперь другой: как понять, что он сделал это надежно, воспроизводимо и без тихой деградации? Хочу завтра, 4 июля, в 18:00 UTC+3 собрать созвон про harness, evals и workflow-as-a-code (WaaS © LLM Neighbors) для агентов ЗАПИСАТЬСЯ? КАЛЕНДАРЬ или ГОЛОСОВАЛКА Не про “топ-10 AI tools” и не про то, какая модель сегодня умнее. Скорее про следующий слой: как из вайбового агента, который “вроде что-то сделал”, получить процесс, которому можно доверять. У меня нет правильного ответа. Хочется порассуждать и обменяться практикой. Последние недели я сам довольно плотно уперся в эту тему: делал маленький intake-harness, гонял workflow через Claude/Codex, пробовал оборачивать это в workflow-as-code, смотрел self-hosted модели, разбирался с evals, guardrails, traceability и тем, где человек должен оставаться в контуре. И чем дальше копаю, тем сильнее ощущение: агент начинается там, где вокруг модели появляются рельсы: - какие tools доступны; - какой контекст она получает; - где deterministic script, а где LLM; - где approve / edit / cancel; - что логируется; - какие evals проверяют качество; - какой receipt остается после run; - кто и как понимает, что стало лучше, а не просто “получилось красиво”. Главный открытый вопрос, который хочется обсудить: как сравнивать не модели, а workflow? Условно: два человека решают похожую задачу разными подходами. Один через Claude Code, другой через Codex, третий через Cursor, четвертый через свой набор scripts/skills/agents. Как понять, чей flow реально лучше, если не скатываться в “мне удобнее” или “я так привык”? Кажется, для этого нужен общий язык: - task class: что за задача — bugfix, feature, refactor, legacy, UI, research-to-code, тесты, docs; - golden set: маленький набор реальных задач с фиксированным входом и acceptance criteria; - outcome quality: что в итоге работает, что сломалось, что пришлось выкинуть; - human touches: сколько раз человек вмешивался, читал, правил, апрувил, разворачивал агента назад; - rework: сколько итераций ушло на неверное понимание, drift, regression, overengineering; - lead time / cost: время, токены, модели, инфраструктура, ручное внимание; - transferability: может ли другой человек запустить этот workflow без автора; - regression evidence: после изменения prompt/model/tools стало лучше, хуже или просто иначе. Для меня это и есть meta-вопрос: не “как написать еще один промпт”, а как собрать такой контур, где intake, execution, verification, HITL и telemetry превращаются в измеримый workflow. Мне хочется обсудить это руками, без академичности. Если придете, подготовьте, пожалуйста, коротко одну из трех вещей: - один workflow, который у вас реально работает; - один кейс, где агентный pipeline ломается или деградирует; - один hard-earned lesson про harness / evals / context / HITL. Если хотите не просто слушать, а коротко показать свой подход, тоже пишите. Поставьте реакцию или отпишитесь в комментариях, чтобы понять, есть ли кворум.

4️⃣2️⃣ Dynamic Thread 👉Как измерить лучше ли твой подход?👈 To be continued in comments

Соседи, второй раз за сегодня привет 👋 Во вторник в чате обсуждали IPO/market signal вокруг Anthropic, а потом мне попался пост Andrew Ng про новую “buzzy job” в Silicon Valley — AI Forward Deployed Engineer / AI FDE. Начал писать draft, не успел нажать enter отвлекли на 3 дня, одно-чатовец напомнил мыслю), так вот И красиво сошлись две темы: 1. Anthropic уже не просто “лаба с хорошими моделями”, а компания, которая тащит enterprise adoption: Claude Code, docs, cookbook, курсы, сертификации, B2B, security, integrations. Формируют стандарты, подходы, FDE в конце-концов они же тоже придумали.. 2. Если AI реально входит в компании, то возникает вопрос: кто именно будет это внедрять и поддерживать? Сколько процентов рынка уйдет в сантехники? В комментах к посту Andrew Ng ожидаемо пошёл спор: AI FDE vs AI Engineer — кто круче? Но мне кажется, вопрос не в том, кто круче. Скорее так: - FDE ускоряет внедрение. Приходит ближе к клиенту, разбирает workflow, security, approvals, integration, adoption, делает так, чтобы AI реально начал работать в конкретной компании. - AI Engineer строит внутреннюю способность компании. Чтобы компания не зависела вечно от внешнего внедрения, а сама понимала свои data, workflows, customers, evals, agents, logs и могла поддерживать систему дальше. FDE можно мемно назвать “внедренцем SAP / Oracle / 1C эпохи LLM”, но это слишком грубо. Нормальный AI FDE — это скорее enterprise SWAT: клиент, безопасность, workflow, agentic integration, политика, approvals, evals, adoption. А AI Engineer — это тот, кто превращает первое демо в устойчивую внутреннюю систему. И вот тут интересный вопрос к вам: Какие AI-роли реально формируются сейчас? - AI FDE? - AI Engineer? - Agent Engineer? - AI Integration Engineer? - AI Product Engineer? - AI Automation Lead? - AI Security / Evals / Governance роли? Кого уже нанимают в западных компаниях / у вас? Какие вертикали видите? Где это новая профессия, а где просто старый внедренец с новым бейджиком? Citrini про 2028 Global Intelligence Crisis: https://www.citriniresearch.com/p/2028gic Andrew Ng post: https://links.llmneighbors.com/pvzWKyv p.s. Подписка на анонсы еженедельных звонков Мы объединяем энтузиастов, инженеров из BigTech, Middle, Startups и инди-хакеров. Главное — это желание разобраться, как эффективно использовать AI в разработке. Хочешь попасть в чат? https://t.me/+LHksX9WA9cs4YTQy после approve #whois #meeting@llm_neighbors

🔔 Напоминаю отметится 🗣 LLM Neighbors - Vol.33 - 18:00 Сб (UTC+3) 6 Июня! ☝️ Две опции ЗАПИСАТЬСЯ: 1) 🗳 Вернул по просьбам, любителям ГОЛОСОВАЛКИ 2) 🗓 Любителям КАЛЕНДАРЯ (7+ там) updated 20260605-1532( 🗳 5+🗓7 ~ 12+_ ТЕМА 🧠 LLM Neighbors: Claude Workflow, Codex|Claude /goal, Hermes-Kanban и новые agent workflows с автономией на максималках

🗣 LLM Neighbors - Vol.33 18:00 Сб (UTC+3) 6 Июня! 🧠 LLM Neighbors: Claude Workflow, Codex|Claude `/goal`, Hermes-Kanban и новые agent workflows с автономией на максималках 📞 Записывайтесь по ссылке Соседи, привет 👋 Давно не было, вылезаю из пещеры, может начнем собираться почаще) Я тут утром опять проверял “пирожки” по агентным workflow - сделал SDD запустил на ночь под "/goal" и с утра очередной. Мы давно не обсуждали Workflow, и вот его наконец выкатили Anthropics с базовыми примитивами и как обычно не собирают за нас пазл лего или не хотят) Как у кого это работает, ставим агенту цель, workflow, что дальше) На радаре сейчас: - Claude Workflow и их goal, loop primitives; - Codex /goal; - Skill-ы подобные codex-dynamic-workflows и похожие OSS-заготовки; - map/reduce workers, skills, memory packs, regression guards; - где это всё помогает, а где превращается в ещё один MetaOS вместо работы. Интересно обсудить не “Claude vs Codex”, "Droid, ampcode, Pi" и не религию вокруг тулов, а практику, обменяться опытом: Если у вас есть свои находки по Claude Workflow, Codex /goal, dynamic workflows, agent harness, OSS-звёздам недели — кидайте заранее. Хочется прийти не с абстрактными мнениями, а с конкретными примерами: что пробовали, где сломалось, что реально ускорило работу. Материалы для старта: - Claude goal docs: https://code.claude.com/docs/en/goal - codex-dynamic-workflows и прочие попытки сделать workflow в кодекс пока его не выкатили - пост Deksden с докладом/презой Поставьте реакцию, если тема нужна, и напишите в комменты. p.s. Новеньким — это не лекция “как правильно пользоваться агентами”. Скорее живой разбор: как мы сами пытаемся не утонуть в Claude/Codex/skills/workflows и превратить это в рабочую систему. p.s. Если останется время можно поговорить и про Hermes vs Openclaw, Pi-дух для OpenClaw как сделать и может коснемся про Memory providers https://hermes-agent.nousresearch.com/docs/user-guide/features/memory-providers (memory: provider: openviking # or honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, graphiti) p.s. Подписка на анонсы Ставьте реакции 👍 - подписывайтесь и зовите друзей) #meeting@llm_neighbors

Меня в агентах-ассистентах больше всего напрягает не “как написал код, а what a fuck”, почему Codex/Claude +120% предвосхищает, а OpenClaw/Hermes часто недотягивают (Понятнее и красивая иллюстрация от NanoBanana в комментариях) https://t.me/llm_neighbors/374?comment=42547 Отсюда появилась на этой неделе 👀 что он постепенно наварил в своём runtime, пока ты жил обычную жизнь. Хочется раз в день, пару раз в неделю или по запросу, когда что-то пошло странно заглянуть "под капот": агент стал отвечать иначе, поменял правила, накопил state, записал что-то в sqlite/json/log, обновил AGENTS.md, начал делать “как-то не так”. И ты смотришь на это и думаешь: а что он вообще там добавлял? 🫠 Вот поэтому на кейсе Hermes я опять скатился в свой любимый “колхозный” GitOps. Не как deploy-моду. А как black box / flight recorder для агентного runtime. Мне нужно быстро увидеть: 1. что агент поменял за период; 2. что из этого смысл, а что timestamp-churn; 3. какой checkpoint был последним нормальным; 4. что можно исключить как шум; 5. что можно откатить или дать следующему агенту как контекст. Схема получилась такая: 🧠 runtime пишет состояние 🧹 anti-noise выкидывает updated_at-мусор 🧾 checkpoint фиксирует только осмысленные изменения 🔁 fanout подтягивает это на read-surface 🏷 main + sparse tags вместо сотни веток 👀 я с macOS смотрю diff и понимаю, что творится Ключевое: это не “memory as git”. Это mirror of blackbox. Периодический снимок того, что агент считает своим миром. И вот с этим уже можно разговаривать тыкая в коммиты: “зачем ты это записал?” “почему ты поменял это правило?” “больше так не делай” “вот это оставляем” “вот это шум, исключаем” “что ты там вообще в AGENTS.md написал?” Без такого слоя ты разговариваешь не с системой, а с текущим ответом модели. А текущий ответ часто уже не объясняет, какой state она успела накопить. И да, дисклеймер: SQLite/state не всегда надо трекать. Иногда LFS, иногда ignore, иногда вообще нельзя. В .gitignore надо было вдуматься заодно и структуру лучше изучил. НSecrets — никогда. Логи — выборочно. И очень важно: без noisy commits. Если checkpoint засоряет историю timestamp-only мусором — это не observability, это новая проблема. Но для маленьких агентных runtime’ов мне нравится эта честная простота: не строить платформу, а сначала иметь зеркало чёрного ящика. Возможно, это overengineering. Но лично для меня это KISS: меньше магии, меньше “ну вроде работает”, больше inspectable следа, пассивное обучение как устроено решение и что можно докрутить под себя. Любопытно, кто ещё как отслеживает, что агенты копят и меняют в своём runtime? Подписка на анонсы.

JSON Contract Task. Одна из самых полезных привычек, которую я сейчас внедряю в свои AI-agentic процессы: задача должна иметь машинно-читаемый источник правды. Не “где-то в чате договорились”. Не “в Linear вроде описано”. Не “в GitHub issue есть комментарий”. А маленький task JSON, где лежит настоящая форма задачи: - цель; - не-цели; - критерии приёмки; - затронутые поверхности; - команды проверки; - evidence; - текущий статус; - blockers; - решения, которые уже приняты. Трекер при этом не исчезает. Linear, Plane, GitHub Issues, Markdown, Telegram summary — всё это полезные интерфейсы для людей. Но они должны быть projection, а не пятью разными правдами. Проблема начинается, когда задача живёт только в трекере и длинном обсуждении. Агент каждый раз заново собирает смысл из описания, комментариев, старых сообщений и локальных догадок. Через несколько итераций уже непонятно: - что было обещано; - что отменено; - что проверено; - что просто “казалось сделанным”; - где настоящий статус. Task JSON не делает процесс идеальным. Он делает его достаточно строгим, чтобы другой агент мог продолжить без шаманства. Для меня это не бюрократия. Это защита от галлюцинаций процесса. Я хочу такой поток: JSON SSOT → tracker projections → execution → verification → evidence → status update. Тогда готово перестаёт быть ощущением. Оно становится состоянием рельсы. AI не убирает необходимость в source of truth. AI делает её обязательной. Подписка на анонсы.

Напоминание про 🗣 LLM Neighbors - Vol.32 18:00 Сб (UTC+3) 2 мая! - CodeAI-Hub 🗣AMA + DEMO BUIDL👨‍💻! Если будете - отмечайтесь! Приходите! p.s. 🔗ССЫЛКИ: Видео-презентация и Github-репо Чтобы подготовить предметные вопросы)