Кому писатиме PM?

Вчора вийшла цікава моделька Sonnet 5 - швидка і досить розумна. А сьогодні обіцяють повернути Fable 5. Але насправді рівно тиждень тому Anthropic випустила щось більш важливе, ніж просто розумнішу модель - це Claude Tag https://www.anthropic.com/news/introducing-claude-tag .

На перший погляд наче нічого особливого - це просто можливість викликати Claude Code зі Slack. Devin так працює давно. Але він не настільки відомий, його ваш PM ймовірно взагалі не знає, на відміну від Клода.

І якщо раніше умовний Java-розробник Петро отримував задачу від PM, а потім писав Клоду щоб той її зробив, то зараз PM може сам написати Клоду. Розумієте, що це означає? :)

Але я у питаннях розробки з AI не казковий оптиміст, а цілком собі практикуючий реаліст, тому повністю усвідомлюю, що Клод потребує Петра. Просто в іншій ролі.

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

Відповідно і інженер не повинен змагатися з Клодом у навичках Java, а максимально швидко здобути навички Агентної інженерії, які включають керування контекстом, роботу з правилами/скілами для агентів, реалізацію агентних флоу, питання безпеки, витрат і багато чого іншого. Про Java тут взагалі нічого немає, бо Клоду все одно на чому писати.

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

Fable 5

Fable 5 - це, без сумніву, найтоповіша модель на сьогодні. Нарешті з неї зняли обмеження і вже приблизно добу я ганяю її для своїх задач.

Особливо гарно для неї підходять складні задачі, наприклад, покращення існуючих проєктів, аудит безпеки і тому подібне.

Але сьогодні я схоже вирішив проблему зі своїм комп’ютером, яка мене діставала кілька тижнів. У мене дуже потужний топовий по характеристикам лептоп, але останнім часом почав сильно лагати під час навантаження. Я грішив на перегрів, чистив від пилу, покращував охолодження, але навіть кондиціонер в кімнаті ситуацію не покращив. Збирався вже купувати новий, бо мені критично щоб не лагало під час занять і стрімів.

Але вирішив спробувати з Fable, дав йому у Claude Code повний доступ до системи, описав проблему і попросив вирішити. Він запустив купу сабагентів, проаналізував купу логів, робив навантажувальне тестування, визначив нерівномірне навантаження на USB контроллери, дав поради як перепідключити обладнання, але найголовніше - ідентифікував другорядний драйвер від Intel, який був причиною проблем. Після того як я його відключив, проблема зникла, поганяв комп’ютер в тих сценаріях, де проблема виникала, і тепер її немає. Дякую, Fable, що ти з нами :)

Code Review з AI

Чи знаєте ви, що AI вміє значно краще код писати, ніж перевіряти? І якщо максимум, що ви робите – це після виконання задачі агентом просто просите у тій же самій сесії її перевірити, то результат буде приблизно такий самий, як попросити студента перевірити власну домашку і поставити собі оцінку.

Чому «перевір себе» не працює

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

Перший – забруднений контекст. Коли агент перевіряє код у тій же сесії, де його писав, він дивиться не на код, а на власні міркування про нього. У контексті вже лежить його план, його пояснення, його впевненість, що все зроблено правильно. Модель фактично перечитує свій конспект, а не розв'язання. Якщо вона припустилась логічної помилки на етапі планування – та сама помилка сидить у контексті і виглядає як «правильна відповідь».

Другий – сліпі зони моделі. Якщо модель не побачила проблему, коли писала код, з чого б їй побачити її через хвилину, дивлячись на той самий код тими самими «очима»? Помилки моделі – це не випадкові одруки, це систематичні патерни її мислення. Просити її знайти власні системні помилки – все одно що просити людину помітити власну сліпу пляму.

Третій – вроджена схильність погоджуватись. LLM-ки натреновані бути корисними і підтверджувати. Спитайте агента «все ж добре, правда?» – і у 9 з 10 випадків він знайде спосіб відповісти «так, все чудово, лише кілька дрібних зауважень». Це не рев'ю. Це ритуал.

