Le Agent Skills di Addyosmani sono tornate su GitHub Trending, ma il punto non sono i prompt

Le agent skills di Addyosmani hanno raggiunto il settimo posto in una hot list di GitHub Trending il 6 agosto, nonostante il progetto abbia già diversi mesi. Il repository raccoglie pratiche di sviluppo software in istruzioni che gli agenti di coding AI possono caricare quando pertinenti. La sua rinnovata visibilità segnala la domanda di qualcosa che ai modelli ancora manca: una disciplina ingegneristica affidabile.

La classifica proveniva da un aggregatore di terze parti e non conferma una nuova data di rilascio. Il progetto di base era già pubblico quando Osmani lo ha illustrato il 3 maggio 2026. Una versione ampliata è apparsa su O'Reilly il 27 maggio. A quel punto, aveva dichiarato che il repository aveva superato 27.000 stelle su GitHub.

Il repository del progetto mostrava circa 82.000 stelle, 8.800 fork e 391 commit quando è stato controllato il 6 agosto. Questi numeri possono cambiare. La competizione importante è più duratura: workflow riutilizzabili contro prompt ad hoc che dipendono dalla scelta del modello di applicare disciplina ogni volta.

Il progetto Addyosmani Agent è di nuovo in tendenza, non viene lanciato oggi

L'evento verificato è una rinnovata attenzione attorno a un progetto già consolidato, non il lancio di un prodotto appena annunciato.

La voce della hot list indicava addyosmani/agent-skills al settimo posto il 6 agosto. Non forniva un timestamp di pubblicazione affidabile né spiegava se la posizione riguardasse una finestra giornaliera, settimanale o regionale. Anche le posizioni su GitHub Trending cambiano quando i repository accumulano attività.

Questa incertezza conta perché un'apparizione tra le tendenze può sembrare una notizia dell'ultima ora senza rappresentare un rilascio recente. In questo caso, la cronologia di base indica altro. Osmani ha datato il suo originale saggio sulle agent skills al 3 maggio, quasi tre mesi prima della classifica osservata.

Il progetto aveva già attirato notevole attenzione in precedenza. Nella versione del 27 maggio del saggio di Osmani, scriveva che il repository aveva superato 27.000 stelle. La pagina GitHub del 6 agosto mostrava circa 82.000 stelle, anche se i contatori GitHub restano dati in tempo reale e non registri storici fissi.

Questa differenza suggerisce un'adozione, un bookmarking o una ridistribuzione continui. Non dimostra un utilizzo attivo in produzione. Le stelle misurano l'interesse espresso, mentre i fork indicano copie o sperimentazioni. Nessuno dei due numeri rivela se i team abbiano eseguito i workflow, li abbiano mantenuti installati o abbiano migliorato gli esiti del software.

Anche il repository è cambiato dal saggio di maggio. Osmani descriveva 20 skill e sette comandi slash nell'articolo precedente. Il repository di agosto documentava 24 skill e otto comandi che coprivano specifica, pianificazione, implementazione, test, revisione, prestazioni web, semplificazione e rilascio.

Questa espansione aiuta a spiegare perché un repository più vecchio possa tornare in una lista di tendenze. È diventato un pacchetto più ampio, ha aggiunto integrazioni e ha accumulato attenzione in diverse comunità di agenti di coding. L'attività sembra più una distribuzione continuativa che un singolo picco nel giorno del lancio.

Il repository è con licenza MIT e consiste principalmente di istruzioni Markdown, riferimenti di supporto, comandi, hook e personaggi agenti. Non è un modello AI, un motore di generazione del codice o una piattaforma di sviluppo ospitata. Gli utenti hanno comunque bisogno di un assistente di coding compatibile e devono decidere quali autorizzazioni riceve tale assistente.

Questa distinzione cambia la storia. Il progetto non compete con Claude Code, Codex, Cursor, Gemini CLI o GitHub Copilot in qualità di ulteriore agente di coding. Mira a fornire un livello di processo riutilizzabile che può essere integrato in molti di essi.

Il tempismo riflette anche un cambiamento più ampio nello sviluppo con agenti. I team stanno andando oltre la domanda su quale modello scriva la funzione migliore. Si chiedono sempre più se un agente possa mantenere il perimetro, raccogliere prove, gestire attività lunghe e produrre modifiche che gli esseri umani possano revisionare.

