Hai bisogno di una software factory?

Una software factory è un ciclo ripetibile attorno al lavoro software. Se stai costruendo una software factory, il codice abbastanza buono per essere rilasciato necessita comunque di gusto umano e responsabilità. Parleremo di questo, incluso se hai davvero bisogno di una factory in questo momento.

Se sì:

• Probabilmente avrai bisogno di persone nel ciclo all'inizio per decidere l'intento del prodotto, la progettazione del sistema (se ti interessa) e la tua soglia di qualità.
• Fai revisione del codice (factory a luci accese) ma sii intenzionale su dove è più necessaria. Ho scoperto che devi stare attento a dove la contropressione automatizzata si rompe. O dove è necessario fare compromessi sulla manutenibilità.
• Punta a che i controlli di qualità avvengano il più presto e continuamente possibile. Non tutti devono esserlo, ma questo include sistemi di tipi, test automatizzati, mutation testing, scanner di sicurezza e linting per regole architetturali.
• Numero di controlli != qualità. Probabilmente dovrai sperimentare quali controlli ti danno il miglior rapporto segnale/rumore. Sii pronto a stringere o allentare deliberatamente i tuoi vincoli.

Vuoi costruire la tua factory in modo che alcuni aspetti del gusto umano vengano codificati nell'ambiente, l'agente ti dia prove della correttezza del suo lavoro e un umano "possieda" ancora ciò che viene spedito in produzione.

Hai davvero bisogno di una software factory?

Nella mia esperienza, puoi arrivare sorprendentemente lontano con il tuo normale kit di codifica! Ad esempio Claude Code o Codex, sessioni multiple, buone specifiche con verifica integrata e vincoli. Puoi persino lanciare un batch di issue GitHub con criteri di implementazione e coinvolgimento umano. Le routine di Claude Code e gli agenti cloud di Copilot/Codex ti danno già un ciclo programmato o guidato da eventi senza infrastruttura personalizzata.

Una factory vale la pena quando hai bisogno di esecuzioni coerenti e ripetibili, passare il lavoro tra agenti, impedire a due sessioni di prendere in carico la stessa issue, conservare le prove e mettere in pausa la produzione quando le revisioni sono in ritardo.

Quindi ho iniziato dicendo che una software factory è un ciclo ripetibile attorno al lavoro software. Possiamo effettivamente guardare un prompt che dimostra un ciclo di factory molto piccolo qui:

Leggi la issue GitHub #123 e le istruzioni del repository prima di modificare il codice.

Implementa solo i criteri di accettazione indicati. Non modificare autenticazione, fatturazione, migrazioni o asserzioni di test esistenti. Lavora in un branch e mantieni il diff revisionabile.

Esegui npm run lint, npm test e npm run build. Se un controllo richiesto non può essere eseguito, fermati e spiega perché. Apri una pull request in bozza con i controlli che hai eseguito, i rischi rimanenti e qualsiasi decisione che un umano deve ancora prendere. Non fare merge.

Un obiettivo può mantenere questo in movimento finché i controlli non passano e possiamo interrogare le issue GitHub ogni mattina per eventuali etichette specifiche o rivedere le pull request aperte. La protezione del branch potrebbe imporre un confine di merge e l'umano può rimanere nel ciclo scegliendo cosa diventa pronto, revisionando e prendendo le decisioni finali di merge, ecc.

Aggiungi una software factory quando hai bisogno di una coda di lavoro guidata da eventi (es. trigger Slack, issue GitHub, Linear, un backlog) per essere eseguita in un ambiente cloud isolato per gestire triage, implementazione e test con un po' di supervisione umana esplicita. Alcuni terminano il loro ciclo con un agente di monitoraggio che osserva la produzione e apre issue che vengono triate di nuovo.

Nella mia esperienza, la factory diventa utile quando la parte difficile è far sì che le tue diverse esecuzioni si comportino in modo coerente, passare il lavoro tra agenti ed evitare che sessioni diverse rivendichino la stessa issue, preservare le prove e fermare la produzione quando la revisione umana è in ritardo.

Ciò che risolve questo potrebbe sembrare un po' noioso. Ad esempio, Warp menziona il triaging di ogni issue in arrivo in uno di quattro stati - pronto-per-implementare, pronto-per-specificare, necessita-info, attendi-per-implementare - e l'etichetta è ciò che attiva l'agente successivo.

