OpenClaw + Claude Code надзвичайний посібник: одна людина може створити повноцінну команду розробників!

Сьогодні я поділюся вражаючим практичним випадком. (Наприкінці статті буде посібник)

Один незалежний розробник створив систему AI Agent за допомогою OpenClaw + Codex/CC. Який же результат?

94 коміти за день, 30 хвилин на 7 PR, і в цей день він також провів 3 зустрічі з клієнтами, навіть не відкриваючи редактор.

Це справді сталося в січні 2026 року. Автор опублікував всю архітектуру системи, робочий процес і конфігурацію коду, і після перегляду я зрозумів, що ця ідея варта вивчення, тому я зібрав це в цю статтю, щоб поділитися з вами.

Якщо ви також використовуєте Codex або Claude Code, або вас цікавить OpenClaw, ця стаття дасть вам багато натхнення.

Одна людина, 94 коміти коду за день

Спочатку подивимося на кілька даних, щоб відчути силу цієї системи:

• Максимум 94 коміти за день (в середньому 50 комітів на день)
• 30 хвилин на 7 PR
• Швидкість від ідеї до запуску настільки висока, що "можна доставити клієнтські вимоги в той же день"

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

А які витрати? Кожен місяць $190 (Claude $100 + Codex $90), новачок може почати з $20.

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

Ні. Історія Git автора виглядає так, ніби "щойно найняли команду розробників", але насправді це лише він один. Ключова зміна полягає в тому, що він перейшов від "управління Claude Code" до "управління AI помічником, який управляє групою Claude Code".

• До січня: безпосередньо використовував Codex або Claude Code для написання коду
• Після січня: використовував OpenClaw як шар оркестрації, щоб він керував Codex/Claude Code/Gemini

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

Чому Codex і Claude Code окремо не є достатньо хорошими?

В цей момент ви, можливо, запитаєте: Codex і Claude Code вже дуже потужні, чому потрібно додавати ще один шар оркестрації?

Відповідь автора дуже пряма: Codex і Claude Code майже нічого не знають про ваш бізнес. Вони бачать лише код, але не бачать повну картину бізнесу.

Тут є фундаментальне обмеження: вікно контексту фіксоване, ви можете вибрати лише одне.

Вам потрібно вибрати, що вкласти:

• Заповнити кодом → немає місця для бізнес-контексту
• Заповнити історією клієнтів → немає місця для кодової бази

Отже, при використанні Codex або Claude Code окремо ви зіткнетеся з такими проблемами:

• Він не знає, для якого клієнта створюється ця функція
• Він не знає, чому минулий подібний запит зазнав невдачі
• Він не знає вашої продуктової позиції та принципів дизайну
• Він може працювати лише на основі поточного коду та вашого запиту

OpenClaw змінив це рівняння.

Він виступає як шар оркестрації, розташований між вами та всіма AI інструментами. Його роль:

• Мати весь бізнес-контекст (дані клієнтів, протоколи зустрічей, історичні рішення, успішні/невдалі випадки)
• Перекладати бізнес-контекст на точні запити, які передаються конкретному агенту
• Дозволити цим агентам зосередитися на тому, що вони вміють найкраще: написанні коду

Порівняємо:

• Codex/Claude Code = професійний кухар, який займається лише приготуванням їжі
• OpenClaw = шеф-кухар, який знає смаки клієнтів, запаси інгредієнтів, позиціонування меню, дає кожному кухарю точні інструкції

Ось чому потрібна двошарова система: через спеціалізацію контексту, а не шляхом заміни на більш потужну модель.

Конкретна архітектура двошарової системи: шар оркестрації + виконавчий шар

Давайте подивимося на конкретну архітектуру цієї системи.

Два шари, кожен виконує свої функції:

Що може зробити OpenClaw (шар оркестрації)?

• Читати всі записи зустрічей з нотаток Obsidian (автоматична синхронізація)
• Доступ до виробничої бази даних (тільки для читання) для отримання конфігурацій клієнтів
• Має права адміністратора API, може безпосередньо поповнювати рахунок клієнта та знімати блокування
• Вибирати відповідного агента в залежності від типу завдання
• Моніторити прогрес усіх агентів, у разі невдачі аналізувати причини та коригувати prompt для повторної спроби
• Після завершення повідомляти автора через Telegram

Що може зробити Agent (виконавчий шар)?

• Читати та записувати кодову базу
• Запускати тести та збірки
• Піддавати код на перевірку та створювати PR
• Відповідати на відгуки з code review

