Modelli, contesto e risposte errate

Distingui le capacità dalle informazioni disponibili

Un modello linguistico usa schemi appresi e informazioni fornite durante un compito. I modelli moderni possono svolgere ragionamenti complessi e lavoro utile sul software. Possono anche produrre una risposta dettagliata basata su un’ipotesi errata.

«Modello frontier» descrive un livello di capacità che cambia nel tempo. Il termine non dimostra che il modello abbia letto il tuo repository. Non indica che conosca le versioni delle dipendenze o le regole aziendali non scritte. L’ambiente del compito deve fornire questi fatti.

Un agente con strumenti adeguati può recuperare informazioni. Una chat senza accesso non può esaminare il repository. Quando una risposta sembra errata, poni due domande. Il modello può risolvere il problema con le informazioni corrette? Ha ricevuto quelle informazioni?

Un modello diverso potrebbe aiutare con il primo problema. Una policy mancante o una verifica delle dipendenze può risolvere il secondo.

Definisci il contesto del compito

Il contesto è l’insieme delle informazioni disponibili per la risposta attuale. Comprende istruzioni, file forniti, conversazione pertinente e risultati degli strumenti. I prodotti selezionano e conservano queste informazioni in modi diversi. Possono anche riassumere contenuti precedenti.

Non presumere che un modello legga ogni file di una cartella caricata. Non presumere che un’istruzione iniziale resti disponibile durante un’intera sessione lunga. Chiedi allo strumento di indicare i file e le istruzioni usati.

Più contesto non migliora sempre una risposta. Una decisione architetturale attuale può essere più utile di file sorgente non pertinenti. Una guida di migrazione obsoleta può causare una risposta errata perché sembra autorevole.

Considera una funzionalità fittizia per le impostazioni dell’account. Fornisci la route, il middleware di autorizzazione, il modello dei dati pertinente e un test esistente. Aggiungi un vincolo specifico: «Un membro può modificare il proprio nome visualizzato. Un membro non può modificare il proprio ruolo nell’organizzazione». Il modello ha ora una regola esplicita da rispettare.

Verifica le affermazioni di una spiegazione

Una risposta potrebbe affermare che un endpoint è sicuro perché il middleware verifica la titolarità della risorsa. Verifica ogni parte di questa affermazione.

1. Controlla che l’endpoint usi il middleware indicato.
2. Controlla che il middleware verifichi la titolarità, non solo l’autenticazione.
3. Individua l’origine dell’identità utente.
4. Esegui un test negativo con un altro utente.

Un riferimento al repository indica dove cercare. Non dimostra che la spiegazione corrisponda al codice.

Usa lo stesso metodo per un consiglio sulle API. Il codice generato può chiamare un metodo che il pacchetto installato non esporta. Verifica versione del pacchetto e documentazione ufficiale prima di sostituire le dipendenze. Un’ipotesi senza riscontri può altrimenti causare una migrazione inutile.

Trasforma l’incertezza in una verifica

«Sii preciso» non è un piano di verifica. Individua l’ipotesi, le prove necessarie e le conseguenze di un risultato errato.

Per esempio: «Non abbiamo verificato l’isolamento dei tenant per questo endpoint. Esamina il gestore delle richieste. Aggiungi un test in cui un utente di un altro tenant richiede lo stesso record». L’istruzione assegna all’agente un’indagine precisa e un risultato osservabile.

Per le domande sull’implementazione, esamina la versione effettiva del sistema. Un documento può descrivere il comportamento previsto. L’esame del codice e i test aiutano a stabilire quello attuale. Se non coincidono, annota la differenza finché un responsabile la risolve. Non scegliere tacitamente la risposta più comoda.

I manager possono usare questo metodo senza leggere ogni modifica al codice. Chiedi quali ipotesi ha verificato il team. Individua quelle ancora aperte e i rispettivi responsabili. Queste informazioni aiutano una decisione di rilascio più direttamente del nome del modello.