Programming Mentor

Про метрики В умовах перебудови SDLC під тиском агентної розробки, питання метрик насправді дуже проблемне зараз у багатьох. Але я завжди раджу не потрапити в пастку tokenmaxxing, бо як тільки розробників починають ранжувати за обсягом спалених токенів, то будь-якому розумному розробнику треба буквально 5 хвилин, щоб навантажити своїх AI агентів на максимальне спалювання токенів. І я не говорю про якусь абстрактну роботу, це може бути щось "умовно корисне", наприклад, усунення технічного боргу чи ще краще - робота над якоюсь фічею в циклі. Для прикладу, я імплементував Фабрику проєктів з купою різних верифікацій і якщо її запустити над якоюсь задачею і поставити ціль довести до досконалості, то вона нон-стоп буде спалювати $1000 тис. в токенах на добу дуже легко :) А що тоді по метрикам? А тут не треба винаходити велосипед - треба виміряти і зафіксувати звичайні проєктні метрики, наприклад, DORA: частота деплойментів, lead time від коміту до продакшена, відсоток невдалих змін (change failure rate) та час відновлення після інциденту. До них можна додати cycle time по задачах, escaped defects (скільки багів долетіло до продакшена), і головне - реальний throughput бізнес-цінності: скільки фіч чи задач з беклогу фактично закрито і прийнято. Але токени тежє варто міряти, однак це витрати, а не результат. Тому їм місце в знаменнику, а не в чисельнику. Цікава метрика не "скільки токенів спалив розробник", а "скільки коштує в токенах одна доставлена фіча" або "одна закрита задача". І тоді ми і adoption поміряємо, і delivery, бо роздування витрат без росту результату одразу видно. А розробник, який за $20 в токенах закриває те, на що в іншого йде $500, виглядає саме тим, ким він і є - ефективнішим.

Всім вітання! Якщо я якийсь курс пораджу, то лише гарний :) Вже завтра Fwdays Academy запускає Crash Course Storytelling для інженерів від Павла Полякова, Principal engineer у Free to move. ⏰Лишилися останні місця. Дисконт для підписників за цим посиланням: 👉 https://bit.ly/3R1d0Jk Що буде: 🎯 структура технічної історії для презентацій, мітингів і пітчів 🎯 вміння пояснювати складні ідеї для технічної та нетехнічної аудиторії 🎯 шаблон самопрезентації та професійного наративу 🎯 storytelling як інструмент впливу без формальної влади 🎯 AI як помічник у побудові переконливих історій Це історія не зовсім для джунів, до нього треба дозріти, але хто дозрів, то є сенс повчитися у професіоналів.

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

Мультиагентне рев'ю: кілька пар очей краще за одну А тепер найцікавіше. Ці інструменти не конкурують – вони доповнюють один одного. Я часто проганяю через кілька рев'юверів паралельно. Результат показовий: чим частіше проганяєш, тим більше шансів щось знайти. Один інструмент знайшов потенційну проблему безпеки, інший неконсистентність в обробці помилок, третій підсвітив архітектурне зауваження, яке перші два проігнорували. Це і є головний практичний висновок: AI-рев'ювери мають різні сліпі зони, тому мультиагентний pipeline знаходить суттєво більше, ніж будь-який окремий інструмент. Вартість додаткового рев'ювера виправдовує вартість проблем, яким він допомагає запобігти. Робоча схема виглядає так: Агент виконує задачу (бажано за специфікацією, а не за вайбом – але це тема окремої статті). Потім ви локально робите рев'ю, і якщо готові, робите PR. PR автоматично проходить ще через 2–3 AI-рев'ювери. Свіжа сесія агента-автора отримує зведені зауваження і виправляє їх – знову ж таки, з чистим контекстом. Нарешті людина дивиться фінальний результат і зведення знахідок. Що AI ловить добре, а що – ні Щоб не було завищених очікувань, чесно про межі можливостей. AI-рев'ювери сильні там, де потрібна уважність: типові вразливості (ін'єкції, небезпечна робота з секретами), race conditions у простих випадках, необроблені помилки, неконсистентність зі стилем кодової бази, забуті edge cases, розбіжності між кодом і документацією. AI-рев'ювери слабкі там, де потрібне розуміння за межами коду: чи треба було це робити взагалі, чи правильно взагалі зрозуміли бізнес-вимогу, чи не ламає це неявний контракт з іншою командою, чи виправдане архітектурне рішення в контексті планів на півроку вперед. Тут людина залишається незамінною – і це, до речі, гарна новина: рев'ю зміщується з «шукати дрібниці» на «думати про суть». Замість висновку Правило просте, і я раджу повісити його на стіну кожній команді, яка працює з агентами: checker ≠ maker Свіжа сесія – мінімум. Інша модель – краще. Спеціалізований інструмент або кілька – ще краще. Людина, яка дивиться на суть, а не на дрібниці в коді – обов'язково. AI дійсно пише код швидше за нас. Але саме тому перевіряти його треба ще ретельніше – просто робити це теж можна з AI. Головне, щоб студент не перевіряв власну домашку.

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. Ви повністю контролюєте промпт, чекліст і формат виводу – і саме тут можна закласти специфічні для вашого проєкту правила, які жоден готовий інструмент не знає.

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

Кому писатиме 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 не мінус, а плюс для розробника, навіть якщо він буде працювати лише з агентами і код не писатиме взагалі. Бо необхідно розуміти що саме роблять агенти, щоб процес був прозорий і всі етапи розробки були зрозумілими. Тому без класичних інженерних знань і навичок та володіння хоча б однією мовою програмування в агентній інженерії теж робити нічого. Проте максимально глибоко прокачувати свої навички треба саме в розробці з агентами, а не розбиратися зі змінами у новій версії чергового фреймворка, як це зазвичай всі звикли робити раніше, і дехто продовжує це робити по інерції.

Agentic Engineering для нових (greenfield) проєктів На наступному тижні протягом трьох днів разом з fwdays Academy я проводжу інтенсивний креш-курс по розробці нових проєктів з AI агентами Ви приходите зі своїм інструментом, може бути будь-який: Claude Code, Codex, Cursor, GitHub Copilot, Antigravity, OpenCode і т.д. - у них принципи роботи схожі, курс на інструмент не зав’язаний. Робити будете власний проєкт, можете реалізувати стартап, про який роками мріяли. Це буде не вайбкодинг, а виважений інженерний підхід, де ми задіємо комплекс заходів для того щоб результати нашої роботи були передбачуваними. Хоча курс в першу чергу орієнтований на software інженерів, але подачу матеріалу я буду робити максимально доступною, писати код руками ми не будемо, тому навчитися робити проєкти за цим підходом можуть люди, які взагалі ніколи код не писали - BA, QA, QA, продакт- і проджект-менеджери, дизайнери, а також усі, хто хоче зрозуміти, як побудувати робочий процес з AI-агентами по-інженерному, а не покладаючись на удачу. Цікаво, що в цій галузі настільки швидко все розвивається, що з моменту анонсу курсу два місяці тому до його запуску зараз вже встигли завіруситися такі підходи як Loop Engineering, які я прямо зараз інтегрую до курсу. Я покажу як зробити повністю автоматичну фабрику проєктів, що дозволить вам швидко, але керовано генерувати рішення, які валідуються до вимог, автоматично тестуються, виправляють дефекти і навіть записують відео з пруфами виконаної роботи. Скорочено концепт цього підходу був на моєму виступі на DOU Day 2026, тут ми все розберемо детально, а ще в нас буде багато додаткового. Окремий блок - це взагалі нова концепція розробки, де ми не просто пишемо детермінований код, а керуємо такими агентами як OpenClaw/NanoClaw/Hermes, які достатньо розумні, щоб робити корисну для нас роботу, не розмінюючись на дрібні деталі. Додатково я покажу свій власний сетап для розробки на основі Claude Code + Cursor, який я вважаю найбільш ефективним на сьогодні і поясню як з нього витягти максимум по швидкості та витратам на використання. Маю спеціальний лінк зі знижкою, заходьте, реєструйтеся, до зустрічі у вівторок! (Кому розклад не підходить, то можна працювати по записах, задавати питання в чаті підтримки, на здачу проєкта буде ще тиждень після закінчення курсу). Лінк з промокодом тут https://bit.ly/3QK37j2