Il progetto agent di Addyosmani affronta direttamente queste domande operative. Il suo ritorno su GitHub mostra che gli sviluppatori cercano strutture di controllo attorno a modelli capaci, anche quando tali strutture sono scritte in semplice Markdown.

Perché le Agent Skills stanno sostituendo il prompt gigantesco

Le agent skills separano le procedure durature dal contesto permanente che ogni richiesta dovrebbe portarsi dietro.

Una skill è una directory costruita attorno a un file SKILL.md. Il file contiene metadati YAML e istruzioni Markdown. Script di supporto, riferimenti e asset possono risiedere accanto ad esso, secondo il formato delle skill aperto.

Il formato sembra semplice perché lo è. Una descrizione indica all'agente quando la skill si applica. Il corpo gli indica quale sequenza seguire. L'harness circostante decide quando caricare le istruzioni e a quali strumenti l'agente può accedere.

Questo design differisce dall'inserire ogni policy in un unico enorme prompt di sistema. Un prompt permanente consuma contesto durante lavori non correlati. Trasforma inoltre linee guida sui test, procedure di rilascio e regole di sicurezza in un unico blocco indifferenziato.

Le skill usano la divulgazione progressiva, il che significa che l'harness carica istruzioni dettagliate solo quando diventano pertinenti. Un'attività di test può attivare le relative linee guida. Una richiesta di deployment può attivare controlli di rilascio senza trascinare il materiale sul deployment in ogni conversazione precedente.

L'attuale documentazione sulle skill di Anthropic descrive lo stesso vantaggio di base. I corpi delle skill vengono caricati quando sono usati, mentre le istruzioni persistenti del progetto rimangono presenti per tutta la sessione. Claude Code può invocare alcune skill automaticamente e altre solo quando l'utente le richiede.

La libreria di Osmani applica questo meccanismo all'intero ciclo di vita convenzionale del software. Il repository attuale associa otto comandi ad attività come scrivere una specifica, suddividere il lavoro in piccole attività, realizzare incrementi, testare il comportamento, revisionare le modifiche e rilasciare in sicurezza.

Questa sequenza è il vero prodotto del repository. Le singole raccomandazioni sono familiari. Gli ingegneri sanno già che i test dovrebbero essere eseguiti, le ipotesi dovrebbero essere rese esplicite e i file non correlati dovrebbero restare intatti.

Il problema è l'esecuzione sotto pressione. Gli agenti di coding tendono a ottimizzare per il completamento visibile, soprattutto quando una richiesta enfatizza la velocità. Possono produrre il codice richiesto saltando prove, limiti di revisione o controlli operativi che l'utente non ha dichiarato esplicitamente.

Osmani definisce la sua risposta “processo prima della prosa”. Una skill utile dovrebbe prescrivere azioni e definire un criterio di uscita. Non dovrebbe limitarsi a fornire al modello un saggio sul comportamento ingegneristico desiderabile.

Si consideri lo sviluppo guidato dai test. Un documento di riferimento potrebbe elogiare i test e descriverne i vantaggi. Un workflow, invece, indirizza l'agente a creare un test fallente, osservare il fallimento, implementare la modifica più piccola, rieseguire il test e poi fare refactoring.

Questi passaggi creano punti di controllo osservabili. L'utente può esaminare il fallimento, l'esecuzione riuscita e il diff risultante. La skill sposta quindi parte del giudizio dal ragionamento interno del modello a prove disponibili al di fuori del modello.

La libreria estende questo modello con linee guida “anti-razionalizzazione”. Queste sezioni anticipano scuse comuni, come considerare un'attività troppo piccola per richiedere criteri di accettazione o promettere di aggiungere i test in seguito. Le istruzioni rispondono a tali scuse prima che l'agente le usi.

È una scelta progettuale insolita ma pratica. I modelli linguistici generano facilmente spiegazioni plausibili, comprese spiegazioni per saltare lavori scomodi. Una confutazione predefinita rende il limite desiderato più esplicito, anche se non può garantire l'obbedienza.

Per le organizzazioni, il richiamo è la coerenza. Un team può codificare una checklist di rilascio una sola volta, versionarla con la codebase ed esporla a diversi agenti. L'istruzione risultante diventa conoscenza organizzativa revisionabile anziché un prompt privato salvato da un singolo sviluppatore.

Crea inoltre una connessione naturale con una base di conoscenza ricercabile. I team hanno comunque bisogno delle decisioni progettuali, dei runbook e del contesto tecnico che spiegano perché esiste ciascun workflow. Le skill possono quindi trasformare conoscenze selezionate in azioni.