Questa etichetta fa diversi lavori in uno: è la coda, il blocco e, poiché una sessione raccoglie solo ciò che è contrassegnato come pronto, è il posto dove un umano può mettere in pausa le cose senza dire no in modo permanente.

Dal punto di vista del flusso di lavoro, ci sono alcune somiglianze e differenze rispetto all'uso di Claude/Codex:

• Guida: l'agente ha bisogno di correzioni di rotta, puoi fornire input e reindirizzarlo
• Notifiche: come la factory dice di essere bloccata. Questo può essere perché un requisito era ambiguo, ha iniziato qualcosa di rischioso o ha bisogno di input umano (guida)
• Passaggio di consegne: sposta l'attività, il suo stato e il contesto tra la factory cloud/un altro agente/revisore umano. Buoni passaggi di consegne terranno traccia di cosa è successo, cosa resta da fare e perché il passaggio è necessario.

In una buona factory, l'umano non è limitato solo a revisionare e approvare il diff finale alla fine. Può modellare il lavoro all'inizio, guidarlo durante l'implementazione, farlo passare attraverso un passaggio di consegne o impedirne la spedizione in produzione.

La verifica è dove una factory responsabile passa molto del suo tempo. Ne parleremo più avanti.

Se decidi che hai bisogno di una software factory, costruirla non è l'unica opzione. Mettere in piedi l'infrastruttura per scalare una factory può essere molto lavoro e potresti voler considerare l'acquisto rispetto alla costruzione. Factory.ai, Devin, Warp e HumanLayer vendono tutti parti di questo ciclo.

Dove concentro effettivamente la mia attenzione

La mia esperienza quotidiana dello sviluppo software è cambiata molto nell'ultimo anno. Ho parlato sempre più di fare molto lavoro parallelo con gli agenti, muovendomi verso l'avere una software factory a luci accese. E molte persone mi hanno chiesto, tipo, cosa significano realmente queste cose? Cosa stai costruendo? Quali sono i tipi di progetti su cui usi queste cose? È molto di questo:

Quindi, in una giornata molto media, ho una software factory a luci accese più semplice. Posso avere attività che vengono eseguite nel cloud. La metà di queste attività potrebbe lavorare su applicazioni client di produzione con aziende più piccole con cui collaboro. Avranno utenti reali. Avranno autenticazione reale, pagamenti, abbonamenti, rischi davvero consistenti con cui devi stare attento. Non puoi semplicemente dire, oh, agente, vai e fai queste cose senza avere test, vincoli e controlli di qualità in atto.

Potrei lavorare sui miei progetti open source. Potrei costruire siti companion per i miei libri. Potrei lavorare su strumenti. Potrei creare le mie app. E queste sono tutte applicazioni molto, molto diverse su cui sto lavorando. E a volte l'unica cosa che hanno in comune è lo strumento che uso per lavorarci, giusto? Forse sto lavorando a una migrazione. Altre volte, potrei fare un vero e sostanzioso lavoro di funzionalità. E il raggio d'esplosione del lavoro potrebbe anche essere molto, molto diverso.

Quindi, mentre inizi a pensare di arrivare a un punto in cui facciamo sempre più lavoro parallelo, cerchiamo di migliorare la velocità, cerchiamo di migliorare la produttività e cerchiamo di migliorare l'autonomia, il che significa portare il sistema a un punto in cui ci fidiamo di più, devi pensare a quali sono i posti che richiedono assolutamente la revisione del codice umana, l'input umano.

E molto di questo sarà richiesto all'inizio, giusto? Quando definisci le tue specifiche, i tuoi requisiti, come sarà il design del prodotto? Quale sarà l'intento del prodotto? E poi come stai verificando che gli agenti abbiano effettivamente svolto correttamente il lavoro? Come stai verificando che non abbiano rotto il sistema esistente che era in atto? Come ti assicuri che soddisfi la tua soglia di qualità?

E quindi generare codice non è necessariamente la parte di cui devi preoccuparti di più. Dato abbastanza contesto, gli agenti possono scrivere l'implementazione, eseguire i test, ispezionare i fallimenti e rivedere il codice per noi. Dobbiamo arrivare a un punto in cui sentiamo che c'è abbastanza gusto umano codificato nell'ambiente da potersi fidare di ciò che viene costruito, in modo che la nostra attenzione umana possa essere concentrata sui posti dove è più necessaria.

