Uno dei clienti di Anthropic ha ricevuto 2.740 candidature per un singolo ruolo in 24 ore.
Nessun prompt scritto a mano rimane corretto così a lungo.
Il recruiter che legge quei CV inizia con un prompt che dice «cinque anni di backend, esperienza in startup, buona conoscenza di Python».
Due giorni dopo, guarda il primo lotto e si rende conto che in realtà cerca persone che costruiscono da zero.
Il prompt è già sbagliato, e non hanno ancora letto il secondo centinaio.
I team che spediscono più velocemente hanno smesso di scrivere i prompt in quel modo.
Hanno costruito sistemi in cui il prompt osserva ciò che l'utente decide effettivamente e si riscrive in background.
Nel momento in cui l'utente si accorge che le sue preferenze sono cambiate, il prompt è già cambiato con loro.
Funziona ovunque un essere umano faccia valutazioni e il modello aiuti.
Recruiting, smistamento assistenza, moderazione dei contenuti, revisione del codice, scoring delle trattative.
Ecco come costruirne uno, passo dopo passo.
Un prompt non è una configurazione, è un apprendista
Il cambio di mentalità deve venire per primo.
Una configurazione è qualcosa che imposti e dimentichi.
Un apprendista ti osserva mentre lavori, coglie ciò a cui tieni veramente e si adatta.
Il tuo prompt dovrebbe essere il secondo.
Nel sistema che Nick Mayhew ha mostrato sul palco ad Anthropic, l'apprendista è un semplice file Markdown.
Lo chiamano il profilo ideale del candidato.
Niente pesi, niente regole, niente diagrammi di flusso. Solo inglese semplice che descrive chi il recruiter sta assumendo.
Ogni volta che il recruiter approva o respinge un candidato, il sistema lo registra.
Ogni commento del tipo «questo non ha abbastanza Python» viene salvato.
Anche ogni modifica manuale al profilo viene salvata.
Quel mucchio di decisioni è il segnale di addestramento su cui si aggiorna il prompt.
Perché 100 decisioni, non una sola
Il primo istinto è aggiornare il prompt dopo ogni azione. Non farlo.
Una decisione è rumore. Un singolo rifiuto non ti dice quasi nulla su ciò che l'utente vuole veramente. Potrebbe essere una qualsiasi di queste:
- L'utente era stanco o distratto
- L'input era strano in un modo non correlato alle sue reali preferenze
- Ha cliccato per sbaglio
- Ha agito velocemente su un caso ovvio
- Stava testando il sistema apposta
Se riscrivi il prompt su quella base, inizi a inseguire fantasmi.
100 decisioni sono un segnale.
Puoi vedere uno schema: l'utente continua a respingere candidati senza esperienza in startup.
Non è un umore, è una preferenza. Ora aggiorni.
Nick è stato diretto su questo sul palco.
Inizi a individuare schemi ogni 100-200 decisioni, non a ogni click.
Anche il lato dei costi conta.
Eseguire un modello intelligente su ogni azione brucia il budget già a pranzo.
Eseguirlo su lotti mantiene il sistema vivo in produzione.
Dividi il sistema in due livelli, non un unico grande agente
La tentazione è creare un unico grande agente che valuta, impara e aggiorna tutto insieme.
Non scala e brucia token che non hai.
Lo schema funzionante è due livelli con compiti molto diversi.
Il livello inferiore è il valutatore. Economico, veloce, eseguito su ogni input.
Nel caso del recruiting, è Haiku che valuta ogni CV rispetto al profilo corrente.
Migliaia al giorno. Compito ristretto: prendere l'input, prendere il prompt corrente, restituire un giudizio strutturato.
Il livello superiore è l'apprendista. Più lento, più intelligente, eseguito raramente.
Osserva solo le decisioni che gli umani prendono.
A ogni lotto, si fa una domanda: il prompt corrisponde ancora a ciò che l'utente sta effettivamente scegliendo?
Se no, lo riscrive.
La maggior parte dei team salta questa suddivisione.
Mettono un modello all'avanguardia nel percorso critico su ogni richiesta, la bolletta esplode, il sistema viene accantonato.
Separare la valutazione dall'apprendimento è ciò che lo mantiene vivo in produzione.
Scrivi il prompt in prosa, non in regole
È qui che la maggior parte dei sistemi auto-miglioranti muore silenziosamente.
L'istinto è scrivere una configurazione: 30% di peso sugli anni di esperienza, 20 sul livello dell'azienda, 10 sull'istruzione, flag per parole chiave.
Sembra rigoroso. Produce un sistema che il modello non può effettivamente aggiornare, perché non c'è niente da aggiornare se non numeri.
E i numeri non catturano il motivo per cui un recruiter ha detto no.
Il formato funzionante è l'inglese semplice in Markdown.
«Cerchiamo qualcuno che abbia lanciato un prodotto da zero a uno, idealmente in una startup con meno di cinquanta persone.»
«Una cultura ingegneristica solida conta più di uno stack tecnologico specifico.»
«Bandiera rossa: aver lavorato solo in aziende con più di mille persone.»
Questo è un prompt che l'apprendista può effettivamente riscrivere.
Può aggiungere una frase, rimuoverne una, stringere un'espressione.
Non puoi farlo con una griglia di punteggi pesata.
Il ciclo di feedback è il prodotto stesso
Una volta che questi quattro pezzi sono a posto, il sistema funziona da solo.
L'utente prende decisioni. Il valutatore assegna un punteggio in base al prompt corrente.
Ogni 100 decisioni, l'apprendista legge il mucchio e riscrive il prompt.
Il lotto successivo di input viene valutato rispetto alla nuova versione.
L'utente non deve mai pensare al prompt.
Continua a prendere le decisioni che solo un umano può prendere.
Il prompt si aggiorna sotto di loro.
Questa è la parte che la maggior parte dei team perde quando spedisce un sistema Claude.
Trattano il prompt come un prodotto finito che completano.
I team che spediscono di più lo trattano come un livello che impara sempre.
Costruiscilo in questo modo dal primo giorno e smetterai di passare le settimane a ottimizzare le parole.
Le spenderai per spedire il prodotto.
Seguimi e iscriviti al mio canale Telegram:
