Vai al contenuto

Cerimonia Proporzionata al Rischio

Principio operativo per l'uso dei coding agent secondo cui il livello di cerimonia metodologica deve corrispondere alla posta in gioco (ceremony should match the stakes), evitando di applicare indiscriminatamente interi pack di skill a ogni progetto e potando regolarmente il contesto dell'agente. 1

La scala di effort: abbinare il processo alla posta in gioco

Di fronte alla proliferazione di repository di skill (vedi Pack di Skill a Confronto), usare l'intero arsenale su ogni singola modifica costituisce un enorme overkill: per cambiare il colore di un bottone non servono un PRD, una scomposizione in task atomici, una review in arena su cinque assi di Pstack o un security auditor. 1 Rob Shocks articola una scala di effort in cinque livelli: 1

  1. Ritocco piccolo (small tweak): eseguirlo direttamente e verificare il risultato di persona. 1
  2. Prototipo o modifica visiva (visual / prototype-based): farlo direttamente iterando rapidamente con l'agente, controllare a vista, fare refresh e procedere oltre. 1
  3. Feature piccola (small feature): una sessione rapida di grill-me (vedi AI Skills e Grill-Me) o di discovery per allinearsi sui requisiti, seguita da test-driven development (TDD). 1
  4. Feature grande o fumosa (big or fuzzy feature): redigere una specifica (spec) e un piano (plan) suddivisi in fasi distinte, verificando ciascuna fase nel mezzo prima di passare alla successiva. 1
  5. Produzione, sicurezza o azioni irreversibili: dispiegare il processo completo con review strutturata, doubt-driven development (vedi Lifecycle delle Skill di Osmani) e tutte le verifiche di security hardening. 1

Potare agents.md e il costo delle skill in eccesso

Man mano che i modelli diventano più capaci, le skill servono sempre meno a insegnare all'agente nozioni che non possiede e sempre più a esprimere "questo è il modo in cui mi piace lavorare". 1 Di conseguenza, una delle azioni ad alto impatto consiste nel passare in rassegna il proprio file agents.md e le skill installate per sfoltirli e potarli (prune): 1

  • Gonfiaggio della finestra di contesto: file di skill troppo lunghi e un numero eccessivo di skill installate gonfiano e confondono la context window dell'agente. 1
  • Rischio di auto-attivazione indesiderata: ogni skill installata rappresenta un'opzione che l'agente deve prendere in considerazione a ogni turno, col rischio concreto di auto-innescare (auto-trigger) per errore skill pesanti quando non sono richieste. 1
  • Più skill non significa un agente più intelligente: lo stesso Addy Osmani, nella guida di adozione del proprio pack, raccomanda un rollout graduale verification-first su un codebase esistente, sconsigliando categoricamente di installare tutte le 25 skill in blocco pretendendo di attivarle insieme fin dal primo giorno. 1

Le skill come buone pratiche codificate e manuali O'Reilly

La lezione più profonda che emerge dallo studio dei pack di skill è che imparare queste skill equivale a imparare le buone pratiche fondamentali dello sviluppo software: 1

  • Test-driven development (TDD) e implementazione per piccole vertical slices. 1
  • Accordarsi sui requisiti prima di costruire e mettere per iscritto il perché di una decisione architetturale. 1
  • Rispettare lo steccato di Chesterton (non cancellare nulla finché non si sa specificamente perché si trova lì). 1
  • Dimostrare che il software funziona contro il sistema reale, perché vedere i test verdi non basta a provare che l'applicazione funzioni davvero. 1

Nessuno dei creatori dei pack ha inventato questi concetti: Matt Pocock attinge a The Pragmatic Programmer e Domain-Driven Design, Osmani codifica la cultura ingegneristica di Google, e Lauren Tan condensa anni di esperienza su React e in Meta; le skill non sono altro che quelle idee classiche riformulate in un formato che un agente può eseguire. 1

Per questo i pack non vanno mai vissuti come una religione, ma trattati come un manuale O'Reilly: si installano, si leggono per studiare come ragionano i top performer, si ruba ciò che funziona e si costruiscono sopra le proprie skill, dando forma al proprio harness su misura da condividere col team. 1 E ogni volta che l'agente commette un errore, invece di imprecare contro il modello, si interviene da "giardinieri" del processo (vedi Programmazione Strategica, Osservabilità e Ruolo del Giardiniere) aggiornando la skill in base a ciò che si è appena imparato — esattamente il modo in cui sono nati tutti e tre i grandi pack. 1

Vedi anche: Pack di Skill a Confronto, Programmazione Strategica, Osservabilità e Ruolo del Giardiniere, Harness Engineering, Lifecycle delle Skill di Osmani, AI Skills e Grill-Me

Fonti e Riferimenti

  1. Fonte: Pocock vs Pstack vs Osmani: Which Skill Pack Wins? (Rob Shocks - Switch Dimension) ↗ ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