Ora, c'è opposizione da parte di persone che dicono, ehi, beh, non credo che tu possa semplicemente automatizzare gran parte di queste cose. Non è per dire che stiamo automatizzando tutto, giusto? Ma dato il volume di codice che viene generato, non penso che sia realistico per gli umani leggerlo tutto, specialmente quando non stiamo costruendo razzi la maggior parte del tempo, giusto? Stiamo costruendo UI, stiamo costruendo applicazioni full stack.

Il nostro giudizio, il nostro gusto è meglio focalizzato sui posti dove è più necessario. Tipo, quali sono le parti più rischiose dei sistemi? Dove dobbiamo applicare il gusto umano? E questo può essere nel frontend. Può essere in come funziona il sistema. Non deve essere al 100%.

La mia larghezza di banda cognitiva non scala con gli agenti

La realtà è che sì, ora possiamo avviare dozzine, centinaia, migliaia di agenti in parallelo, ma la tua larghezza di banda cognitiva non scala allo stesso modo. Questo può alimentare un debito cognitivo o di comprensione di cui ho parlato in precedenza.

Se ricordi solo cinque, dieci anni fa, c'era molta discussione nella comunità ingegneristica sul cambio di contesto e il suo costo. Si parlava di come le persone odiassero quando un collega o qualcuno si avvicinava alla tua scrivania mentre eri nel bel mezzo di un'attività. Ci voleva poi così tanto tempo per tornare nel tuo stato di flusso perché dovevi recuperare, tipo, dove ero? Cosa stavo facendo? Anche se avevi un po' di residuo, ci voleva comunque tempo.

Ora cambiamo contesto ancora più di prima. In un dato giorno, se lavoro al di fuori di una software factory, posso lavorare su cinque o dieci progetti diversi con agenti contemporaneamente, o cinque o dieci funzionalità diverse su un singolo progetto alla volta. Posso avere cinque o dieci sessioni diverse, si può effettivamente dire.

Questo significa che devo essere in grado di tenere traccia di almeno alcune di esse. È possibile che io possa aumentare quanta autonomia do ad alcune attività se ho fiducia di aver definito abbastanza bene l'attività, di aver definito il risultato, come verificherà che sia stato fatto abbastanza bene. Ma poi ci saranno attività in cui forse non mi sento necessariamente così e c'è più rischio coinvolto o più sfumature. Dovrò prestare attenzione.

Considera l'ottimizzazione della software factory per il tuo revisore. Dato che ognuno di questi approcci indirizza comunque il suo output all'attenzione di una sola persona, dovresti chiederti quanto la factory stia rendendo più economiche le decisioni che devi ancora prendere.

Un errore di progetto sbagliato

Ricordo quando ho lavorato su più progetti paralleli con i miei agenti, e ci sono state volte in cui ho accidentalmente fatto cose come, forse stavo lavorando a un'app web a cui volevo aggiungere una modalità scura, e quindi avevo in testa, ok, beh, questa è la forma che deve avere. Ma sono accidentalmente andato alla sessione per un progetto diverso e ho iniziato a inserire lo stesso prompt.

Quindi ho iniziato a implementare la modalità scura per qualcosa che non ne aveva assolutamente bisogno. E quindi posso fare quell'errore. Non voglio che la mia software factory faccia quel tipo di errore.

Devi pensare a questo realmente in termini di sistema. Stai effettivamente cercando di codificare una cultura ingegneristica del software, una cultura di squadra, in un sistema in modo che abbia gli stessi tipi di comportamenti, in modo che abbia una proprietà che appartiene da qualche parte, in modo che qualcuno sia ancora responsabile di ciò che accade, e tu sia molto esplicito su come pensi a queste cose.

Quando il verde è fuorviante

Anche in questi sistemi, vuoi stare molto attento, giusto? Molti di noi hanno visto che quando hai chiesto all'AI di aiutarti a superare un test, come un test di programmazione, un test unitario, può cambiare il test unitario per soddisfare quella condizione, o può cambiare la logica del codice per superare quella condizione. Questo non significa che abbia effettivamente seguito la tua intenzione per allineare sia il comportamento funzionale che ciò che il test avrebbe dovuto testare, giusto?

