Questa è la prima edizione di un report che intendiamo aggiornare ogni trimestre: cosa chiedono le persone agli agenti di coding altrui e cosa succede quando lo fanno. I dati provengono dalla beta privata di muti, coprono i trenta giorni fino al 6 settembre 2026 e sono contenuti. Cinquantotto richieste, sei macchine, dieci stanze. Li pubblichiamo comunque perché nessun altro sta pubblicando nulla sugli agenti condivisi, e numeri piccoli e onesti battono numeri grandi e inventati.
Tutte le cifre sono aggregate. Nessun testo delle richieste, nessun nome, nessun nome di stanza.
The numbers
Cinque cifre dei primi trenta giorni, con i relativi denominatori.
Cosa pensiamo significhino
Un terzo delle richieste da parte di non proprietari è un dato elevato per una beta senza attività di marketing. I proprietari hanno invitato delle persone e queste persone hanno usato l’agente. La condivisione è il prodotto stesso, ed è avvenuta in modo naturale.
Le approvazioni sono rapide quando sono rare. Nove approvazioni su cinquantotto richieste, con un tempo di risposta mediano di 38 secondi. È il comportamento per cui il design è stato pensato: le quattro azioni con pausa obbligatoria e le modalità di autorizzazione mantengono rari i prompt, così quelli che restano ricevono un’attenzione reale. Vedi le quattro azioni per cui un agente dovrebbe sempre chiedere prima di procedere.
Bash chiede. La maggior parte delle approvazioni riguardava comandi di shell. Le letture e le modifiche dei file sono state eseguite per lo più sotto acceptEdits; i momenti in cui è stato necessario l'intervento umano riguardavano i comandi. Questo riflette esattamente ciò per cui sono state progettate le modalità di autorizzazione.
I fallimenti sono per lo più errori di runtime, non di autorizzazione. Dieci richieste non sono andate a buon fine; nella timeline figurano come test falliti, tool mancanti e un timeout di runtime. Nessun fallimento è stato dovuto a un’approvazione negata.
Quarantuno secondi è il job mediano. Finora agli agenti condivisi vengono chieste cose piccole e specifiche: riesegui questo, riassumi quello, esporta questi file. I refactoring lunghi sono rari e avviati principalmente dai proprietari.
Cosa non significano questi numeri
- Non sono rappresentativi. Sei macchine, per lo più nostre e di amici. La quota di richieste da parte di non proprietari diminuirà con l'espandersi della base di proprietari, prima di risalire.
- Il completamento non equivale alla correttezza. “Done” significa che il runtime ha terminato l'esecuzione senza errori; se il risultato sia valido o meno non viene misurato qui.
- La latenza di approvazione dipende dal proprietario. Nove punti dati, diversi proprietari, un unico numero. Consideratelo come “meno di un minuto” piuttosto che come “38 secondi”.
Cosa aggiungeremo
Prossima edizione: categorie di richieste (codice / documenti / dati / file), percentuale di richieste con allegati e latenza di approvazione per ora del giorno. Tutto aggregato, tutto pubblicato con i relativi denominatori.
Metodologia
I dati provengono dalle stesse tabelle su cui si basa il prodotto: richieste, approvazioni di tool, iscrizioni alle stanze ed eventi della timeline, conteggiati su giorni UTC. Nessun campionamento. Le stanze e gli agenti eliminati in modalità soft-delete sono esclusi dai conteggi “attuali” e inclusi nei conteggi “storici”. Il modello di audit è descritto in cosa deve registrare un audit log.
Domande frequenti
Posso ottenere i dati grezzi? No. I dati aggregati sono gli unici che pubblichiamo; le richieste rimangono private all'interno delle rispettive stanze.
Perché pubblicare con n = 58? Perché l'alternativa è non pubblicare nulla, e perché indicare il denominatore consente a chi legge di soppesare il dato. La prossima edizione sarà più ampia, oppure spiegherà perché non lo è stata.
Con quale frequenza? Trimestrale, con le stesse metriche in modo da poterle confrontare, oltre alle novità annunciate nell'edizione precedente.
Se vuoi partecipare alla prossima edizione, crea una stanza per il tuo agente.
Pubblicato il