Англійською для GitHub Copilot Workspace Developers

GitHub Copilot Workspace розширює програмування пар ШІ за межі вбудованих пропозицій до повного потоку роботи від завдання до запитів на витягування, а опис цього потоку роботи вимагає словника, який все ще новий для багатьох команд. Вміння пояснити, що таке «план», чому пропозиція була прийнята або відхилена, або як запит на витягування, створений штучним інтелектом, відрізняється від запитів, створених людиною, має значення як для чітких переглядів коду, так і для встановлення очікувань з нетехнічними зацікавленими сторонами. Цей посібник містить терміни, які вам знадобляться для плавного і точного обговорення програмування робочого простору Copilot і пар ШІ.

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

** Програмування з використанням пар штучного інтелекту ** — процес роботи, у якому розробник співпрацює з асистентом штучного інтелекту, який пропонує код, пояснення або цілком змінює його у реальному часі, подібно до роботи разом з людською парою. “Ми ставимося до Copilot як до парного програмування штучного інтелекту, він розробляє перший прохід і ми разом уточнюємо логіку.”

** Специфікація завдання ** — опис у природній мові того, що слід змінити, надіслано до робочого простору Copilot як початкову точку для створення плану.

• “Напишіть чітку специфікацію завдання, включаючи файли, які будуть змінені, і якість плану значно поліпшиться.” *

** Створення плану ** — крок, за допомогою якого робочий простір Copilot пропонує структуровану, редагувану послідовність кроків для реалізації завдання перед написанням будь- якого коду.

• “Під час створення плану, він визначив три файли, які, на його думку, потребували змін, ми вилучили один, який був за межами обсягу.” *

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

• “Половина з цих пропозицій коду є правильними, але я завжди переглядаю їх перед прийняттям.” *

** Запит ** — інструкція або питання, яке розробник дає асистентові ШІ, ясність якого безпосередньо впливає на якість і актуальність виводу.

• “Перша пропозиція була неправильною, тому я вдосконалив запит, щоб вказати певний шаблон обробки помилок, який ми використовуємо.” *

** Галюцинація ** — коли асистент ШІ впевнено генерує неправильну або сфабриковану інформацію, наприклад, неіснуючу функцію або API.

• « Цього імпорту не існує у цій бібліотеці, це галюцинація, тому перевірте всі невідомі елементи перед об’ єднанням. » *

** Перегляд відмінностей ** — процес перевірки певних рядків, які змінив помічник ШІ, замість прийняття всього сформованого запиту на завантаження за його значенням.

• “Відповідно перевіряйте відмінності навіть у запитах на завантаження, створених штучним інтелектом, а не просто переглядайте резюме.” *

** Контекстне вікно ** — кількість коду, файлів і історії розмов навколо асистент ШІ може враховувати під час створення пропозиції або плану. “Не вдалося виконати функцію спільної програми, оскільки вона знаходилася поза контекстним вікном помічника.”

Звичайні фрази

• «Давайте дамо Копілотові спочатку розробити план, а потім ми підберемо кроки, перш ніж він торкнеться будь-якого коду»
• «Ця ідея виглядає правдоподібною, але я хочу перевірити, що це не галюцинація перед злиття»
• “Чи можете ви посилити специфікацію завдання? План, який він створив, був занадто широкий»
• «Я прийняв більшість відмінностей, але переписав обробку помилок вручну.»
• «Ми все ще потребуємо людського рецензента на кожному запиті на витяг, створеному штучним інтелектом, без винятків»
• «Контекстне вікно не включало наш конфігураційний файл, тому воно вгадувало змінні середовища.»

Приклади висловлювань

При поясненні роботи GitHub Copilot нетехнічним користувачам: “Ми описуємо завдання простою англійською, а ШІ пропонує покроковий план і проект змін коду, який розробник потім переглядає і коригує перед тим, як щось буде об’єднано, тому людина завжди приймає остаточне рішення.”

Під час створення квитка підтримки:

• “Робочий простір Copilot створив план, що посилається на файл, який було вилучено у попередньому спринті. Чи є спосіб змусити його пересканувати сховище перед створення плану, а не покладатися на застарілий індекс?»*

Під час обговорення архітектури на груповій нараді:

• “Я вважаю, що нам слід використовувати робочу область Copilot для рефакторингу з чіткою специфікацією завдання, але не використовувати ШІ для будь- чого, що стосується автентифікації, доки ми не збудували більшої впевненості у процесі перегляду відмінностей.” *

Професійні поради

