Il prossimo Product Manager potrebbe essere un QA

In breve. Quando a costruire sono gli agenti, scrivere le specifiche diventa economico e il mestiere scarso si sposta: decidere cosa significa "fatto", e scriverlo in un modo che una macchina sa verificare. Eval, criteri di accettazione, gate di rilascio — il mestiere del QA, con il contesto di business del PM. Tre casi datati dai miei sistemi in cui a decidere è stato il QA, e cosa resta al PM che QA non è.

Quando costruire costa quasi zero, "fatto" è il lavoro

Il PM classico scriveva PRD: pagine di prosa che descrivevano cosa costruire, e la qualità del documento decideva la qualità del prodotto. Poi gli agenti hanno iniziato a costruire da soli, e la prosa ha smesso di essere il collo di bottiglia: descrivere un risultato costa poco, ottenerlo costa poco. Quello che costa — e decide — è dire con precisione quando il risultato è accettabile.

Nei miei sistemi questa frase ha una forma concreta: ogni cura nasce con criteri di accettazione numerati (AC-1, AC-2...), ognuno con la sua asserzione, firmati e con un verdetto di copertura. Non è un documento che accompagna il lavoro: è il lavoro, perché il verdetto finale lo emette un comando che li riesegue sul codice davvero rilasciato. Chi scrive quei criteri non sta facendo il QA "dopo": sta facendo il PM "prima", con gli strumenti del QA.

Ogni cura nasce con il suo esame

Nella factory che ripara software da sola, nessuna cura parte senza dire come verrà giudicata, e nessun giudizio arriva da chi ha scritto la cura. Il comando di verdetto è sempre lo stesso — npm run verify su una checkout pulita, dopo npm ci — e gira fuori dalla sessione di chi ha costruito, sulla testa effettivamente rilasciata. L'ho descritto come meccanismo nella guida su come verificare il lavoro di un agente AI: qui mi interessa il ruolo.

Perché quel comando è, a tutti gli effetti, la job description del PM che verrà: non "visione e roadmap", ma "l'esame che il lavoro deve superare". Quando ho dovuto decidere cosa significasse "verificare un agente", non ho scritto un paragrafo: ho scritto i controlli — tre casi datati, FACT e INTERPRETATION separati, link al corpus — e l'articolo esiste perché ha superato il suo esame. La specifica che non è un test è un auspicio.

Chi costruisce non corregge i compiti

La seconda mossa è la separazione: nel registro della factory il verdetto emesso da chi ha scritto la cura viene rifiutato dal diario con codice EXECUTOR_CANNOT_SELF_CERTIFY, e il caso è blindato da un golden test, GC-027, che fallisce se qualcuno prova a farlo passare. Non è sfiducia: è la stessa separazione tra chi esegue e chi giudica che ho raccontato quando il verifier bocciava i test verdi — il verde dichiarato in locale valeva solo se riprodotto nell'ambiente di chi verifica.

Il caso più grande l'ha fatto un revisore esterno: il 9 ottobre 2026 una review indipendente ha riletto 51 elementi pubblicati contro 173 criteri, con citazioni file:riga verificate da uno script del revisore, fuori dalla factory. 153 criteri soddisfatti, 20 diventati follow-up. Il punto che mi interessa non è il punteggio: è che il controllo che contava lo faceva chi non aveva costruito niente. Quella è QA che decide il rilascio, con un altro nome.

Gli articoli che portano il loro QA

La stessa mossa, in piccolo, gira ogni giorno sul sito che state leggendo: molti articoli della factory viaggiano con il loro script di controllo, decine di check che verificano tesi, fatti datati, link e appartenenza ai cluster. Quando pubblico un pezzo, non chiedo a nessuno "ti sembra buono": eseguo il suo esame. Il contenuto ha i suoi eval come il codice ha i suoi test.

È il rovesciamento completo del vecchio flusso, dove il QA arrivava alla fine a cercare i buchi nelle specifiche altrui. Qui il QA arriva all'inizio e scrive lui le specifiche — sotto forma di criteri eseguibili — e la fine è solo l'esecuzione. L'autonomia nasce progettando il controllo, non eliminandolo: e progettare il controllo è scrivere l'esame prima del compito.

Cosa resta al PM che non è QA

La tesi ha un limite onesto, ed è nel titolo: "potrebbe". Il QA decide se il lavoro è fatto, ma non decide quale lavoro vale la pena di fare: visione, priorità, scoperta del cliente restano mestiere da PM, e nessun eval li genera. Quello che cambia è la proporzione: man mano che costruire costa meno, la fetta di mestiere che è giudizio di accettazione cresce, e il PM che non sa scrivere un criterio verificabile diventa il collo di bottiglia del suo stesso team di agenti.

Non sto dicendo che i PM spariscono. Sto dicendo che il prossimo si riconoscerà da cosa scrive per primo al mattino: non la roadmap, l'esame.

Fatti e limiti

FACT. Nella factory ogni cura dichiara criteri di accettazione numerati (AC-1...) con asserzioni e verdetto di copertura; il verdetto lo emette npm run verify su checkout pulita dopo npm ci, fuori dalla sessione del costruttore.

FACT. Il diario rifiuta il verdetto auto-emesso con EXECUTOR_CANNOT_SELF_CERTIFY; il golden test GC-027 fallisce se una verification senza provenance indipendente prova a passare.

FACT. Il 9 ottobre 2026 una review indipendente rilegge 51 elementi contro 173 criteri con citazioni file:riga: 153 soddisfatti, 20 follow-up; il controllo meccanico lo fa uno script del revisore, esterno alla factory.

FACT. Molti articoli della factory viaggiano con il loro script di controllo in scripts/check-*.mjs, eseguito prima della pubblicazione.

INTERPRETATION. Chiamo questo spostamento "il PM diventa QA" perché il mestiere scarso è diventato scrivere l'accettazione eseguibile, non la specifica in prosa.

INTERPRETATION. Non ho misurato questa tesi fuori dai miei sistemi: vale come episodio con provenance, e il "potrebbe" del titolo è la parte più seria dell'articolo.

Limiti: tre meccanismi dai miei sistemi, non un mercato del lavoro. Le cifre (51 elementi, 173 criteri, 153/20) sono rilette nelle fonti approvate al momento della scrittura. Dove le fonti tacciono, taccio anch'io.

Domande frequenti

Il QA sostituirà il Product Manager?

No, e l'articolo dice "potrebbe" apposta. Il QA decide se il lavoro è fatto; quale lavoro valga la pena resta giudizio da PM — visione, priorità, cliente. Quello che cambia è dove il PM passa le ore: sempre meno a descrivere, sempre più a definire l'accettazione in forma eseguibile.

Cosa deve saper fare un PM per scrivere buoni criteri?

Le stesse tre cose di un buon QA: scomporre "fatto" in asserzioni controllabili una per una, separare i fatti dalle interpretazioni, e far eseguire il verdetto a mani diverse dalle sue. Se un criterio non si può rieseguire, non è un criterio: è un auspicio con un ID.

Da dove comincio se il mio team non ha nessun eval?

Da un esame per il prossimo lavoro, non da una suite per tutto il passato. Un criterio numerato, un comando che lo verifica, un verdetto fuori dalla sessione di chi costruisce. Poi il secondo. Gli eval si accumulano come i test: uno alla volta, partendo da quello che duole di più.