Байка Три дні тому вийшла Fable 5, я прям під неї перейшов на підписку Claude на $200/міс. і за цей час встиг нормально так поганяти модельку в Cowork / Claude Code. В Cursor вона теж була доступна, але там її використання виходить дорожче. Модель дуже сподобалася, хоча у неї якийсь параноїдальний рівень безпеки, бо вона часто відмовлялася робити роботу, особливо якщо десь слова security / vulnerability зустрічалися. У Антропіків взагалі з цим проблеми - у одного з моїх клієнтів так заблочили корпоративний екаунт разом з усіма грошима на балансі. Нічого відновити не вдалося, тільки час змарнували. На вихідні мав великі плани на неї, але сьогодні зранку побачив, що її заблочили для всіх неамериканців за вказівкою уряду США. Ну що тут скажеш - в довготривалій перспективі штати самі своїми діями підштовхують до розвитку опенсорсу та конкурентів з інших країн, і найбільшим бенефіціаром від цього стане Китай. А для нас всіх важливий урок в тому, що ніколи не можна ставити себе в абсолютну залежність від будь-якого стороннього постачальника і завжди бути готовим до подібних кейсів, їх далі буде тільки більше. Якщо говорити про AI в SDLC, то стараємося структурувати проєкт таким чином, щоб працювати з ним могли люди з різними AI-інструментами одночасно. Я сам останнім часом працюю у зв’язці Cursor + Claude Code, і якщо в останньому упираюсь в ліміти, то спокійно переключаюсь на перший і продовжую в ньому. Робити це зовсім нескладно, більшість складових для агентної розробки універсальні, а те що не універсальне стараємося уникати за можливості. Цікаво, що Claude Code в багатьох аспектах ігнорить стандарти і робить по-своєму, але окремий ріспект Cursor за те що вони їх підхоплюють конфіги і можуть напрямку використовувати (конфіги хуків, CLAUDE.md і т.п.). Також моя порада взагалі поменше використовувати якихось сторонніх сервісів та інтеграцій, намагайтеся все тримати в репозиторії проєкту (доки наприклад) - це не лише вирішує подібні питання з можливими блокуваннями, але і сильно спрощує агентам робити свою роботу.

Професія тестувальника та AI Можливо ви здивуєтеся, але все йде до того, тестувальник - це професія, яку найближчим часом не просто не замінить AI, а ще й збільшить на неї попит. Звісно що професія трансформується і звичайні Manual QA / виконавці тест-кейсів не дуже будуть потрібні, але попит на кваліфікованих QA інженерів схоже лише зростає і буде продовжувати зростати в майбутньому. Причина насправді досить очевидна - коли AI-генерованих рішень стає більше, то зростає попит на його перевірку. Але тут виявляється ще один досить забавний нюанс - згенерувати проєкт з AI стає кратно простіше в порівнянні зі створенням його вручну в минулому, а от перевірити його в усіх деталях настільки простіше не стає. Тому що тестування – це не просто натискати кнопки і звіряти результат з очікуваним. Це про побудову стратегії тестування, вміння ставити незручні питання, виявляти неочевидні ризики, розуміти контекст продукту, поведінку користувача, бізнес-логіку і місця, де система може зламатися не лише технічно, а і концептуально. Так, AI може допомогти згенерувати тест-кейси, автотести, проаналізувати логи чи підказати edge cases. Але хтось має зрозуміти, що саме варто перевіряти, а що не варто, чому це важливо і які наслідки матиме помилка. І звичайно не варто забувати про повноту - в тестуванні це особливо критично, і якщо в розробці достатньо пройтися по вимогах і проставити галочки про їх виконання, то в тестуванні потрібно перевірити не лише те, що описано у вимогах, а й те, про що в них забули, що неправильно сформулювали, що користувач зрозуміє не так, як очікувалось, і т.д. і т.п. Саме тому в епоху Agentic Engineering гарні QA будуть на вагу золота, і так, щоб таким QA інженером стати, треба також повчитися інженерному мисленню: системному аналізу, тест-дизайну, роботі з вимогами, ризик-орієнтованому підходу, автоматизації та вмінню використовувати AI інструменти. PS. До речі, прямо зараз на один з проєктів для моїх клієнтів шукають QA, який зможе якісно протестувати телеграм-бота, що керується LLM. Оплата буде гарна (самі оцінюєте відповідно до обсягів робіт), кому цікаво - додаю формочку, закиньте туди свої дані, з вами зв’яжуться. Лінк на формочку https://forms.gle/AMMefVP6e2n5CYA46