Il prompt gigantesco non sta scomparendo del tutto. Ogni harness necessita comunque di regole permanenti per confini, convenzioni del repository e sicurezza. La divisione emergente è più chiara: i file persistenti contengono fatti sempre applicabili, mentre le skill contengono procedure attivate da lavori specifici.

La competizione principale è tra workflow riutilizzabile e giudizio del modello

Il repository mette in discussione la convinzione che un modello migliore fornirà in modo affidabile un processo ingegneristico senza scaffolding esplicito.

I miglioramenti dei modelli restano importanti. Modelli più forti possono comprendere codebase più grandi, chiamare più strumenti e riprendersi da fallimenti difficili. Tuttavia, la capacità grezza non determina quali passaggi un agente scelga di eseguire.

Un modello può sapere come scrivere un documento di progettazione e comunque saltarlo. Può comprendere la revisione del codice producendo però una modifica troppo ampia perché un revisore possa valutarla. La conoscenza di una pratica è diversa dalla sua esecuzione coerente.

L'approccio agent di Addyosmani colloca un workflow riutilizzabile tra l'intento dell'utente e l'azione del modello. Il modello continua a ragionare sui dettagli dell'implementazione, ma la skill ne vincola il percorso. Definisce fasi, punti di controllo e condizioni di arresto che dovrebbero restare stabili tra le attività.

Questo approccio mette pressione ai fornitori che si affidano a un'orchestrazione proprietaria. Se i team possono esprimere comportamenti di valore in Markdown portabile, parte della differenziazione degli agenti si sposta dai prompt nascosti verso librerie di workflow trasparenti.

Il repository afferma che le sue skill funzionano con più di 70 agenti tramite un installer condiviso. Documenta inoltre configurazioni native o adattate per Claude Code, Cursor, Gemini CLI, Windsurf, OpenCode, GitHub Copilot, Kiro e Codex.

La compatibilità non equivale a un comportamento identico. Una piattaforma può selezionare automaticamente una skill dalla sua descrizione. Un'altra può richiedere all'utente di copiare le istruzioni in un file di regole. Una terza può supportare le skill ma interpretare diversamente metadati aggiuntivi.

La specifica aperta standardizza un nucleo essenziale. Richiede una directory con SKILL.md, oltre a front matter contenente un nome e una descrizione. Script, riferimenti, asset, note di compatibilità e dichiarazioni sugli strumenti consentiti sono facoltativi.

Questo piccolo denominatore comune è al tempo stesso un vantaggio e un limite. Rende le skill facili da creare e ispezionare. Non può standardizzare il modo in cui ogni agente instrada le richieste, gestisce il contesto, richiede approvazioni, esegue strumenti o dimostra il completamento.

Il repository di Osmani aggira queste differenze con directory specifiche per piattaforma e documenti di configurazione. Claude Code riceve un pacchetto plugin. Gemini CLI ottiene indicazioni per l'installazione nativa. Gli utenti di Copilot adattano il contenuto di personaggi e skill ai file di istruzioni del repository.

Si tratta di portabilità tramite traduzione, non di perfetta equivalenza di runtime. L'intento del workflow può viaggiare, ma la sua forza di applicazione dipende dall'harness di destinazione. Un controllo di sicurezza trattato come obbligatorio su una piattaforma può diventare testo consultivo su un'altra.

Il problema diventa più evidente quando un workflow invoca strumenti esterni. Un'istruzione Markdown può dire a un agente di eseguire i test o ispezionare il comportamento del browser. Non può creare un ambiente di test, concedere l'accesso al browser o assicurare che le credenziali siano isolate.

I team devono quindi valutare l’intero harness: modello, strumenti, autorizzazioni, hook, regole del workspace e traccia di audit. Una skill ben scritta migliora uno strato. Non sostituisce gli altri.

Questa distinzione separa inoltre le skill dall’automazione deterministica. Una regola di integrazione continua può bloccare un merge quando i test falliscono. Una skill può dire a un agente di non procedere, ma il modello o l’harness potrebbero comunque continuare, a meno che un controllo separato non imponga l’arresto.

L’architettura più solida combina entrambi. Le skill guidano il giudizio flessibile dove gli script rigidi farebbero fatica. Hook, sistemi di autorizzazione, branch protetti e controlli CI impongono confini dove la conformità non può restare facoltativa.

