Dave Farley, fondatore del canale Modern Software Engineering e figura storica della Continuous Delivery, sostiene qui che il dibattito pubblico su IA e sviluppo software trascura una variabile decisiva: la continuous delivery. Senza di essa, lo sviluppo assistito dall'IA non è semplicemente rischioso, è una trappola — una bomba di complessità a innesco ritardato.

Il suo argomento centrale si sviluppa in quattro parti. Primo, il codice non è mai stato il collo di bottiglia dell'ingegneria del software. La difficoltà è sempre risieduta altrove: comprendere il problema, progettarlo, testarlo, integrarlo, distribuirlo. L'IA accelera proprio la parte che non era il problema.

Secondo, si applica il paradosso di Jevons: quando produrre codice diventa economico, se ne produce di più. Più codice significa più complessità, più punti di integrazione, più comportamenti da valutare, più manutenzione. E probabilmente meno tempo per comprendere il problema. Non è un guadagno di produttività, è una bomba a orologeria.

Terzo, l'IA tende a fare grandi balzi, mentre una buona ingegneria richiede passi piccoli e reversibili con feedback rapido. Farley cita Bob Martin ("l'unico modo per andare veloci è andare bene") e racconta di un progetto in cui l'arrivo improvviso di 200 consulenti un lunedì mattina ha distrutto diciotto mesi di progressi.

Quarto, la Continuous Delivery è definita come "lavorare in modo che il nostro software sia sempre in uno stato rilasciabile". La meccanica: piccoli incrementi, test automatizzati rapidi, una deployment pipeline che arbitra la releasability. La pipeline non si cura di chi ha scritto il codice — umano o IA, lo standard è lo stesso.

Farley illustra questo con la propria esperienza: ora insegna al suo assistente IA l'Acceptance Test-Driven Development, specifica a livello di accettazione, e in poche ore percorre ciò che un tempo richiedeva settimane — con la fiducia che la direzione sia corretta. Descrive anche come la sua pipeline abbia rilevato un disallineamento di schema silenzioso: l'IA aggiornava il database di test ma non quello di produzione. Tutti i test passavano, l'app si bloccava in produzione. È stata la pipeline a segnalarlo, non l'IA.

La sua frase conclusiva riassume tutto: "L'IA non sostituisce la necessità dell'ingegneria del software. Espone i team che in realtà non hanno mai fatto ingegneria." La domanda non è se l'IA possa scrivere codice, ma se le vostre pratiche di ingegneria siano abbastanza solide da assorbire codice proveniente da qualsiasi fonte — umana o macchina — e distribuire software funzionante.