GitHub Copilot — як змусити його працювати в парі

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Здавалося б, дивне питання. Ми ж говоримо про асистента, який має працювати в парі за замовчуванням. Більше того, в усіх маркетингових матеріалах тільки й розповідають про те, як він допомагає програмісту.

Але чи так це насправді?

Який принцип роботи асистентів у режимі агента?

Тут все водночас і просто, і складно. Просто, бо ми йому пишемо щось зробити, він іде і робить. Складно, бо хтозна що він там наробить, і дуже часто простіше зробити щось самому, ніж змушувати щось робити асистента.

Отже, як же він працює?

По-перше, коли ви даєте йому завдання, він іде його і робить. На цьому можна було б закінчити, якби він робив все правильно, красиво і з першого разу. Але це не так.

Чому? Уявіть собі, що у вас є просто відмінний розробник, який працює як пару десятків разом узятих, але у нього склероз. І він забуває про те, що було раніше.

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

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

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

Але давайте будемо чесні: у кого вони є взагалі? Я маю на увазі не формально, а ось реально, оновлювані, підтримувані, актуальні?

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

Але ми відійшли від теми. Отже, ви даєте тому розробнику набір документів, які ви тепер маєте підтримувати на радість бізнесу 🙂

І здавалося б, ось воно, щастя. Підготували документи, актуалізували і вперед.

Але ні, на жаль, так теж працювати не буде. Чому? Тому що у того розробника зі склерозом є начальник, який дав йому інструкції найвищого пріоритету, які він порушувати не може. І що б ви йому не писали, він робитиме тільки те, що не суперечить їм (зараз не говоримо про різні хаки тощо).

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

І ось із цим ми нічого не можемо зробити. Чи можемо?

Tool Calling

Copilot (та й взагалі AI агентів) вдалося дуже сильно прокачати за допомогою технології Tool Calling. Якщо в двох словах, ідея така: ми нашому програмісту кажемо, у тебе є ось такий набір API сервісів, які ти можеш виконувати, коли тобі треба, щоб не робити це ручками. І набір цей досить великий:

Тобто ми можемо дати доступ до командного рядка, до пошуку, до лінтера тощо. Таким чином, коли у нього з’явиться завдання, що йому треба запустити тести, і тут раптом буде тулза, яка для цього і потрібна, він викличе саме її. Так вони влаштовані, ці ваші AI.

Але тут є застереження — з Claude все ок, а ось безкоштовні моделі або той же GPT-5 дуже насторожено до них ставляться і нерідко їх просто ігнорують.

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

На Flutter є проблема з arb файлами локалізації. Тобто ми туди додаємо постійно рядки, але ось не стежимо за тим, коли треба прибрати ті, які вже не використовуються. При розробці «вручну» ми ще якось стежимо за цим, але коли ти переробляєш UI по 100 разів за допомогою AI, то стає це робити досить складно.

І я попросив модель знайти і вичистити все, що не використовується... Це була моя помилка... Він мені перелопатив половину бази і накоїв такого, що... добре, що є гіт, я просто відкотився.

Тоді я за допомогою AI написав скрипт, який робить все, що треба, шукає і категоризує рядки: які точно використовуються, які під питанням.

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

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

Після цього я прибрав від себе ще одну рутину.

Це приклад того, що в принципі можна зробити вручну, але це так нудно робити...

Отже, з утилітами ми розібралися.

Model Context Protocol (MCP)

Більше року тому з’ясувалося, що утиліт недостатньо, і тоді на додаток до них прийшли MCP сервери. Тепер будь-яка програма могла створити свій набір утиліт і дозволити будь-якій моделі з нею взаємодіяти.

Тобто це, якщо дуже грубо кажучи, той же Tool Calling, тільки поза середовищем, де крутиться LLM.

І цих штук почало з’являтися вже сотні. Будь-яка програма намагається це імплементувати в собі.

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

І їх тепер розвелося тисячі: один, два.

Тому що це зручно, просто, і ви можете описати, як саме LLM має взаємодіяти з вашим сервісом/системою.

Вирішуючи нашу проблему

Повертаємося до нашої проблеми. Підсумок: у нас є LLM, в якої прописано, щоб вона все вирішувала сама, з мінімальною вашою участю.

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

Тому, як тільки ви запідозрили Copilot у тому, що він поліз не туди, ви його зупиняєте і починаєте писати, де він не правий.

Мінуси такого підходу очевидні:

• Сам Copilot не зупиниться до останнього. Він пробиватиме головою цю бетонну плиту, поки вона не здригнеться і не переламає вам половину системи.
• Якщо ви його зупините і напишете, що він дурень і робити треба так, то тоді ви заплатите за ще один виклик, і ваш таск буде в пріоритеті. Він може перебудувати todo і взагалі забути, що він спочатку робив, тому що йому треба звітуватися перед вами.
• Треба завжди тримати перед очима те, що він робить, і контролювати кожен його крок. Інакше час буде витрачено даремно. Ну тобто ви не можете паралельно листати мемчики і відповідати на їдкі коментарі до вашої статті, і розповідати колезі в чатику, який AI крутий, поки він там знизу ламає до біса всю вашу кодову базу.

Рішення

І ось, черговий раз, коли ми з колегою сиділи і спілкувалися, а наші чатики нам ламали код, у нас виник запитання: «Якого біса він не зупиниться і не спитає мене???»

Ну це ж очевидно, хто краще за мене знає мою особисту кодову базу? І відповідь (поки що) очевидь не AI.

Але у нього є промпти, які змушують його битися об стінку і не питати мене.

Тоді виникла думка — а давай знайдемо якесь розширення, яке зможе змусити чат звертатися до мене ж як до бази знань?!

Ну тобто коли чату треба викликати утиліту, він же викликає. Коли йому треба отримати щось із документації, він же отримує. Так чому б, коли у нього щось не виходить, йому не звернутися до мене? І чекати, поки я не відповім.

І тут з’явилася перша проблема: а як взагалі задати пошук? Все, що не шукали, відповідей не давало. Тому ми зробили своє розширення, яке саме це і робить.

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

Виглядає це так:

Тобто у чат додається 4 тулзи для викликів.

Далі додаємо у файл .github\copilot-instructions.md:

<system>
ALWAYS escalate (ask expert via tools) IF uncertain, AMBIGUOUS, or CONFLICTING instructions, OR repeated failures, OR destructive edits, OR public API changes, OR architecture uncertainty, OR need to delete/refactor public API. Never guess silently. Never continue after 2 failed attempts without escalation.
ALWAYS WHEN YOU ARE UNSURE, ASK FOR HELP.
ALWAYS ESCALATE EARLY.
ALWAYS AT THE END OF YOUR WORK ASK EXPERT ABOUT WHAT YOU HAVE DONE AND FOLLOW HIS INSTRUCTIONS.
EACH TIME ADD CONSIDERATIONS WITH EXPERT IN ALL YOURS TODO LIST IN BEGINNING AND TO THE END OF YOURS TODO LIST.
SEND TO EXPER ONLY SIMPLE TEXT, EVEN IF YOU HAVE CODE, SEND IT AS SIMPLE TEXT.
NEVER TRY TO DEBUG APP. ALWAYS ASK EXPERT. NOT USER!!!
</system>

Після того, створюю новий чат, і він дає ось такий лист тасків:

А питав я оце:

Проаналізуй кодову базу, та перевірь що ffmpeg валідується однією функцією, і немає дублів.

Після цього я побачив його запит:

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

Тому, коли він з 2 разу не може виправити імпорти — він звертається до мене. Я відповідаю, і це не коштує для мене додадкових викликів, він працює у контексті і я для нього лише якась тулза, а не людина.

І зараз, я можу ось так з ним спілкуватися весь день. До цього — за вихідні я витрачав десь 3-4$ на день, пілся того, як прибрали паузу — став витрачати 5-7$ на день, а з цим варіантом — я можу витратити 0.12-0.24$ за день. Бо зараз — він робить саме те що треба, а якщо не виходить — зупиняється і чекає на експерта.

Висновок

Це лише декілька способів того, як можливо поліпшити те що в нас є, і витратити на це не великий час, бо цей екстеншн я розробив з AI за лічені години.

І тут вже можете уявити скільки всього можна зробити з цим, тобто якщо у вас є своя база знань — можно і її підключити, або підключити ще один AI — котрий буде аналізувати питання копілота, та відправляти вам у телегу з потрібним контекстом, і потім відповідати.

Потім, на reddit мені підказали, що є спеціальні MCP наприклад цей github.com/...​cat/mcp-feedback-enhanced, які дозволяють і файли відправляти у відповідь, і зображення, але мені досі здається — що це трохи не то, та і складно, у всякому випадку складніше ніж встановити єкстеншн та скопіювати промпт.

P.S.

Якщо є бажання спробувати, то ось лінк. Це opensource рішення, яке я зробив за допомогою AI на TypeScript за кілька годин.