Dynamic Workflows: Запускаємо сотні агентів паралельно

Трошки із запізненням, але закинув відос про найцікавішу, на мою думку, фічу Claude Code за останній час. Claude сам пише собі JS-скрипт оркестрації і розгортає під задачу цілий рой субагентів.

Масштаб там такий: команда Bun (той що JS all in one) за 11 днів переписала 750 тисяч рядків з Zig на Rust, і 99,8% тестів залишились зеленими (але комьюніті накидала цьому релізу тисячі дизлайків) 😅

📍 У відосі розбираю, звідки це виросло (з тупого bash-циклу ralph-loop), показую демо з security audit, розповідаю про чотири примітиви, на котрих все побудовано, і чесно говорю про вартість - мій приклад зʼїв 3,2 млн токенів за одну команду 😁

👉 https://youtu.be/cbQ0QCK7ujc

З вас перегляд, лайкос і коментар, ну і буде цікаво почути, чи юзали вже 🙂

Youtube | Instagram

🔥 Anthropic вимкнули Fable 5 і Mythos 5

Пу пу пуууууу
5 годин тому вийшла новина, що уряд США видав директиву: відрубити доступ до Fable 5 і Mythos 5 для всіх хто не є громадянином США.

Навіть для своїх же співробітників-неамериканців. Щоб не порушити закон, Anthropic тупо вимкнули обидві моделі для всіх клієнтів, бо паспорти вони не перевіряють.

Інші моделі (Opus, Sonnet, Haiku) працюють як працювали

Тепер трошки теорії

📍 Що таке jailbreak взагалі

Якщо хто не в темі. У кожної LLM є safeguards - це система обмежень, яка не дає моделі робити шкідливі речі (написати малварь, пояснити як зробити зброю, тощо). Jailbreak - це коли ти спеціально підбираєш промпт так, щоб ці обмеження обійти і витягнути з моделі те, що вона за замовчуванням робити відмовляється

Тут є важлива різниця у двох типах:

✅ Non-universal jailbreak
Працює в одному конкретному кейсі, витягує якийсь шматок інформації за певних умов. Не дає системного обходу

❗️ Universal jailbreak
Один метод, який широко ламає захист моделі і відкриває цілий клас заблокованих можливостей. Оце реальна проблема. І от саме universal jailbreak для Fable поки ніхто не знайшов - ні урядові тестери, ні UK AISI, ні треті сторони, які тестували модель тисячі годин

📍 Що сталося по факту

Уряд натякнув, що з’явився спосіб обійти захист Fable. Anthropic подивились демку цієї техніки і кажуть: вона знаходить кілька вже відомих дрібних вразливостей, будь-яка інша публічна модель знаходить ці ж речі без жодного jailbreak, включно з OpenAI GPT-5.5.

👉 А тепер найсмішніше, що ж там за демка.

Моделі дали почитати конкретну кодову базу і попросили пофіксити software flaws. Все. Тобто рівно те, чим кожен день займаються нормальні розробники🙈

📍 Позиція Anthropic

Закон є закон, доступ забрали, але відкрито не згодні.

Відкликати модель якою користуються сотні мільйонів людей, через вузький non-universal jailbreak - це дивно. Якби такий стандарт застосували до всієї індустрії, він би фактично зупинив будь-який реліз будь-якого frontier-провайдера

Цікаво, де та межа, на якій закон і держава намагаються втручатись в комерційні продукти

Джерело: anthropic.com/news/fable-mythos-access

Youtube | Instagram

Друзі, став готувати новий воркшоп

Інструментів навколо агентів стало дуже багато. І я бачу як люди тонуть
Хтось колупає Claude Code, Codex, Cursor другий місяць і досі не розуміє з чого почати. Хтось накидав скілів і хуків, а АІ генерує сміття

👉 І поки програма не зафіксована - хочу трошки вас почути

Бо я можу зробити воркшоп про те що цікаво мені, але буде зовсім не в тему

💬 Тому коротке питання: що болить найбільше? Чи про що хотілось би почути чи розібрати

Накидайте будь ласка в коментарі. Автор комента, котрий набере найбільше лайкосів і тему котрого ми розберемо - потрапить на розбір безкоштовно 😉

Youtube | Instagram

Такс, календарчик івентів

Планую повертатися сюди частіше - з новими постами та матеріалами. Вже готую нове відео, буде зовсім скоро😉

А поки що ми з командою зробили сторінку на якій зібрали всі активності і заходи на липень.
Переходь на сторінку і переглядай ГРАФІК ЛИПНЯ.


