← Back to Blog

Il prossimo collo di bottiglia del software non è il codice. È tutto ciò che gli sta attorno.

Il prossimo collo di bottiglia del software non è il codice. È tutto ciò che gli sta attorno.

Due anni fa, se aveste detto alla maggior parte dei responsabili ingegneristici che l'AI avrebbe scritto funzioni di produzione, rifattorizzato moduli legacy e individuato bug prima ancora che un essere umano li guardasse, l'avrebbero definito un miracolo di produttività in arrivo. E in senso stretto lo è stato. Gli assistenti di programmazione AI sono davvero eccellenti nel digitare codice velocemente.

Quindi ecco la domanda su cui vale la pena soffermarsi: se la parte più lenta della creazione di software è diventata drasticamente più veloce, perché non sembra che i team rilascino il doppio più in fretta?

Perché scrivere codice non è mai stato il collo di bottiglia. Lo era coordinare tutto ciò che gli sta attorno.

La parte che nessuno ha automatizzato

Pensate a cosa succede davvero tra "abbiamo un'idea" e "è live in produzione". Qualcuno definisce l'ambito del lavoro. Uno sviluppatore lo scrive. Resta in coda per la review. Resta in un'altra coda per il QA. Qualcuno deve scrivere la documentazione, di solito a cose fatte, di solito di fretta. Qualcuno configura la pipeline di deployment. Qualcuno ne osserva il rilascio. Ognuno di questi passaggi comporta un passaggio di consegne e ogni passaggio di consegne significa che il contesto si perde, le priorità vengono rinegoziate e un ticket che ha richiesto quattro ore di programmazione effettiva passa quattro giorni in attesa tra una persona e l'altra.

Gli assistenti di programmazione AI hanno reso più veloce la stazione più rapida di quella catena di montaggio. Hanno lasciato ogni altra stazione (e le code che le collegano) lenta e manuale esattamente come prima. Ecco perché "i nostri sviluppatori ora programmano più in fretta" così spesso non si è tradotto in "ora rilasciamo più in fretta". Accelerare un solo passo in una catena di passaggi di consegne significa solo che il lavoro aspetta più a lungo al successivo.

Ripensare che cosa dovrebbe significare "AI per lo sviluppo software"

È il problema che abbiamo costruito AITM per risolvere, ed è il motivo per cui non abbiamo creato un altro strumento di autocompletamento.

AITM è una piattaforma di ingegneria del software basata sull'AI che gestisce l'intero ciclo di vita dello sviluppo software: pianificazione, programmazione full-stack, code review automatizzata, test end-to-end, documentazione, CI/CD e deployment cloud, tutto a partire da una singola richiesta. L'idea è semplice da enunciare e davvero difficile da realizzare: invii un task una volta sola, e AITM progetta, programma, testa, documenta e consegna software pronto per la produzione, senza che una persona debba accompagnarlo manualmente attraverso sei strumenti e quattro team diversi.

È un tipo di automazione diverso da "aiutami a scrivere questa funzione più in fretta". È l'automazione dei passaggi di consegne stessi, la parte del ciclo di vita che gli strumenti di produttività ingegneristica hanno per lo più ignorato perché è più difficile da automatizzare dell'autocompletamento e meno appariscente da mostrare in una demo.

Che cosa cambia quando l'intera pipeline è governata, non solo un passo

Quando code review, test, documentazione e deployment non sono code manuali separate ma parte di un unico processo gestito in modo continuo, ne conseguono naturalmente alcune cose. Il codice arriva già testato e documentato, invece di arrivare come un diff grezzo che poi aspetta che qualcuno si occupi del resto. Le decisioni architetturali vengono prese fin dall'inizio tenendo conto di sicurezza e scalabilità, anziché essere rimediate dopo un incidente di scalabilità. E il ciclo di rilascio si accorcia, non perché qualcuno abbia digitato più in fretta, ma perché il software ha trascorso molto meno tempo in fila.

Per gli ingegneri questo cambiamento conta più di quanto possa sembrare a prima vista. Significa meno tempo speso nel sovraccarico di coordinamento per portare una modifica attraverso la review, oltre il QA, nella documentazione e fuori dalla porta, e più tempo dedicato al lavoro che richiede davvero giudizio umano: cosa costruire, come progettarne l'architettura, quali compromessi contano per questo prodotto e questi utenti. L'AI non dovrebbe cercare di sostituire quel giudizio. Dovrebbe eliminare tutto ciò che intralcia il suo esercizio.

La vera domanda competitiva

Per anni il settore del software ha misurato la produttività in base a quanto velocemente un singolo ingegnere può scrivere una riga di codice. Era un indicatore ragionevole quando scrivere codice era la parte costosa. Oggi non lo è più. I team che da qui in avanti passeranno in testa non saranno quelli i cui ingegneri digitano più in fretta, ma quelli che hanno azzerato la distanza tra "abbiamo un'idea" e "è live, testato, documentato e in esecuzione in sicurezza in produzione".

È la scommessa alla base di AITM, ed è il cambiamento su cui pensiamo si giocheranno davvero i prossimi anni dell'AI nello sviluppo software - non un autocompletamento più intelligente, ma un'AI che governa i risultati lungo l'intero ciclo di vita, end to end.

Se è un problema che vive anche il vostro team, ci piacerebbe sapere come ci state pensando.