Claude Code у non-interactive mode

1. Claude Code за межами локальної сесії

Коли ви тільки починаєте працювати з Claude Code, його дуже легко зафіксувати в голові як «помічника в терміналі»: дали задачу, отримали diff, перевірили тести — готово. Але робота не закінчується на «ну, здається, готово». Зміна має дожити до build, перевірок, CI, інколи до release pipeline. Тут Claude бере участь уже не в написанні коду, а в доставленні результату.

Важливо лише не переоцінити його роль. У delivery loop він не автопілот, який сам керує merge, release і тим більше production. Його роль прозаїчніша і тому цінніша: він сильний там, де сирий матеріал — diff, лог, changelog, список файлів — треба швидко перетворити на перевірюваний артефакт. Саме тому на цьому рівні ми перестаємо сприймати його лише як співрозмовника. Далі він для мене робоча ланка software delivery loop. Не господар, не суддя, не людина-оркестр. Отримав вхід, виконав обмежену задачу, повернув результат, поступився місцем перевірці.

2. Три точки участі Claude в delivery workflow

Щоб не змішувати все в одну кашу, корисно одразу побачити карту місцевості. У delivery loop у Claude три точки участі: різні за контекстом, ризиком і тим, хто після нього ухвалює рішення. Якщо цю карту не зафіксувати в голові, дуже швидко виникає спокуса ліпити один підхід усюди, а потім дивуватися, чому зручне локально в CI стало небезпечним.

На прикладі Commerce OS це виглядає зовсім приземлено. Локально Claude збере опис поточного diff після виправлення багу в сортуванні refund-запитів. У CI отримає build.log або test.log і поверне коротку класифікацію причини падіння. У release pipeline збере чернетку release notes за змінами, які вже пройшли перевірки. Корисний усюди — власником фінального рішення ніде.

Якщо хочеться запам’ятати це однією фразою, то ось вона: локально Claude допомагає думати швидше, у CI — бачити ясніше, у release — оформлювати зрозуміліше. А відповідальність усе одно залишається у людини та детермінованих перевірок.

3. Non-interactive mode і звичайна сесія

Тут зазвичай виникає головне питання лекції: а що взагалі мається на увазі під non-interactive mode? Це той самий Claude Code, але запущений не як тривала інтерактивна сесія з діалогом, а як обмежений одноразовий прогін зі скрипта, термінальної команди або CI job. Вхід, вихід, межі — і після завершення він не живе своїм життям, як нескінченний чат про все на світі.

Корисно побачити різницю прямо:

Новачків це спочатку часто дратує: здається, ніби Claude «нічого не пам’ятає». Але в delivery workflow забудькуватість — перевага. Запуск відтворюваний: ви знаєте вхід і очікуваний вихід і повторюєте пізніше. Не розмова біля дошки, а лабораторна робота: поклали зразок, отримали вимірювання, записали результат.

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

4. Патерн bounded run: серце всієї схеми

Тепер давайте зафіксуємо головний патерн цієї лекції. Звучить він так: input → bounded Claude run → structured output → human or CI review. На папері майже нудно — і ця нудьга робить систему надійною. Чим менше у запуску прихованих припущень, зайвих інструментів і туманного «ну він якось розбереться», тим легше його повторити, перевірити й вбудувати.

Ось схема в найкомпактнішому вигляді:

flowchart TD
    A[Вхідні дані
diff, log, changelog] --> B[Обмежений запуск Claude]
    B --> C[Структурований результат
markdown, JSON, summary]
    C --> D[Перевірка людиною або CI]

Щоб bounded run справді був bounded, у нього має бути дуже конкретний контракт. Не філософія, не «побажання», а саме контракт.

Зверніть увагу на важливу деталь: хороший bounded run повертає структурований результат, а не потік свідомості на пів сторінки. Читає людина — короткий markdown зі списком змін. Потрібно в pipeline — JSON із фіксованими полями. «Здається, проблема десь у середовищі» годиться за кавою, але безкорисне для CI. А {"тип_падения":"environment","вероятная_причина":"не збігається версія Java"} уже предметно.

Такий контракт зручно фіксувати навіть усередині EVIDENCE_LOG.md — не заради бюрократії, а щоб через два дні не згадувати, що ви подавали на вхід і чому отримали саме це. Погана пам’ять — звичайна людська риса. Хороший артефакт — інженерне рішення.

5. Вузькі permissions для scripted Claude

Тут легко потрапити в пастку. Раз запуск неінтерактивний, здається, що задля зручності можна дати більше прав: нехай і diff подивиться, і файл поправить, і тести запустить, і про всяк випадок усе сам полагодить. Проблема в тому, що scripted run майже завжди живе без вас поруч. Отже, його межі мають бути вужчими, ніж у інтерактивної сесії, а не ширшими.

Якщо інтерактивна сесія схожа на похід із рюкзаком, де ви йдете поруч і в будь-який момент можете зупинитися, то non-interactive run — це ручна поклажа в аеропорту. Нічого зайвого. Усе передбачувано. Жодних сюрпризів на огляді. Метафора нервова, але delivery loop і не славиться розслаблювальною атмосферою.

