Modely, kontext a nesprávné odpovědi

Oddělte schopnosti od dostupných informací

Jazykový model používá naučené vzory a informace dodané během úkolu. Moderní modely dokážou složitě uvažovat a vykonávat užitečnou práci na softwaru. Mohou také vytvořit podrobnou odpověď, která závisí na nesprávném předpokladu.

„Frontier model“ označuje proměnlivou úroveň schopností. Tento pojem neprokazuje, že model četl váš repozitář. Neukazuje, zda zná verze vašich závislostí nebo nepsaná obchodní pravidla. Tyto informace musí dodat prostředí úkolu.

Agent s vhodnými nástroji může informace získat. Chat bez přístupu repozitář prozkoumat nemůže. Když odpověď vypadá nesprávně, položte dvě otázky. Dokáže model tento problém vyřešit se správnými informacemi? Dostal je?

S prvním problémem může pomoci jiný model. Druhý problém může vyřešit dodání chybějícího pravidla nebo kontrola závislosti.

Vymezte kontext tohoto úkolu

Kontext jsou informace dostupné pro aktuální odpověď. Patří sem pokyny, dodané soubory, relevantní konverzace a výsledky nástrojů. Produkty tyto informace vybírají a uchovávají různými způsoby. Mohou také shrnout dřívější obsah.

Nepředpokládejte, že model čte každý soubor v nahrané složce. Nepředpokládejte, že pokyn ze začátku zůstává dostupný po celou dlouhou relaci. Požádejte nástroj, aby uvedl soubory a pokyny, které použil.

Více kontextu odpověď vždy nezlepší. Aktuální architektonické rozhodnutí může pomoci více než nesouvisející zdrojové soubory. Zastaralý návod k migraci může způsobit nesprávnou odpověď, protože působí důvěryhodně.

Představte si fiktivní funkci nastavení účtu. Dodejte cestu požadavku, autorizační middleware, příslušný datový model a existující test. Přidejte konkrétní omezení: „Člen může změnit své zobrazované jméno. Člen nemůže změnit svou roli v organizaci.“ Model nyní má výslovné pravidlo, které musí zachovat.

Prověřte tvrzení ve vysvětlení

Odpověď může tvrdit, že endpoint je bezpečný, protože middleware kontroluje vlastnictví. Ověřte každou část tohoto tvrzení.

1. Zkontrolujte, že endpoint používá uvedený middleware.
2. Zkontrolujte, že middleware ověřuje vlastnictví, nejen autentizaci.
3. Určete zdroj identity uživatele.
4. Proveďte negativní test jako jiný uživatel.

Odkaz do repozitáře ukazuje, kde hledat. Neprokazuje, že vysvětlení odpovídá kódu.

Stejný postup použijte pro doporučení API. Vygenerovaný kód může volat metodu, kterou nainstalovaný balíček neexportuje. Před výměnou závislostí zkontrolujte verzi balíčku a oficiální dokumentaci. Nepodložený předpoklad by jinak mohl způsobit zbytečnou migraci.

Proměňte nejistotu v konkrétní kontrolu

„Buď přesný“ není plán ověření. Určete předpoklad, potřebný důkaz a následky nesprávného výsledku.

Například: „U tohoto endpointu jsme neověřili izolaci tenantů. Prozkoumej obsluhu požadavku. Přidej test, ve kterém uživatel z jiného tenantu požaduje stejný záznam.“ Tento pokyn dává agentovi konkrétní úkol k prozkoumání a pozorovatelný výsledek.

U implementačních otázek zkoumejte skutečnou verzi systému. Dokument může popisovat zamýšlené chování. Kontrola kódu a testy pomáhají zjistit současné chování. Pokud se liší, rozdíl zaznamenejte, dokud jej odpovědná osoba nevyřeší. Nevybírejte si mlčky pohodlnější odpověď.

Vedoucí mohou tento postup používat, aniž čtou každou změnu kódu. Ptejte se, které předpoklady tým ověřil. Určete otevřené předpoklady a osoby za ně odpovědné. Tyto informace podpoří rozhodnutí o vydání přímočařeji než název modelu.