Моделі, контекст і неправильні відповіді

Відокремлюйте можливості від доступної інформації

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

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

Агент із відповідними інструментами може отримати інформацію. Чат без доступу не може перевірити репозиторій. Коли відповідь здається неправильною, поставте два питання. Чи може модель розв’язати цю проблему, маючи правильну інформацію? Чи отримала модель цю інформацію?

Інша модель може допомогти з першою проблемою. Надання відсутньої політики або перевірка залежності можуть розв’язати другу.

Визначте контекст цієї задачі

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

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

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

Розгляньмо вигадану функцію налаштування облікового запису. Надайте маршрут, middleware авторизації, відповідну модель даних і наявний тест. Додайте конкретне обмеження: «Учасник може змінити своє відображуване ім’я. Учасник не може змінити свою роль в організації». Тепер модель має явне правило, яке потрібно зберегти.

Перевіряйте твердження в поясненні

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

1. Перевірте, чи endpoint використовує вказаний middleware.
2. Перевірте, чи middleware перевіряє належність запису, а не лише автентифікацію.
3. Визначте джерело ідентифікаційних даних користувача.
4. Виконайте негативний тест від імені іншого користувача.

Посилання на репозиторій вказує, де шукати. Саме посилання не доводить, що пояснення відповідає коду.

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

Перетворюйте невизначеність на перевірку

«Будь точним» — це не план перевірки. Визначте припущення, потрібні докази та наслідки неправильного результату.

Наприклад: «Ми не перевірили ізоляцію орендарів для цього endpoint. Переглянь обробник запиту. Додай тест, у якому користувач іншого орендаря запитує той самий запис». Ця інструкція дає агенту конкретне дослідження та спостережуваний результат.

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

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