Принцип: розділяйте автора і рев'ювера

У людських командах ніхто не мержить власний PR без стороннього ока – і це правило з'явилося не просто так. З AI-агентами воно працює ще жорсткіше. Мінімальний робочий рецепт складається з трьох рівнів, і кожен наступний дає помітний приріст якості.

Рівень 1: свіжа сесія. Найпростіше, що можна зробити вже сьогодні – відкрити нову сесію (або новий термінал з claude -p, якщо ви в Claude Code) і дати агенту тільки diff та опис задачі. Без історії, без пояснень «чому я так зробив». Чистий контекст – і раптом агент починає бачити те, що годину тому «сам у себе» не помічав: незакриті edge cases, забуту обробку помилок, розбіжність між специфікацією і реалізацією.

Рівень 2: інша модель. Ще краще – щоб перевіряла модель з іншою «головою». Різні моделі мають різні систематичні помилки, і те, що є сліпою зоною для однієї, часто очевидне для іншої. Писали з Sonnet – дайте перевірити Opus або GPT. Це той самий принцип, чому в науці рецензент ніколи не є співавтором статті. До речі, GPT 5.5 зазвичай робить рев'ю краще, ніж Opus 4.8.

Рівень 3: спеціалізовані інструменти. І нарешті – інструменти, які створені саме для рев'ю, а не для генерації. Вони дивляться на PR структуровано: аналізують diff у контексті всього репозиторію, знають типові патерни вразливостей, вміють коментувати порядково прямо в GitHub.

Чим перевіряти

Екосистема AI code review вже цілком зріла, і ось з чим варто познайомитись у першу чергу:

CodeRabbit – мабуть, найпопулярніший спеціалізований рев'ювер. Підключається до репозиторію, автоматично коментує кожен PR, робить summary змін, ставить уточнювальні питання і навіть пропонує конкретні виправлення, які можна закомітити в один клік. Сильна сторона – порядкові коментарі та розуміння контексту репозиторію, а не лише diff.

GitHub Copilot code review – вбудований у GitHub, тому поріг входу мінімальний: призначаєте Copilot рев'ювером PR так само, як колегу. Ловить типові проблеми, добре інтегрований у звичний workflow, але за глибиною аналізу поки поступається спеціалізованим рішенням.

Qodo – гарний варіант з командами на кшталт /review, /describe, /improve прямо в коментарях PR.
Власний агент у CI/CD. Claude Code у headless-режимі (claude -p "зроби рев'ю цього diff за чеклістом...") чудово вбудовується в pipeline. Ви повністю контролюєте промпт, чекліст і формат виводу – і саме тут можна закласти специфічні для вашого проєкту правила, які жоден готовий інструмент не знає.

Мультиагентне рев'ю: кілька пар очей краще за одну

А тепер найцікавіше. Ці інструменти не конкурують – вони доповнюють один одного. Я часто проганяю через кілька рев'юверів паралельно. Результат показовий: чим частіше проганяєш, тим більше шансів щось знайти. Один інструмент знайшов потенційну проблему безпеки, інший неконсистентність в обробці помилок, третій підсвітив архітектурне зауваження, яке перші два проігнорували.

Це і є головний практичний висновок: AI-рев'ювери мають різні сліпі зони, тому мультиагентний pipeline знаходить суттєво більше, ніж будь-який окремий інструмент. Вартість додаткового рев'ювера виправдовує вартість проблем, яким він допомагає запобігти.

Робоча схема виглядає так:

Агент виконує задачу (бажано за специфікацією, а не за вайбом – але це тема окремої статті).
Потім ви локально робите рев'ю, і якщо готові, робите PR.
PR автоматично проходить ще через 2–3 AI-рев'ювери.

Свіжа сесія агента-автора отримує зведені зауваження і виправляє їх – знову ж таки, з чистим контекстом.

Нарешті людина дивиться фінальний результат і зведення знахідок.

Що AI ловить добре, а що – ні

Щоб не було завищених очікувань, чесно про межі можливостей.

