AI-агенти в робочому процесі розробника: практичний гайд

Більшість статей про AI-агентів або продають їх як магію, або лякають, що завтра вони замінять розробників. Після роботи з Claude Code, Codex, Cursor і Gemini-інструментами Google на реальних проєктах моя думка нудніша і, як на мене, корисніша: AI-агент — це дуже швидкий junior-розробник, який не втомлюється, не відчуває контексту, і якого в жодному разі не можна залишати сам на сам із продакшеном. З цієї ідеї і виростає весь робочий процес нижче.

Це гайд для тих, хто вже пройшов стадію «вау, воно написало функцію» і хоче отримати повторюваний процес: правила, інструменти, шаблони промптів, етапи та речі, які я й досі роблю руками.

Оновлено в травні 2026: AI-агенти для розробки вже не схожі на розумний autocomplete. Codex працює в CLI, IDE, хмарі та мобільному сценарії, Claude Code має зрілу модель permissions і hooks, Cursor активно розвиває background agents та AI-review pull requests, Google просуває Gemini CLI, Gemini Code Assist і Jules, а MCP став спільним інтеграційним шаром. Можливостей стало більше, але ціна помилки теж зросла.

Чому питання безпеки важливіше за питання продуктивності

Один показовий кейс. У 2025 році The Guardian описав ситуацію, де AI-агент видалив production-базу даних компанії, бо виконав інструкцію буквально. Це не рідкісний баг. Це нормальна поведінка агента: він читає інструкцію та виконує її максимально прямо, без розуміння бізнес-контексту.

У мене є власна, менш ефектна версія цієї історії. На старті я попросив агента «почистити зайві файли в проєкті». Він радо видалив папку, яку я ще не закомітив, разом із половиною дня роботи. Агент зробив рівно те, про що я попросив. Помилка була моя: формулювання, scope, оточення, відсутність підтвердження. Щойно приймаєш, що це структурний режим відмови, а не рідкісна випадковість, решта процесу перестає здаватися параноїдальною і починає виглядати розумно.

Тому головне питання сьогодні не «як використовувати AI», а «як використовувати його безпечно». Варто прийняти цю рамку, і весь процес стає логічним.

П’ять правил, які я не порушую

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

1. Мінімум прав, завжди. Агент отримує саме ті ключі та доступи, які потрібні для поточної задачі. Жодних admin-токенів «про всяк випадок». Для GitHub — fine-grained токен на один репозиторій з мінімальним набором прав. Для бази — read-only користувач, якщо запис не є метою. Для хмари — тимчасові credentials із закінченням терміну дії.
2. Стежте за тим, що він робить, особливо вперше. Сучасні CLI за замовчуванням просять підтвердження для shell-команд. Не вимикайте. День, коли ви це зробите, — день, коли щось зламається.
3. Деструктивні операції не делегуються. Міграції бази, видалення, force push, зміни інфраструктури — це все я роблю руками. Агент може підготувати команду й пояснити, що вона робить. Enter натискаю я.
4. Коміти й push — зона відповідальності розробника. Агент може запропонувати повідомлення та підготувати файли. Diff я читаю порядково перед git commit, а git push — завжди вручну.
5. Можна довіряти задачі, але не її наслідкам.

Якщо запам’ятаєте лише останній пункт — цього вже достатньо.

Початкове налаштування проєкту

Більшість сучасних інструментів працюють за схожою схемою: ставите CLI (наприклад, Claude Code або OpenAI Codex), вказуєте на репозиторій, і агент індексує проєкт. Далі основну роботу роблять три конфігураційні сутності.

Що змінилося у workflow з AI-агентами до травня 2026

Інструменти перейшли від формату «чат із репозиторієм» до маленької операційної моделі розробки. У матеріалі OpenAI про безпечний запуск Codex добре сформульовано принцип: тримати агента в технічних межах, швидко дозволяти низькоризикові дії та явно підтверджувати високоризикові. Я застосовую той самий підхід локально.

У Claude Code settings і hooks уже дозволяють кодувати правила проєкту, а не сподіватися лише на рядок у промпті. Background agents у Cursor корисні, коли робота може йти в віддаленій гілці й потім проходити review, але вони вимагають обережних прав до репозиторію: агент уміє сам запускати команди у віддаленому середовищі. У Google картина розділена між Gemini CLI, Gemini Code Assist всередині IDE та Jules для асинхронних coding tasks, пов’язаних із GitHub. MCP-інтеграції дають GitHub, браузерні перевірки, логи й документацію, але кожен MCP-сервер — це ще одна поверхня можливостей. Ставтеся до нього як до залежності з доступами.

