Оберіть корисну першу задачу для ШІ

Оберіть задачу, яку можна перевірити

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

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

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

Порівняйте можливі задачі

Розгляньмо три вигадані запити для застосунку звітності.

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

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

Запишіть умову завершення

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

Додайте приклади дійсних і недійсних вхідних даних. Вкажіть наявну команду тестування. Попросіть агента перевірити поточну поведінку перед зміною файлів. Вимагайте короткого пояснення дефекту та доказів після зміни.

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

Спостерігайте за процесом роботи

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

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

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

Розширюйте по одній межі

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

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

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