Передісторія
Поштовхом стали кілька зустрічей один на один із моїм тімлідом. Його цікавило, як я використовую AI-інструменти, будую власні Harnesses та організовую свій робочий процес AI Coding. Здебільшого тому, що я швидко й якісно закриваю задачі, і вже є основним відповідальним за деякі проєкти. Тож я скористався цією нагодою, щоб систематизувати свій щоденний AI-робочий процес. Наразі в команді я переважно займаюся розробкою Agent'ів, паралельно підтримуючи наявну бізнес-логіку бекенду.
Раніше я вже ділився подібними воркфлоу на Xiaohongshu. Тоді контекст був таким: GPT-5.4 та Opus 4.6 вже чудово справлялися із задачами, якщо дати їм точний контекст і розумні обмеження. Поява Harness Engineering змусила всіх усвідомити: потужними моделями можна краще керувати, додаючи обмеження.
Наприклад, Skills на кшталт Superpowers — це доволі «важка» реалізація, побудована навколо Spec і TDD, яка допомагає людям легше структурувати та просувати задачі.
Але в цьому є свої мінуси. Найочевидніше відчуття: Token'и злітають дуже швидко. Такі Skills, як Superpowers, містять безліч Workflows, покликаних обмежувати наступну дію моделі. Навіть якщо глобально певний крок уже не потрібен — скажімо, контексту достатньо й можна одразу писати код, — модель усе одно може продовжити рухатися заздалегідь визначеним процесом.
З виходом нових моделей я помітив, що багато розробників почали ділитися тим, що вони практично відмовилися від таких важких Skills. Головна причина: після посилення можливостей моделей деякі обмеження й процеси, які раніше здавалися корисними, перетворилися для моделі на шум. Наприклад, коли OpenAI випустила Astra, вони окремо написали статтю про те, як очистити зайві Skills та системні промпти, щоб покращити досвід роботи з моделлю.
Тому в цій статті я поєднаю свій досвід за останні кілька місяців і поділюся методами, які зараз працюють для мене. Поговоримо про те, як ефективніше використовувати різних Agent'ів для підвищення щоденної продуктивності в розробці.
1. Мої найчастіше використовувані Skills та Prompts
Як я зараз розподіляю інструменти:
Наразі для написання коду я переважно використовую Codex + GPT-5.6 Sol, а для планування — Astra. До релізу Astra задачі з планування я віддавав GPT-5.6 Sol Max.
Для простих задач беру pi + DeepSeek V4 Flash; adversarial review рішень та Code Review здебільшого робить Claude 5 Fable. У особистих проєктах для проєктування основних рішень я також використовую вебверсію GPT-6 Pro.
Мої найчастіше використовувані Skills
- think: Skill від tw93, переважно для узгодження рішень та брейнштормів.
- grill me / grill with docs: Використовуються для уточнення вимог. Через серію запитань вони допомагають прояснити цілі, обмеження та компроміси, а потім фіксують їх в ADR або CONTEXT.md відповідно до потреб процесу розробки. Це допомагає мені знаходити проблеми, які ми пропустили під час початкового узгодження.
- implement: Працює в парі з grill, частина набору Skills від Matt Pocock. Використовується для реалізації чітко сформульованих планів або Issues.
- ponytail: Для прибирання надмірного овердизайну від AI, що спрощує Review. Я використовую його часто, бо GPT-5.6 Sol любить ускладнювати архітектуру там, де це не потрібно.
- handoff: Пакує поточний контекст у файли, щоб було зручно продовжити задачу в новій сесії. Зазвичай я передаю так роботу від Codex до Claude Code або pi agent.
- check: Для code review, зазвичай під час створення MR.
- Skills, напрацьовані в роботі та особистих проєктах: Переважно це SOP-процеси багаторазового використання, наприклад, end-to-end тестування. Моя порада: якщо в щоденній роботі якийсь процес повторюється більше трьох разів, попросіть Codex оформити його в Skill, щоб надалі просто переиспользовувати.
Мої найчастіше використовувані Prompts
Зараз я рідко пишу великі обсяги Prompt'ів власноруч. Коли потрібно, я зазвичай прошу Codex допомогти їх структурувати. Наприклад, якщо після кількох раундів обговорень я хочу передати поточний контекст у GPT Pro для проєктування рішення, я спочатку прошу Codex згенерувати повний handoff Prompt.
Окрім цього, я часто використовую такі типи дуже коротких Prompt'ів.
Іноді вони дають ефект «одне слово варте тисячі». Я сприймаю їх як «ярлики мислення» для моделі.
Це не магічні заклинання, а методології, давно стандартизовані в людських знаннях. Під час навчання модель бачила величезну кількість відповідних статей, коду, проєктних документів та обговорень, тому часто немає потреби вручну писати сотні рядків Workflow — достатньо сказати, який підхід до мислення обрати. Ось кілька prompt'ів, які на практиці виявилися дуже ефективними:
- Перші принципи (First Principles): Не продовжуйте оптимізувати наявне рішення, запитайте заново, як цю проблему взагалі слід вирішувати. Наприклад, якщо інтерфейс працює повільно, можна сказати:
Не продовжуй проєктування на основі готового рішення «додати Redis-кеш». Проаналізуй із перших принципів, чому цей інтерфейс повільний і яке мінімально необхідне рішення.
Фокус моделі зміщується з «як правильно спроєктувати Redis» на:
Де саме вузьке місце: у SQL, мережі, серіалізації, конкуренції за блокування чи повторних обчисленнях? Якщо додавання індексу в SQL вирішує проблему, навіщо взагалі тягнути Redis?
Такий тип Prompt'ів підходить, коли ви підозрюєте, що «сама постановка питання може бути хибною».
- Adversarial Review: Не шукай виправдання моєму рішенню, спробуй довести, що воно неправильне.
Зазвичай запит звучить так:
Подивись, чи є проблеми в цьому технічному рішенні.
Його можна замінити на:
Проведи adversarial review цього рішення, пріоритетно шукай контрприклади, здатні спростувати ключові припущення.
Припустимо, ваше рішення — «впровадити розподілені блокування для усунення дублів запитів». Тоді модель не просто пояснить, як налаштувати таймаут блокування, а почне запитувати:
Чи дійсно дублям запитів потрібне взаємне виключення? Чи вирішить це ідемпотентність інтерфейсу? Що буде, якщо сервіс блокувань впаде? Що, якщо блокування протермінується, а бізнес-логіка ще не завершилась? Чи не впроваджуємо ми нову точку розподіленого збою заради вирішення локальної проблеми?
Цей тип Prompt'ів особливо корисний для ревʼю рішень та Code Review.
- Абляційні експерименти (Ablation Experiments): Те, що система стала кращою, не означає, що кожне ваше доповнення було корисним.
Наприклад, ви зробили три оптимізації водночас:
Після додавання індексів, Redis-кешу та пакетних запитів затримка інтерфейсу впала з 800ms до 100ms.
У такому разі можна напряму запитати:
Спроєктуй абляційні експерименти для цих трьох оптимізацій, щоб визначити, звідки саме береться реальний ефект.
Модель спроєктує контрольні групи для різних комбінацій: починаючи від Baseline, порівнюючи лише додавання індексів, індекси + кеш, індекси + кеш + пакетні запити тощо.
Зрештою вона може виявити:
Лише додавання індексів знизило затримку з 800ms до 120ms, а решта двох складних рішень дали лише 20ms.
Так ви чіткіше розумітимете, який код варто залишити, а яка складність, імовірно, зайва.
- Бритва Оккама (Occam's Razor): За однакового ефекту обирайте рішення з меншою кількістю припущень і нижчою складністю.
Наприклад, Agent спроєктував таке рішення:
Kafka + Redis + розподілене блокування + машина станів + компенсація за таймером.
Ви можете додати одну фразу:
Переглянь цей дизайн через призму бритви Оккама, видаливши всі необов'язкові механізми за умови виконання вимог.
Часто зрештою виявляється:
У поточному сценарії запис іде лише в одну базу даних, тому достатньо однієї транзакції та унікального індексу.
Ця фраза особливо корисна для сучасних Coding Agent'ів, адже моделі легко вдаються до овердизайну заради «повноти картини».
- Висока зв'язність, низька залежність (High Cohesion, Low Coupling): Перевірте обов'язки та межі коду.
Наприклад, якщо ви бачите, що OrderService вже налічує 2000 рядків, можна запитати:
Перевір межі відповідальності OrderService за принципами високої зв'язності та низької залежності, не розбивай код просто заради розбиття.
Модель зазвичай починає аналізувати:
Чому сервіс замовлень одночасно відповідає за склади, купони, SMS, оплату та звіти? Яка логіка належить самому домену замовлень, а яку слід передати іншим модулям через стабільні інтерфейси?
Це запускає не просто «розбиття файлів», а цілий комплекс суджень щодо модульності, приховування інформації, напрямку залежностей та розподілу відповідальності.
Тому я майже не пишу:
Крок 1: проаналізуй вимоги, Крок 2: перевір припущення, Крок 3: знайди альтернативи, Крок 4...
Багато зрілих методологій модель уже засвоїла. Я волію казати їй напряму:
Переосмисли все з перших принципів, проведи adversarial review поточного рішення; ключові механізми мають бути перевірені абляційними експериментами; рішення має відповідати бритві Оккама, а код — принципам високої зв'язності та низької залежності.
За цими кількома десятками слів насправді стоять п'ять різних когнітивних дій:
Переформулювати проблему → Атакувати припущення → Перевірити внесок → Видалити складність → Організувати межі системи.
Саме в цьому, як на мене, полягає зміна Prompt Engineering в епоху нових моделей: замість того, щоб прописувати моделі жорсткий покроковий процес мислення, краще точними методологіями підказати їй «як думати», а потім додати лише ті обмеження, які дійсно необхідні для конкретної задачі.
2. Мій щоденний робочий процес розробки
Отримавши задачу, я зазвичай спочатку передаю Agent'у відповідний контекст: PRD, нотатки зі зустрічей, історію чатів, фідбек користувачів, а потім використовую grill, щоб узгодити з ним вимоги.
Ці матеріали рідко бувають цілісною та несуперечливою вимогою. PRD може бути не оновлений, деякі обмеження могли обговорити на зустрічах, пріоритети — змінити в чатах. Моє власне розуміння вимог також може містити невисловлені припущення.
Я даю Agent'у змогу опрацювати ці матеріали разом із командною Wiki та наявним кодом, а потім через постійні запитання прояснити цілі, межі та компроміси, що впливають на реалізацію. На деякі питання я можу відповісти одразу, інші потребують повернення до продакт-менеджера чи колег.
Тут я дотримуюся певної міри: коли відповіді на решту питань уже не змінять суттєво напрямок реалізації та критерії приймання, можна починати розробку.
Я не вимагаю, щоб він заздалегідь спланував усі деталі реалізації, інакше саме узгодження вимог перетвориться на надто громіздкий процес.
Висновки після узгодження фіксуються в Spec або CONTEXT.md, де записуються проблема, яку треба вирішити, скоуп, ключові рішення та критерії приймання. Це також дозволяє наступним Agent'ам, відповідальним за реалізацію та ревʼю, працювати в одному контексті, не перечитуючи всі попередні діалоги.
Коли рішення визначено, я даю головному Agent'у можливість самостійно вирішити, як діяти, залежно від складності задачі. Прості вимоги реалізуються одразу; складні — розбиваються на Issues із чіткими межами, які можна приймати незалежно. Лише ті частини, що можуть виконуватися автономно, передаються subagent'ам для паралельної розробки в різних worktrees, а потім головний Agent їх інтегрує.
Coding Agent спершу пише тести. Коли він вважає, що готовий до здачі, я, залежно від складності задачі, залучаю інших Agent'ів для перехресного adversarial review. Знайдені проблеми централізовано повертаються головному coding Agent'у, тобто Codex, який їх виправляє та перевіряє заново.
Перед власним Review я також проводжу end-to-end тестування.
Наразі я не читаю весь згенерований код порядково, звертаючи увагу переважно на результати тестів та ключову бізнес-логіку. Тут є важлива передумова: скоуп кожного MR достатньо малий, а повні бізнес-сценарії поступово перевіряються в процесі розробки.
Невеликі MR гарантують, що обсяг змін, які потребують осмислення та оцінки, щоразу залишається контрольованим; end-to-end тести допомагають перевірити, чи витримують ці зміни інтеграцію в реальні бізнес-процеси. Під час ручного Review я зосереджуюсь на підтвердженні бізнес-логіки та на тому, чи достатньо наявних результатів тестування для цього релізу.
3. Як побудувати end-to-end тестування, зручне для Agent'ів
AI вже чудово пише тест-кейси, часто генеруючи сотні рядків тестів для одного Bugfix'у (особливо 5.6 sol). Саме по собі написання більшої кількості тестів — не проблема, але після деплою та релізу ми все одно стикаємося з неочікуваними помилками.
На мою практику, ключова проблема ось у чому: ми не надаємо Agent'у середовища для end-to-end тестування, позбавляючи його можливості виявляти ці проблеми на етапах написання коду та самотестування.
Якщо побудувати таке середовище, де Agent зможе зручно виконувати задачі від реальної точки входу тестового стенду, перевіряючи все аж до результатів, потрібних користувачу, ми зможемо впевнено запускати написаний AI код у реальних системах.
У реальній розробці я побудував набір end-to-end середовищ для тестування нашого бізнесу. Agent може зручно запитувати таблиці баз даних, логи та підключатися до машин для діагностики проблем.
По суті, весь процес побудови — це коли Agent витягує мої щоденні процеси самотестування, інтегруючи розрізнені інструменти та можливості: те, що можна перетворити на інструмент, стає MCP або CLI; процеси багаторазового використання оформлюються в Skills.
Це дійсно потребує певних зусиль на старті, але не бійтеся мороки. Після налаштування це значно пришвидшує розробку, зменшує кількість переробок та ризик проблем на проді, і вам не доведеться цілодобово хвилюватися, чи не спричинить написаний AI код аварію.
Щодо end-to-end тестування, зручного для Agent'ів, я зробив чотири основні речі:
- Дав Agent'у освоїтися в середовищі: наприклад, підтримка запуску тестових середовищ в один клік, створення тестових даних, прояснення поточних версій, тестових акаунтів та прав доступу, а також забезпечення можливостей очищення та скидання.
- Дав Agent'у можливість керувати бізнес-системами: виконання реальних бізнес-процесів через браузери, API або CLI.
- Дав Agent'у зручний доступ до таблиць БД та логів: підтвердження результатів збереження через read-only MCP бази даних, пошук проблем через Skills лог-систем та запити Trace.
- Переиспользование нудних, але стабільних процесів: стабільні операції винесені в скрипти, точки входу та методи траблшутингу оформлені в Skills, що зменшує кількість повторних ручних втручань та діалогів.
Спираючись на цю роботу, ось кілька методів, які зараз здаються мені ефективними:
- Автоматизація браузера: коли бізнес-системи потребують роботи через браузер, я рекомендую open-source браузер ego lite. Він зручний і швидкий. У парі з pi agent + DeepSeek V4 Flash тести проходять відносно швидко, що економить час.
- Об'єднання операцій у CLI: інтегруйте Skills багаторазового використання, налаштовані MCP та написані скрипти в єдиний тестовий CLI, який забезпечить перевірку середовища, підготовку даних, виконання сценаріїв, запит результатів та очищення. Це також може стати внутрішнім інструментом для підвищення ефективності. Наразі я оформив цей набір у CLI, і це дуже зручно для траблшутингу, коли виникають проблеми.
- Нехай інструменти безпосередньо працюють на приймання: запити до БД використовуються для підтвердження статусу, логи та Traces — для пояснення помилок, але очікувані результати все одно мають братися з бізнес-контрактів. Не дозволяйте Agent'у вважати щось правильним лише тому, що він побачив відповідь системи. За складної бізнес-логіки система може видати цілком логічний на вигляд, але фактично некоректний результат. Інструменти допомагають нам отримати докази, а не визначають правильні відповіді за нас.
- Якщо сам продукт є Agent'ом, перевіряйте й якість відповідей: якщо тестований продукт сам по собі є Agent'ом, окрім успішності проходження бізнес-процесів, варто враховувати й якість відповідей. Це те, що ми зазвичай називаємо Agent Eval, але тут я не буду на цьому зупинятися.
4. Як робити Review коду, написаного AI
У попередніх розділах я розповів, як змусити AI писати якісний код, але зрештою саме розробник залишається головним відповідальним за бізнес-вимоги.
Без Review великі системи легко ламаються.
І ви точно не хочете, щоб вас підняли по On-call посеред ночі, а виявилося, що проблема в коді, написаному AI.
Щодо Review, наразі я дотримуюся таких основних практик:
- Спочатку критерії приймання, потім результати тестів: спершу перевірте критерії приймання, сформульовані Agent'ом, а потім порівняйте їх із результатами попереднього end-to-end тестування, щоб переконатися, що очікування виконані й нічого не пропущено. Дивіться не лише на кількість пройдених тестів, а й на те, чи перевіряють ці тести те, що дійсно важливо для цієї задачі.
- Ідіть за бізнес-сценаріями, переглядаючи реалізацію, зосереджуючи сили на високоризикових місцях: я переважно перевіряю права доступу, зміни станів, конкурентність, повторні спроби, консистентність даних та такі ризиковані речі, як міграції та rollback'и. На стабільний CRUD за шаблоном можна витрачати менше часу — частину такого коду я тепер навіть не дивлюся.
- Окремо перевіряйте нові абстракції та механізми: для щойно доданих абстракцій і механізмів я використовую підходи на кшталт бритви Оккама, щоб AI провів повторне ревʼю: чи дійсно вони потрібні, чи є простіша реалізація, чи не внесли вони забагато складності заради локальної проблеми?
- Подумайте про створення спеціалізованих Review Bot'ів, якщо MR багато: якщо в команді багато MR, можна спроєктувати спеціального Review Bot'а для перехресного ревʼю. На відміну від прямого виклику pi agent / Claude Code для adversarial review, про що йшлося раніше, тут акцент робиться на поєднанні інформації про зміни з Git із заздалегідь спроєктованими процесами ревʼю, формуючи повторювану систему перевірки, створену спеціально для MR.
5. Деякі підсумки та роздуми
Мій найочевидніший bottleneck у поточній розробці — швидкість Review.
Agent'и можуть одночасно просувати кілька задач, але моя швидкість розуміння бізнесу, оцінки рішень та підтвердження результатів не зростає пропорційно. Якщо просто дозволити йому писати більше, ви, найімовірніше, лише накопичите більше коду, що чекає на ревʼю.
Тому наступне, що я хочу покращити, — це щоб повторювані проблеми виявлялися та виправлялися ще до того, як потраплять до мене.
Проблеми, які можна знайти через перевірку типів, тести та бізнес-асерти, Agent має максимально вирішувати сам під час розробки; а ті, що потребують мого втручання, зводяться до питань: чи правильно зрозумілі вимоги, чи працює ключова бізнес-логіка та які неперевірені ризики залишилися в цих змінах.
Спеціалізовані Review Bot'и можуть допомогти з цим, але їхня цінність залежить від того, чи зменшують вони пропуск реальних проблем та ручне навантаження, а не просто від кількості залишених коментарів.
Це також робить моє розуміння Harness більш конкретним: окрім надання Agent'ам правильного контексту, їм потрібні середовища, здатні виконувати задачі, та база для оцінки результатів.
Я оформив операції, які постійно повторював під час щоденних самотестів, у CLI, скрипти та Skills, дозволивши йому самостійно запускати системи, перевіряти результати та шукати докази помилок. У майбутніх подібних задачах ці можливості можна використовувати далі, поступово передаючи їх іншим колегам для переиспользования.
Водночас цей робочий процес потребує регулярного «віднімання».
Деякі кроки компенсують недоліки певного покоління моделей. Коли моделі змінюються, корист від цих кроків слід переоцінювати. Прості задачі виконуються напряму, складні потребують планування, розбиття та перехресного ревʼю. Наприклад, після оновлень Astra я видалив деякі надто суворі обмеження з AGENTS.md. Моделі ітеруються, і наші робочі процеси мають ітеруватися разом із ними.
Звісно, тестування та Review зменшують невизначеність, але люди все одно мають задавати правильні критерії приймання. Навіть якщо код і тести відповідають одне одному, вони обидва можуть однаково неправильно зрозуміти вимоги. End-to-end тести покривають лише поведінку в обраних середовищах та сценаріях; трафік, конкурентність та розподіл даних у прод-середовищі все одно можуть принести нові проблеми.
Як розробник, який лише почав працювати, я все ще сподіваюся здобувати більше професійних знань у цій сфері через роботу. Однак AI дійсно зменшив кількість можливостей особисто наступати на граблі. Деякий цінний досвід, який раніше здобувався через зіткнення з проблемами та пошук їхніх причин, тепер може звестися до того, що AI скаже:
«Я помилився, виправляю».
Тому
зараз я резервую частину свого щоденного робочого часу для навчання та рефлексії, водночас розмірковуючи: які навички дійсно потрібні R&D-спеціалістам в епоху AI.
Ця стаття фіксує набір методів, які я поступово напрацював у своєму бізнесі протягом перших кількох місяців. Їхню сферу застосування та недоліки я все ще досліджую.
Кожен може взяти один типовий шлях самотестування, спробувати дати Agent'у пройти його самостійно, зберегти докази, а потім зафіксувати ефективні кроки.
Через вимоги конфіденційності компанії багато деталей неможливо включити у статтю. Сподіваюся, цей текст стане тією «цеглиною, що привабить нефрит», і мені буде дуже цікаво почути ваші найкращі практики з реальної розробки~
