# saboo-loop-engineering-product-managers-2026-06-21

## Veille

Saggio lungo di **Shubham Saboo** (X/Twitter) che sostiene una tesi sul ruolo del Product Manager nell'era degli agenti: la prossima competenza chiave **non è il prompt engineering** ma il **Loop Engineering** — progettare un *sistema che migliora a ogni esecuzione* anziché scrivere il prompt perfetto ogni volta. Un **loop** è un ciclo ripetuto: modificare ciò che modella il comportamento dell'agente → eseguirlo → valutare l'output → mantenere la modifica se la qualità aumenta, altrimenti annullarla → **capitalizzare l'apprendimento** in modo che la versione successiva parta avvantaggiata. Per un PM, il punto d'ingresso non è il codice ma gli **artefatti durevoli** che codificano il suo giudizio: skill di PRD-review, *summarizer* di chiamate con i clienti, griglia di valutazione, checklist di lancio, workflow di ricerca, `CLAUDE.md`, template di prompt, framework di prioritizzazione. Poiché vengono riutilizzati, questi artefatti **si accumulano in entrambe le direzioni** — e **degradano** silenziosamente (un CLAUDE.md che continua a crescere, una checklist ignorata…): il modello non è peggiorato, sono gli artefatti a essere degradati senza sorveglianza. Un loop ha **5 componenti**: trigger, azione, **prova**, memoria, **condizione di arresto** (la più critica). Gli **eval** diventano lavoro del PM (testare l'artefatto su esempi noti: 3 PRD buoni / 3 cattivi, 5 chiamate comprese, 2 lanci passati). La **memoria** risiede su **GitHub** (il repository diventa "memoria di prodotto": commit, diff, risultati degli eval, registro delle decisioni, rollback). Primo loop consigliato: un **loop settimanale di segnale di prodotto** (ogni venerdì). Il gusto/istinto resta centrale — ma ora richiede una **prova**. Cita Boris (creatore di Claude Code): "non scrive più prompt, scrive loop".

## Titre Article

Loop Engineering for Product Managers

## Date

2026-06-21

## URL

https://x.com/Saboo_Shubham_/status/2068730090457006588

## Keywords

Loop Engineering, product management, PM aumentato, prompt engineering, artefatti riutilizzabili, degrado degli artefatti, drift, accumulo, condizione di arresto, loop agentico, eval, griglia di valutazione, PRD review, summarizer di chiamate con i clienti, checklist di lancio, CLAUDE.md, memoria di prodotto, GitHub, versionamento, loop settimanale di segnale di prodotto, verifica, giudizio, gusto, Boris Cherny, Claude Code

## Authors

Shubham Saboo (@Saboo_Shubham_)

## Ton

Profilo: saggio d'opinione lungo pubblicato come thread X/Twitter, prospettiva di un praticante-evangelista di prodotti AI che si rivolge direttamente ai colleghi PM ("tu"), registro didattico e prescrittivo in inglese, livello tecnico medio (vocabolario ingegneristico reso accessibile ai non sviluppatori), pubblico target di product manager, product lead e professionisti delle operazioni di prodotto che già lavorano con agenti. Il tono è quello di un **manifesto pedagogico**: una tesi-slogan ("la prossima competenza del PM non è il prompt engineering, è il Loop Engineering"), una salita controllata nell'astrazione (da un problema concreto — il degrado — verso il framework in 5 componenti), e un'enfasi sull'**operatività** ("il tuo primo loop", "lo scheletro di ogni loop"). L'autorevolezza si fonda sull'esperienza sul campo (esempi di PRD, chiamate con i clienti, lanci) e su convalide esterne (Boris, creatore di Claude Code; la *Loop Library* di Matthew Berman). La retorica procede per **opposizioni binarie** (fare prompting una volta vs. un loop che migliora a ogni esecuzione; generazione risolta vs. verifica/giudizio ancora da fare; un artefatto che si accumula vs. uno che decade) e formule memorabili ("un loop che sa dire stop è un loop che puoi lasciare in esecuzione"). Metafora implicita: l'artefatto come organismo vivente che, se lasciato incustodito, **marcisce** — e il loop come sistema immunitario che lo mantiene sano. Posizione finale equilibrata: "costruisci il loop, ma resta il PM".

## Pense-betes