Questo modello ibrido mette sotto pressione la scuola di pensiero del “basta migliorare il prompt”. La progettazione dei prompt resta importante, ma il lavoro di produzione ripetibile richiede procedure versionate e controlli verificabili dalle macchine. Il repository di tendenza offre un modello visibile per realizzare questa transizione.

Cosa impongono effettivamente le Agent Skills di Addyosmani

La libreria trasforma le abitudini dell’ingegneria senior in lavoro sequenziale, ma ogni sequenza resta un’istruzione anziché un’autorità indipendente.

L’attuale raccolta copre l’intero percorso da una richiesta poco chiara a un rilascio in produzione. Le sue skill di specifica chiedono agli agenti di esplicitare le assunzioni, chiarire gli obiettivi e definire i criteri di accettazione prima dell’inizio dell’implementazione.

La guida alla pianificazione suddivide poi la specifica in attività piccole e verificabili. Questa struttura limita la quantità di modifiche prodotte prima dell’arrivo dei feedback. Offre inoltre ai revisori un rapporto più chiaro tra un requisito e il codice destinato a soddisfarlo.

Le skill di implementazione privilegiano sottili slice verticali, impostazioni predefinite sicure, feature flag e modifiche favorevoli al rollback. L’obiettivo non è semplicemente avere file più piccoli. È ridurre la distanza tra una modifica e le prove che gli utenti possono osservare.

Il workflow di test utilizza le fasi red, green e refactor. Per prima cosa, l’agente scrive un test che fallisce per il motivo previsto. Implementa quindi il comportamento minimo necessario al successo, prima di migliorare il design senza cambiare il risultato.

La revisione del codice amplia le prove oltre una suite di test verde. I test possono confermare i casi attesi, pur non rilevando confini di sicurezza, interfacce poco chiare, complessità eccessiva o un ambito involontario. Il workflow di revisione chiede all’agente di esaminare separatamente queste dimensioni.

Il repository include inoltre materiale specializzato per progettazione API, lavoro frontend, sicurezza, prestazioni, debugging, sviluppo basato sulle fonti, gestione del contesto, deprecazione e migrazione. Una meta-skill indirizza le richieste alla procedura pertinente.

Il suo comando di rilascio coordina i controlli finali anziché trattare il deployment come una singola azione. Ciò riflette l’argomentazione più ampia di Osmani: il percorso più rapido di un agente verso il “fatto” spesso esclude il lavoro operativo che rende affidabile il completamento.

Molte pratiche attingono alla guida pubblica di Google sull’ingegneria. Il repository rimanda a concetti quali modifiche piccole, test leggibili, evoluzione attenta delle API, validazione precoce e comprensione del codice esistente prima di rimuoverlo.

Non si tratta di principi ingegneristici nuovi. Il loro valore deriva dalla confezione e dalla tempistica. Un agente vede una procedura mirata nel momento in cui prende la decisione, anziché affidarsi a un modello che richiami il materiale generale dell’addestramento al momento giusto.

Una correzione concreta di un bug mostra la differenza. Senza una guida al workflow, un agente potrebbe individuare la funzione sospetta, modificarla, eseguire un test ristretto e segnalare il successo. La patch può sembrare convincente pur lasciando inspiegato il guasto originale.

Con una skill di debugging, l’agente dovrebbe riprodurre il problema, raccogliere prove, formulare ipotesi concorrenti, testarle, identificare la causa, aggiungere un test di regressione, implementare la correzione e verificare il comportamento visibile all’utente. Ogni passaggio riduce lo spazio per una patch attraente ma errata.

Una richiesta di funzionalità crea un’altra prova. Il workflow di specifica dovrebbe costringere l’incertezza a emergere prima delle modifiche al codice. Se due requisiti sono in conflitto, l’agente dovrebbe fermarsi per chiedere chiarimenti anziché scegliere silenziosamente l’interpretazione più semplice.

Questo comportamento di arresto conta più di un codice generato in modo eloquente. Un agente capace che pone una domanda necessaria può essere più sicuro di un modello più forte che realizza con sicurezza la funzionalità sbagliata.

Tuttavia, i file di istruzioni non possono dimostrare che questi miglioramenti avvengano. La popolarità del repository dimostra interesse nel modello. Non fornisce prove controllate che tutte e 24 le skill riducano difetti, tempi di revisione o tassi di incidenti tra agenti e repository diversi.