AI-рев'ювери сильні там, де потрібна уважність: типові вразливості (ін'єкції, небезпечна робота з секретами), race conditions у простих випадках, необроблені помилки, неконсистентність зі стилем кодової бази, забуті edge cases, розбіжності між кодом і документацією.

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

Замість висновку

Правило просте, і я раджу повісити його на стіну кожній команді, яка працює з агентами:

checker ≠ maker

Свіжа сесія – мінімум. Інша модель – краще. Спеціалізований інструмент або кілька – ще краще. Людина, яка дивиться на суть, а не на дрібниці в коді – обов'язково.

AI дійсно пише код швидше за нас. Але саме тому перевіряти його треба ще ретельніше – просто робити це теж можна з AI. Головне, щоб студент не перевіряв власну домашку.

А я сьогодні мало спав і майже від комп'ютера не відходив :)

Всім вітання!

Якщо я якийсь курс пораджу, то лише гарний :)

Вже завтра Fwdays Academy запускає Crash Course Storytelling для інженерів від Павла Полякова, Principal engineer у Free to move.

⏰Лишилися останні місця.

Дисконт для підписників за цим посиланням:
👉 https://bit.ly/3R1d0Jk

Що буде:
🎯 структура технічної історії для презентацій, мітингів і пітчів
🎯 вміння пояснювати складні ідеї для технічної та нетехнічної аудиторії
🎯 шаблон самопрезентації та професійного наративу
🎯 storytelling як інструмент впливу без формальної влади
🎯 AI як помічник у побудові переконливих історій

Це історія не зовсім для джунів, до нього треба дозріти, але хто дозрів, то є сенс повчитися у професіоналів.

Про метрики

В умовах перебудови SDLC під тиском агентної розробки, питання метрик насправді дуже проблемне зараз у багатьох.

Але я завжди раджу не потрапити в пастку tokenmaxxing, бо як тільки розробників починають ранжувати за обсягом спалених токенів, то будь-якому розумному розробнику треба буквально 5 хвилин, щоб навантажити своїх AI агентів на максимальне спалювання токенів. І я не говорю про якусь абстрактну роботу, це може бути щось "умовно корисне", наприклад, усунення технічного боргу чи ще краще - робота над якоюсь фічею в циклі.

Для прикладу, я імплементував Фабрику проєктів з купою різних верифікацій і якщо її запустити над якоюсь задачею і поставити ціль довести до досконалості, то вона нон-стоп буде спалювати $1000 тис. в токенах на добу дуже легко :)

А що тоді по метрикам? А тут не треба винаходити велосипед - треба виміряти і зафіксувати звичайні проєктні метрики, наприклад, DORA: частота деплойментів, lead time від коміту до продакшена, відсоток невдалих змін (change failure rate) та час відновлення після інциденту. До них можна додати cycle time по задачах, escaped defects (скільки багів долетіло до продакшена), і головне - реальний throughput бізнес-цінності: скільки фіч чи задач з беклогу фактично закрито і прийнято.

Але токени тежє варто міряти, однак це витрати, а не результат. Тому їм місце в знаменнику, а не в чисельнику. Цікава метрика не "скільки токенів спалив розробник", а "скільки коштує в токенах одна доставлена фіча" або "одна закрита задача".

І тоді ми і adoption поміряємо, і delivery, бо роздування витрат без росту результату одразу видно. А розробник, який за $20 в токенах закриває те, на що в іншого йде $500, виглядає саме тим, ким він і є - ефективнішим.

Рівні автономності AI-агентів, новий SDLC і чому я вирішив піти з SoftServe

Нове відео на ютуб-каналі https://youtu.be/VsH99Ny30as

За три роки розробка з AI пройшла шлях від автодоповнення в Copilot до автономних агентів, які самі імплементують і верифікують задачі.

Імплементація тепер займає хвилини — найскладнішим стало прийняти й перевірити роботу агентів.

А ті, хто не перебудується, просто підуть з ринку.

У відео:
▪️ 4 рівні автономності AI (за свіжим звітом Google)
▪️ новий SDLC, evals і Self-Improving Project Factories
▪️ чому сервісна модель українського IT у зоні ризику
▪️ моя нова AI-native компанія: агентна інженерія під ключ