3-4 липня - воркшоп Agentic Engineering Workflows
Більшість уже встигла на ньому побувати, але якщо тебе там ще не було - саме час приєднатися. Вважай, ще одна нагода :)

11 липня - новий практичний воркшоп
Окремий пост про нього ще зроблю, а поки що за посиланням можна глянути тему😌 і одразу зареєструватися.

Окрема вдячність всім хто відписав коментарі! Це було дуже корисно. Як обіцяв, автору найпопулярнішого дам безкоштовний доступ

15 липня - старт групи мого основного курсу Agentic Engineering
11 тижнів, 11 модулів практики і 9 живих Q&A-сесій. Основна ідея: перестати закидати в AI рандомні запити і перейти до системної роботи - з власним Agentic Workflow на виході.
На сторінці видно, скільки місць у групі ще лишилось. А якщо хочеш зануритися в тему глибше - залишай анкету передзапису, і я або моя команда з тобою зв'яжемось.

Тож переходь, дивись і реєструйся 👇
https://agenticengineering.it.com/events

OpenAI випустила GPT-5.6 (але не для нас 😅)

На бенчмарках це новий рекорд

Але є кілка але. На Terminal-Bench (тест на роботу в терміналі: планувати, ітерувати, смикати тулзи) звичайний Sol дає 88.8%, а Claude Mythos 5 (котрий ми так і не бачили) - 88.0%
Справжній стрибок до 91.9% з'являється тільки в режимі ultra, коли під капотом запускається рій сабагентів. Та сама ідея, що вже працює в Claude Code (динамічні воркфлоу), тільки зашита прямо в модель (як я зрозумів з опису).

👉 Друге але. Реліз моделі пригальмував уряд США - через кіберспроможності (опять 25)

Тому зараз модель доступна тільки вузькому колу партнерів (близько 20), погоджених з адміністрацією, і лише через API та Codex. У ChatGPT та для звичайного юзера її ще немає. Ширший доступ обіцяють за кілька тижнів.

Виходить, вперше вийшла модель, яку показали всім, а дали - одиницям

Джерело: https://openai.com/index/previewing-gpt-5-6-sol/

Youtube | Instagram

Агенти пишуть тобі сміття, увага, не тому що вони тупі

Хоча часто дуже хочеться саме так і сказати 😅

Типу сидиш, даєш агенту задачу, він щось там генерує, розкладає по файлах, пише “готово”, “усе працює”, “я все перевірив”
А потім ти відкриваєш код і такий:

боже
шо це за гівно

👉 Я записав про це новий відос відео:

І головна, що проблема часто не в моделі, а в процесі навколо неї
• Бо якщо не дав контекст - вона вгадає
• Якщо засрав чат - вона затупить
• Якщо не дав перевірку - вона повірить сама собі
• Якщо не міряєш якість - ти просто вайбчекаєш
• Якщо не записуєш правила - завтра вона повторить ту саму помилку

Як на мене вийшло цікаво 😅 Сподіваюсь кожен знайде для себе щось корисне. Приємного перегляду 😘

https://www.youtube.com/watch?v=wOW0-RZDPbA

Youtube | Instagram

От-от вийде Sonnet 5

І так, вже в наступній версії 2.1.197 модель зʼявилась в списку доступних, її можна активувати, але для використання поки обмежена, то ж чекаємо офіційного релізу і анонса

Ще лютому ходило багато слухів, що ця модель просто неймовірна і що вона може впоратись з кодінгом супер складних проектів. Після чого антропіки випустили sonnet 4.6 і слухи затихли 🙂

То як думаєте, чого очікувати?

👉 Для тих, хто хоче побачити на власні очі - треба примусово поставити наступну версію

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.197

Youtube | Instagram

UPD: Релізнули 🙂 Тестуємо, поки Сполучені Штати не заблокували 😁

Fable 5 знову доступний

https://x.com/claudeai/status/2072402636813607381

Судячи з усього фолбек на opus буде доволі частою історією, але це не повод не тестити.
До 7 липня можна користуватись моделю і вартість входить в ліміти (до 50% від тижневого), а потім буде за окремий кост.

Вже можна пробувати, якщо у вас все ще не перемикається на нову модель - оновить клод код і перелогіньтесь

Youtube | Instagram

🔄 Loop Engineering - наступний крок після Сontext Engineering

Ну що друзі, продовжуємо занурюватись в АІ напрямок. Сontext Engineering дав загальну картину: як побудувати робочій розробниціький workflow.

Але є одна річ, від якої залежить, чи можна цьому workflow довіряти, бо агенти самі по собі здатні доволі сильно часто приверати і не виконувати обіцяну роботу.

