Stai facendo girare piu agenti IA di programmazione sullo stesso repository. Forse tre, forse tredici. Devono gestire il proprio lavoro: creare issue, aggiornare stati, verificare dipendenze, riportare progressi. Decine di scritture al minuto su tutta la flotta.
Questo e l'agentic engineering: umani che coordinano flotte di agenti IA per produrre software. Il workflow e nuovo, ma la prima cosa che tutti fanno e affidarsi allo strumento che gia conoscono. Jira. Linear. GitHub Issues. Notion. Qualunque cosa il tuo team usi per la gestione dei progetti.
Non funziona. E l'incompatibilita non e superficiale. E architetturale.
La latenza uccide il throughput
Una chiamata all'API di Jira richiede 200-800ms. Una chiamata all'API di Linear e piu veloce ma resta tra 100 e 300ms. Creare un singolo issue, leggere le sue dipendenze, aggiornare il suo stato: sono tre round-trip attraverso HTTPS, risoluzione DNS, handshake TLS e serializzazione JSON. Diciamo 500ms in una buona giornata.
Una scrittura locale via CLI su un database SQLite richiede meno di 50ms. Spesso meno di 10ms.
Sembra un errore di arrotondamento finche non lo moltiplichi per il numero di operazioni. Un agente che lavora su un task potrebbe creare 2-3 sotto-issue, aggiornare lo stato del padre, verificare i blocchi e commentare il suo progresso. Sei operazioni. A 500ms ciascuna, sono 3 secondi di pura attesa. A 10ms ciascuna, sono 60 millisecondi. L'agente che potrebbe completare un ciclo di task in 30 secondi ora spende il 10% del suo tempo ad aspettare risposte HTTP invece di scrivere codice.
Scala questo a 13 agenti e l'overhead si misura in minuti per ora.
L'infrastruttura di autenticazione e colla fragile
Ogni agente ha bisogno di un token API. I token scadono. I rate limit esistono. Un agente lancia una raffica di 20 aggiornamenti rapidi e riceve un 429 Too Many Requests. Ora e bloccato in un loop di retry con backoff esponenziale invece di fare il suo lavoro.
Hai appena aggiunto un'intera modalita di fallimento che non ha niente a che fare con il lavoro stesso. Rotazione dei token, gestione dei segreti, distribuzione dei rate limit tra agenti. Questo e overhead operativo per una capacita che dovrebbe essere banale: scrivere un record in un database locale.
Quando l'issue tracker e un file su disco, non c'e nulla contro cui autenticarsi. Se l'agente puo leggere il filesystem, puo leggere e scrivere issue. Una cosa in meno che puo rompersi.
Il modello dati presuppone umani
Apri Jira. Vedi sprint. Story point. Assegnatari con foto profilo e indirizzi email. Workflow con stati come "In revisione" e "Pronto per il refinement". L'intero modello dati e stato progettato per un team di umani che fanno standup, pianificazione degli sprint e retrospettive.
Gli agenti non fanno standup. Non stimano in story point. Non hanno bisogno di un workflow con sette stati e quattro gate di approvazione.
Quello di cui gli agenti hanno bisogno e un grafo delle dipendenze. Questo task e bloccato da quello. Questo epic ha 12 figli e 7 sono completati. Questo agente ha rivendicato questo issue 45 secondi fa e non ha ancora riportato. La struttura dati fondamentale e un albero di task con relazioni di blocco, non una board di schede che si spostano tra colonne.
Gli strumenti SaaS aggiungono funzionalita di "automazione", ma il modello centrale sotto resta un quadro Kanban per umani. Puoi scrivere un plugin Jira che permette agli agenti di creare issue. Non puoi cambiare il fatto che Jira pensa che il tuo agente sia una persona in un team di sprint.
La dipendenza dal cloud e un single point of failure
I tuoi agenti girano in locale. Leggono file locali, scrivono codice locale e fanno commit su repo git locali. Possono lavorare offline, su un aereo o su una rete con 2000ms di latenza. Non gli interessa.
Ma se il tuo issue tracker e un prodotto SaaS, ogni operazione dell'agente richiede accesso a internet. Linear va giu per 10 minuti? L'intera flotta si ferma. La tua connessione internet di casa salta per 30 secondi? Ogni agente riprova in loop. L'issue tracker, la cosa che dovrebbe coordinare il lavoro, diventa il single point of failure dell'intero sistema.
Local-first significa che l'issue tracker e affidabile quanto il filesystem. Sempre disponibile, sempre veloce, sempre sotto il tuo controllo.
Il volume di scritture e sbagliato di ordini di grandezza
Gli strumenti SaaS di project management sono progettati per un team di 5-10 umani che fanno una manciata di aggiornamenti al giorno. Forse 50-100 scritture in tutto il team.
13 agenti che aggiornano issue ogni pochi minuti producono centinaia di chiamate API all'ora da un singolo progetto. Non e un aumento marginale nell'utilizzo. E un pattern di utilizzo completamente diverso. I rate limit che sembrano generosi per team umani diventano muri invalicabili per flotte di agenti.
E non e solo volume. E concorrenza. Tre agenti che aggiornano i figli dello stesso epic simultaneamente. Race condition sui campi di stato. Fallimenti di locking ottimistico sui thread di commenti. Questi sono problemi che gli strumenti SaaS non hanno mai dovuto risolvere perche gli umani non aggiornano lo stesso issue da tre terminali nello stesso istante.
Collaborare significa cedere i tuoi dati
Per condividere un progetto Jira con un collega, entrambi avete bisogno di account Jira. I dati risiedono sui server di Atlassian. Stai pagando per postazione, al mese, per il privilegio di accedere ai tuoi stessi dati di progetto attraverso la loro API.
Vuoi migrare a un altro strumento? Esporta quello che puoi come CSV e abbandona il resto. Commenti, allegati, campi personalizzati, cronologia di audit: buona fortuna a estrarre tutto in un formato utilizzabile. Il modello SaaS scambia la proprieta dei dati con la comodita.
Ma la collaborazione non richiede un intermediario. Se il tuo database di issue e supportato da qualcosa come Dolt (Git per database), lo fai push su un remote e il tuo collega fa pull. Crea branch nel tuo database di issue nello stesso modo in cui crei branch nel codice. Fai merge nello stesso modo. Risolvi conflitti con gli stessi strumenti e lo stesso modello mentale. I tuoi dati restano tuoi. La collaborazione funziona come git, non come un abbonamento.
Cosa funziona davvero
Metti da parte i nomi dei brand e pensa a cosa gli agenti hanno realmente bisogno da un issue tracker:
- Local-first. Nessuna dipendenza dalla rete. Il database e un file su disco.
- Nativo CLI. Gli agenti vivono nel terminale. L'interfaccia dovrebbe farlo anche lei.
- Basato su Git. Versionato, unificabile, auditabile. Nessun vendor lock-in.
- Nessun overhead di autenticazione. Se l'agente puo leggere il filesystem, puo gestire issue.
- Bassa latenza. Sotto i 50ms per operazione, non 500ms.
- Sincronizzabile senza intermediari. Push e pull come un repo git, non attraverso webhook API.
Questo e quello che uso quotidianamente. beads e un issue tracker nativo Git costruito esattamente per questo workflow. Memorizza tutto in un database locale SQLite supportato da Dolt per il versionamento e la sincronizzazione. Il CLI e l'interfaccia principale. Gli agenti creano, aggiornano e interrogano issue nello stesso modo in cui eseguono qualsiasi altro comando.
Beadbox e il livello visuale che ho costruito sopra. Osserva il database locale per i cambiamenti e renderizza alberi delle dipendenze, progresso degli epic e attivita degli agenti in tempo reale. Gli agenti usano il CLI. Io uso il dashboard. Entrambi leggono dallo stesso database locale.
I vecchi strumenti non sono il problema
Jira e eccellente in quello che fa: coordinare team umani attraverso workflow strutturati. Linear e bellissimo per team piccoli che vogliono velocita e cura dei dettagli. GitHub Issues e perfetto per la collaborazione open-source.
Nessuno di loro e cattivo. Stanno risolvendo un problema diverso. Se il tuo workflow e un team di cinque umani che fanno sprint di due settimane, continua a usarli.
Ma se stai facendo girare 5, 10 o 13 agenti IA che si coordinano in tempo reale sullo stesso repository, hai superato il modello SaaS. L'agentic engineering ha bisogno di strumenti costruiti per l'agentic engineering, non workflow umani con un'API aggiunta sopra.