Моя нова стаття на ДОУ, бачу по коментарях гарно зайшло :)
https://dou.ua/forums/topic/60832/

Про нові моделі

Нещодавно головні гравці на ринку трохи наспамили нових моделей, і бенчмарки по ним вийшли суперечливі - Anthropics заявляє що Opus 5 навіть розумніший за Fable 5, OpenAI переконує що їх GPT 5.6 sol найкращий, а тут ще й китайці з Kimi 3 неочікувано побили всіх по фронтенду (до виходу Opus 5), та й взагалі сильну модель зробили для програмування. Але якщо взяти до уваги не абсолютний інтелект, а співвідношення інтелекту і вартості, то виявляється, що на першому місці взагалі Grok 4.5 (дивимося тут у праву верхню частину).

То що з цим всім робити? Яку модель обирати, кому заносити гроші за токени?

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

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

Наприклад, у OpenAI є окремий розділ на сайті, де рекомендації по промптингу наведені по версіям моделей https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6
Там просто переключаєте версії і читаєте рекомендації.

Аналогічно у Anthropic, там просто моделі переключаєте у навігації з лівої сторони
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

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

Далі обидва вендори, кожен своїми словами, радять по суті одне й те саме: прибрати зайве з промптів. OpenAI навіть наводить цифри зі своїх внутрішніх прогонів evals для кодинг-агента – зменшені системні промпти дали приблизно +10–15% до оцінок, при цьому мінус 41–66% токенів і мінус 33–67% вартості. Anthropic формулює аналогічно: скіли та інструкції, написані під попередні моделі, часто виявляються надто прескриптивними і погіршують результат – їх треба перечитати й повикидати те, що модель тепер робить краще без вас.

Тобто ваша бібліотека промптів і скілів – це не актив назавжди. Це те, що доведеться ревізувати з кожним релізом. Привіт, для тих, хто складав промпти у “бібліотеки”.

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

Зверніть також увагу, що модель видає результат, який дуже залежить від налаштувань міркувань (reasoning, effort - low / medium / high / xhigh і т.п.) У багатьох моделей тепер якість результату буде від цього сильно залежати, ви маєте цей рівень підбирати уважно.

Третє – межі автономії. Загальна рекомендація - заздалегідь визначати, що агент може робити сам (читати файли, дивитися логи, правити код у скоупі, ганяти тести), а що потребує підтвердження (зовнішні записи, деструктивні дії, розширення скоупу). Якщо накидати по всьому промпту «спитай спочатку», «не чіпай», «дочекайся апруву» – модель почне зупинятися там, де не треба, і ви самі собі зробите гірше.

Четверте, і особисто для мене найцікавіше, бо я багато пишу про verification gap. Anthropic рекомендує явну інструкцію: перед тим як звітувати про прогрес, звірити кожне твердження з реальним результатом виклику інструмента, а неперевірене – прямо називати неперевіреним. За їхніми тестами це майже повністю прибирає вигадані звіти про виконану роботу, навіть на задачах, спеціально сконструйованих щоб їх спровокувати. Тобто частина проблеми «агент сказав що зробив, а насправді ні» лікується не лише тулінгом і хуками, а одним абзацом у промпті.

П'яте – довгі запуски стають нормою. Anthropic пише, що окремий запит на складній задачі може виконуватися багато хвилин, а автономний запуск – годинами. З цього випливає цілком інженерна робота: таймаути, стрімінг, індикатори прогресу, асинхронна перевірка запусків замість блокуючого очікування, паралельні субагенти й окремі верифікатори зі свіжим контекстом. Плюс зовнішня пам'ять: банальний markdown-файл, куди агент записує висновки з попередніх запусків, дає хороший ефект.

