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

Безкоштовний воркшопчик

📅 20 серпня, четвер, 19:00 за Києвом - проводжу безкоштовний воркшоп на 3 години
Якщо раніше не були на моїх воркшопах - для вас буде багато цікавого.

Тема: як віддавати агентам більше роботи і не втрачати контроль над результатом.

Беру сиру ідею, наговорену голосом, і за три години наживо доводжу її до продукту на власному домені.

Пройдемо по такому воркфлоу

🟢 Карта рішень - як зупинити агента від додумування вимог
🟢 Специфікація з критеріями приймання і пошук неоднозначностей
🟢 Архітектура, модель даних, API-контракт, діаграма станів
🟢 TDD з coding-агентом у маленькому перевірюваному циклі
🟢 Верифікація: скріншоти, E2E, незалежне рев'ю, смоук-тест після деплою

👉 Що отримаєте вкінці

Карту всього процесу, приклади документів, чекліст і відкритий репозиторій зі скілами, агентами й ранбуком.
І, звісно, розуміння, де у вашому процесі зараз найслабше місце

Про формат: Це демо. Я будую, ви дивитесь 🙂 також пояснюю навіщо потрібен кожен крок. Практики в моменті не буде, щоб змогли пройти як умога далі за зазначений час

⏱️ 180 хвилин, online в zoom
💰 Безкоштовно

🔗 Реєстрація та деталі

Запилив новий відос про безпеку AI-агентів

У квітні AI-агент у Cursor за дев'ять секунд зніс компанії продакшн-базу. Разом із бекапами. Агент просто мав токен, широкі права й доступ до API.

А коли хакер є, все стає ще цікавіше. Йому навіть не обов'язково ламати твою машину. Іноді достатньо написати звичайний GitHub issue, який прочитає твій агент.

Фактично для моделі твій промпт, написаний issue, відповідь MCP-сервера чи завантажений SKILL.md - це просто текст в одному контексті. А виконує вона цей текст уже з твоїми правами.

У відео розбираю:

• як через issue або пошту перехоплюють керування Claude Code, Cursor, Codex і Gemini CLI;
• як AI вигадує неіснуючі пакети, а хакери заливають туди трояни;
• чому секрети можуть потрапити в модель, навіть якщо агент не відкривав .env;
• чому CLAUDE.md, Cursor Rules і другий агент-рев'ювер самі по собі не рятують;
• як виглядає нормальна модель загроз і що варто перевірити у своєму проєкті.

Для цього відео я перелопатив понад двадцять першоджерел 😅

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

Дивитися тут: https://youtu.be/QKRs6IHV-y4

Після перегляду напишіть у коментарях: ваш агент уже намагався залізти туди, куди його взагалі не просили? 👇

Youtube | Instagram

Друзі, є чудова новина :)

Сьогодні стартує нова група Agentic Engineering.
Кілька людей перенесли свої бронювання на жовтень - і звільнилось 4 місця.

Якщо ти давно приглядався до курсу - це той самий знак(!), що пора доєнуватись
можна зайти прямо зараз і не чекати наступний потік😉

Тебе чекає:
12 тижнів, 11 модулів за які ти вбудовуєш агентний воркфлоу у свою роботу

Розбираємо систему - власні скіли й субагенти під твій стек, повний цикл Spec-Driven Development, отримаєш результат на власному проєкті

Кому це буде корисно:

→ пишеш код щодня і хочеш перейти від AI-чатів до системного воркфлоу
→ вже юзаєш Claude Code / Cursor / Codex, але процес тримається на промтах
→ хочеш, щоб агент давав передбачуваний результат, бо зараз це як рулетка

Щоб приєднатись - заповни коротку анкету, і моя команда звʼяжеться з тобою: детально розповість про продукт, формати та умови навчання👇

https://agenticengineering.it.com/anketa

Місць 4. Група стартує сьогодні, матеріали теоретичних модулів відкриваються одразу, а перший ефір за 2 тижні - тож і вирішувати варто швиденько😎

А старі моделі часом не пишуть краще? 🤔

Я помітив, що читати тексти, які видає AI, стало складніше. Вони якісь менш складені, перевантажені менш природні чи бог його знає які

😅 І я це прям дуже добре помітив на своєму прикладі. У мене є бот, який присилає мені новинний дайджест. І останнім часом його читати стало просто неможливо

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

Знову ж таки - це чисто суб’єктивна думка, тому не засуджуйте 😄

👉 Спробував прогнати це через claude-opus-4-5, і шо я побачив, що текст легше читається і легше сприймається. Тобто мені реально більше подобається як стара модель пише 🙂

Попри те, що Opus 4.5 коштує стільки ж, скільки 5, у мене виникло логічне питання:

❓навіщо платити стільки ж за старішу модель?

Але по факту вона:
• швидше видає результат;
• суб’єктивно пише простіше;
• і результат мені банально більше подобається.

📌 Можливо це через новий tokenizer Anthropic, котрий з'явився починаючи з Claude 4.7 (доречі самі антропіки пишуть, що він генерує на 30% більше токенів тексту). Тобто теоретично, стара модель все ж таки буде коштувати трошки дешевше.

📌 Або можливо вотермарк, хоча Anthropic звісно пишуть, що він не повинен помітно впливати на якість або читабельність тексту (ще б вони стверждували щось інше)

Коротше цікаво те, що умовно «тупіша» або старіша модель може бути для конкретної задачі навіть кращою

Я ще спробував Haiku, але він мені вже здався доволі тупим 😄 Але тепер цікаво поганяти ще й GPT-шні моделі

Цікаво, чи помічали ви таке? Чи користуєтесь старішими / слабшими моделями для якихось конкретних задач?

Або, можливо, у вас є якісь свої skills, prompts або інші фішки, якими ви робите генеровані тексти більш адекватними та читабельними?

Youtube | Instagram

І знову я зі своїм воркшопом 🙂

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

Тепер до основної теми

Я вже провів кілька воркшопів з Agentic Engineering Workflow за останні місяці. Кожного разу після ефіру отримую повідомлення від тих, хто пропустив, а чи буде ще
Буде!

17 і 19 вересня проводжу ще один:

📅 17 вересня, 19:00 (Київ) - теорія: як агент працює під капотом, чому щось постійно забуває, чому вгадує, що з цим робити
📅 19 вересня, 13:00 (Київ) - практика: повний шлях фічі від ідеї до коду, показую на своєму робочому проекті, а ви паралельно - тренуєтесь кожний на своєму

Практику проходять усі учасники.

Також обовʼязково буде Q&A і в перший і в другий день. Можна (і треба) приходити зі своїми питаннями, проєктами, кейсами.
Запис буде! правда-правда 🙂 У кожного учасника буде доступ і одразу після зустрічі

Якщо ще не були - запрошую приєднатись😌

Деталі: https://agenticengineering.it.com/workflow-september17

Youtube | Instagram