На permissions корисно дивитися так:

Найважливіша думка тут проста: права підлаштовуються не під мрію «нехай усе зробить сам», а під реальну задачу. Підсумувати diff — редагування не потрібне. Класифікувати лог падіння — секрети й мережеві інтеграції не потрібні. Зібрати чернетку release notes — про production знати не треба.

6. Один Claude на трьох етапах delivery

Давайте подивимося на це не абстрактно, а на знайомому проєкті. Уявімо Commerce OS, де ви вже локально виправили баг із неправильною сортуванням refund-запитів у inbox: issue, plan, невеликий diff, локальні тести, перевірка. На цьому місці початківець часто каже: «Ну все, код готовий». Досвідчений запитує: «Як ця зміна дійде до review, CI та релізної нотатки?»

Локально ви робите bounded run, який код не чіпає: отримує поточний diff і повертає коротку чернетку опису — готове summary для review. Далі код іде в CI, і одна job падає — скажімо, через розбіжність середовища. Замість ритуалу «перезапустити й молитися» ви даєте Claude вхідний лог і просите класифікувати причину у фіксованому форматі. За ним людина вирішує: code issue, dependency issue чи environment drift. Пройшло далі — release pipeline запускає ще один bounded run для чернетки нотатки: які зміни потрапили, які ризики закрито, що згадати в документації.

Зверніть увагу: в усіх трьох випадках Claude той самий. Змінюються вхід, межі й очікуваний вихід. Звідси доросла думка: delivery automation рідко виграє від «надрозумного універсального агента» і майже завжди — від повторюваних вузьких сценаріїв. Тому Workflow Kit тут доречний: у ньому зручно фіксувати такі шаблони як повторно використовувані практики команди, а не згадувати їх щоразу з нуля.

Ось як може виглядати структурований результат для CI-аналізу логу:

{
  "тип_падения": "environment",
  "вероятная_причина": "в CI використовується інша версія Java",
  "проверить": ["./gradlew --version", "java -version"],
  "следующий_шаг": "звірити runner і локальне середовище"
}

Це ще не виправлення. І в цьому його сила. Спочатку ясність, потім дія.

7. Маленькі приклади неінтерактивного запуску

Теорія хороша рівно до того моменту, поки не захочеться побачити все руками. На вічний синтаксис приклади не претендують, тому тримаємо в голові правило курсу: точні прапорці та доступні опції перевіряйте через claude --help. Важливий патерн, не заклинання.

Перший приклад — локальна чернетка summary за поточним diff. Це типовий сценарій: Claude оформлює вже зроблену зміну, а не пише код замість вас.

claude -p "Коротко опиши поточний diff у 5 пунктах для review." \
  --allowed-tools "Bash(git diff:*)" \
  > tmp/pr-summary.md

cat tmp/pr-summary.md
# - Виправлено сортування refund-запитів
# - Додано regression test для inbox
# - Поведінку поза refund-сценарієм не змінено

Другий приклад — аналіз build.log без редагування проєкту. Тут зручно подавати лог як вхід і чекати структурований результат.

cat build.log | claude -p \
  "Класифікуй причину падіння і поверни JSON із полями тип_падения, вероятная_причина, следующий_шаг." \
  > tmp/ci-failure.json

cat tmp/ci-failure.json
# {"тип_падения":"dependency","вероятная_причина":"lockfile застарів","следующий_шаг":"оновити залежності та повторити job"}

Третій приклад — як це можна зафіксувати в EVIDENCE_LOG.md, щоб запуск не перетворився на «ми щось там робили, здається, в четвер».

## delivery-run
- мета: чернетка summary за diff
- вхід: `git diff HEAD~1..HEAD`
- режим: non-interactive, read-only
- вихід: `tmp/pr-summary.md`
- перевірка: розробник читає diff і виправляє summary вручну

Такі шматочки хороші тим, що вони маленькі, перевірювані й не потребують віри в магію. А якщо automation десь піде не туди, залишиться зрозумілий слід: який був вхід, який вихід очікували, де review-точка.

8. Межі застосовності non-interactive

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

Ось хороше практичне розрізнення:

Це розрізнення рятує від однієї дуже поширеної помилки: упакувати в scripted run задачу, яка ще не до кінця зрозуміла. Тоді запуск повертає банальності або вгадує, а ви злитеся на «марний ІІ». Насправді проблема не в Claude, а в режимі.

Тому робоча модель на сьогодні така. Чіткий вхід, вузька мета, зрозумілий формат виходу і ясна review-точка — non-interactive run доречний. Задача поки схожа на розмову, а не на процедуру — залишайтеся в інтерактивній сесії. Із цієї дисципліни й виростають хороша діагностика середовища, зрозумілі CI-сценарії та build automation, яким можна довіряти не на вірі, а на відтворюваному інженерному процесі.