Cosa può costruire oggi un manager senza team

In breve. Dal 4 all'11 ottobre 2026, su questo sito: 114 merge su main (106 da branch della factory), 61 nuovi articoli datati, 25 pagine di strumenti. Autori: un account solo, il mio, più i loop che ci girano sopra. Dieci anni fa lo stesso perimetro chiedeva un team — redazione, sviluppo, QA — e settimane di coordinamento: è una stima professionale, non una misura, e la dichiaro come tale. Quello che è misurato è il perimetro, e sta tutto qui sotto.

Il perimetro, misurato

I numeri vengono da due comandi, entrambi rieseguibili: il log dei merge su main e la metrica del pack che conta gli articoli per data. Finestra 4-11 ottobre 2026, sito danielepelleri.com, perimetro intero:

• 114 merge su main, di cui 106 da branch factory/* — il resto è lavoro owner separato a mano;
• 61 nuovi articoli con data negli ultimi 7 giorni, contati dalla metrica ufficiale del pack;
• 25 pagine di strumenti interattivi, 145 post totali all'11 ottobre;
• autori dei merge: 113 volte il mio account, una volta l'account di servizio della factory.

Per dare la scala del ritmo: la PR #1 è del 3 ottobre, la #117 dell'11. In totale fanno 124 merge in otto giorni, quasi tutti un problema piccolo e chiuso. Non è velocità di scrittura: è velocità di chiusura. Il loop non scrive più in fretta di un umano — chiude più in fretta, perché ogni giro finisce con un verdetto invece che con una bozza.

Cosa ci voleva qui dentro, dieci anni fa

Qui smetto di misurare e comincio a stimare, e lo dico in chiaro: il confronto col team di dieci anni fa è giudizio professionale, non conteggio. Ma è un giudizio che so motivare voce per voce.

Il ritmo è di 61 articoli in sette giorni, 8 al giorno: nessuna redazione sotto le cinque-sei persone li scrive, li revisiona e li pubblica con FAQ, link interni e controlli SEO — e nessuna li accompagna ognuno col suo test di regressione, come fa qui la fabbrica che ripara il software mentre dormiamo. I 25 calcolatori e simulatori interattivi, ognuno con pagina, FAQ e dati strutturati, valgono settimane di uno sviluppatore frontend più un QA. E 114 merge verificati in sette giorni vogliono un processo di release che, dieci anni fa, si chiamava con nomi come "release manager" e "change advisory board".

Somma onesta: redazione piccola, uno sviluppatore, un QA part-time, e un coordinamento che mangia un terzo del tempo di tutti. Quello che il loop ha sostituito non sono le persone: è il coordinamento. Esecuzione e verifica girano da sole; a me restano le decisioni e l'accettazione, che è la divisione che descrivo nell'AI-native management.

Perché adesso basta uno

Il motivo non è che gli agenti sono bravi. È che il lavoro è disegnato per essere chiudibile senza riunioni: un problema alla volta, criteri scritti prima, verdetto emesso fuori dalla sessione di chi costruisce. Ogni giro del loop è un'unità di lavoro completa — diagnosi, cura, verifica, deploy — che non aspetta nessuno e non blocca nessuno. Per 114 volte in sette giorni.

Il manager, in questo disegno, fa tre cose che gli agenti non fanno: sceglie quale problema vale la pena (la priorità resta giudizio), scrive cosa significa "fatto" (l'accettazione resta responsabilità), e cambia il disegno quando è sbagliato. Tutto il resto — scrivere, verificare, pubblicare, notificare — è esecuzione, e l'esecuzione scala senza organigramma. Chi vuole i dettagli del meccanismo li trova nell'azienda che lavora mentre dormi: qui mi fermo al perimetro, che è la notizia.

Cosa non ho misurato

Tre limiti, dichiarati prima che me li chiediate. Primo: ho misurato l'output, non l'esito — quanti pezzi sono usciti, non quanto traffico portano o quanto vendono. Il verdetto SEO arriva tra mesi, non tra giorni. Secondo: non ho misurato il costo di run — token, revisioni, i miei interventi da supervisore — quindi non so dirvi il costo pieno per articolo, solo che il perimetro umano è uno. Terzo: la settimana misurata è la migliore, non la media: il loop era maturo e io ero disponibile a decidere in fretta. Una settimana normale produce meno; una senza decisioni produce quasi niente, perché senza "fatto" scritto nessuno chiude.

Fatti e limiti

FACT. Dal 4 all'11 ottobre 2026: 114 merge su main (106 da branch factory/*), 61 articoli datati negli ultimi 7 giorni, 25 pagine strumenti, 145 post totali; autori 113 volte Daniele Pelleri, una volta Content Factory.

FACT. La PR #1 è del 3 ottobre 2026, la #117 dell'11 ottobre: 124 merge totali in otto giorni, quasi tutti un problema piccolo e chiuso.

FACT. La metrica ufficiale del pack conta i nuovi articoli dalla data degli articoli su main negli ultimi 7 giorni: valore 61 all'11 ottobre 2026.

INTERPRETATION. Stimo che lo stesso perimetro, dieci anni fa, volesse redazione piccola, uno sviluppatore, un QA part-time e coordinamento: è giudizio professionale motivato voce per voce, non misura.

INTERPRETATION. Attribuisco la differenza al disegno chiudibile del lavoro (un problema, criteri prima, verdetto esterno), non alla bravura dei modelli.

Limiti: misuro output in una settimana, non esiti, non costi pieni, non medie. Le cifre sono rilette da log git e metrica del pack al momento della scrittura. Dove le fonti tacciono, taccio anch'io.

Domande frequenti

Quindi un manager da solo sostituisce un team?

No: sostituisce il coordinamento di un team su lavoro chiudibile. Restano al manager priorità, accettazione e disegno — e resta fuori dal perimetro tutto ciò che non si può scrivere come criterio verificabile. Un team serve ancora dove il lavoro è ambiguo; qui non lo era più.

I 61 articoli sono di qualità o riempitivo?

Ognuno viaggia con controlli: tesi, fatti datati con fonti, FAQ, link interni, cluster, SEO tecnica verificata in build. Se è riempitivo, è riempitivo che supera gli esami — e gli esami sono pubblici, nel repository. Il giudizio sulla qualità di lettura resta al lettore, come sempre.

Posso replicarlo nella mia azienda?

Il meccanismo sì, i numeri non necessariamente: questo perimetro viene da anni di corpus, strumenti e loop già costruiti. Comincia da un perimetro piccolo e misurabile — un tipo di output, un verdetto meccanico — e allarga solo quando la settimana misurata batte la precedente. Misura prima di scalare.