Ключовий момент: Виконавчий шар Agent ніколи не контактує з виробничою базою даних і не бачить чутливу інформацію клієнтів. Вони отримують лише "мінімальний контекст, необхідний для виконання цього завдання".

Цей дизайн дуже розумний: безпечні межі чіткі, при цьому забезпечується ефективність.

Повний робочий процес: 8 кроків від вимог клієнта до злиття PR

Тепер переходимо до основної частини. Використовуючи реальний випадок автора минулого тижня, я проведу вас через повний процес.

Контекст: Один корпоративний клієнт зателефонував і сказав, що хоче повторно використовувати вже налаштовані налаштування та ділитися ними в команді.

Крок 1: Вимоги клієнта → OpenClaw розуміє та розбиває

Після закінчення дзвінка автор і Zoe (його OpenClaw) обговорили це прохання.

Чудова річ тут: нульові витрати на пояснення. Оскільки всі записи зустрічей автоматично синхронізуються з Obsidian, Zoe вже прочитала зміст дзвінка, знає, хто клієнт, їх бізнес-сценарій та існуючу конфігурацію.

Автор і Zoe разом розбили вимогу на: створити шаблонну систему, щоб користувач міг зберігати та редагувати існуючу конфігурацію.

Потім Zoe зробила три речі:

• Поповнила рахунок клієнта — за допомогою адміністратора API негайно зняла обмеження з використання клієнта
• Отримала конфігурацію клієнта — з виробничої бази даних (тільки для читання) отримала існуючі налаштування клієнта
• Згенерувала prompt і запустила агента — упакувала весь контекст і передала його Codex

Крок 2: Запуск агента

Zoe створила для цього завдання:

• Окреме git worktree (ізольоване середовище гілки)
• Сесію tmux (щоб Agent працював у фоновому режимі)

# 创建 worktree + 启动代理 git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install

tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high Чому використовується tmux? Тому що можна втрутитися в процес.

Якщо AI йде не в тому напрямку, не потрібно вбивати і починати спочатку, просто надішліть команди в tmux:

# 代理方向错了 tmux send-keys -t codex-templates "Зупиніться. Спочатку зробіть API шар, не звертайте уваги на UI." Enter

代理需要更多上下文

tmux send-keys -t codex-templates "Типи визначені в src/types/template.ts, використовуйте їх." Enter Одночасно завдання буде зафіксовано в JSON файлі: [[HTMLPLACEHOLDER0]]\n

Основна ідея: воно не \Повний процес, від потреб клієнта до запуску коду, може зайняти лише 1-2 години, а фактичні витрати автора можуть становити лише 10 хвилин.

Три механізми, які роблять систему розумнішою

Механізм 1: Покращена версія Ralph Loop — не просто повторення, а навчання

Ви, можливо, чули про Ralph Loop: витягування контексту з пам'яті → генерація виходу → оцінка результату → збереження навчання.

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

Ця система інша.

Коли Agent зазнає невдачі, Zoe не перезапускає з тим же prompt. Вона аналізує причини невдачі з повним бізнес-контекстом і переписує prompt:

❌ Поганий приклад (статичний prompt): { "реалізувати функцію користувацького шаблону" }

✅ Добрий приклад (динамічна корекція): { "Стоп. Клієнт хоче X, а не Y. Ось їхні слова з наради: Ми хочемо зберегти існуючу конфігурацію, а не створювати нову з нуля. Основна увага на повторному використанні конфігурацій, не створюйте новий процес." }Zoe може робити такі корекції, тому що вона має контекст, якого немає у виконавчого рівня Agent:

• Що сказав клієнт на нараді
• Чим займається ця компанія
• Чому минулий подібний запит зазнав невдачі

Більше того, Zoe не чекає, поки ви призначите завдання, вона активно шукає роботу:

• Вранці: сканує Sentry → виявляє 4 нові помилки → запускає 4 Agent для розслідування та виправлення
• Після наради: сканує протокол наради → виявляє 3 функціональні вимоги, згадані клієнтами → запускає 3 Codex
• Ввечері: сканує git log → запускає Claude Code для оновлення changelog та документації для клієнтів

Автор повертається з прогулянки, у Telegram з'являється повідомлення: "7 PR готові. 3 нові функції, 4 виправлення помилок."

Успішні моделі будуть зафіксовані:

• "Ця структура prompt дуже ефективна для функції рахунків"
• "Codex потрібно отримати типи визначень заздалегідь"
• "Завжди потрібно включати шлях до тестових файлів"

