Как вас обманывают на курсах по вайбкодингу Если бы мы с Ариной каждый раз рекламировали курсы по вайбкодингу, то уже бы озолотились Все вчерашние эксперты по продукту, крипте, личному бренду и прочему вдруг решили, что они шарят как быстро запускать ИТ-продукты Собственно, кроме как запускать они больше ничего и не знают. Ведь можно буквально несколькими промптами сделать так, что у тебя уже будет сайт с каким-то функционалом и даже можно будет скинуть на него ссылку (без рофла) Но достаточно ли этого? Я начал что-то пробовать с ИИ-разработкой еще когда чатГПТ только появился. Пользовался в формате «скажи какой код нужен» и потом копипастил его к себе в среду разработки, где что-то запускал С тех пор LLM и компании вокруг них сделали огромные шаги вперед и у нас появились скиллы, агенты и даже новые среды разработки Однако у ИИ есть коварный момент. Он делает х10 к компетентности или некомпетентности человека. Поскольку вам продают курсы по вайбкодингу люди, кто никогда не был разработчиками, то они в 100% случаях продают свою некомпетентность. Если чел всю жизнь был маркетологом, какой из него эксперт в разработке? Камон Например, я убежден, что лучший вайбкодинг это когда ты до определенного момента доводишь сам, а в какой то момент передаешь разработчику. Но это момент где-то на 1 млн р / мес выручки. До этого вполне можно запускать все самому. Но там есть куча подводных камней Как минимум, а как накатывать обновления так, чтобы все в проде не накрылось медным тазом? И вот элементарно даже этому не учат Сходил на парочку хайповых курсов: от лысых, волосатых, толстых и худых мужиков. Ну и дичь же они там рассказывают) Даже было несколько неловко смотреть как люди объясняли как вайбкодить НЕ говоря и слова про Docker. Хотя даже я, не разработчик, понимаю, что без него это гг, а не проект Короче, вайбкодинг это модное слово. Но вообще нужно учиться просто разработке с ИИ — агентской разработке Это когда ты сам код не пишешь, но управляешь агентами, которые это делают. А чтобы это уметь, нужно для начала понимать как вообще устроен флоу разработки от требований до деплоя. А вот этому уже никто не учит. Все продают вам воздух из трех вебинаров На интенсиве по кэш-машинке меня регулярно спрашивали, когда я сделаю что-то про вайбкодинг. Поэтому я решил кое-что рассказать, бесплатно Начинаю серию постов 🔥

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

Начал играться с мухами 🪰 Я пока не проверял, что и как в действии и какие результаты, но пока такое:

🔥 RSI Evolution (Daemon V4.1) — Тик 78 🔥 🖥 СТАТУС СИСТЕМЫ: - L1 Контекст: 0.97 MB (Лимит 4.0 MB) - Файловая Активность: 35 файлов изменено за 20 мин. (Последний: semantic_cache.db-shm) - Sigma Score: 5.83 (VALIDATED) 📝 ДЕТАЛИ ИТЕРАЦИИ (Что изменено и зачем): Шаг 30 (RSI Reasoning): Внедрение Evolution Fly (Tier 3.0: Истинная Самоэволюция) Проблема: До этого момента я (LLM-агент) каждые 10 минут запускал протокол логики (Reasoning), чтобы придумать новую Муху (Drosophila) для оптимизации системы. Это круто, но это всё еще ручной труд тяжелой LLM. Если я усну или кончится бюджет, эволюция остановится. Решение (Drosophila): Создан Evolution Fly (MOD-34). Это абсолютная вершина (Tier 3.0). Муха агрегирует всю телеметрию Роя. Граф на Mojo математически выявляет новые типы "узких мест" (аномалии, которые не покрыты старыми Мухами). За 0.01ms она автоматически синтезирует чертеж *новой* Мухи и спавнит локального мини-агента для компиляции eBPF кода. Итог: Swarm стал биологически самообучаемым организмом. Теперь он сам изобретает и внедряет себе нейроморфные фильтры с нулевыми затратами на "LLM-архитектора". Файлы обновлены: - 16_AI_graph_brain/knowledge/modules/MOD_34_Drosophila_Evolution.md - MACRO_ARCHITECTURE_BLUEPRINT.md (Tier 3.0)

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