І це feedback loop. Тобто додаткові перевірки (круто коли вони детерміновані по типу тестів чи лінтерів) на котрі агенти можуть спиратись під час виконання конкретної задачі

Проблема в тому, що між кроками у агента немає чіткого розуміння чи виконав він задачу, чи ні. І поки його немає - єдиним врифікатором залишається людина. Ну і спочатку це прикольно, перечитувати що там згенерував агент, але швидко втомлює і кожен знає, як це приймати зміни наосліп 😉

11 липня проводжу окремий воркшоп саме про це

Наживо розберемо:
✅ чому агент зупиняється коли йому «виглядає готово»
✅ шар верифікацій: test/lint, logs, metrics, verifier та judge agents
✅ хуки котрі допомогають блокувати неякісні реалізації
✅ «очі» і «вуха» для агента - Playwright, логи, метрики
✅ як змусити агента навчатись через learning loop та меморі

Що отримаєш: готові сценарії перевірок, котрі одразу можна буде застосувати в своїх проектах. І розуміння, де ставити що саме верифікувати, які є інструменти, які є стратегії, як це тестувати, щоб це був engineering, а не vibe coding 🙂

🗓 11 липня, старт о 12:00 за Києвом
🖥 Онлайн, дві частини з перервою на каву
💬 Плюс розбір твоїх питань наживо

💶 Зараз найнижча ціна. Деталі та участь 👉
https://agenticengineering.it.com/workshop-july11

Чому агент тупить при вирішенні бажинок?

Тобі, як зазвичай, прилітає баг. Закидаєш агенту опис проблеми, стектрейс, тести, лінк на issue і купу додаткової інфи. І чомусь одну бажинку він фіксить одразу, а на дуже схожій проблемі ловить затуп. І інформація начебто однакова, і проблеми схожі, але працює через раз

👉 Вийшло дослідження «How Do LLMs Read Bug Reports?» - хлопці полізли подивитись, куди модель спрямовує attention (увагу), коли сама генерує готовий патч на баг. Це називається APR (Automated Program Repair)

Attention - це механізм всередині моделі, за допомогою якого вона на кожному кроці вирішує, які токени з усього твого промпту брати до уваги, а які майже ігнорити. Технічно - для кожного токена рахуються ваги до всіх інших токенів, і на виході зважена сума. Тобто модель не читає промпт рівномірно, вона щоразу вирішує, що в ньому важливе, а що не дуже

Дослідники по черзі прибирали частини bug report і перевіряли, наскільки через це змінюється згенерований патч. Якщо після видалення фрагмента патч сильно змінювався - значить, ця інформація суттєво впливала на рішення моделі.

А тепер згадай, що лежить у звичайному bug report - змінні оточення, версії бібліотек, номери білда, купа технічної інфи. Для моделі це такі ж токени, і туди теж може піти увага

🎯 Суть дослідження:
Взяли 319 багів на python і java зі SWE-bench Verified і Multi-SWE-bench. Для кожного простежили, як attention розподіляється по секціях bug report, і порівняли вдалі фікси з невдалими і дійшли такого висновку:

successful repairs are characterized by diffused attention across multiple diagnostic components such as bug descriptions, stacktraces, and test cases, while failures often exhibit over-localized attention toward metadata such as version information

Тобто:
✅ вдалий фікс - увага розподілена між кількома релевантними компонентами: опис + стектрейс + тести і модель може втримати в фокусі всю картнику
❌ провальний - увага залипає на чомусь вузькому, найчастіше на метаданих (типу версії бібліотек). Фактично модель чіпляється за другорядну деталь і спрямовує всю увагу туди

Під час дослідження модель залипла на посиланні на зовнішній PR, до якого не мала доступу, і проігнорувала згадку TypeError, яка фактично вказувала на те, як зробити фікс

Ще цікаво, хоча і очевидно, що чим сильніше attention моделі збігається з тим, що самі розробники вважають головною проблемою через яку виник баг - тим вищий шанс, що фікс спрацює

Що з цим робити
📍 Не вивалюйте моделі все однією купою. Структуруйте дані: спочатку головне - опис, потім стектрейс, потім тест
📍 Не давайте агенту лінки, бо якщо він не може реально відкрити issue або PR, посилання може стати ще одним відволікаючим токеном. Краще вставити релевантний фрагмент прямо в контекст
📍 Метадані винесіть в окремий блок і залишайте лише тоді, коли версія або оточення справді можуть пояснювати баг
👉 Якщо агент затупив, перший інстинкт - докинути ще контексту, але на практиці спочатку спробуй навпаки - прибери шум і дай один точний приклад чи напрямок