Solo perché una software factory mostra che tutto è verde non significa che sia effettivamente verde, specialmente all'inizio quando stai impostando queste cose. Devi prestare molta attenzione per assicurarti che i tuoi controlli, le tue verifiche, siano tutti modellati nel modo giusto. Stiano facendo ciò che ti aspetti che facciano. Non vuoi che siano fuorvianti.

Non vuoi una situazione in cui hai test che dicono, ehi, in realtà, ho cambiato quali provider di autenticazione sono supportati. Mi hai chiesto di aggiungere GitHub, per esempio, come provider di autenticazione, ma ehi, la mia UI aveva spazio solo per tre, quindi ho rimosso uno degli altri. E, a proposito, quello era uno che i tuoi clienti volevano effettivamente. Quindi devi solo essere molto esplicito su come vuoi che funzionino questi sistemi.

Tra l'altro, anche la sicurezza è super importante e se la tua factory legge input non fidati come una issue GitHub/un messaggio Slack, potrebbe essere avversaria e includere problemi come attacchi alla supply chain. Alcuni prodotti relativi alle software factory, come Vercel Sandbox/AI ADK Factory, eseguono i loro agenti in sandbox isolati contenenti solo i segreti di cui un'attività ha bisogno. In questo modo, un'esecuzione compromessa non può raggiungere ciò di cui il lavoro non ha bisogno. La tua difesa finisce per essere a strati.

Quali vecchi progetti meritano un'altra vita?

Penso anche che una grande parte di come lavoriamo oggi sia decidere cosa dovrebbe esistere. Se ricordi molti anni fa, prima dell'AI, c'erano così tanti progetti software abbandonati, così tanti progetti del weekend abbandonati, progetti personali che semplicemente non venivano lanciati perché non avevamo il tempo di finirli. Non avevamo la larghezza di banda per dare priorità al loro completamento perché non erano così importanti per noi o non riuscivamo a trovare il tempo.

Ora è abbastanza banale per noi completare quei progetti, ma entra in gioco la stessa domanda di giudizio umano. Quei progetti meritano di esistere? Dovrebbero essere lanciati? Perché li metti nel mondo e anche se ha solo cinque utenti, forse devi mantenerlo. Forse ora hai una soglia di qualità che vuoi mantenere.

So di aver avuto così tanti progetti GitHub nel corso degli anni in cui ora che ho un agente, la prima cosa che faccio è far sì che la cosa compili. Perché, ovviamente, lo cloni e ora non compila perché tutte le dipendenze sono cambiate. Metà delle cose sono obsolete o hanno vulnerabilità di sicurezza dappertutto, quindi devi aggiornarlo.

Poi devi aggiungere test se non avevi test in modo da sapere che quel comportamento sarà almeno lì se stai aggiornando il progetto in qualche modo, o se lo stai migrando a un linguaggio o framework più moderno o cose del genere.

Poi inizi a chiederti, beh, forse, un esempio stupido, ma forse usavo Twitter Bootstrap ai vecchi tempi per questo, ma ora tutti usano Tailwind e shadcn, quindi devo reimplementare la UI. E ciò che noterai è che improvvisamente questo ti sta prendendo più tempo, giusto? Sì, l'agente può fare molto di questo più velocemente, ma ora devi tenere conto del senso del prodotto e del gusto e di tutte queste cose.

Ti chiedi ancora, beh, per chi è? Ha un mercato? È per me stesso? È per altre persone? Se lo metto nel mondo, sarà ancora interessante dato che ora chiunque può mettere in piedi queste cose così velocemente?

Quindi penso che la domanda umana se queste cose meritino di esistere? Come teniamo conto del nostro gusto e giudizio? Sento che queste cose continuano ad essere estremamente importanti. È lì che entra in gioco quella risorsa scarsa dell'attenzione umana. Ai vecchi tempi, avevamo solo un numero finito di ore al giorno. Avevamo riunioni. Dovevamo preventivare il tempo per la progettazione e la codifica e così via.

Ora che abbiamo agenti per aiutarci, penso che tu debba davvero essere molto esplicito su dove stai spendendo il tuo tempo e perché.