- **Tesi centrale**: la prossima competenza del PM non è il **prompt engineering** ma il **Loop Engineering** — *"progettare un sistema che migliora ogni volta che viene eseguito"*, non scrivere il prompt perfetto ogni volta.
- **Definizione di loop**: un ciclo ripetuto — modificare ciò che modella l'agente → eseguirlo → valutare → mantenere se la qualità aumenta / annullare altrimenti → **capitalizzare l'apprendimento** in modo che la versione successiva parta avvantaggiata.
- **Il punto d'ingresso del PM = gli artefatti** (non il codice): skill di **PRD-review**, **summarizer di chiamate con i clienti**, **griglia di valutazione**, **checklist di lancio**, **workflow di ricerca**, **`CLAUDE.md`**, template di prompt, framework di prioritizzazione. Sono **durevoli, riutilizzati e codificano il giudizio**; modellano l'agente attraverso decine di esecuzioni.
- **Accumulo bidirezionale**: un buon artefatto affina il lavoro ogni settimana; uno cattivo lo rallenta, silenziosamente. *"Un prompt usa e getta puoi permetterti di sbagliarlo. Una griglia da cui dipendono dieci persone, no."*
- **Il problema che il prompting non risolve — IL DEGRADO (DRIFT)**: il CLAUDE.md continua a crescere, la skill di review si irrigidisce, la checklist si gonfia fino a essere per metà ignorata, i criteri di valutazione cambiano senza che nessuno sappia quando/perché. Un mese dopo l'agente "sembra peggiore": *"probabilmente il modello non è peggiorato. I tuoi artefatti sono degradati, e nessuno li sorvegliava."*
- **Anatomia di un loop — 5 componenti**: (1) **trigger** (quando inizia), (2) **azione** (cosa fa l'agente), (3) **prova** (come sai che è migliore), (4) **memoria** (dove viene salvato l'apprendimento), (5) **condizione di arresto** (quando si ferma).
- **La condizione di arresto è la più critica** (soprattutto per i loop ricorsivi): molti sistemi falliscono non perché il modello è scadente, ma perché il loop **non ha un'uscita pulita** (scope creep, lavoro inventato, un riassunto sicuro di sé ma senza prova). Un buon loop di PM deve poter dire: niente è cambiato / l'input è troppo esiguo / è bloccato / la soglia di qualità non è raggiunta / serve una decisione umana. *"Un loop che sa dire stop è un loop che puoi lasciare in esecuzione."*
- **Gli eval diventano lavoro del PM**: non un benchmark gigantesco — si parte da **esempi noti**. Es. 3 PRD forti / 3 deboli → l'artefatto coglie le lacune reali senza essere pignolo, preservando l'intento?; 5 chiamate già comprese → coglie il dolore reale, cita accuratamente, distingue il segnale forte dal rumore?; 2 lanci passati (1 riuscito, 1 fallito) → avrebbe individuato cosa si è rotto? Domanda: *"questo artefatto è migliorato rispetto a un giudizio di prodotto noto?"* (non "l'agente sembra intelligente?").
- **Livello di memoria = GitHub**: non per trasformare i PM in ingegneri, ma per la **cronologia delle versioni** degli artefatti. Contiene l'artefatto, le modifiche, i risultati degli eval, il registro delle decisioni, il percorso di rollback. *"Il repository diventa memoria di prodotto."*
- **Primo loop consigliato — loop settimanale di segnale di prodotto**: non partire dalla strategia (troppo ampia/soggettiva) ma dalle **operazioni di prodotto**. Ogni venerdì: leggere chiamate con i clienti, ticket di supporto, note vendite, aggiornamenti sperimenti, riepiloghi analytics, modifiche rilasciate, escalation aperte → produrre **un memo di segnale di prodotto** che separa il **segnale ricorrente** dal **rumore isolato**, cita testualmente il cliente, mostra cosa è cambiato, segnala le evidenze deboli e indica quali ipotesi di roadmap si sono rafforzate/indebolite.
- **Il gusto/istinto resta centrale ma richiede PROVA**: quando il giudizio viene messo in artefatti riutilizzabili, bisogna dimostrare che una modifica migliora davvero le cose (altrimenti aggiunge solo rumore o "cerimonia").
- **Confine umano**: un loop può riassumere le evidenze, rivedere un PRD, segnalare un lancio rischioso — **non deve** decidere la strategia da solo, diventare il leader di prodotto, o arbitrare senza contesto. *"Costruisci il loop, ma resta il PM."* Aumentare l'autonomia **lentamente**, dopo aver guadagnato fiducia.
- **Citazioni e riferimenti**: Boris (creatore di Claude Code) *"non fa più prompting, scrive loop che fanno prompting al posto suo"*; *"La generazione è risolta… restano solo la verifica e il giudizio"*; **Loop Library** di **Matthew Berman** (loop reali di ingegneria/ricerca/operazioni).
- **Collegamenti forti**: converge direttamente con il **Compound Engineering** ("ogni unità di lavoro rende più facile la successiva", accumulo di artefatti) e la fase Compound dell'**SDLC**; fa eco a **Stack Overflow for Agents** (capitalizzare/verificare invece di rigenerare) e a Monperrus / alla dottrina *verifica > generazione*. `CLAUDE.md` come artefatto vivo e versionato si ricollega alla dottrina del **Context Engineering**.

## RésuméDe400mots