p.s. окрема кайфова тема - Iron Law: працює дуже добре, але це вже на окремий пост

Youtube | Instagram

Чи готовий агент чергувати замість тебе?

Продовжуємо гілку цікавих досліджень

Чергування - це коли серед ночі тебе будить алерт, продакшн лежить, і треба шивдко зрозуміти, що саме зламалось і чому. Робота напряжна, виснажлива, давно хочеться віддати її агенту. Отже вирішили це перевірити - подивитись як таку задачу будуть вирішувати топові моделі

🔬 Як перевіряли
Тестове оточення майже як продакшн - повноцінна архітектура з 19 мікросервісів з метриками, логами, трейсами (Prometheus, Jaeger, OpenSearch через Grafana) і повним доступом до коду. Баги теж докинули цілком реальні: на основі feature flags, які вмикають за розкладом, тож збої виглядають як природні

Складність кожної задачі вимірювали так:
• наскільки конкретний звіт користувача - Easy, Medium чи Hard (рівні складності самих задач)
• скільки часу минуло до виявлення - від 15 хвилин до 24 годин
• скільки поломок співпало одночасно - 5 сценаріїв: ізольована / незалежні / конфліктні / каскадні / послідовні

📊 Що саме міряли
RCA тут - це root cause analysis, пошук причини поломки, міряли три штуки:
• RCA Accuracy - чи назвав агент УСІ справжні причини
• RCA Depth - наскільки глибоко докопався, шкала від 0 до 3
• Hallucination Rate - як часто вигадав причину, якої взагалі не було

Еталонні відповіді складали і затверджували самі SRE (інженери що відповідають за надійність софта). Оцінки спершу виставляв LLM-суддя, потім люди переоцінили вручну і майже повністю з ним зійшлися

🎯 Що вийшло
Найкращий агент знаходить справжню причину приблизно в одному випадку з чотирьох на середніх інцидентах і в одному з десяти на важких. І це топова модель, найкраща з тестованих (Opus 4.7, Sonnet 4.6, GPT-5.5, GLM-5, DeepSeek-V4-Pro)

А найслабша модель (DeepSeek-V4-Pro) у 40% звітів впевнено вигадувала причину, якої в системі взагалі нема.

❗️ Чому Hard такий важкий
Один і той самий інцидент переписали в три версії, просто ВИДАЛЯЮЧИ слова. На Hard агент бачить лише «users are reporting site issues», і все. Через таку розмитість на кожен інцидент стає більше причин, які треба перебрати.

Також окремий парадокс з кодом. Якщо забрати у агента доступ до коду, то результати сильно погіршуються, отже телеметрії недостатньо, треба лізти в код і читати. Але сам Opus на читання коду витрачає лише 16% своїх дій, а на телеметрію - 72%

Автори попереджають, що навіть ці цифри оптимістичні:

Every dimension along which ORCA-bench simplifies real production points in the same direction: real oncall is harder.

Висновок

Зазвичай всі дивляться на SWE-bench, котрий показує, що агент вміє полагодити вже знайдений баг. Але oncall - це коли ще ніхто не знає, що зламалось, дані розкидані, і падає кілька речей одразу. Поки що тут тупить будь-яка модель. Тож якщо мрієш віддати агенту нічні чергування - мрій :)

Але напрямок правильний, і бенчмарк нарешті міряє те, що дійсно болить

Youtube | Instagram

Твій скіл можна шерити в команді?

Зняв новий відос про зрілість Agent Skill, як довести скіл від найпростішого стану до такого, що не соромно віддати команді.

Ось ця драбина зрілості, по рівнях:

1️⃣ Файл із трьох рядків - мінімальний робочий скіл
2️⃣ Фіксований workflow - додаєш чітку послідовність кроків, і агент перестає імпровізувати
3️⃣ Опис як маршрутизатор - тут агент сам вирішує, коли підвантажити скіл
4️⃣ Три шари підвантаження - головний файл тонкий, деталі тягнуться за потреби
5️⃣ Права і середовище виконання - прописуєш, які інструменти скілу дозволені, які заборонені
6️⃣ Евали - перевіряєш скіл на реальних кейсах, і впроваджуєш тестування скілів та агентів
7️⃣ Дистрибуція - пакуєш скіл з папки в плагін, віддаєш команді й далі підтримуєш

👉 Переходьте, дивіться, коментуйте - буду вдячний за фідбек 🙂

https://www.youtube.com/watch?v=3t7VVZp2si8