Cosa è successo quando ne ho costruito un esempio

Quindi parlerò dell'esecuzione della factory di 82 minuti. Le persone mi hanno chiesto per molto tempo, sai, "Come si costruisce una software factory?" O, "Sono abituato a usare Claude Code o Codex. Come faccio a evolvere la mia configurazione per usare una software factory?"

Quindi la prima cosa che ho detto è: "Potresti stare bene. Il tuo lavoro potrebbe effettivamente andare perfettamente bene senza bisogno di una factory." Ma volevo dare alle persone una configurazione di riferimento che potessero consultare. Quindi quello che ho messo insieme è un repository chiamato Factory che puoi andare a vedere. Ho anche messo insieme un'applicazione demo e un workshop.

Ora, negli ultimi due anni, la mia applicazione demo di riferimento per molte cose è stata un'app di film. Sono un grande fan dei film. Amo guardare film. Guardo film tutto il tempo, e quindi ho un'applicazione demo, che inizia davvero come un'app di film molto semplice. E ciò che voglio che la factory sia in grado di fare è andare avanti e implementare una serie di funzionalità. Ci sono alcune funzionalità diverse. Voglio una funzionalità preferiti. Voglio che sia in grado di fare forse una ricerca, e forse anche un tema scuro, quel tipo di cose.

Quindi la mia factory va e inizia a lavorare con queste cose. Puoi controllare l'implementazione. Uno dei vantaggi è stato effettivamente cogliere problemi reali. Questi problemi potrebbero non essere cose che avrei colto se le avessi semplicemente chiesto di fare un'implementazione one-shot.

Forse intorno al minuto 60, mi sentivo come, "Wow, sta andando insolitamente lenta." Ho chiesto al mio harness usando la factory, "Perché le cose vanno lente?" Ha detto, "Questo è in realtà perfettamente normale. Tutti i verificatori sono ancora in esecuzione."

Potresti esserti aspettato che le singole attività richiedessero 10 minuti, 15 minuti, 20 minuti, ma possono richiedere da due a quattro volte tanto una volta che inizi a includere verifica, tentativi, controlli del browser, revisione umana, uno qualsiasi di questi ritardi extra.

Penso che questi possano sommarsi a una migliore qualità e a una maggiore fiducia nel sistema. Da una prospettiva di misurazione, potresti guardare metriche come il costo per PR unita e la durata di vita del codice come metriche del debito di comprensione.

Devi anche pensare a cosa sia un ritardo utile rispetto ai sovraccarichi della factory. I verificatori, nel mio caso, hanno colto alcuni problemi reali. Un po' di tempo è stato forse speso per produrre prove che volevo. Un po' era sovraccarico nell'esecuzione della factory. Non ho passato molto tempo a ottimizzarla, ma una factory che esegue solo molti controlli che non trovi preziosi non significa che sia di alta qualità.

Vuoi studiare come, per qualsiasi controllo ripetuto, siano irrilevanti? Siano rumorosi? Stiano effettivamente rendendo il sistema più sicuro?

La verifica ha bisogno di un budget

Il modo in cui penso al budget per la verifica, questo è fondamentalmente ciò di cui stiamo parlando. Stiamo parlando di un budget di verifica. Ci penso allo stesso modo in cui storicamente ho pensato ai budget delle prestazioni.

Ci saranno alcuni tipi di controlli che puoi eseguire all'inizio del tuo ciclo di vita dello sviluppo software, e ci saranno alcune cose che sono così pesanti, ma offrono così tanto valore che vorrai eseguirle più tardi. Ci sono alcuni tipi di controlli veloci, il linting, per esempio, il type checking. Questi sono controlli relativamente veloci che puoi eseguire all'inizio.

La nostra suite completa di test può essere eseguita più vicino a prima che una PR in bozza venga messa insieme o dopo. Questo può includere mutation testing, test del browser, controlli di sicurezza, qualsiasi cosa del genere.

Penso che non vuoi necessariamente sostituirli con solo riassunti. Vuoi test reali, ma devi solo assicurarti di fare budgeting per loro nei posti giusti perché non vuoi rallentare il tuo ciclo di sviluppo. Di certo non voglio mai rallentare il mio ciclo di sviluppo. Avere un ciclo di iterazione veloce è importante per me, ma voglio anche avere ancora quei controlli e contrappesi.