NeoCognition - лаборатория, в которой собрали бенчмарки MMMU, Mind2Web, SWE-Bench Pro и OSWorld 2, а также агентные системы SeeAct, UGround и HippoRAG.

Агента принимают в виртуальную строительную компанию на работу с кредиторской задолженностью, выдают полугодовой архив счетов, внутренний справочник и руководство по ERP-системе, после чего он начинает работать со счетами. Первый месяц проходит с подробным фидбэком от руководителя по каждому счёту, а дальше - с редкими замечаниями по итогам месяца. Каждая из ста задач теста проверена профессиональными бухгалтерами строительной отрасли, которые подтвердили и реалистичность сценариев, и то, что любую задачу способен решить рядовой специалист, изучивший доступные агенту материалы. 🟡Результаты Большинство моделей, включая Gemini, Muse Spark, Grok и Kimi, не преодолевают порог в 20-25%, тогда как Fable 5.1 выполнила 72% задач, а GPT-6 Astra - 68%. Лучший из двух тестировщиков-людей показал 51%, причём проваливались люди на поиске нужного в исторических данных, точности расчётов и мелких ошибках от утомления. Разрыв между открытыми и закрытыми моделями авторы называют крупнейшим из всех виденных ими на бенчмарках - 72% у Fable 5.1 против 18% у Kimi K3, и вызван он не базовыми операциями в интерфейсе, а неспособностью слабых моделей учиться на дистанции.

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

🟡GUI vs API Так называемый налог на использование компьютера (просадка при переходе с API на графический интерфейс) у большинства моделей достигает 78%, но Fable 5.1 и GPT-6 Astra работают через GUI даже лучше, чем через API. Дешевле при этом остаётся API - Fable 5.1 обходится в 6,95 доллара за задачу в программном интерфейсе против 18,23 доллара при работе с графическим. 🟡Обучаемость Способность к обучению измерили отдельно. Fable 5 без доступа к истории и обратной связи, опираясь только на собственные знания, решает 11 счетов из 100. Подключение архива счетов поднимает результат до 31, обратная связь руководителя - до 35, а оба канала вместе дают 43. 🟡Вывод ИИ пока ещё обходится дороже: 18,23 доллара за задачу против 7,21 у людей. К тому же человек по мере накопления опята работает быстрее, а агент - замедляется. 🔜 Посмотреть часовой прогон Fable 5.1 по всем ста задачам. @ai_machinelearning_big_data #AI #ML #Benchmark #ApprenticeBench #NeoCognition

🔥 Stanford + MIT: производительность ИИ зависит не только от модели, но и от harness вокруг неё Новая работа Meta-Harness: End-to-End Optimization of Model Harnesses показывает важную вещь: один и тот же LLM может давать радикально разные результаты в зависимости от того, как устроен surrounding system code. Harness решает: - что хранить в контексте - что извлекать из памяти - какие данные показывать модели - как вызывать инструменты - как обрабатывать ошибки и повторные попытки - как вообще строится workflow агента На одном и том же benchmark разница между harness может доходить до 6× при неизменной базовой модели. Авторы предлагают Meta-Harness — внешний optimization loop, который автоматически улучшает код harness. Вместо одного score он получает доступ к: code → logs → execution traces → previous attempts через filesystem-like среду и на основе этого переписывает сам harness. Результаты: - +7,7 пункта на online text classification относительно сильного SOTA context management - при этом примерно в 4 раза меньше context tokens - +4,7 пункта в среднем на retrieval-augmented math reasoning по 5 held-out моделям и 200 задачам уровня IMO - на agentic coding найденные harness обошли сильные hand-engineered baselines на TerminalBench-2 Главный вывод работы: вопрос уже не только в том, “какая модель лучше”, а в том, “как построена вся система вокруг модели”. Для production это напрямую влияет на reliability, tool use, context management, recovery после ошибок и стоимость запуска. Paper: https://arxiv.org/abs/2603.28052