In questo saggio lungo pubblicato su X, **Shubham Saboo** sostiene che la prossima competenza decisiva per il Product Manager nell'era degli agenti non è il **prompt engineering** ma il **Loop Engineering**. Lo stato finale non è un PM che scrive il prompt perfetto ogni volta che ha bisogno di qualcosa, ma un PM che **progetta un sistema che migliora a ogni esecuzione**. Un loop è un ciclo ripetuto: modificare ciò che modella il comportamento dell'agente, eseguirlo, valutare l'output, mantenere la modifica se la qualità migliora e annullarla altrimenti, quindi **capitalizzare l'apprendimento** in modo che la versione successiva parta avvantaggiata.

Per un ingegnere, questo ciclo parte dal codice. Per un PM, parte dagli **artefatti** che strutturano il lavoro di prodotto: skill di PRD-review, *summarizer* di chiamate con i clienti, griglia di valutazione, checklist di lancio, workflow di ricerca, `CLAUDE.md`, template di prompt, framework di prioritizzazione. Durevoli e riutilizzati, codificano il giudizio e modellano l'agente attraverso decine di esecuzioni — quindi **si accumulano in entrambe le direzioni**. È qui che emerge il vero problema: il **degrado (drift)**. Il CLAUDE.md continua a crescere, la checklist si gonfia, i criteri di valutazione cambiano senza lasciare traccia; un mese dopo l'agente "sembra peggiore". Il modello non è peggiorato: sono gli artefatti a essere degradati senza sorveglianza, ed è esattamente questo che il Loop Engineering corregge.

Un loop utile ha **cinque componenti**: trigger, azione, **prova**, memoria, **condizione di arresto**. Quest'ultima è la più critica: molti sistemi falliscono per mancanza di un'uscita pulita (scope creep, un riassunto sicuro di sé ma senza prova). Un buon loop deve poter dire "stop" — nulla è cambiato, l'input è troppo esiguo, è bloccato, la soglia di qualità non è raggiunta, serve una decisione umana.

Mettere il proprio giudizio in artefatti riutilizzabili richiede che il **gusto/istinto** sia ora accompagnato da una **prova**: gli **eval** diventano lavoro del PM, costruiti a partire da esempi noti (3 PRD buoni / 3 cattivi, 5 chiamate comprese, 2 lanci passati). La domanda non è più "l'agente sembra intelligente?" ma "questo artefatto è migliorato rispetto a un giudizio di prodotto noto?". L'apprendimento richiede una **memoria**: **GitHub**, dove risiedono l'artefatto, i diff, i risultati degli eval, il registro delle decisioni e il percorso di rollback — *"il repository diventa memoria di prodotto"*.

Saboo consiglia di iniziare in piccolo, con le **operazioni di prodotto**: un **loop settimanale di segnale di prodotto** (ogni venerdì) che produce un memo separando il segnale ricorrente dal rumore isolato. Il loop alimenta una decisione che il PM **mantiene**: *"costruisci il loop, ma resta il PM"*. La generazione è risolta; restano la verifica e il giudizio.

## GrapheDeConnaissance

- Shubham Saboo —publie→ Loop Engineering for Product Managers (DOCUMENT, 0.97)
- Shubham Saboo —recommande→ le Loop Engineering comme prochaine compétence clé des PM (AFFIRMATION, 0.95)
- Loop Engineering —remplace→ prompt engineering (METHODOLOGIE, 0.85)
- Loop Engineering —utilise→ artefacts réutilisables (revue de PRD, summarizer, rubrique d'éval, checklist) (CONCEPT, 0.92)
- Loop Engineering —résout→ dérive des artefacts (artifact drift) (CONCEPT, 0.9)
- Loop Engineering —utilise→ condition d'arrêt (stop condition) (CONCEPT, 0.9)
- Loop Engineering —s_applique_à→ product management (ops produit) (CONCEPT, 0.9)
- évaluations (evals) —permet→ preuve qu'un artefact s'améliore face à un jugement produit connu (CONCEPT, 0.88)
- GitHub —permet→ mémoire produit (version history des artefacts) (CONCEPT, 0.88)
- weekly product signal loop —est_instance_de→ Loop Engineering (METHODOLOGIE, 0.85)
- Loop Engineering —converge_avec→ Compound Engineering (METHODOLOGIE, 0.82)
- Boris Cherny —a_créé→ Claude Code (TECHNOLOGIE, 0.95)
- Boris Cherny —affirme_que→ il n'écrit plus de prompts mais des boucles qui prompt pour lui (CITATION, 0.88)
- Shubham Saboo —affirme_que→ la génération est résolue ; vérification et jugement sont tout ce qui reste (CITATION, 0.9)
- Matthew Berman —a_créé→ Loop Library (DOCUMENT, 0.85)

---
Canonical: https://www.thekb.eu/it/fiches/saboo-loop-engineering-product-managers-2026-06-21/