• При обговоренні змін, створених штучним інтелектом, скажіть « **перегляньте відмінності ** », а не « перевірте код » — це означає, що ви оцінюєте точну модифікацію, а не просто переглядаєте кінцевий файл.
• Викликайте ** галюцинацію ** явно за назвою, коли ви знайдете її в перегляді коду; це точний, широко розуміний термін, який уникає неоднозначності, наприклад, «це виглядає неправильно»
• Якщо пропозиція є поганою, описуйте її як ** проблему підказки ** або ** проблему контексту **, а не звинувачуйте « штучний інтелект » у загальних термінах — це збереже зворотній зв’ язок, який можна буде використати для вдосконалення роботи команди.
• Підкресліть, що ** сформований план ** є чернеткою для обговорення, а не зобов’ язанням, коли ви представляєте робочий простір Copilot команді, яка не має досвіду роботи з програмуванням на парі штучного інтелекту.

Практичні вправи

1. Колега об’єднав запит на витяг, створений штучним інтелектом, без перегляду, і це пошкодило виробництво. Напишіть від двох до трьох речень, у яких ви поясните професійною англійською мовою, чому перегляд відмінностей має значення навіть для змін, які здійснюються за допомогою штучного інтелекту.
2. Поясніть у одному реченні різницю між специфікацією завдання і створеним планом.
3. Створити коротке повідомлення Slack з проханням до співробітника команди двічі перевірити код, який, на вашу думку, може бути галюцинацією.

Наприклад, слово «кода» означає «розмовляти з кодом»

Ядро розуміння цінності GitHub Copilot полягає не тільки в його здатності генерувати код, але і в вашій здатності *ефективно * комунікувати про це. Як розробник, що використовує робочий простір, ви постійно взаємодієте - через коментарі, описи PR, канали Slack - з колегами і потенційними зацікавленими сторонами. Часто ці взаємодії залежать від точного вираження того, що робить Copilot, чому він це робить і як він збігається з більш широкими цілями проекту. Це вимагає більше, ніж просто технічного жаргону; це вимагає нюансового розуміння професійного англійського словника, зосередженого на співпраці і зворотному зв’язку. Ключовим викликом для носіїв мови, яка не є рідною, є розпізнавання тонких відмінностей у фразуваннях, які сигналізують про різні рівні залучення або критики. Наприклад, просто сказати «Копілот виправив це» може бути відвертим, тоді як «Копілот визначив можливість рефакторизувати цей розділ за допомогою більш ефективного алгоритму» демонструє глибше розуміння його вкладу і запрошує до подальшого обговорення. Аналогічно, оформлення пропозицій як рекомендацій, а не директив, загалом є більш ефективним у співпраці середовищ.

Одним з найпоширеніших сценаріїв, з якими ви можете зіткнутися, є отримання коментаря від переглядача коду: « Це можна поліпшити ». Хоча це твердження здається простим, у ньому бракує специфіки. Кращий підхід був би “Чи можемо ми дослідити використання switch-заяви тут замість декількох if-else-блоків? Це може поліпшити читабельність і підтримку в довгостроковій перспективі.” Зауважте зміну від відкритої критики до фокусованої пропозиції з виправданням - ключовий елемент для конструктивного діалогу. Іншою поширеною ситуацією є створення описів PR: « Копілот автоматично створив цю функцію ». Знову ж таки, тут бракує контексту. Сильнішим описом буде: “Copilot створив цю функцію на основі вказаних вимог і існуючої документації API. Я ретельно переглянув його і вніс найкращі практики для обробки помилок. » Забезпечення цього додаткового шару пояснень демонструє ваше розуміння і перевіряє вивід Copilot. Завдяки оволодінню цими тонкими змінами у мові ви зможете повністю використати потенціал робочого простору і стати більш ефективним співробітником.

Крім того, зверніть увагу на словниковий запас, який використовується під час обговорення * планування * з Copilot. Фрази на кшталт «Давайте використаємо Copilot, щоб створити план високого рівня» або «Чи може Copilot допомогти нам розбити це завдання на менші, керовані кроки?» підкреслюють роль інструменту в сприянні структурованому мисленню і ефективному робочому потоку. Не вагайтеся запитати у другого пілота про пояснення — чітке формулювання ваших запитів має велике значення. Пам’ятайте, що ефективне спілкування не тільки про те, що ви кажете, але і як ви це говорите. Використання цієї навики не лише поліпшить ваші взаємодії з самим інструментом, але й зміцнить ваші стосунки з іншими членами команди.

Ось простий приклад використання git diff для відображення змін, які може запропонувати Copilot:

git diff --stat HEAD^..HEAD