Як один Claude‑скіл замінив крихкий n8n‑конвеєр для розсилки
Щотижнева розсилка — типовий кандидат на автоматизацію: багато рутинних кроків, повторювані дії, купа дрібних перевірок. Для досвідченого інженера це виглядає як ідеальне завдання для складного workflow‑оркестратора. Саме так кілька місяців тому працював Кріс Парсонс — інженер із майже 30‑річним стажем, колишній CTO VC‑беканих стартапів і керівник агенції, який нині допомагає командам впроваджувати AI у повсякденну роботу.
Під час практичного воркшопу на каналі AI Engineer він показав, як повністю відмовився від складної схеми в n8n для створення свого щотижневого newsletter’а і замінив її… одним єдиним скілом у Claude Code. Цей скіл працює у вигляді простого циклу, сам викликає потрібні інструменти, сам вирішує, коли завдання завершене, і після кожного запуску ще й оновлює власні інструкції. Результат виявився парадоксальним: архітектурно простіший підхід дає кращий перший драфт розсилки, ніж попередній «інженерний шедевр» на n8n.
Коли автоматизація стає роботою замість того, щоб її знімати
Початковий підхід Парсонса до автоматизації розсилки виглядав дуже знайомо для будь‑кого, хто працював з no‑code/low‑code оркестраторами. У n8n він зібрав велику діаграму з десятків вузлів: окремий потік для «featured article», який читав пости з блогу, перевіряв, чи публікувалися вони раніше, узагальнював їх за допомогою AI і формував блок розсилки; інший потік — для лінків, які він додавав у спеціальний список, з автоматичною генерацією коротких коментарів; додаткові гілки для форматування, перевірок, публікації.
Цей конвеєр був не просто складним — він був крихким. Майже кожного понеділка о 14:00 Парсонс отримував сповіщення від n8n: workflow впав. Замість того щоб натискати «Send» і займатися іншими справами, він відкривав діаграму, намагався зрозуміти, який саме вузол зламався, перезапускав окремі гілки, лагодив дрібні помилки.
Це не була проблема конкретно n8n. Парсонс прямо підкреслює, що інструмент потужний, зручний для керування API‑ключами й «склеювання» сервісів. Без нього йому було б значно важче взагалі організувати подібну схему, навіть з урахуванням того, що він професійний розробник. Проблема була в іншому: у самій ідеї складного графа як способу керувати AI‑процесом.
У певний момент він дійшов до парадоксального висновку: простіше й швидше написати розсилку вручну, ніж підтримувати систему, яка мала її писати за нього. До того ж «ручна» версія виходила якіснішою. Для людини, яка десятиліттями будувала автоматизацію, це був тривожний сигнал: якщо інструмент забирає більше часу, ніж економить, щось у підході принципово не так.
Від графа до скіла: як JSON‑workflow перетворився на один цикл
Перелом стався тоді, коли Парсонс перестав сприймати AI як «чорну коробку» всередині workflow і почав дивитися на нього як на самодостатнього агента, здатного самостійно керувати процесом. Замість того щоб оркеструвати десятки кроків у n8n, він вирішив описати весь процес розсилки як один Claude Code skill.
Стартовий крок виглядав майже карикатурно просто: він узяв JSON‑опис свого n8n‑workflow, скопіював його і вставив у Claude Code з інструкцією: «Створи скіл на основі цього flow». Модель проаналізувала граф, зрозуміла, які кроки виконуються, у якій послідовності, які дані потрібні, і згенерувала один скіл, що інкапсулює всю логіку створення newsletter’а.
У цьому рішенні немає жодної зовнішньої діаграми, жодних візуальних вузлів, жодної окремої системи оркестрації. Усе, що раніше було розкидано по десятках блоків n8n, тепер живе в одному текстовому описі скіла. Claude Code отримує цей опис і сам вирішує, які інструменти викликати, у якій послідовності й коли зупинитися.
Цей крок важливий не лише як технічний трюк «переписати workflow в код». Він показує зміну парадигми: замість того щоб будувати складні графи навколо AI, Парсонс переносить складність усередину самого агента. Людина описує ціль і контекст, а не детальний маршрут.
Як працює «нескінченний» newsletter‑цикл у Claude Code
Ключ до нового підходу — у тому, як саме працює Claude Code зі скілами. На відміну від традиційного workflow‑оркестратора, де кожен крок жорстко зафіксований, Claude фактично виконує один і той самий цикл:
спочатку читає опис скіла, тобто інструкції, що саме потрібно зробити, які є інструменти, які обмеження та критерії якості;
на основі цього вирішує, який інструмент викликати далі: наприклад, прочитати список статей, перевірити історію публікацій, згенерувати анотацію, зібрати структуру випуску;
викликає обраний інструмент, отримує результат і повертається… на початок, знову читаючи той самий опис скіла з урахуванням нового контексту.
Цей цикл повторюється стільки разів, скільки потрібно. На кожній ітерації модель бачить як поточний стан роботи (чернетку розсилки, уже оброблені статті, сформовані блоки), так і незмінні інструкції скіла. У якийсь момент вона доходить висновку, що завдання виконано: усі потрібні блоки створені, структура відповідає вимогам, текст достатньо цілісний. Тоді цикл завершується, і користувач отримує готовий перший драфт newsletter’а.
Ззовні це виглядає як «магія»: ви натискаєте «запустити скіл» і через кілька хвилин маєте розсилку. Усередині ж це просто послідовність повторних проходів через один і той самий набір інструкцій, де кожен прохід трохи просуває роботу вперед. Ніяких гілок, ніяких «якщо‑то‑інакше» на рівні зовнішнього інструмента — лише один цикл прийняття рішень усередині моделі.
Цікаво, що саме така «тупа» структура — прочитати інструкції, зробити крок, знову прочитати інструкції — виявляється достатньо потужною, щоб замінити складний граф із десятків вузлів. І, що важливіше, вона виявляється набагато надійнішою: немає десятків точок відмови, немає розсинхронізації між гілками, немає необхідності вручну «підштовхувати» workflow після падіння.
Чому простий цикл дає кращий перший драфт, ніж складний workflow
Найцікавіша частина історії Парсонса — не лише в тому, що новий підхід виявився менш крихким. Виявилося, що Claude Code‑скіл дає кращий перший драфт розсилки, ніж попередній n8n‑конвеєр.
Старий workflow був ретельно продуманий: окремі гілки для різних типів контенту, спеціальні кроки для перевірки, чи не дублюється матеріал, окремі AI‑виклики для резюме й коментарів. Але кожен із цих кроків був локальним, «сліпим» до загальної картини. Оркестратор бачив лише те, що закладено в конкретний вузол, а модель — лише той фрагмент контексту, який їй передавали на цьому кроці.
У Claude Code‑циклі модель постійно має перед очима і загальні інструкції, і поточний стан усього випуску. Вона не просто «виконує крок 7 із 23», а щоразу оцінює, що ще потрібно зробити, щоб розсилка виглядала цілісною. Це дозволяє їй краще тримати в голові тон, структуру, баланс між блоками, уникати повторів і логічних розривів.
Парсонс не ідеалізує результат: він усе одно редагує тексти, переписує формулювання, додає власні інсайти. Але різниця в тому, з чого він стартує. Якщо раніше автоматизація давала сирий, часто фрагментований драфт, який вимагав значної доробки, то тепер він отримує значно більш зв’язний і придатний до публікації перший варіант. Це вже не «чернетка для чернетки», а основа, яку можна довести до фінального вигляду за відносно короткий час.
Фактично, простий цикл у Claude Code краще використовує сильні сторони сучасних моделей: здатність працювати з великим контекстом, оцінювати власний прогрес і коригувати план на льоту. Складний workflow, навпаки, намагається «розкласти» завдання на дрібні кроки, ніби модель — це набір вузьких функцій, а не цілісний агент.
Самонавчальний скіл: коли автоматизація покращує сама себе
Останній елемент цієї історії робить її особливо показовою для майбутнього автоматизації. Парсонс не просто запустив Claude Code‑скіл і залишив його в спокої. Наприкінці кожної сесії створення newsletter’а він додає ще один крок: просить Claude оновити сам скіл на основі досвіду поточного запуску.
Формулювання просте: «Будь ласка, онови скіл, врахувавши все, що ти зрозумів із цієї сесії, що варто було б зробити інакше». Модель аналізує, як проходив процес, які кроки були зайвими, де виникали труднощі, що можна оптимізувати, і вносить невеликі правки в інструкції скіла.
Це не драматичні переписування з нуля, а радше дрібні еволюційні зміни: уточнення формулювань, корекція порядку дій, додавання нових перевірок або критеріїв якості. Але саме така дрібна, постійна еволюція перетворює статичний скрипт на живу систему, яка з кожним запуском стає трохи кращою.
У результаті виникає самопокращувальний цикл: скіл керує створенням розсилки, розсилка редагується людиною, а потім досвід цієї сесії повертається назад у скіл у вигляді оновлених інструкцій. Людина не переписує промпт вручну, не проводить «ретроспективи» для workflow — вона просто ставить моделі завдання вдосконалити власний опис.
Цей підхід добре узгоджується з тим, як Парсонс загалом бачить роботу з AI‑циклами. Він постійно наголошує, що нині використовує подібні «лупи» практично в усьому: від листування й календаря до клієнтських проєктів і коду. У кожному випадку ідея одна й та сама: замість складної зовнішньої оркестрації — простий повторюваний цикл, який сам оцінює свій результат і з часом навчається працювати краще.
Висновок: кінець епохи «інженерних діаграм» для AI‑процесів?
Історія з newsletter’ом Парсонса — це не просто анекдот про те, як один інженер втомився від падінь n8n по понеділках. Це показовий кейс зміни підходу до AI‑автоматизації.
По‑перше, вона демонструє межі складних workflow‑графів у світі, де моделі вже достатньо потужні, щоб самостійно планувати й коригувати свої дії. Те, що ще недавно здавалося «єдиним професійним шляхом» — детальна оркестрація кожного кроку, — сьогодні може виявитися зайвою складністю, яка створює більше проблем, ніж вирішує.
По‑друге, кейс показує, як можна практично перейти від такої архітектури до простішої, не викидаючи попередню роботу. JSON‑опис workflow стає вихідним матеріалом для створення скіла, а не «мертвим вантажем» минулого проєкту.
По‑третє, він підкреслює силу простих циклів: один і той самий скіл, який багаторазово читає власні інструкції, викликає інструменти, оцінює прогрес і вирішує, коли зупинитися. У поєднанні з сучасними моделями це виявляється достатнім, щоб замінити складні системи оркестрації й водночас підняти якість результату.
І нарешті, самонавчальний аспект — оновлення скіла після кожного запуску — натякає на майбутнє, де автоматизація не просто виконує завдання, а й поступово вдосконалює власні інструкції без постійної участі людини. Роль інженера зміщується від «архітектора графів» до куратора циклів, який задає цілі, контролює якість і час від часу коригує напрямок еволюції.
Для команд, які сьогодні лише починають впроваджувати AI у свої процеси, цей кейс дає просту, але важливу рекомендацію: перш ніж будувати ще один складний workflow, варто запитати себе, чи не можна описати завдання як один скіл і дозволити моделі самій пройти шлях від плану до результату — у власному, «тупому», але напрочуд ефективному циклі.
Джерело
YouTube: Ralph Loops: Build Dumb AI Loops That Ship — Chris Parsons, Cherrypick