L’articolo di Osmani di maggio presenta ragionamenti progettuali ed esperienza, non un ampio benchmark comparativo. Il suo successivo saggio sul workflow ingegneristico spiega perché esistono questi passaggi e come riflettano pratiche software consolidate.

Queste prove sono utili ma circoscritte. I team che adottano la libreria dovrebbero definire le proprie metriche, inclusi difetti sfuggiti, modifiche annullate, latenza di revisione, variazioni della copertura dei test, costi degli strumenti e frequenza di arresti non necessari degli agenti.

Dovrebbero inoltre ispezionare ogni skill prima dell’installazione. I file di istruzioni possono richiedere comandi, influenzare l’uso degli strumenti e importare materiale di supporto nel contesto del modello. Trattare un repository popolare come una policy eseguibile affidabile ripeterebbe la stessa scorciatoia che il progetto cerca di prevenire.

Portabilità e verifica restano i problemi più difficili

La maggiore incertezza è se un’istruzione portabile produca un comportamento equivalente e applicabile tra diversi harness per agenti.

Il progetto presenta un argomento convincente a favore di workflow riutilizzabili. Presenta un caso più debole per un’esecuzione uniforme. Ogni piattaforma controlla in modo diverso la scoperta delle skill, l’assemblaggio del contesto, le autorizzazioni dei comandi e la gestione degli errori.

Il routing automatico è una fonte di variabilità. La descrizione di una skill aiuta un agente a decidere quando attivarla. Le descrizioni possono sovrapporsi e le richieste degli utenti spesso coprono più fasi. L’harness può caricare troppe procedure, scegliere quella sbagliata o non rilevare una skill pertinente.

I limiti di contesto introducono un altro compromesso. La divulgazione progressiva riduce il peso permanente del prompt, ma le skill attivate consumano comunque attenzione. Una funzionalità complessa potrebbe richiedere diversi workflow, riferimenti di supporto, istruzioni del repository, codice, log e output degli strumenti in un’unica sessione.

Più contesto non è automaticamente meglio. I vincoli pertinenti possono competere con i dettagli dell’implementazione. Procedure lunghe possono inoltre incoraggiare il completamento superficiale di checklist quando l’agente non ha spazio sufficiente per ragionare attentamente sul codice.

La portabilità aggiunge deriva semantica. Un repository può copiare lo stesso Markdown in Claude Code, Cursor, Gemini CLI e Copilot. Ogni modello e harness può interpretare parole come “deve”, “verifica” o “fermati” con affidabilità diversa.

Anche la disponibilità degli strumenti cambia ulteriormente il risultato. Un workflow di verifica del browser non può ispezionare un’interfaccia in esecuzione senza accesso al browser. Una revisione della sicurezza non può convalidare il risultato di una dipendenza se l’accesso alla rete è disabilitato e il database locale è obsoleto.

Le autorizzazioni determinano il tetto di rischio. Un agente con shell senza restrizioni, credenziali di produzione e accesso al deployment può causare danni nonostante istruzioni di processo eccellenti. Un agente con autorizzazioni ristrette rimane vincolato anche quando fraintende una skill.

Per questo le skill dovrebbero integrare i controlli deterministici. La protezione dei branch può richiedere revisioni. La CI può bloccare test falliti. Le sandbox possono limitare l’accesso a file e rete. I gate di approvazione possono interrompere i deployment finché un umano non autorizza l’azione esatta.

Il rischio della supply chain merita uguale attenzione. Un repository di skill è una configurazione adiacente al codice che plasma il comportamento privilegiato del modello. Gli aggiornamenti possono modificare istruzioni, script, hook e file referenziati senza alterare il modello sottostante.

I team dovrebbero fissare versioni revisionate, ispezionare le differenze e limitare gli aggiornamenti automatici. Dovrebbero verificare i file referenziati e gli script inclusi anziché revisionare soltanto il SKILL.md di primo livello. Un file di ingresso conciso può delegare altrove comportamenti rilevanti.

Il repository stesso riconosce una lacuna di portabilità per le installazioni individuali. Il suo README avverte che l’installazione di una sola skill può omettere directory di riferimento condivise, lasciando indisponibili checklist supplementari. L’installazione dell’intero repository o la copia dei riferimenti necessari evita quel problema specifico.

Questo avvertimento illustra la sfida più ampia. Una skill può sembrare installata pur mancando di parte del proprio contesto operativo. L’agente può comunque funzionare, rendendo il degrado silenzioso più difficile da notare rispetto a una dipendenza convenzionale mancante.