Quando un'esecuzione non viene spedita

Molto di ciò che ho scritto sopra riguarda i controlli.

Nella loro software factory, Vercel marca ogni esecuzione dell'agente come "successo", "difettoso", "bloccato" o "manuale" e solo "successo" viene spedito in produzione. Il resto rientra nel sistema. Ho pensato alle esecuzioni in termini simili.

"Difettoso" qui significa che è stata implementata la cosa sbagliata o forse non aveva il contesto completo, quindi deve essere risolto. Bloccato significa che all'ambiente potrebbe mancare una credenziale, quindi devi fornirla. Manuale è un confine che la factory potrebbe non essere ancora autorizzata ad attraversare.

Due delle tre cose qui possono avere correzioni meccaniche e l'ultima riguarda la fiducia.

Anche se questo è fantastico, ciò che l'ordinamento non ti mostra è il costo. Tornando alla mia implementazione della factory con l'app TMDB, il cercatore veloce senza rifiuti ha richiesto 7 minuti. Preferiti, con due rifiuti e una decisione umana nel mezzo, ha richiesto 56 minuti. Stessa factory. Quindi abbino la tassonomia ai tempi per fase, altrimenti sai che un'esecuzione è tornata difettosa senza sapere quanto ti è costato scoprirlo. L'altra cosa che sistemerei è il passaggio di consegne al confine: la mia factory di esempio ha fermato la prima issue e l'ha spostata su factory:necessita-info, il che era giusto, ma non sapevo dove mettere la mia risposta. Un'esecuzione manuale non è finita quando la factory si ferma, ma quando l'umano sa cosa fare dopo.

L'autonomia non è un'impostazione singola

Un paio di settimane fa ho scritto un articolo sull'autonomia agentica e su come pensare all'autonomia perché l'autonomia non sarà un'impostazione singola per ogni singolo progetto.

La verifica ti compra fiducia e compra la capacità di concedere più autonomia ai tuoi agenti. Quindi se, per esempio, sto lavorando a una modifica non banale, ma ho una serie di controlli in atto, tutto viene verificato correttamente, e forse l'ho controllato io stesso manualmente. La prossima volta che farò un'attività del genere nello stesso progetto, forse mi sentirò a mio agio nel dare all'agente un po' più di autonomia.

Questo è ciò a cui pensi quando costruisci queste software factory. La tua verifica cambierà con il rischio. Il tuo obiettivo è il miglior rapporto segnale/rumore. Non vuoi solo avere una lunga lista di controllo che stai eseguendo.

La funzionalità che ho dovuto reimparare

C'era una funzionalità che stavo rimandando in un giorno in cui stavo usando più sessioni con Claude, e stavo lavorando a diversi progetti contemporaneamente, a diverse funzionalità per progetto. E quindi Claude aveva implementato la funzionalità su cui stavo lavorando. Sembrava che i test stessero passando. Non avevo pensato molto alla verifica, ma i test passavano, e quindi ho pensato che funzionasse. L'ho unita.

E quindi questa era una funzionalità di preferiti. Pensavo che fosse effettivamente abbastanza buona. Ho provato a controllarla nel browser. Sembrava andasse bene, ma un paio di giorni dopo, sono effettivamente tornato al codice perché c'erano alcune modifiche che pensavo di poter apportare.

Non volevo semplicemente chiedere al mio agente di apportare le modifiche, perché era solo un modo sottile in cui funzionava. Tocchi l'icona e non mostrava l'effetto giusto al tocco, quindi volevo solo ritoccarlo. Volevo capire come funzionasse per poter guidare correttamente il mio agente.

Sono tornato al codice e non sarei stato in grado di spiegarti come funzionava la funzionalità. Questa repository era mia, giusto? Avevo approvato la modifica. Capivo come funzionavano molte cose, gran parte della repo, ma la mia comprensione non era riuscita a tenere il passo con tutto il codice che si era accumulato.

Quello che non ero riuscito ad assimilare era come funzionasse effettivamente questa funzionalità che era stata aggiunta, come funzionasse l'interfaccia utente, come funzionasse l'effetto su di essa. Ho dovuto rifare questa funzionalità e procedere passo dopo passo: "Come funziona? Come posso capirla?"