Якщо коротко:
- На бенчмарки дивитеся лише для загального орієнтиру.
- Ганяєте моделі на своїх задачах, за можливості переключаєтеся між ними, виконуєте в паралель щоб побачити що краще працює.
- Для кращого результату - заглянте в гайди промптингу конкретної моделі, підправити промпт/контекст часто спрацьовує краще, ніж змінити модель.
- Думка, що «модель тупіша за попередню» – часто причина в промпті, який був заточений на попередню модель. Перепишіть промпти, спростіть їх і подивіться, чи це допомогло.
- Експериментуйте з режимами міркувань - “слабша” модель з вищим режимом може виявитися дешевшою і кращою, ніж “сильніша”, але з нижчим.

Ну і пам’ятаємо, що промпти/скіли/правила - це все живий артефакт проєкту, який не пишеться один раз, його треба супроводжувати точно як код, а вже скоро - і замість коду :)

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

По цьому маю кілька важливих апдейтів:

1. З fwdays запускаємо черговий креш-курс по Агентній інженерії, 5 живих онлайн-занять (+1 заняття опційне), інтенсивно, орієнтовано на людей, що хочуть отримати швидкий результат. Зараз ціна найнижча до 1 серпня, знижки не діють, це Early Birds. Реєстрація та деталі. Я ще закину інфу про курс окремим постом.

2. Активно проводжу корпоративне навчання по Agentic Engineering / AI Assisted розробці - від тривалих програм з нуля, до швидких поглиблених інтенсивів. Працюю з кількома компаніями-клієнтами також веду перемовини з потенційними клієнтами, кепесіті для нових клієнтів ще є, але швидко вичерпується, кому цікаво - не відкладайте, контактуйте.

3. І нарешті - я довго обдумував концепт свого джедайського курсу і нарешті виводжу його на публіку. На відміну від курсів/воркшопів, які роблю з fwdays, це буде тривала програма на рік, без живих занять, учасники будуть рухатися по підручнику з детальним контентом і завданнями у власному темпі, я буду підтримувати в діскорді плюс давати фідбеки до завдань. Зараз запускаю орієнтований на розробників курс по Agentic Engineering СИТХ. Курс недешевий, тому зробив можливість брати в розстрочку монобанку, у такому випадку ціна виходить дуже ок. Для своїх підписників даю знижку 15% (діє лише на оплату одним платежем), купон SITH_FORCE (його треба вставити в поле з коментарем у формі під час оформлення покупки), а ще буде ексклюзивний подарунок - стартер-кіт, який дозволить генерувати сайти в стилі лендингу джедайського курсу.

Купон і подарунок діють до 09 серпня, більше цей подарунок доступний не буде. Лендинг курсу тут
PS. Згодом ще концепт нового джедайського курсу розпишу детальніше, відосик теж запишу.

🤔 Платите за AI-інструменти, але більшість роботи все одно робите вручну — бо не знаєте, скільки можна довіряти агенту?
Довірите замало — AI перетворюється на дорогий автодоповнювач. Довірите забагато — отримаєте код, за який соромно на рев'ю. Між цими крайнощами існує ціла система, яку ніхто не пояснив.

🪄 Пройдіть шлях від першого агента-асистента до повністю автономної фабрики проєктів на Crash Course: Agentic Engineering від Fwdays Academy та Вʼячеслава Колдовського!

📅 Старт: 8 вересня
🛠 Формат: 6 онлайн-сесій + практичні домашні завдання
👉 Реєстрація та деталі: https://bit.ly/4b624kr
⚡️До 1 серпня діє ціна Early Birds!

👨‍🏫 Ментор: В'ячеслав Колдовський — Founder Dev AI Consulting. 20+ років в IT, Google Cloud Professional Cloud Architect, керівник Центру Gen AI в IT STEP Університеті.

Результат курсу:
🎯 поступове проходження 6 рівнів довіри до агентів
🎯 власна фабрика проєктів: harness, guardrails і observability, зібрані з нуля на ваших очах
🎯 практика Spec-Driven Development і делегування в Claude Code, Cursor та ChatGPT Codex
🎯 повна трасованість: ви завжди бачите, що агент зробив, чому і скільки це коштувало
🎯 capstone-проєкт із сертифікатом і журналом автономності — артефакт, який можна показати команді

🚀 Не наглядайте за агентами, а навчіться керувати ними разом з Fwdays Academy!