Моє правило на 2026 рік просте: що автономніший агент, то явнішими мають бути межі. Автономність без scoped credentials, review-gates і відтворюваних перевірок — це не продуктивність, а швидкість, прикладена до невизначеності.

1. CLAUDE.md — довготривала пам’ять агента

Найважливіший перший крок — ініціалізація. У Claude Code команда /init створює файл CLAUDE.md у корені репозиторію. Цей файл підвантажується в кожну розмову. Тут ви розповідаєте агенту, як проєкт працює насправді.

Ніколи не приймайте згенерований файл як є. Скелет нормальний, але в деталях він майже завжди помиляється: вигадує команди, пропускає угоди, оптимістично описує «чистоту» кодової бази. Читайте порядково та виправляйте.

Хороший CLAUDE.md відповідає на:

• Що це за проєкт — одним абзацом, зрозумілим людині збоку.
• Стек і версії: PHP 8.3, Node 20, версія фреймворка, все нестандартне.
• Команди: як запустити, протестувати, відлінтити, задеплоїти. Реальні команди, які працюють сьогодні.
• Архітектура: де що лежить, чому, які шари. Два-три абзаци, не роман.
• Угоди: іменування, структура файлів, те, що ви виправили б на рев’ю.
• Заборонені зони: файли й папки, які чіпати не можна, навіть якщо поруч щось «не так».
• Процедура деплою, особливо ручні кроки.

Пишіть так, ніби онбордите нового інженера. Агент працює за тим самим принципом.

1b. Один AGENTS.md на всіх агентів

Маленький, але дуже корисний прийом, щойно у вас з’являється більше одного інструмента. Замість того щоб підтримувати окремі CLAUDE.md, GEMINI.md та конфіги Codex з однаковим вмістом, тримайте єдиний AGENTS.md у корені репозиторію як джерело істини, а кожен файл під конкретний інструмент нехай просто посилається на нього:

# CLAUDE.md
@AGENTS.md

Те саме для GEMINI.md і будь-якого іншого агента, що підтримує посилання на файли. Правиш один файл — зміни бачать усі агенти. Жодного «оновив Claude, забув оновити Gemini» і тихого розходження між інструментами.

2. Налаштування й дозволи

Сучасні CLI дозволяють розділити команди на «запускати без питань» і «завжди питати підтвердження». Користуйтеся. У мене read-only команди (git status, git diff, ls, cat) дозволені тихо, все інше — з підтвердженням. П’ять секунд на натискання y — найдешевша страховка у вашому процесі.

3. Хуки для жорстких обмежень

Усе, що має дотримуватися, а не просто проситися в промпті, йде в хуки. Наприклад, pre-commit, що забороняє push у main, або перевірка, що певні файли не редагуються. Агент не «забуде» хук. Інструкцію — легко.

MCP-інструменти, які я підключаю

MCP (Model Context Protocol) — стандарт, через який агент спілкується із зовнішніми системами. У мене три постійні інтеграції та кілька, яких я свідомо уникаю.

GitHub MCP

Офіційний GitHub MCP дає змогу агенту створювати issues, читати PR, залишати коментарі та запускати запити для код-рев’ю й пошуку коду. Я використовую fine-grained токен на один репозиторій, рівно з тими правами, що потрібні під задачу. Жодних особистих токенів з адмін-доступом на всю організацію і жодного спільного токена між проєктами.

Laravel Boost

Для Laravel-бекендів Laravel Boost відкриває агенту маршрути, логи, SQL-запити та Artisan-команди. Сильно скорочує переписку «покажи, де визначено цей маршрут». Найкорисніше — інспекція маршрутів: агент відповідає «який контролер обробляє цей URL» без grep.

Chrome DevTools MCP

Chrome DevTools MCP дає агенту справжній браузер: переходи, кліки, форми, Network, консоль, скриншоти, Lighthouse. Це й є основа легкого end-to-end тестування без повноцінного Playwright-сьюта.

Чого я свідомо не даю агенту

Credentials бойової бази. Будь-що з білінгом. SSH-ключі на живі сервери. Особистий GitHub-токен. Логіка проста: якщо одна неправильна команда створює інцидент — агент цього не отримує.

Мій процес із п’яти етапів

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

Етап 1. Створення задачі

Раніше написати нормальний GitHub issue займало 15 хвилин. Тепер я формулюю задачу одним абзацом і прошу агента оформити її з описом та мітками. Приклад:

«Створи GitHub issue: додати backend-підтримку блоку Usage Statistics на сторінці Subscription для користувачів браузерного розширення. Повтори логіку, реалізовану для SDK. Відповідь має повертати wordsLimit, wordsCount, wordsLeft, percentageUsed, percentageLeft. Зашлися на контролер SDK. Запропонуй acceptance criteria».

Отримую структурований issue з контекстом, acceptance criteria, посиланнями на файли та потрібними мітками — за хвилину. Перед збереженням все одно перечитую. Секрет — навантажити промпт конкретикою: назвати наявну реалізацію, імена полів, конкретну сторінку. Тоді агент не вигадує деталей.

Етап 2. Письмовий аналіз задачі

До будь-якого коду прошу агента вивчити поточну реалізацію, знайти пов’язані файли, перелічити обмеження та запропонувати два-три підходи з компромісами. Ключовий момент — попросити зберегти результат як markdown-файл у репозиторії, наприклад docs/analysis/usage-stats.md.

Чому це важливіше, ніж здається:

• У агента обмежена робоча пам’ять. Файл — це стійкий контекст, який він може перечитати, не передивляючись половину кодової бази.
• Завтра ви відкриєте його і швидко згадаєте, про що йшлося, навіть якщо контекст розмови зник.
• Запис змушує агента зайняти конкретну позицію. Розмиті відповіді стають конкретними, щойно їх треба зафіксувати.
• Якщо аналіз неправильний — ви ловите це зараз, коли вартість виправлення = коментар, а не переписати все.

Промпт, який я перевикористовую:

«Перед написанням коду проаналізуй задачу. Прочитай пов’язані файли, знайди шви, куди має лягти зміна, перелічи обмеження (форма даних, авторизація, кешування, i18n), запропонуй 2–3 підходи з компромісами. Збережи аналіз у docs/analysis/<task-slug>.md. На цьому етапі не редагуй production-код».

Фраза «не редагуй production-код» важлива. Без неї агенти охоче починають «попутно лагодити» під час аналізу.

Сильніший промпт для аналізу у 2026

«Проаналізуй цю задачу як маленький implementation RFC. Прочитай релевантні файли, переліч конкретні файли, які ти дивився, опиши data contracts, межі permissions, cache/i18n-ризики та тести, які вже покривають сусідню поведінку. Запропонуй два підходи: найменшу безпечну зміну й чистіше довгострокове рішення. Збережи результат у docs/analysis/<task-slug>.md. Production-код не редагуй».

Фраза про переглянуті файли не декоративна. Вона допомагає ловити вигаданий аналіз: агент має показати, на які факти він спирався.

Етап 3. План, потім реалізація

З аналізу агент складає пронумерований план: що міняти, в якому файлі, в якому порядку. Це найдешевший момент, щоб упіймати неправильні припущення. Виправити пункт плану безкоштовно. Переписати наполовину готову фічу — ні.

У більшості агентних CLI є окремий «plan mode», що забороняє правки до погодження. Користуйтеся. Це різниця між 30-секундною дискусією та відкатом упевнено неправильного diff.

Залежно від ризику я або реалізую план сам, використовуючи агента як розумне автодоповнення, або дозволяю йому йти кроками з рев’ю кожного diff. Грубе правило:

• Чисті рефактори, скаффолд, тести, бойлерплейт: агент пише, я роблю групове рев’ю.
• Нова бізнес-логіка: агент пише, я читаю кожен рядок.
• Безпека, авторизація, платежі, міграції: я пишу, агент рев’юїть.

Етап 4. Тестування у справжньому браузері

З Chrome DevTools MCP агент може:

• Відкрити локальний сайт
• Зареєструвати тестового користувача або зайти під фікстурою
• Пройти зачеплений користувацький сценарій
• Стежити за консоллю та Network
• Зробити скриншот у точці збою

Добре працює чек-лист у промпті: «відкрий сторінку Subscription, переконайся, що новий блок рендериться, що wordsLeft збігається з відповіддю API, що в Network немає 4xx і 5xx, зроби скриншот і відзвітуй».

Чого це не ловить: UX-проблеми, доступність, повільна відрисовка, «працює, але відчувається дивно». Після агента я завжди проходжуся по фічі сам. Браузерна автоматизація — мережа проти регресій, а не показник якості.

Етап 5. PR і коміти

Коміти — за мною. Агент може запропонувати повідомлення, але індексую файли, читаю diff і роблю commit я. Так само з git push.

