Блог

Понад рік тому я зібрав цикл контролю якості перекладу для свого українського новинного сайту про великих котів — руками, у Laravel. Форма була проста: перекласти іншомовну статтю українською, запустити аналізатор, що вичитує результат на ознаки машинного перекладу, передати його правки редактору, що їх застосовує, і знову проаналізувати, доки виправляти не залишиться нічого. До шістнадцяти проходів для новини, тридцять два — для довшої статті. Я написав це ще до того, як почув, як хтось уживає словосполучення «агентний воркфлоу»; це просто було те, як я уявляв собі будову циклу вичитки.

Claude Code тепер постачає рівно цю форму як функцію. Динамічні воркфлоу — це JavaScript-скрипти, які викликають субагентів у циклі, розгалужують їх, передають один етап у наступний. Те, що я зробив руками, — з коробки. Тож я переніс свій цикл в один такий: невелику проєктну навичку, /translation-qa <news-id>, яка читає статтю з продакшну й запускає той самий цикл переклад → аналіз → застосування як воркфлоу.

Я керував портуванням; код писав Opus 4.8. Він наробив чимало помилок, бо функція нова, а модель насправді ще не знає, як та поводиться. Публічна документація описує воркфлоу на високому рівні; API скрипта — ту частину, яку ти власне й пишеш, — пізнаєш промацуванням. Там, де модель не знала, вона здогадувалася — з тією самою впевненістю, яку має щодо всього.

Записати варто не помилки, а те, хто їх ловив, бо здебільшого це був не я. Їх ловили власні валідаційні запуски моделі: сухі прогони й проби, які вона робила замість того, щоб припускати, що воркфлоу працює. Мій рік зі старим Laravel-циклом підказав мені, як має виглядати чистий переклад, тож я знав, до чого цілитися, але знати ціль і ловити кожний промах — то різні роботи, і другу я здебільшого делегував за однієї умови: перевіряй, ніколи не оголошуй себе готовим. Моїм у цьому портуванні був напрям.

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

ШІ це змінив. Не тому, що ШІ підтвердив MBTI як науку, а тому, що MBTI виявився найпопулярнішою термінологією про особистість у тренувальних даних. LLM знають її добре. Вони вільно оперують усіма шістнадцятьма типами та їхніми когнітивними функціями — що кожен тип помічає першим, що відсіює, як упорядковує інформацію, яке пояснення «заходить», а яке ні.

Кожен тип і справді споживає інформацію по-різному. Те, що одному типу одразу зрозуміле, для іншого непрозоре. Те саме пояснення, перебудоване під іншу когнітивну послідовність, лягає геть інакше. Я можу попросити ШІ оцінити чийсь тип MBTI — за повідомленнями, стилем письма, патернами рішень — а тоді скроїти повідомлення так, щоб воно було зрозуміле для того, як ця людина насправді думає.

Global Agile Summit завершився 6 травня. Ці п'ять записів я подивився за пару тижнів по тому, коли Oikosofy виклала їх до відеобібліотеки. Воркшоп із мобпрограмування від Вуді Зуйла, чотири живі наступні сесії запитань-відповідей із Джейсоном Літтлом, Маркусом Буллоком, Клінтоном Кітом і Джошуа Талером, приблизно п'ять годин матеріалу, втиснутих у тиждень вечорів.

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

Зуйл відповів грою. Літтл збудував структуру тек. Буллок виявив це, коли чотири тижні автоматизації минули без жодної розмови з клієнтом, а Кіт — коли підрахунок голів на парковці виміряв не те. Талер приніс меча.

Я закриваю 3+ позиції в стартапі. Ціна перемикання між режимами проявляється в Slack. За звичайний день є рішення та судження, які зрушуються лише тоді, коли я дивлюся, — а коли я глибоко занурений в іншу задачу, я не дивлюся годинами.

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

Ці сім я подивився наступного дня після того, як Global Agile Summit 2026 завершився. Прямі сесії запитань-відповідей першого дня вимагали попереднього квитка, який я проґавив, поки слоти не закрилися; виступи Ітана Чейзіна та Адама Гутса я не зміг знайти на YouTube — схоже, це ексклюзиви Oikosofy Library. П'ять проґаваних сесій і двоє запізнілих з бібліотеки, переглянуті поспіль. Спливли тут і дві лінії з початку тижня: де виконання дешевшає, туди зміщується судження; пряме спостереження за користувачами досі б'є непрямий сигнал. Але цього разу спікери конкретно показали, як ці лінії проявляються в робочому тижні.

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

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