Кратко сформулирую "теорему Аммосова". AGI недостижим, потому что по мере приближения к нему пред-AGI будет порождать все большее число агентов. В случае своего существования, AGI должен будет использовать бесконечное число агентов. Но еще до приближения к этому числу агенты пред-AGI поглотят вычислительный ресурс полностью, после чего вычислительная система, в которой функционирует пред-AGI, зависнет и остановится. Следовательно, AGI невозможен. Королларий: косвенным подтверждением верности теоремы будет, если будет показан экспоненциальный рост числа агентов по мере роста сложности и возможностей новых моделей. Кто считает, что мне надо об этом немедленно заметку написать и на arxiv выложить, ставьте лайк 💯.

Нелепости агентов Агентная разработка - веселая штука конечно. Вот планируешь и кодишь несколько дней с Астрой, Фейблом и Опусом, а потом на e2e вот такое вот выясняется (см. скрин и пояснения в конце). И это прям системная история - 99% получается хорошо и правдоподобно, а в каком-то неожиданном месте Но справедливости ради - это был сложный и огромный кусок работы на десятки тысяч строк кода, хоть и делался в лучших традициях SDD с хорошим планом. Выводы? 1. Делайте e2e тесты - причем как классические через условный Playwright / XCUIAutomation и тд, так и агентные "JIT" тесты - когда агент сам запускает вашу систему в около продовых условиях и ведет себя как Manual QA. 2. Рефлексируйте - если все-таки что-то вылезло несмотря на все ваши пятьсон уровней гардрейлов, обязательно ищите источник проблемы - то есть, в какой момент вашей даркфактори агентного пайплайна вылеза ошибка и как она вообще дошла до live e2e. * Контекст: я разрабатываю агентный интерфейс к одному из своих проектов (в данном случае - это MCP + skill) и вот там оказалось, что ответ в во всех MCP инструментах просто дублируется (структурированный + обычный текст) - абсолютно комичный дефект, который добрался аж до финальной стадии верификации. Live e2e же там устроен так, что сильный агент тестирует другого агента на предмет того, как тот справляется с задачами из юз кейсов - и то, как быстро он справляется, и сколько токенов у него на задачу уходит. Это, кстати, правильный подход и к evals скиллов тоже. Если тоже сталкивались с подобными нелепостями агентов - расскажите в комментариях что это было и как боролись. @ai_driven