La valutazione è l’ultima lacuna. I team hanno bisogno di attività con risultati attesi noti, non solo impressioni soggettive. Dovrebbero confrontare lo stesso agente con e senza una skill, quindi esaminare correttezza, modifiche non necessarie, chiamate agli strumenti, durata e consumo di token.

L’adozione dovrebbe iniziare da un problema circoscritto. Un team che soffre di patch troppo ampie potrebbe testare le skill di disciplina dell’ambito e revisione. Un altro con regressioni ricorrenti potrebbe valutare il workflow di test rispetto a bug storici.

Il risultato dovrebbe determinare se il workflow entra nella policy condivisa. La popolarità può giustificare un’ispezione, ma non può sostituire una prova locale. La lezione più forte del progetto è la verifica, e tale lezione dovrebbe applicarsi al progetto stesso.

Tre segnali mostreranno se le Agent Skills diventeranno infrastruttura

La prossima fase dipende da risultati misurabili, conformità multipiattaforma e applicazione esterna al ragionamento del modello stesso.

Il primo segnale è una valutazione comparativa credibile. Bisogna osservare se maintainer o team indipendenti pubblicheranno test ripetibili su repository reali. Le valutazioni utili dovrebbero misurare tassi di difetto, violazioni dell’ambito, qualità della revisione, costi e tempi di completamento.

Un risultato favorevole mostrerebbe che skill selezionate migliorano gli esiti in più attività senza imporre ritardi o uso di token eccessivi. Risultati deboli o incoerenti suggerirebbero che il successo dipende più dal modello, dal repository o dal valutatore che dal testo del workflow.

Il secondo segnale è una conformità più forte tra le piattaforme per agenti. La specifica comune definisce attualmente struttura dei file e metadati, mentre i runtime mantengono una libertà sostanziale sull’attivazione e l’esecuzione.

I progressi includerebbero test condivisi per scoperta, caricamento dei file di supporto, restrizioni degli strumenti e comportamento in caso di errore. Se la stessa skill produce tracce comparabili in Claude Code, Codex, Gemini CLI, Cursor e Copilot, la portabilità diventa più della semplice compatibilità dei file.

Estensioni divergenti indebolirebbero questa promessa. I fornitori possono supportare lo stesso nucleo SKILL.md aggiungendo però campi di routing, semantiche di autorizzazione e sistemi di packaging incompatibili. I team finirebbero quindi per mantenere più versioni di un unico workflow.

Il terzo segnale è l’integrazione con policy deterministiche. Le skill diventano infrastruttura quando i loro checkpoint si collegano a sistemi in grado di verificare o bloccare le azioni. Esempi includono prove CI obbligatorie, approvazioni firmate, policy sandbox e record di completamento leggibili dalle macchine.

Questa integrazione preserverebbe la flessibilità senza chiedere a un modello di controllare sé stesso. La skill potrebbe decidere quale percorso di verifica si adatta al compito, mentre controlli esterni confermano che esistono le prove richieste prima del merge o del deployment.

Il progetto di agenti Addyosmani indica già questa architettura a strati attraverso hook, comandi, personas e workflow incentrati sulla verifica. La sua prossima sfida è dimostrare che questi strati funzionano insieme in modo affidabile al di fuori di esempi preparati con cura.

Per gli sviluppatori, l’azione immediata è l’ispezione, non l’adozione indiscriminata. Leggete i workflow più vicini ai vostri guasti ricorrenti. Confrontate i loro checkpoint con i controlli ingegneristici già esistenti. Poi testatene uno su un lavoro rappresentativo con autorizzazioni limitate.

Per i responsabili dell'ingegneria, il progetto offre uno spunto per censire il giudizio non documentato. Quali abitudini di revisione esistono solo nella mente degli ingegneri senior? Quali controlli di rilascio dipendono dalla memoria? Quali eccezioni si trasformano ripetutamente in incidenti?

Trasformate uno di questi processi in un flusso di lavoro breve e verificabile. Affiancatelo a un controllo esterno nei casi in cui un fallimento conta davvero. Misurate se l'agente lo segue e se la modifica risultante diventa più facile da considerare affidabile.

La rinnovata attenzione verso le agent skills di addyosmani non dimostra che Markdown possa rendere senior un programmatore AI. Mostra che gli sviluppatori non accettano più la generazione di codice come l'intero lavoro. La domanda successiva è se flussi di lavoro portabili possano produrre prove abbastanza solide da consentire ai team di farvi affidamento.