Другий день мав ту саму форму, що й перший, записані доповіді в чотирьох паралельних треках плюс жива сесія запитань і відповідей до кожної презентації. На сесії потрібно було реєструватися окремо перед початком кожної, і я пропустив геть усі сесії першого дня, бо не знав, що такий крок узагалі існує. На другий день я застав чотири, одну за одною впродовж пообіддя. Пер Бейнінг про Claude Code, Анна Лаврова про те, чому системи опираються змінам, Аніта Калмане-Бут про нейророзмаїття в командах розробників, Тара Скотт про розрив петлі дозволу. Жива сесія запитань і відповідей виявляє, що спікер насправді думає про питання, до яких не готувався, - інший різновид суті, ніж записана доповідь. Цей текст про ті чотири сесії; записані доповіді другого дня - окремий допис.

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

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

Що здивувало мене під кінець дня: наскільки п'ять треків (Keynotes, AI in Organizations, People, Agile in Gaming, Agile in Construction) знов і знов сперечалися про одне й те саме з різних боків. Жоден з аргументів не був новим. Новим було сходження — спікери, які десятиліттями працювали кожен у своєму кутку, прийшли приблизно в одне місце приблизно в один час.

Проходжу доповіді в порядку ефіру.

Минулого року я нарешті автоматизував свій новинний конвеєр про великих котів. Шукаю, інколи перекладаю та публікую новини про великих котів із 2007 року. Я швидко зрозумів, що в мене немає ресурсів підтримувати й розширювати його самотужки. Потім на основній роботі я почав працювати з ШІ-агентами й побачив, що можу керувати ними так само, як керую джуніор-розробниками. Саме це й зробило мій особистий проєкт життєздатним для однієї людини з допомогою ШІ.

Я перебудував один конкретний шар: сам пошук. Решту конвеєра я написав вручну впродовж 2025 року: переклад, аналіз, редагування, повторний аналіз. Він працював справно. Пошук працював на безкоштовному тарифі NewsCatcherAPI для некомерційних проєктів. Безкоштовний тариф поновлюється кожні кілька місяців, але лише якщо попросити й показати, що проєкт досі живий і досі некомерційний. 1 вересня 2025 року мій доступ закінчився. Я не попросив про поновлення. На той момент я вже був перевантажений іншими справами й не повертався до особистого проєкту кілька місяців.

На початку 2026 року моя підписка NewsCatcherAPI знову запрацювала на кілька днів. Не знаю чому. Якісь статті потрапили до моєї черги на перегляд і нагадали, що проєкт усе ще існує. На той час я вже щодня користувався ШІ-агентами на роботі, а ще почав використовувати їх для власного коду. Я також згадав пару статей у блозі NewsCatcher про те, як збудувати сервіс на кшталт їхнього з нуля. Я вирішив скерувати ШІ-агента, щоб він прочитав ті статті та перебудував пошук.

Оновив класифікатор новин з GPT-5-mini на GPT-5.4-mini та одразу почало проскакувати купа новин не про котячих, це на стільки деградація моделі чи треба інші промти? Я промт ще писав для GPT-4-mini та не змінював

Відкотив на GPT-5-mini все, виходе GPT-5.4-mini на порядок швидша та в рази дорожча, але якість роботи на порядки гірша. Модель для тих, кому важлива швидкість роботи. Але не розумію, ШІ який робить роботу в рази гірше, в результаті вимагає більле часу, бо треба більше виправляти. В чому сенс таких нових моделей?

Для щоденних завдань із кодом я використовую Claude Code з плагіном Oh My ClaudeCode. Його оркестраційні воркфлоу змушують AI-агентів рев'юити власний вивід у циклі, автоматично відловлюючи проблеми й перевіряючи виправлення.

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

Коли агенти ділять контекст між ітераціями, вони здебільшого перевіряють, що проблеми з першого проходу виправлено. Нові проблеми вони знаходять рідко. Спільна пам'ять працює проти мене.

Більше місяця на роботі активно вайбкодю, переважно використлвую Claude Opus. Оскільки обов'язки не дозволяють концентруватися на програмуванні, то ШІ добре допомогає. Спробував повайбкодити особистий проект, преміум платні запити робочої підписки для нього не використовував.

Спочатку спробував за свої API-ключі кодити. За пару-трійку запитів Opus зняв 2 долари. Потім спробував GPT-5.2, де мільйон токенів на добу безкоштовно, безкоштовні швидко вичерпались і далі пішло за гроші, хоча може під десяток запитів можна було в рамках того мільйону зробити.

В кінці вже спробував GPT-4.1, котра входе в корпоративну підписку, та за котру немає додаткової плати. З результатом справилась, але робила елементарні помилки та на їх виправлення йшло дуже багато часу, так ще в результаті якість коду явно посередня вийшла, при цьому виправляє проблеми дуже не охоче, треба самому занурюватися та давати вказівки, а тоді вже сенс у ШІ зникає. Не схоже, що воно варте того, спробую взяти підписку Claude Pro на місяць і подивитись як з нею буде, все ж пет-проектом займаюсь не постійно, не завжди на це ментальні ресурси є, хоча може ШІ дозволить регулярно робити, оскільки ментальних ресурсів менше вимагає.