Сигналом для винагороди є: CI пройшов, три code review пройшли, ручне злиття. Будь-яка невдача викликає цикл.

Чим довше, тим кращими стають prompt, написані Zoe, тому що вона пам'ятає, що може бути успішним.

Механізм 2: Стратегія вибору Agent — різні завдання для різних експертів

Не всі Agent однаково сильні. Автор підсумував стратегії вибору:

• Codex(gpt-5.3-codex) — основний — бекенд логіка, складні помилки, рефакторинг кількох файлів, завдання, що потребують міжкодового міркування
• Повільний, але ретельний
• Складатиме 90% завдань

• Claude Code(claude-opus-4.5) — швидкісний гравець — фронтенд робота
• Менше проблем з правами, підходить для git операцій
• (Автор раніше використовував частіше, але після виходу Codex 5.3 змінив)

• Gemini — дизайнер — має дизайнерську естетику
• Для красивого UI спочатку нехай Gemini створить HTML/CSS специфікацію, а потім передайте Claude Code для реалізації в системі компонентів
• Gemini проектує, Claude будує

Zoe автоматично вибирає Agent залежно від типу завдання і передає виходи між ними. Помилка в системі рахунків йде до Codex, виправлення стилю кнопки — до Claude Code, новий дизайн панелі спочатку йде до Gemini.

Механізм 3: Де вузьке місце? RAM

Тут є несподіване обмеження: не вартість токенів, не швидкість API, а пам'ять.

Кожен Agent потребує:

• Власного worktree
• Власних nodemodules
• Запуску збірки, перевірки типів, тестування

5 Agent одночасно = 5 паралельних компіляторів TypeScript + 5 тестових запусків + 5 наборів залежностей, завантажених у пам'ять.

Мак Mini автора (16 ГБ RAM) може одночасно запускати максимум 4-5 Agent, більше — починає використовувати swap, і потрібно сподіватися, що вони не будуть одночасно будувати.Отже, він купив Mac Studio M4 Max (128 ГБ оперативної пам'яті, $3500), який прибуде в кінці березня. Він сказав, що тоді поділиться, чи варто це того.

Ви також можете налаштувати: від нуля до запуску всього за 10 хвилин

Хочете спробувати цю систему?

Найпростіший спосіб:

Скопіюйте цю статтю для OpenClaw і скажіть йому: "Згідно з цією архітектурою, реалізуйте для моєї кодової бази систему кластерів агентів."

Тоді він:

• Прочитає архітектурний дизайн
• Створить скрипти
• Налаштує структуру каталогів
• Налаштує моніторинг cron

10 хвилин - і готово.

Вам потрібно підготувати:

• Обліковий запис OpenClaw
• Доступ до API Codex і/або Claude Code
• Git-репозиторій
• (необов'язково) Obsidian для зберігання бізнес-контексту

2026: мільйонна компанія однієї людини

Автор в кінці статті сказав одну фразу, яка, на мою думку, дуже надихаюча:

"Ми побачимо велику кількість мільйонних компаній однієї людини, які з'являться з 2026 року. Важелі величезні, вони належать тим, хто розуміє, як будувати рекурсивні системи самовдосконалення AI."

Це виглядає так:

• AI-координатор як ваше продовження (як Zoe для автора)
• Делегуйте роботу спеціалізованим агентам, які займаються різними бізнес-функціями
• Інженерія, підтримка клієнтів, операції, маркетинг
• Кожен агент зосереджений на тому, в чому він сильний
• Ви зберігаєте фокус і повний контроль

Наступне покоління підприємців не найматиме 10 людей, щоб зробити те, що може зробити одна людина з системою. Вони будуть будувати так — залишатися малими, швидко діяти, публікувати щодня.

Зараз AI генерує занадто багато сміттєвого контенту. Різноманітні розкрутки, різноманітні "центри управління завданнями" з розкішними демо, але без справді корисних речей.

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

На цьому стаття закінчується.

Основні моменти:

• Двошарова архітектура: шар оркестрації містить бізнес-контекст, виконавчий шар зосереджений на коді
• Повна автоматизація: 8-етапний процес від вимог до PR, більшість завдань успішно виконуються з першого разу
• Динамічне навчання: не повторне виконання, а коригування стратегії на основі причин невдач
• Контроль витрат: початок з $20/місяць, інтенсивне використання $190/місяць

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

Посилання на джерело:[[HTMLPLACEHOLDER_1]]