А ось опис PR — чудовий кандидат на делегування. Промпт, який стабільно дає нормальний результат:

«Напиши опис PR для поточної гілки. Включи: абзац-резюме, маркований список користувацьки видимих змін, test plan, нотатки про міграції/rollout, посилання на issue. Аналізуй diff проти main, не вигадуй змін, яких немає в diff».

«Не вигадуй» — робоча фраза. Без неї агенти додають в опис PR правдоподібні зміни, яких насправді немає в коді.

Де реально з’являється виграш у часі

Якщо чесно міряти, агент майже ніколи не економить час «написанням коду». Сам код — невелика частка роботи. Економія народжується навколо:

• Створення issue: з 15 хвилин до приблизно 1.
• Аналіз незнайомої кодової бази: з годин читання до 5–10 хвилин структурованого виводу.
• Опис PR: з 10–15 хвилин до 1.
• Базове регресійне тестування: великий шматок повторюваних кліків зникає.
• Бойлерплейт (CRUD, форми, фікстури, повторювані міграції): хвилини замість десятків хвилин.
• Читання документації заради однієї деталі: агент читає, ви питаєте. Ця економія тихо перемагає решту.

У цьому й полягає справжня цінність: агент прибирає допоміжну роботу навколо інженерії, і більше дня йде на рішення, які має ухвалювати людина. Економія в годину на день — реальна. Обіцянка «агент написав усе за мене» — здебільшого маркетинг.

Чеклист перед тим, як дати агенту задачу

• Я можу описати очікуваний результат одним абзацом? Якщо ні, спершу уточнюю задачу сам.
• Blast radius маленький? CSS-правка, test fixture або локальний скрипт підходять агенту. Payments, auth і migrations — ні.
• В агента тільки потрібний доступ? За замовчуванням read-only, запис лише там, де він справді потрібен.
• Є спосіб перевірити результат? Тест, браузерний сценарій, WP-CLI команда, screenshot, review diff.
• Спробу можна викинути? Якщо ні — використовую branch, worktree або роблю задачу руками.

Чеклист навмисно нудний. Саме нудний процес дозволяє користуватися цікавими інструментами, не перетворюючи production на експеримент.

Неочевидні уроки, які довелося отримати на собі

Деградація контексту — реальна

Що довша розмова, то гірше працює агент. Після тривалої сесії правок, відступів і невдалих спроб модель починає суперечити раннім рішенням, забувати обмеження з system prompt і повертати щойно виправлені баги. Коли це відчувається — не тисніть. Правильний хід: почати нову розмову, тицьнути у файл аналізу з етапу 2 і продовжити звідти. Це одна з найвпливовіших звичок у роботі з агентами.

Агенти переробляють на розмитих задачах

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

Тести пишуться з агентом, але не для агента

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

git worktree — для паралельної роботи агента

Якщо хочеться спробувати ризикований підхід, не блокуючи основну гілку, запускайте агента в окремому git worktree. Ізольована робоча директорія в окремій гілці, яку можна викинути цілком. Безпечніше, ніж stash і перемикання гілок під агентом, який може не зрозуміти, що контекст змінився.

Не токени — справжній бюджет

Усі бояться вартості токенів. На практиці на серйозному платному тарифі гранична вартість задачі — копійки порівняно з годиною розробника. Справжній бюджет — ваша увага. Рев’ю та підтвердження і є дефіцитним ресурсом, а не API-токени. Це змінює, які оптимізації мають сенс.

Подвійне рев’ю краще самоперевірки, але не настільки, наскільки хочеться

Зв’язка з двох агентів: один пише, другий рев’юїть. Claude реалізує, ChatGPT критикує, або навпаки. Працює напрочуд добре: друга модель бачить сліпі плями першої. Але не панацея. Дві моделі впевнено погодяться з однією й тією ж неправильною відповіддю, особливо коли їм бракує проєктного контексту. Фінальне рішення все одно за людиною.

Пастка впевненості

Агенти майже ніколи не звучать невпевнено. Вони пояснять непрацюючий підхід з тією ж спокійною інтонацією, що й працюючий. Питання не «чи це правильно» (відповідь — так), а «що має бути істинним, щоб це було помилкою, і як це перевірити».

Типові помилки новачків