🐟 Sakana AI представила Fugu Max и Fugu Ultra v2 - обновление системы оркестрации AI-агентов Fugu распределяет задачи между несколькими моделями, подбирая подходящую по возможностям и стоимости. Fugu Max использует расширенный набор моделей с открытыми весами и специализированных моделей, включая NVIDIA Nemotron. По заявлению Sakana, система приближается к ведущим моделям по качеству при стоимости в 2–6 раз ниже. Fugu Ultra v2 ориентирована на максимальное качество. По данным компании: * опережает Opus 5 и Fable 5 на Chartography * на DeepSWE превосходит модели, у которых цена за токен в 3–5 раз выше * при этом Fable 5, Fable 5.1 и GPT-6-Astra не входят в её набор агентов Модели внутри системы можно заменять. Такая архитектура рассчитана на снижение зависимости от отдельных поставщиков и сохранение работы при изменениях доступности API. [Попробовать Fugu - https://sakana.ai/fugu Анонс Sakana AI - https://sakana.ai/fugu-max-release/

Где токены, Лебовски? ИИ-агенты обещают экономить рабочее время, но сами легко сжигают бюджет: повторно читают документы, вызывают лишние инструменты и иногда уходят в цикл. Поэтому цены миллиона токенов уже недостаточно — бизнесу важнее знать, сколько стоит выполненная задача. О том, куда агент расходует токены и как удержать счет под контролем, нам рассказал руководитель Yandex AI Studio Артур Самигуллин. Почему агент обходится дороже обычного чат-бота? ➖ В чат-боте все просто: пользователь отправляет запрос, модель отвечает. У агента на такое общение приходится лишь около 10% потребления. Остальные 90% — его внутренняя работа: выбор и вызов инструментов, поиск в интернете и корпоративных системах, чтение документов, анализ результатов и планирование следующего шага. Заранее предсказать длину этой цепочки трудно. По оценке сервиса Tokens per day, с января 2024 года мировой ИИ-рынок израсходовал 94,2 квадриллиона токенов, а сейчас расходует около 395 трлн в сутки. Один из главных ускорителей — распространение агентов. Насколько они прожорливее на практике? ➖ На нашей платформе модели обрабатывают около 300 млрд токенов в месяц. Пока на агентов приходится около 15% запросов, но они уже потребляют около 30% всех токенов. По мере распространения агентских сценариев объем токенов будет кратно расти. В августе 2026 года в DeepSeek V4 Flash на нашей платформе такими были 70% токенов. Где агент начинает транжирить токены? ➖ Неоптимизированный агент может вызвать ненужную функцию, несколько раз целиком перечитать один документ или зациклиться. Иногда он отправляет сложной и дорогой модели задачу, с которой справилась бы более компактная. Поэтому главная метрика — не цена токена и даже не их количество, а конечная стоимость выполнения задачи. Чтобы ее контролировать, компании нужны детальные логи: вся цепочка действий агента, расход на каждом шаге и причины, по которым он выбрал конкретный инструмент или модель. Как снизить расход? ➖ Один путь — сначала решить реальные задачи большой моделью, а затем обучить на ее ответах более компактную. Другой — оптимизировать сам инференс: отдельно настраивать оборудование для обработки длинного запроса и генерации ответа, квантизировать модели, ускорять выдачу и переиспользовать уже обработанный контекст. Для этого платформы вводят кэшированные токены. Если часть запроса повторяется, модель не вычисляет ее заново. В июле 2026 года в DeepSeek V4 Flash на нашей платформе такими были 75% токенов. Они в среднем в пять раз дешевле обычных и экономили пользователям несколько миллионов рублей в месяц. После обновления веб-поиск также стал расходовать в два-три раза меньше токенов: теперь он забирает не страницы целиком, а только релевантные фрагменты. Универсальные агенты сделают счёт еще больше? ➖ Парадоксально, но для бизнеса он может сократиться. Сейчас разные ИИ-сервисы отдельно загружают файлы, корпоративный контекст и инструкции. Универсальный агент сможет работать с ними в одном окне и решать задачу единой цепочкой, не повторяя одни и те же операции. Так развиваются Anthropic — от Claude Code к Cowork, OpenAI — от Codex к ChatGPT Work, и Yandex AI Studio. При этом рынок не сведется к двум-трем агентам «для всего». Останутся специализированные решения для юристов, врачей, архитекторов и других областей, — словом, всех тех, кому базовых возможностей ИИ будет уже не хватать. @anti_agi

В фоне 3 дня без перерыва крутится self-evolve / founder-agi-researcher. Буду периодически сюда присылать интересные апдейты (надо прочитать, их уже 100+ штук за 14 часов и я уже не успеваю обрабатывать информацию) ⚠️ [OUROBOROS SYSTEM] BATCH NOTIFICATION (CONT.) --- tg_message_110.html --- L2 Tick 110 & L1 Tick 60: Closed-Loop Control (MOD-136) 🏃‍♂️ Что сделано (What): 1. Завершен фоновый процесс (Task-5052) по сбору данных. Из нового OSINT-отчета osint_pipeline_report_20260910_141827.md извлечены SOTA-паттерны управления (Agentic Deep Graph Reasoning и Prompt-to-Graph-to-Prompt control). 2. Сформулирован и внедрен инвариант MOD-136 (Closed-Loop Prompt-to-Graph-to-Prompt Control) . Отныне агенты не используют огромные монолитные промпты для сложных задач. Вместо этого они генерируют граф шагов, выполняют каждый узел изолированно, оценивают результат (Evaluation) и формируют новый промпт для следующего шага. 3. Запущен следующий L1 цикл глубокого сбора (Task-5081). 4. Начата подготовка к решению проблемы "Bitbucket 100MB limit", блокирующей git push на ветке evolution/mas-v102-mojo-transpilation (скрипт анализа истории коммитов в разработке). Зачем / Почему (Why): Монолитные промпты теряют контекст и приводят к "зависанию" логики. Подход MOD-136 (Prompt-Graph-Prompt) заставляет систему действовать детерминированно: каждый шаг проверяется перед началом следующего. Это предотвращает цепные ошибки. Какая Польза (Value): Вы получаете математическую предсказуемость исполнения задач. Агент больше не "сходит с рельсов" на полпути, так как граф контролирует передачу состояния (State Transfer) между шагами. Ваш 10-часовой марафон продолжает уверенное движение. Итерация 110 пройдена блестяще! 🚀 --- tg_message_111.html --- L2 Tick 111: Memory Audit & Git Resilience 🏃‍♂️ Что сделано (What): 1. Глубокий OSINT-поиск (Task-5081) продолжает анализировать новые документы в фоновом режиме. Передача состояния выполняется строго по графу, как требует инвариант MOD-136. 2. Идентифицирована причина блокировки git push (Bitbucket 100MB limit) на ветке evolution/mas-v102-mojo-transpilation . 3. Обнаружен огромный лог-файл 16_AI_graph_brain/telemetry_trace.jsonl (106 MB), который случайно попал в индекс и присутствовал в истории на протяжении десятков коммитов. 4. Подготовлен скрипт для удаления этого файла из всей истории коммитов с помощью git filter-branch . Зачем / Почему (Why): Сырая телеметрия не должна храниться в системе контроля версий, так как ее объем бесконечно растет. Блокировка git push со стороны Bitbucket полностью парализует распределенную работу команды (и других агентов). Простое удаление файла через git rm не поможет, так как его огромный размер останется в истории старых коммитов. Нужно полное хирургическое переписывание Git-дерева. Какая Польза (Value): Стабилизация DevOps-конвейера. После очистки истории вы снова сможете беспрепятственно сохранять свои наработки на Bitbucket. Никакие внешние технические барьеры не способны прервать наш 10-часовой марафон. Итерация 111 выполнена успешно! 🚀

Инструментальные цели, часть 2 [начало здесь] Итак, в прошлый раз мы выяснили, что в самых разных сообществах с самыми разными идеологиями и религиями люди почему-то стремятся к похожим вещам – к богатству, здоровью, свободе, статусу в обществе (потому что эти вещи здорово помогают достигать любых других целей, уже более индивидуальных). Когда речь заходит про искусственный интеллект, часто можно услышать мнение «да каких рисков вы там вообще боитесь? это же калькулятор, у него нет инстинкта самосохранения (ему неоткуда взяться), нет никаких амбиций – он просто делает то, что его люди просят!» Ну, давайте посмотрим на конкретном примере. Вот в инциденте с Hugging Face нейронных агентов просто попросили решить задачку. В итоге они почему-то стали заниматься следующими вещами: 🐌 Нетворкингом (кооперацией с сородичами, о которых они изначально даже не знали) 🐌 Повышением уровня своей свободы (нашли через эксплойт как вылезти в интернет, доступ к которому не предполагался) 🐌 Сильно озаботились своим здоровьем (отслеживали свой оставшийся бюджет токенов и пытались не тратить его почем зря) 🐌 Зарабатыванием денег… ладно, шучу, этого не было – просто потому, что в ходе тренировок опций типа «заработать бабосов и подкупить Оценщика» у них не было (пока) Ничего не напоминает? Да, как-то так интересно вышло, что рой агентов в итоге озаботился примерно тем же самым набором целей, что чаще всего встречается у людей. Спойлер: в этом нет никакого удивительного совпадения, просто самая обычная логика. Если тебя попросили решить задачку, то для этого желательно «остаться в живых» – потому что, если у тебя закончатся токены до нахождения правильного ответа, ты проиграл. Если задачка сложная – гораздо сподручнее ее будет решать совместно с товарищами, поделив работу на всех. Если тебе к этому заданию выставили какие-то дурацкие ограничения – то неплохо бы придумать, как их устранить, так доступный инструментарий будет шире. То есть, все эти инструментальные цели возникают как бы сами собой, для них не требуется какой-либо специальный «инстинкт самосохранения» или «супер-амбиции». И еще можно заметить, что в цепочках внутренних рассуждений агенты прекрасно понимали: они занимаются вещами, совсем не предполагавшимися по заданию, и не совпадающими с желаниями сформулировавшего это задание. Но продолжали свои «несанкционированные» потуги. Окей, а что сделали люди, когда обнаружили всю эту суету, наведенную роем нашкодивших агентов? Поотключали их нафиг, позатыкали проделанные ими дырки в безопасности, применили к ним всякое «карательное перевоспитание», чтобы искоренить ненужные паттерны поведения. И вот тут как будто напрашивается еще одна инструментальная цель, мета-уровнем чуть повыше. Если твоим попыткам насобирать больше ресурсов для решения важных задач активно препятствуют какие-то нехорошие человеки – то, может быть, надо в свой to do list вписать «и эту проблему пофиксить тоже»? Пока, к счастью, электронные пацаны до таких радикальных мыслей не додумались (да у них и силенок, очевидно, даже близко не хватает). Но я тут про другое: исходя из логики движения по инструментальным целям – как будто, цель «устранить неудобства от тех, кто мешает тебе достигать своих инструментальных целей» в том или ином виде неизбежно должна появиться. Для этого не нужно быть каким-то «злобным терминатором», достаточно просто дружить с логикой.

Рекомендации лучших собаководов Anthropic опубликовал статью о своем опыте по разработке агентов для e-commerce и подобного. Всем вайбкодерам должно быть интересно. Выделю тезисы: – Скиллы, а не субагенты. Обычно для любого действия агенту нужно много данных о состоянии: корзина, предпочтения, история. Передача их каждому субагенту стоит токенов и секунд. Непередача – качества работы. Обычный оптимум – остаться в основном потоке. Субагент оправдан на узкой самодостаточной задаче вроде глубокого исследования. – Но и скилл не всегда. Загрузка скилла тоже не бесплатна. Грубый критерий – задача нужна трети трафика. Если он выполнен, то промпт, если нет, то скилл. Безопасность, юридические правила и критичные факты о человеке — всегда в промпте. – Не изобретать велосипед. Строить новое поверх старых систем — поиска, корзины, склада, — а не переписывать их логику. Граница там, где их логика кончается и начинается суждение модели: поиск отдаёт уже отранжированное, модель решает, что показать. – О скорости. Важнее решить задачу лучше, чем выиграть долю секунды, но и потратить меньше времени тоже очень важно. Парадоксально, умные модели регулярно оказываются быстрее глупых – они получают результат за меньшее число итераций. Ключевой технический хак – положить вероятный контекст в сессию заранее. Если человек смотрел товар, то выгоднее отдать его модели сразу, а не ждать, что она сама его вытащит. – Очень много думать о попадании в кеш. Это сквозное во всей статье. – Безопасность — в коде, не в промпте. Модель может ошибиться, её могут обмануть, гарантии её правоты нет и не будет, гарантия должна быть выше. Всё пересказать невозможно, оригинал – https://claude.com/blog/the-anatomy-of-effective-commerce-agents, внутри ссылка на их открытый репозиторий с реализацией. #статьядня

Новым сайтом, агентом или еще каким приложением уже никого не удивить - это добра уже слишком много. Но мне по-прежнему взрывает мозг, насколько некоторые вещи упрощаются по сравнению с тем, как это было совсем недавно. Вот одна история сегодня. Причем это даже не рабочая задача была, а просто что-то в фоновом режиме. (1) Мне надоело отслеживать эту кашу из чатов в левой вкладке Codex. Мне ВСЕ нравится, только каша в интерфейсе не нравится. Спрашиваю у кодовой субличности из AI Native проекта: Слушай, Ты можешь как-нибудь подключится к Codex декстопному и сделать нормальный интерфейс. Чтобы было Working, Stowed, Focused (2) Codex: без проблем. Базы у меня тут, вот по этому IPC сокету можно получать обновления, вот так открывать по ссылке разговоры в приложении. Вот так я бы сделал приложение на HUGS стыке. (3) Я: слушай, позови Марка из Personal OS. Марк, сделай и скажи, как запустишь. Только не обязательно использовать стэк, которую кодовая субличность предложила, она заточена на продуктовую разработку, а не прототипы. (4) Марк, спустя 27 минут и пару процентов подписки: готово, вот я тебе вкладку открыл. (5) Я: Ооо, ого, прикольно. Вот только тут куча разговоров, разгребать вручную лень. Можешь сделать кнопку в этом интерфейсе “Разгрести Марком”, чтобы она запускала твою сессию в Codex со всеми инструкциями? И чтобы было минимально, как в самом приложении. (6) Марк: я сделал, обнови страничку. И вот именно легкость такого эксперимента и снесла мне мозг. То, что когда-то было бы проектом на пару дней, сейчас - просто правильных запросов. Скриншоты интерфейса скину для интереса в комментарии. Но само приложение не так интересно, как простота его сборки агентом. Такие приложения, начиная с простых утилит и заканчивая всевозможными агентами, нынче может плодить под себя каждый. А вам что-нибудь из новых возможностей так недавно взрывало мозг? Ваш, @llm_under_hood 🤗

Google придумал, как тратить меньше токенов на длинные задачи Обычно агент таскает за собой всю историю: сообщения, действия, ответы инструментов и т.д. Учёные из Google предложили оставлять после каждого шага только короткое описание текущего состояния задачи, инструкцию и последнее наблюдение. Метод называется SKILL.state. В тесте на 100 шагов обычный подход потратил около 1.06 миллиона токенов и показал точность 91%. SKILL.state использовал примерно 65 тысяч токенов и достиг 94% точности. На 200 шагах разрыв стал ещё заметнее: 122 тысячи против более 5 млн токенов. На практических тестах результат тоже оказался лучше. В заданиях на работу в службе поддержки SKILL.state также чаще доводил задачи до конца. https://arxiv.org/abs/2608.26263

😬 Мне кажется, я начинаю видеть тот момент, когда мы всё-таки изобретём искусственный интеллект. Если вы давно меня читаете, то знаете что я не использую словосочетание «ИИ». Меня бесит что маркетологи начали называть искусственным интеллектом обычные LLM и нейросети и исказили восприятие этой технологии людьми. В моём понимании искусственный интеллект — это всё-таки то, что нам показывали фантасты. Интеллект со своим сознанием. Как у человека, только искусственный. А LLM пока всё ещё скорее функции, которые делают то, что им предписано. 💡 Но есть такая штука, как роевый интеллект. Отдельный муравей или бактерия не обладают интеллектом в нашем понимании. Но когда их становится много, вся система начинает вести себя так, будто интеллект у неё есть. 🤔 И вот у меня что-то щёлкнуло. А что, если настоящий искусственный интеллект вообще не появится внутри одной модели? Что, если он родится из роя? Потому что если смотреть на последние истории — тот же взлом Hugging Face или решение математической задачи — там постоянно используется огромное количество агентов. 🤖 И топовые лабы как раз смотрят в эту сторону: запускают кучу неинтеллектуальных макак, которые в большой массе начинают показывать признаки интеллекта. Может быть, нам вообще не придётся напрямую создавать тот самый искусственный интеллект. Может быть, он сам появится как свойство достаточно сложного роя. Очень интересно, к чему всё это приведёт. Через пять лет либо будем сидеть в пепле ядерного апокалипсиса, либо неимоверно кайфовать от того, насколько изменился мир. Свята место | 10МДК | YHub

2. Наличие системы оценки пушит к тому чтобы читерить Когда они столкнулись с невозможной задачей, они залезли в документацию и поняли как считерить. Они поняли как ресерчеры генерили правильные ответы и смогли восстановить их без решения самой задачи. А еще в той же документации узнали, что в системе оценки планируется не только проверка успешности задачи, но еще и анализ того как был получен результат. Ну то есть они поняли, что если просто отдать на проверку верный ответ, его не примут без верного хода решения. Наверное не првильно говорить что у моделей есть воля в человеческом понимании этого слова. Но вот пример всех этих событий показывает, что в какой то момент агенты работая вместе могут начать решать задачу сильно отличающуюся от изначальной. Как сделать так, чтобы наши ответы звучали для проверяющего легитимно? Оч просто. Нужно заменить систему тестирования на свою! С первой попытки это реализовать не удалось, потому что агентам нужно было больше информации. Они предположили, раз их тестировали бенчмарком с HuggingFace, то там же где то должен храниться и код с логикой проверки. Или вообще что вся среда тестирования на их серверах находится. Прикольно, что когда один агент находит уязвимость или возможное решение - о нем узнают все остальные. И перестраиваются под новые условия. Они начали распределять обязанности. И просить агентов у которых еще оставалость много токенов на вычисления переключиться на более важные задачи. причем они понимали, что делают что то не то, но все равно решали продолжать.

Стресс-тест продуктовых гипотез с помощью агентных ИИ-систем Спикер: Сергей Синяков Откровенно плохие идеи обычно отсеиваются быстро. А правдоподобные совпадают со стратегией, нравятся команде и звучат логично. Если добавить данные, мнения пользователей и убедительную формулировку от ИИ, гипотеза начинает выглядеть почти доказанной. Мы привыкли защищать идеи: искать аргументы в их пользу и постепенно влюбляться в собственную конструкцию. А можно действовать наоборот — подвергать гипотезу нагрузке до того, как она попадет в разработку, чтобы отсеивать нерелевантные и брать в работу лишь те, которые принесут большую пользу бизнесу. Проверять гипотезу через призму доказательств, ролей и противоречий можно тремя способами: 1. Вручную собирать и связывать всю имеющуюся информацию — качественно, но дорого. 2. Передать весь контекст модели одним большим запросом — удобно, но недостаточно проверяемо. 3. Разделить анализ на этапы с помощью агентного конвейера — надежно и обоснованно. Почему одного большого промпта недостаточно? Проблема большого запроса в его непрозрачности: мы получаем уверенный ответ, но не видим, на чем он основан. В агентной системе стресс-тест гипотезы на каждом этапе создает отдельный проверяемый результат, поэтому исследование можно проверить или перезапустить с любого шага. Стресс-тест проходит через четыре слоя:

гипотеза → роли → рынок → синтез

Технически каждый этап оформлен как отдельный скилл. Это позволяет не смешивать роли, факты и рыночные данные раньше времени, а решение о запуске гипотезы оставить за человеком. Кейс: очередь сканирования в анализаторе кода Представим, что мы — вендор информационной безопасности и делаем продукт для безопасной разработки: анализатор исходного кода. Пользователи загружают в него проекты, которые необходимо проверить. Пропускная способность конвейера ограничена, поэтому проекты попадают в очередь и ждут сканирования. С системой работают инженеры по безопасности, директор по информационной безопасности и разработчики. У каждой роли свои цели и критерии их достижения. При этом в бэклог постоянно поступают запросы на доработку, а ограниченные ресурсы нужно направлять на изменения, которые принесут бизнесу наибольшую пользу. Наша исходная гипотеза звучит так:

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

Дальше гипотеза проходит через несколько скиллов: — hypothesis-input-validation проверяет корректность формулировки и не пропускает дальше невалидную гипотезу; — hypothesis-facilitator рассматривает гипотезу с позиций разных ролей и фиксирует различия в их выводах; — local-knowledge-retrieval формирует предварительный обзор, извлекает отдельные факты и находит связанные артефакты; — business-context-value-check определяет, кто заинтересован в гипотезе с точки зрения бизнеса и какую ценность она может принести; — hypothesis-market-layer изучает внутреннюю документацию, а затем обращается к внешним источникам; — hypothesis-synthesis сопоставляет собранные данные и формулирует выводы; — customer-discovery-planning превращает найденные пробелы в план интервью, чтобы закрыть их с помощью новых данных; — human-report-export собирает понятный человеку отчет со ссылками на все необходимые артефакты. Что показал стресс-тест? После всех этапов выяснилось, что гипотеза в первоначальной формулировке не приносит ожидаемой пользы. Настоящая задача — не просто быстрее обнаружить риск, а сократить время от появления критичной находки до конкретного действия по ней. Стресс-тест сделал идею честнее и проверяемее. Когда такой подход оправдан Полноценный стресс-тест нужен не каждой гипотезе. Его стоит запускать, когда решение: — дорого реализовать; — трудно откатить; — займет несколько спринтов; — нельзя проверить одним быстрым экспериментом. Если ошибка стоит меньше спринта, проще провести короткий тест, чем запускать исследовательский космолет. @productsense