La maggior parte delle conversazioni sullo sviluppo software autonomo inizia con agenti che scrivono codice. Un agente prende in carico un ticket, implementa una funzionalità, apre una pull request. La demo funziona. Le persone si entusiasmano.
Prima che qualsiasi consegna autonoma possa funzionare in modo affidabile, qualcuno deve progettare il sistema ingegneristico all'interno del quale l'autonomia opererà. La struttura del repository, le scelte tecnologiche, i confini architetturali, la direzione del design, le convenzioni ingegneristiche, i meccanismi di validazione, i ruoli specialistici, i confini di approvazione. Niente di tutto ciò dovrebbe emergere da una collezione di agenti indipendenti che procedono a tentativi in parallelo.
Il mio approccio parte da una diversa divisione delle responsabilità. Gli umani progettano il sistema ingegneristico. Agenti specializzati eseguono il lavoro. Loop asincroni orchestrano quando quel lavoro viene svolto e cosa succede dopo.
L'obiettivo non è rimuovere gli umani dallo sviluppo software. È concentrare il coinvolgimento umano sulle decisioni che richiedono giudizio, contesto e comprensione del prodotto, costruendo al contempo un ambiente in cui gran parte dell'esecuzione possa proseguire in autonomia.
Questi sono i sei passaggi che seguo ogni volta che avvio un progetto destinato a funzionare eventualmente senza che io lo stia guardando.
Passaggio 1: l'umano progetta il sistema ingegneristico
Quando inizio un progetto, non chiedo a un agente autonomo di inventare le sue fondamenta.
Decido prima le parti importanti: come organizzare il repository, quali tecnologie usare, come funzionano i principali confini architetturali, qual è la direzione del design, quali convenzioni ingegneristiche devono essere rispettate e dove l'autonomia deve fermarsi. Queste decisioni diventano il fondamento di tutto ciò che verrà dopo.
Poi uso opencode-onboard per codificarle nel repository.
/make-engineer crea gli ingegneri AI specializzati di cui il progetto ha bisogno. Frontend, backend, infrastruttura, test, sicurezza, dati, mobile, qualsiasi cosa il prodotto richieda. Non sono agenti generici con etichette diverse. Ognuno ha una specializzazione definita, un insieme di capacità e un posto chiaro nel flusso di lavoro ingegneristico.
/make-architecture cattura la struttura tecnica e i confini in ARCHITECTURE.md. /make-design cattura il linguaggio visivo, i token di design e gli schemi dei componenti in DESIGN.md. /make-guardrails converte tutte quelle decisioni in regole concrete che ogni agente deve rispettare. Confini architetturali, convenzioni di denominazione, aspettative di test, stile del codice, vincoli di sicurezza, pratiche Git. Smettano di essere conoscenze possedute solo dal developer originale e diventano parte dell'ambiente operativo.
Il repository finisce per contenere più della semplice documentazione. Contiene un'organizzazione ingegneristica codificata e una fonte di verità condivisa per ogni agente che lavorerà al suo interno.
L'umano definisce il sistema per primo. Solo allora l'esecuzione autonoma diventa utile.
Passaggio 2: la base interattiva viene prima dell'autonomia
Una volta definito il sistema ingegneristico, costruisco la base iniziale del progetto in modo interattivo.
Normalmente uso /plan-quick e /plan-apply a questo punto. /plan-quick analizza un obiettivo mirato e lo trasforma in una sequenza concreta e ordinata di compiti. È intenzionalmente più leggero di un flusso di lavoro di specifica completo. Lo uso quando il lavoro è chiaro e voglio muovermi rapidamente senza perdere visibilità o controllo. /plan-apply implementa quei compiti e verifica il risultato.
È così che stabilisco l'infrastruttura di base del progetto. Struttura del repository, scheletro dell'applicazione, setup del database, fondamenta dell'autenticazione, sistema di design, infrastruttura di test, configurazione CI/CD, fondamenta del deployment.
Le prime fasi di un progetto contengono decisioni che influenzano tutto ciò che viene costruito dopo. Un'astrazione debole, una struttura di cartelle incoerente, una strategia di test poco chiara. Ognuna di queste può essere riprodotta centinaia di volte una volta che gli agenti autonomi iniziano a lavorare. L'ho visto accadere. Non è carino.
Per questo motivo, questa fase rimane veloce e assistita dall'AI, ma supervisionata.
Lo scopo non è massimizzare l'autonomia il prima possibile. Lo scopo è rendere il progetto sufficientemente stabile, comprensibile e prevedibile affinché l'autonomia possa successivamente operare in sicurezza al suo interno.
Passaggio 3: il coinvolgimento umano diventa una politica di progetto
Dopo aver preparato le fondamenta, decido quanta autonomia dovrebbe avere il sistema di consegna.
Non si tratta di una scelta binaria tra sviluppo manuale e automazione completa. Il coinvolgimento umano può esistere in diversi punti del ciclo di vita, e la configurazione giusta dipende dal progetto.
Un progetto completamente supervisionato potrebbe richiedere che un umano rifinisca il ticket, approvi il piano di implementazione, riveda la pull request, approvi il merge e autorizzi il deployment.
Un progetto parzialmente autonomo potrebbe permettere all'AI di rifinire e implementare, mentre gli umani rispondono a domande irrisolte, rivedono pull request importanti o mantengono il controllo sul merge finale.
Un progetto altamente autonomo potrebbe permettere al sistema di rifinire, implementare, rivedere e unire le modifiche automaticamente quando i guardrail, i test e i controlli di qualità richiesti sono superati.
Un nuovo prodotto con requisiti instabili ha bisogno di più partecipazione umana rispetto a uno strumento interno maturo. Un sistema regolamentato richiede porte di approvazione esplicite che sarebbero inutili per un piccolo esperimento. E lo stesso progetto può diventare più autonomo nel tempo man mano che la sua architettura, i test e i meccanismi di consegna maturano.
Il punto importante è che l'autonomia è definita intenzionalmente. Perfezionamento dei ticket, risoluzione delle domande, approvazione del piano, revisione della pull request, approvazione del merge, approvazione del deployment. Non sono interruzioni accidentali. Sono porte configurabili nel sistema ingegneristico.
Ogni progetto sceglie un diverso livello di autonomia, e quei confini si evolvono con esso.
Passaggio 4: le idee diventano elementi del backlog durevoli
La console interattiva è ancora il posto dove esploro le idee.
Quando un'idea è incompleta, uso /plan-explore. Non è un comando di implementazione. È un processo di esplorazione collaborativa. L'agente esamina il repository, mappa i componenti rilevanti, identifica i pattern esistenti, sfida le assunzioni, traccia le dipendenze, considera i rischi e aiuta a determinare cosa dovrebbe effettivamente essere costruito.
Molti problemi di sviluppo inizialmente sembrano compiti di codifica, ma sono in realtà problemi di comprensione. Inviare un'idea poco chiara direttamente in un flusso di lavoro di implementazione autonomo produce di solito un'implementazione poco chiara. L'esplorazione dà all'idea abbastanza struttura per diventare attuabile senza impegnarsi prematuramente in una soluzione.
Una volta che la direzione è chiara, uso /ops-backlog per creare un elemento di lavoro strutturato in GitHub, Azure DevOps o Jira. L'elemento di lavoro diventa il passaggio durevole tra il pensiero interattivo e l'esecuzione asincrona. Può contenere il contesto, l'ambito, i criteri di accettazione, i rischi, le domande irrisolte e le dipendenze necessarie per le fasi successive del flusso di lavoro.
A questo punto il backlog non è più solo un posto dove vengono archiviati i compiti. Diventa il livello di coordinamento condiviso tra umani, agenti e loop.
Gli umani creano idee, rispondono a domande e prendono decisioni. I loop osservano gli stati dei ticket e selezionano il lavoro idoneo. Gli agenti ricevono compiti mirati con il contesto necessario per eseguirli.
Il backlog trasforma una conversazione interattiva in lavoro durevole che continua dopo che quella conversazione è finita.
Passaggio 5: loop-task orchestra il lavoro asincrono
Una volta che il progetto, gli ingegneri, i guardrail, il backlog e la politica di approvazione sono pronti, configuro loop-task su una macchina locale o una VM.
loop-task esegue i loop di orchestrazione esterni. Questi loop ispezionano continuamente il backlog, identificano il lavoro idoneo, invocano il flusso di lavoro ingegneristico appropriato e aggiornano lo stato di ogni ticket.
Un loop di perfezionamento può selezionare un nuovo ticket, esaminarlo, migliorarne la specifica e aggiungere domande quando mancano informazioni. Quando è necessaria una decisione umana, il ticket passa in uno stato di attesa. Una persona risponde quando disponibile, e il loop riprende quando l'informazione arriva.
Una volta che il ticket è sufficientemente chiaro, passa in uno stato "pronto per l'implementazione". Il loop di implementazione lo preleva e invoca il flusso di lavoro ingegneristico autonomo.
Un loop di revisione può ispezionare il feedback della pull request, coordinare le correzioni, rieseguire il flusso di lavoro necessario e spostare la modifica verso l'accettazione. Un loop di completamento può unire il lavoro accettato, chiudere il ticket correlato e consentire al prossimo elemento idoneo di entrare nel sistema.
I loop non hanno bisogno di comunicare direttamente tra loro. Si coordinano attraverso stati durevoli del backlog. Un ticket tipico attraversa un ciclo di vita come questo:
Nuovo, In perfezionamento, In attesa di risposte, Pronto per l'implementazione, In implementazione, Pull request, In revisione, Completato.
Gli umani possono entrare nel processo ogni volta che la politica del progetto lo richiede, ma il sistema non dipende da qualcuno che guarda continuamente un terminale. Anche quando il developer è offline, la VM continua a controllare il backlog e a far avanzare il lavoro idoneo.
Questa è la distinzione al centro dell'ingegneria dei loop:
Gli agenti eseguono il lavoro. I loop decidono quando il lavoro esiste, quando dovrebbe iniziare, quale flusso di lavoro dovrebbe eseguirlo e cosa succede dopo.
Passaggio 6: /plan-goal esegue un ticket dall'inizio alla fine
Quando il loop di implementazione trova un ticket che è pronto, invoca /plan-goal.
Questo comando non è responsabile di decidere la direzione del prodotto o di inventare l'architettura del progetto. Quelle decisioni sono già state prese e codificate nel repository. La sua responsabilità è eseguire un elemento di lavoro sufficientemente raffinato all'interno del sistema ingegneristico esistente.
/plan-goal legge il ticket, esplora le parti rilevanti del codebase, crea una proposta OpenSpec, genera compiti strutturati, identifica lacune nelle specifiche o nei test, seleziona gli ingegneri specializzati appropriati, assegna livelli di modello, calcola le dipendenze e organizza il lavoro di implementazione in ondate di esecuzione parallele.
I compiti che sono indipendenti e modificano aree separate del repository possono essere assegnati a diversi ingegneri simultaneamente. I compiti che dipendono da lavoro precedente o toccano gli stessi file vengono eseguiti nell'ordine richiesto.
L'agente principale coordina il lavoro, raccoglie ogni risultato, crea commit mirati, esegue test, linting, type check e build. Si ferma piuttosto che spedire la modifica quando la verifica non può essere completata con successo.
Quando l'implementazione è valida, il branch viene pushato e viene creata una pull request con il contesto e le prove necessarie.
La politica di progetto configurata determina quindi cosa succede dopo. Un umano può rivedere la pull request. Un altro sistema AI può eseguire la revisione. Un progetto altamente autonomo può unire automaticamente quando tutti i controlli richiesti sono superati. In altri progetti, la decisione finale rimane esplicitamente umana.
Questo rivela i due livelli di orchestrazione nel sistema. loop-task è il livello di orchestrazione esterno. Gestisce il ciclo di vita del backlog e decide quando dovrebbero avvenire perfezionamento, implementazione, revisione o completamento. /plan-goal e gli altri comandi opencode-onboard formano il flusso di lavoro ingegneristico interno. Capiscono come esplorare, pianificare, assegnare, implementare, verificare e consegnare una modifica specifica.
Un sistema che sopravvive alla conversazione
Uno dei limiti dello sviluppo basato su prompt è che troppa risiede all'interno di una conversazione temporanea.
L'architettura deve essere spiegata di nuovo. Le decisioni precedenti vengono dimenticate. Un'implementazione interrotta è difficile da riprendere. Uno sviluppatore deve rimanere presente per decidere cosa dovrebbe fare l'agente dopo ogni passaggio.
Questo flusso di lavoro sposta quello stato in sistemi durevoli. Il repository contiene l'architettura, le regole di design, gli ingegneri e i guardrail. OpenSpec contiene la modifica pianificata e i suoi compiti. Git contiene la cronologia delle implementazioni e i punti di ripristino. Il backlog contiene lo stato di consegna e le decisioni umane. La macchina locale o la VM fornisce l'ambiente persistente in cui i loop continuano a funzionare.
Il risultato non è un singolo agente autonomo che tenta di comportarsi come un'intera organizzazione software. È un sistema coordinato in cui diversi componenti hanno responsabilità diverse.
Gli umani definiscono la direzione, i vincoli e i confini di responsabilità. Agenti specializzati eseguono un lavoro ingegneristico mirato. I loop coordinano il ciclo di vita in modo asincrono. Il backlog li collega.
Il cambiamento più importante non è che gli agenti possono generare più codice. Il cambiamento più grande è il passaggio da interazioni AI isolate a sistemi ingegneristici persistenti.
Invece di spiegare il repository prima di ogni compito, il progetto porta con sé la propria architettura e i propri guardrail. Invece di chiedere a un agente generico di implementare tutto, il lavoro viene assegnato a specialisti. Invece di decidere manualmente cosa dovrebbe succedere dopo ogni passaggio, i loop reagiscono a stati del flusso di lavoro durevoli. Invece di mantenere l'intero processo all'interno di una conversazione, i progressi sopravvivono in ticket, specifiche, commit, pull request e stato locale.
Il ruolo umano non scompare. Si sposta verso la progettazione dell'ambiente in cui è consentito operare l'esecuzione autonoma.
Questo è il modello che sto attualmente costruendo: un SDLC AI progettato dall'umano in cui il developer stabilisce prima l'ambiente ingegneristico e i confini dell'autonomia, poi loop asincroni coordinano agenti specializzati attraverso un ciclo di consegna guidato dal backlog.
Da zero a loop che funzionano da soli. Sei passaggi, ognuno basato sul precedente, ognuno che sposta un po' più di stato fuori dalla conversazione e in sistemi che non dimenticano.
PS: Puoi trovare loop-task, opencode-onboard e il resto di questi strumenti su ckgrafico.com