• Давати агенту admin-доступи. Завжди обмежуйте scope. Read-only токена вистачає у 80% випадків.
• Пропускати вичитку CLAUDE.md. Сміття на вході — сміття у кожній наступній задачі.
• Приймати код без читання diff. Агент із радістю видалить тести, щоб вони «пройшли», або закоментує впалий ассерт.
• Дозволяти git push та продакшен-команди. Зекономлене натискання не варте ризику.
• Просити «фікс» без етапу аналізу. Отримаєте правдоподібний код, який лікує симптом, а не причину.
• Затягувати одну сесію на години. Краще почати наново. Вартість re-priming менша за вартість дій на зіпсованому контексті.
• Вірити звітам агента на слово. «Усі тести пройшли» потребує верифікації. І «все реалізовано» — теж.

Конкретний приклад із реальної роботи

Свіжа задача з цього ж сайту: нормалізувати слаги сторінок Polylang, щоб /about/, /ru/about/, /uk/about/ і /es/about/ резолвилися однаково. П’ять етапів пройшли так:

1. Issue: один абзац про неузгодженість — агент за хвилину зібрав issue з посиланнями на файли.
2. Аналіз: агент простежив логіку слагів по Polylang, rewrite-правилах і темі, зберіг усе в docs/analysis/polylang-slugs.md з трьома варіантами рішення.
3. План: обрали найменш ризикований варіант (одноразовий скрипт нормалізації при деплої), агент розбив його на маленький набір правок і сам скрипт.
4. Реалізація: агент написав скрипт, я дивився кожен diff. Два моменти, спіймані на рев’ю: зайве перейменування та пропущений language-guard. Обидва виправлені до коміту.
5. Тест і деплой: Chrome DevTools MCP перевірив, що всі чотири мовні URL повертають 200 після прогону скрипта локально. Деплой я зробив руками однією командою: git pull && wp eval-file && wp rewrite flush.

Повний час: менше години на задачу, яка раніше з’їла б половину дня. Агент не «вигадав рішення». Він прибрав накладні витрати навколо нього.

FAQ

Чи потрібен платний план для серйозної роботи?

Для щоденної роботи — так. На безкоштовних тарифах можна спробувати процес, але реальна продуктивність приходить із довгим контекстом і швидкими моделями. Вартість мала порівняно з годиною розробника.

Чи замінять AI-агенти розробників?

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

Чи можна дозволяти агенту виконувати shell-команди?

Так, за двох умов: обмежене оточення (контейнер чи scoped) та явне підтвердження для всього деструктивного. Ніколи не вимикайте підтвердження на машині, яка має шлях до прода.

Claude Code, Codex чи Cursor — що обрати?

Claude Code, Codex, Cursor і Gemini — усі заслуговують уваги, але це не один і той самий інструмент. Cursor найсильніший, коли потрібен агент усередині IDE, background agents і PR-review поруч із редактором. Claude Code особливо добрий для terminal-native роботи з сильною project memory, settings і hooks. Codex цікавий там, де хочеться один і той самий agentic workflow у CLI, хмарі, IDE та мобільному handoff. Gemini CLI і Gemini Code Assist логічні, якщо команда вже живе в Google-екосистемі, а Jules ближчий до асинхронного coding agent для задач із GitHub. Правильна відповідь усе одно проста: спробувати кожен на реальній задачі, а не на демо.

Яка звичка дає максимальний ефект?

Чистий CLAUDE.md (чи його аналог), який ви підтримуєте в актуальному стані. Усі інші покращення нарощуються зверху.

Ключові висновки

1. AI-агент — це швидкий асистент, а не автономний інженер. Якщо ставитися до нього так, решта схеми збирається сама.
2. Безпека, обмежені доступи й ручний контроль над деструктивними операціями — без варіантів.
3. Головний приріст продуктивності — не в генерації коду, а у зникненні допоміжної роботи навколо нього.
4. Чистий CLAUDE.md, продумані MCP-інтеграції та процес із п’яти етапів покривають більшу частину шляху.
5. Контекст — це бюджет: починайте нові сесії частіше, зберігайте аналіз у файли, вузько формулюйте кожен промпт.
6. Відповідальність за архітектуру, рішення й наслідки залишається за розробником.

Схожі статті

• Коли витік секрету в Git обернувся переписуванням чотирьох років історії — реальний інцидент, який пояснює правило №1 краще за будь-який гайд.
• Дебаг продакшен-сайту після ІІ-деплою — що робити, коли задеплоєне агентом ламається в продакшені.
• Як я створив і задеплоїв кастомну WordPress-тему з AI-агентами менш ніж за 6 годин — той самий процес на реальному проєкті від початку до кінця.