Beer::Code🍺

описание

Тут публікуються короткі замітки про PHP, Linux, Unit Testing, DB, OOP тощо, витяги зі статей, книг, відео, курсів та інших матеріалів. Тепер тобі більше не потрібно перегортати тонни інформації ;) @genkovich — написати автору каналу.

← к каналу @beerphp

3 342

подписчиков

Охват к подписчикам

84,5%

ERR

Реакции к просмотрам

0,74%

741 на 34 постов

Пересылки к просмотрам

0,80%

807

Постов в день

0,0

всего 35

Где отзываются чаще

доля реакций к просмотрам

9 авг.без подписи3,05%
9 авг.Твій скіл можна шерити в команді? Зняв новий відос про зрілість Agent Skill, як довести скіл від найпростішого стану до такого, що не соромно віддати команді. Ось ця драбина зрілості, по рівнях: 1️⃣ Файл із трьох рядків - мінімальний робочий скіл 2️⃣ Фіксований workflow - додаєш чітку послідовність кроків, і агент перестає імпровізувати 3️⃣ Опис як маршрутизатор - тут агент сам вирішує, коли підвантажити скіл 4️⃣ Три шари підвантаження - головний файл тонкий, деталі тягнуться за потреби 5️⃣ Права і середовище виконання - прописуєш, які інструменти скілу дозволені, які заборонені 6️⃣ Евали - перевіряєш скіл на реальних кейсах, і впроваджуєш тестування скілів та агентів 7️⃣ Дистрибуція - пакуєш скіл з папки в плагін, віддаєш команді й далі підтримуєш 👉 Переходьте, дивіться, коментуйте - буду вдячний за фідбек 🙂 https://www.youtube.com/watch?v=3t7VVZp2si82,31%
31 июл.Чому агент тупить при вирішенні бажинок? Тобі, як зазвичай, прилітає баг. Закидаєш агенту опис проблеми, стектрейс, тести, лінк на 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 | Instagram2,12%
2 авг.Чи готовий агент чергувати замість тебе? Продовжуємо гілку цікавих досліджень Чергування - це коли серед ночі тебе будить алерт, продакшн лежить, і треба шивдко зрозуміти, що саме зламалось і чому. Робота напряжна, виснажлива, давно хочеться віддати її агенту. Отже вирішили це перевірити - подивитись як таку задачу будуть вирішувати топові моделі 🔬 Як перевіряли Тестове оточення майже як продакшн - повноцінна архітектура з 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 | Instagram2,11%
26 мар.AI Workflow Багато розробників вже пробували AI в роботі, але по даним опитування на stack overflow довіра до того, що AI генерує, впала з 70% до 60% за 2025 рік. Чому? Бо підхід "кинув в чат - отримав результат" показує себе не кращим чином 👉 Але якщо побудувати pipeline, де кожен етап має свій контекст і свої перевірки - картинка змінюється. Спочатку аналіз задачі і генерація вимог, потім дизайн в Figma - щоб побачити візуально ще до першої строчки коду, потім імплементація з тестами і обовʼязково код-рев'ю Тобто AI не просто "генерує код", він аналізує, проектує, верифікує і рев'юїть і все це в циклі, котрий відвторює SDLC 📍 Закинув відос де показую весь цей цикл на прикладі, то ж переходьте, дивіться, буду вдячний за фідбек 🙂 https://www.youtube.com/watch?v=4uLqamwjl-w #ai #claudecode #workflow #sdlc1,72%
9 июн.UPD: ну і, власне, релізнули Fable 5 тепер доступний в Claude Code і Cowork Anthropic прямо називає її Mythos-class model, яку зробили безпечною для general use Boris Cherny пише, що це найкраща модель для кодингу, яку він використовував, причому з великим відривом І що саме покращилось: → менше треба промптити і постійно рулити руками → ефективніше використовує токени → краще пише код → краще користується тулами → розумніше себе перевіряє → довше тримає сесію → більше trust & autonomy Ну що, погнали тестувати і ділитись враженнями 😁 Youtube | Instagram1,68%
28 маяAnthropic випустили Opus 4.8 Буквально сьогодні говорили про те, що якось 4.7 потупішав, пахне новим релізом і от сталось Що обіцяють: 📍 Opus 4.8 сам проактивно сигналізує про проблеми у вхідних/вихідних даних. Інші моделі це регулярно пропускали. Тому пропонують активніше користуватись /goal Разом з моделлю - Dynamic Workflows (research preview): 👉 Якщо в Claude Code написати: "Create a workflow", то Claude складе план, запустить купу паралельних субагентів і перевірить вкінці роботу перед тим, як повернути результат. Ну що погнали тестити 🙂 Youtube | Instagram1,65%
9 июн.Anthropic, доволі чітко рухається в сторону автономної агентної системи для роботи Є дві новини, які окремо звучать цікаво, а разом - прям дуже показово. 1️⃣ ходить інсайд (поки тільки чутки), що Anthropic готує публічний Mythos. Судячи з опису, це має бути щось сильно краще для довготривалих і мультиагентних задач: → розбери задачу → побудуй план → піди в код → знайди контекст → внеси зміни → перевір → поправ → не загуби суть через 30 кроків 2️⃣ в Claude Code підʼїхав nested subagent support (має бути сьогодні в релізі) 👉 Ідея в тому, що агент зможе запускати інших агентів (Поки з обмеженням depth=5) Це ближче до структури команди: • головний агент задає ціль • один сабагент розбирає архітектуру • інший дивиться тести • третій копає edge cases • четвертий перевіряє, чи всі разном не наробили хєрні Довготривалі задачі побудовані на тому, що має бути 1. сильна модель 2. нормальне керування контекстом 3. делегування 4. контроль проміжних результатів 5. здатність не забути, навіщо ми взагалі почали 🔥Це, на мою думку, набагато важливіше, ніж чергові плюс 3% на SWE бенчмарках, бо реальна розробка, це коли ти відкрив легасі, через 20 хвилин зрозумів, що задача взагалі не про те, через годину знайшов приховану залежність, через дві - переписав план, а потім, при деплої ще маєш не зламати прод. Кодінг асистенти поступово перестають бути автокомплітом, вони стають чимось ближчим до маленької dev-команди, і це доволі цікаво Youtube | Instagram1,55%
3 апр.без подписи1,39%
30 июн.UPD: Релізнули 🙂 Тестуємо, поки Сполучені Штати не заблокували 😁1,31%
29 мар.без подписи1,23%
11 июн.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 | Instagram1,17%