Agentic AI Developer Тут на гітхабі вийшла перша частина курсу під сертифікацію Agentic AI Developer https://learn.microsoft.com/en-us/training/paths/gh-developing-agentic-systems-1 Інфа про сам іспит тут https://learn.microsoft.com/en-us/credentials/certifications/agentic-ai-developer/

DOU Day 2026 Багато про AI, але вже говорили переважно про те як правильно користуватися, а не абстрактно що "за ним майбутнє". Потужно звучить наш мілтек – зараз це серйозна альтернатива “традиційному” сервісному та продуктовому IT. Квитки не дешеві. Але якщо брати заздалегідь, розраховувати, що це інвестиції у себе, нетворкінг, який простіше/дешевше здобути навряд чи вийде, то воно точно того вартує. Приємно, що мій виступ зібрав повний зал і багато позитивних фідбеків. Обіцяю, що далі буде більше – вся ця історія з AI у Software Engineering мене зачепила не на жарт. Вважаю що це і є Golden Era у Software Engineering - шлях від ідеї до реалізації ще ніколи не був таким коротким - придумуйте ідеї та імплементуйте і поменше слухайте критиків, якби їх слухали винахідники та бізнесмени, то багато з того що ми знаємо і чим користуємося - просто б не існувало. Окрема подяка організаторам - зробити івент на кілька днів на понад 4 тис. учасників, з якого не хочеться йти - то і є топовий рівень. :)

Agentic Engineering Для Greenfield Вчора я проводив воркшоп для DOU Day по швидкій розробці Greenfield проєктів з AI агентами. Приємно було почути позитивні відгуки, але загалом там час був досить обмежений і була можливість розібрати підхід лише теоретично. Якщо цікаво  зануритися глибше, то в червні я буду проводити швидкий триденний курс разом з fwdays academy саме по цій темі, там у нас буде достатньо часу щоб глибше розібрати теорію і все реалізувати на практиці. Зараз на курс діє знижка плюс від мене є купон ще на -15%, запрошую всіх, кому ця тема цікава. Окремо зазначу що цей підхід сформований на досвіді таких популярних проєктів як Claude Cowork, OpenClaw та інших, і з ним мої клієнти роблять проєкти, в яких практично весь код  AI-генерований, і  при цьому успішно залітає в продакшин. Лінк на курс тут https://fwdays.com/event/agentic-engineering-greenfield-course Купон programming_mentor

Це слайди з мого воркшопу в DOU Day 2026, хто має питання - обговорюємо в коментарях https://koldovsky.github.io/2026-dou-day-workshop/

PR на 1 млн Тут цікава історія - Anthropic придбала bun 5 місяців тому, а вчора на гітхабі змерджили PR на 1 млн рядків коду, в якому проєкт переписаний з Zig на Rust. Звісно що без AI не обійшлося, говорять що Claude Code все переписав за 5 днів. Причина не технічна, просто з розробниками Zig не домовилися в деяких моментах.  Думаю що без багів у таких масштабах не обійдеться, але баги вони є завжди, в от відомих міграцій в таких обсягах ще не було. Це знакова подія для всієї галузі я вважаю. Далі буде більше :) https://www.reddit.com/r/rust/s/JNkAjAGQRA

До зустрічі завтра на DOU Day 2026 Якщо ви раптом не в курсі, то завтра починається DOU Day, квитків залишилося мало, але вони ще є https://dou.ua/dou-day-2026/#tickets Ось промокод від мене KOLDOVSKYI10 Буду проводити воркшоп на цікаву тему - як робити нові проєкти з AI агентами швидко і при цьому щоб вам за це нічого не було. Починаємо о 14:20 :)

Тут цікавий скіл завезли https://github.com/ckpxgfnksd-max/uap-release-analyzer

Це не фейк, особисто заскрінив вчора. :)

Економимо на токенах Свіженьке відео - як економити на токенах https://youtu.be/xaK7s54boxg Окремо рекомендую Caveman Skill, прям дуже гарна штука https://github.com/juliusbrussee/caveman

Інтерв'ю для ДОУ Запрошую прочитати моє інтерв'ю для ДОУ. Коли записували, то багато чого довелося згадати з дев'яностих та початку двохтисячних, таке відчуття наче все зовсім недавно було. https://dou.ua/lenta/interviews/koldovsky-about-evolution-of-it-industry