Cosa fa il lavoro parallelo alla comprensione

Quando svolgi un lavoro parallelo, questo amplifica il problema generale, e diventa ancora più amplificato quando lo fai in una fabbrica software. Quando fai cinque o dieci sessioni, creano molto più di un semplice problema di volume di revisione. Creano diversi modelli mentali che possono finire per raffreddarsi parecchio mentre lavori altrove.

Storicamente abbiamo parlato delle sfide legate al cambio di contesto, e non appena la chat si compatta, scarti alcuni approcci, provi cose diverse, ti accoppi con l'agente, avrai difficoltà a ricordare tutto ciò che è successo nella tua sessione.

Puoi scorrere verso l'alto, e man mano che la compattazione è avvenuta, non avrai tutto lì, e non sarai in grado di immagazzinarlo tutto nella tua testa. Il codice spesso preserva una decisione che è stata presa, ma non il motivo per cui è stata presa.

Questa è una cosa che penso possa essere un apprendimento utile per te, dove è importante considerare di chiedere al tuo agente di memorizzare effettivamente informazioni sulla sua traiettoria, o lezioni interessanti su come ha affrontato un problema, in modo da poterci tornare in seguito.

Questa può o non può essere una cosa che decidi di impegnare in una repo. Puoi tenerla in locale se vuoi, puoi condividerla con un team se vuoi, ma può essere qualcosa a cui puoi fare riferimento in seguito. Piuttosto che fare affidamento sul fatto che sia forse in una sessione, o che tu forse te ne ricordi in seguito.

Cosa produce effettivamente?

@threepointone e @bentlegen hanno pubblicato alcune opinioni sulle fabbriche software con cui ero fortemente d'accordo:

È facile lasciarsi affascinare dal meccanismo del fare, ottimizzare il meccanismo e dimenticare cosa doveva produrre. Se la tua fabbrica produce principalmente una fabbrica migliore, hai costruito un software il cui prodotto è sé stesso.

Penso che investire nel ciclo vada bene e che dia i suoi frutti. Il fallimento si verifica quando il ciclo si chiude, quando tutto ciò che la fabbrica produce viene consumato dalla fabbrica e nessuno all'esterno se ne accorgerebbe se la spegnessi. Il test che applicherei è la trazione. Qualcosa all'esterno deve chiedere il miglioramento. Se non riesci a nominare chi sta trainando, stai solo lucidando.

La proprietà non scompare

C'è un principio più ampio alla base di tutto questo.

La percentuale di codice fisicamente digitato dagli esseri umani potrebbe diminuire drasticamente. Non credo che la proprietà umana debba diminuire con essa.

• Qualcuno sceglie ancora il problema.
• Qualcuno sceglie ancora l'architettura.
• Qualcuno imposta ancora lo standard di qualità.
• Qualcuno decide quali segnali di verifica meritano fiducia.
• Qualcuno decide quando le prove sono sufficienti per rilasciare.

E quando il sistema risultante fallisce, "l'ha scritto l'agente" non è una scusa valida. Ecco perché non penso che il futuro dell'ingegneria del software sia meglio descritto come esseri umani che escono dal ciclo. Invece, il giudizio umano viene riposizionato.

Dovremmo rimuovere le persone dalle parti del ciclo in cui le macchine possono produrre segnali più forti, più veloci e più deterministici. Allo stesso tempo, dovremmo concentrare le persone nei luoghi in cui il contesto, il gusto, il rischio e la proprietà a lungo termine contano di più.

Le migliori fabbriche software non saranno definite da quanto completamente eliminano il coinvolgimento umano.

Saranno definite da quanto intelligentemente lo posizionano.

Mantieni il giudizio umano a monte su intento, forma del sistema e standard di qualità. Rivedi il codice dove la contropressione automatizzata diventa debole o le conseguenze diventano soggettive. Spingi ogni segnale deterministico il più presto e continuamente possibile nel ciclo. Stringi e allenta i vincoli deliberatamente man mano che il sistema guadagna o perde fiducia.

Un essere umano deve ancora possedere ciò che il codice alla fine rilascia. Il codice abbastanza buono per essere rilasciato inizia ancora con qualcuno a cui importa se dovrebbe esistere.