Il collo di bottiglia dell'ingegneria del software non è più il codice.

      Per la maggior parte della storia del software, la pianificazione era sacra. Dovevi pianificare prima che chiunque toccasse una tastiera, perché il costo di costruire la cosa sbagliata poteva essere così punitivo, specialmente per le startup, che ottenere il giusto fin dall'inizio era l'unica strategia razionale.

      L'implementazione era costosa, il tempo di ingegneria era scarso e cambiare direzione una volta che il team si era impegnato in un approccio poteva farti perdere mesi.

      L'intero apparato dello sviluppo software moderno, le roadmap, i framework di priorità, i rituali di pianificazione trimestrale, sono cresciuti come risposta a quel singolo fatto economico.

      Quel fatto non è più vero, e la maggior parte delle organizzazioni di ingegneria non si è ancora adeguata.

      Gli strumenti di codifica AI hanno ridotto il costo di trasformare un'idea in software funzionante. Ciò che prima richiedeva settimane di implementazione può ora essere esplorato in ore.

      Puoi chiedere a un agente di prototipare tre approcci concorrenti durante la notte e scartare i due che non reggono quando ti svegli al mattino.

      Puoi mettere in discussione un'assunzione con una demo funzionante invece di una presentazione. L'economia si è invertita: la pianificazione e il processo erano più economici della costruzione, e ora costruire è più economico delle riunioni che avresti tenuto per decidere cosa costruire o come costruirlo.

      Questo cambia tutto su come i team di ingegneria dovrebbero operare. Non esiste più un piano perfetto, e anche se ci fosse, il tempo necessario per produrne uno significa che hai già perso contro qualcuno che ha appena iniziato a costruire.

      In Synthesia, abbiamo deciso di testare questa idea nel modo più diretto possibile. Ogni trimestre, i nostri team di prodotto, ingegneria e R&D si riuniscono a Londra per pianificare i prossimi tre mesi di lavoro.

      Storicamente, trascorrevamo la maggior parte di quel tempo in stanze ad analizzare, dibattere e dare priorità. L'obiettivo era emergere con un piano sufficientemente buono da giustificare il costo dell'implementazione.

      Durante il nostro incontro più recente, abbiamo invertito la sequenza. Abbiamo sostituito i primi due giorni di pianificazione con un hackathon. 200 persone provenienti da ingegneria, prodotto, design, legale, ricerca e talenti hanno formato 70 team e hanno costruito per 28 ore consecutive.

      Il brief era semplice: prendi un'idea, costruiscila, trasforma il risultato in un video demo di due minuti. Niente specifiche dettagliate, niente sovrapianificazione: solo costruire.

      Ciò che è accaduto ci ha sorpreso.

      Uno dei team vincitori, un gruppo di cinque ingegneri, ha ricostruito completamente il nostro editor video da zero. L'editor video fornisce un'interfaccia simile a PowerPoint in cui gli utenti della nostra piattaforma creano video con avatar AI.

      Gli ingegneri hanno consegnato una completa reinterpretazione end-to-end del prodotto, focalizzandosi su interattività, narrazioni ramificate e storytelling multi-avatar.

      Questo non era un caso isolato; in tutti e 70 i team è emerso lo stesso schema: quando dai alle persone concentrazione e rimuovi le frizioni, possono muoversi molto più velocemente di quanto chiunque si aspettasse.

      La lezione che abbiamo tratto da questo esperimento è che l'esecuzione non è più il vincolo, ma il giudizio.

      Questo potrebbe contraddire l'assunzione operativa con cui la maggior parte dei leader di ingegneria ha lavorato per tutta la carriera. Abbiamo trascorso anni a costruire organizzazioni ottimizzate per il throughput di esecuzione: quante funzionalità sono state spedite, quanti punti storia completati, quanto velocemente si riduce il backlog.

      Ma quando costruire diventa economico, il collo di bottiglia si sposta a monte. La parte difficile non è più scrivere il codice. Invece, è sapere quale codice vale la pena scrivere in primo luogo.

      Quando parlo di giudizio, intendo quattro cose specifiche. Prima, la capacità di aiutare i product manager ad affrontare il giusto problema del cliente più rapidamente, il che richiede di distinguere tra ciò che è intellettualmente interessante e ciò che conta davvero per gli utenti e per l'azienda.

      In secondo luogo, definire come appare il "grande" prima di iniziare, perché se non riesci a articolare quel standard, non lo riconoscerai quando lo vedrai.

      In terzo luogo, si tratta di sapere quando qualcosa è abbastanza buono da mettere di fronte a un utente, non perfetto, non rifinito, solo sufficiente per imparare. E infine, essere in grado di eliminare rapidamente le idee.

      Quando puoi provare molte cose in parallelo, l'abilità più preziosa diventa lasciar andare quelle che non funzionano, piuttosto che innamorarti del tuo primo tentativo perché costa così tanto produrlo.

      I migliori team di ingegneria nei prossimi anni non vinceranno sulla produzione di codice, vinceranno sul gusto.

      Questo ha reali implicazioni su come pensiamo al ruolo dell'ingegneria stessa. Stiamo passando dall'essere costruttori all'essere orchestratori. Gli agenti AI possono ora eseguire grandi parti del processo di sviluppo end-to-end.

      Il lavoro dell'ingegnere diventa sempre più scegliere i problemi giusti, rivedere i risultati e iterare rapidamente. Meno tempo a scrivere ogni riga e più tempo a dirigere sistemi che scrivono righe per te.

      Alcune persone trovano questo minaccioso. Io penso che sia l'opposto. Le parti noiose dell'ingegneria, il boilerplate, il cablaggio ripetitivo, il lavoro che non è mai stato realmente la parte interessante, è ciò che viene automatizzato per primo.

      Ciò che rimane è il lavoro su cui gli ingegneri hanno sempre desiderato poter trascorrere più tempo: comprendere profondamente il problema, progettare soluzioni eleganti, prendere le decisioni difficili su cosa costruire e cosa scartare. L'arte si distilla nella sua essenza.

      Ci stiamo rendendo responsabili di questo cambiamento in Synthesia. Stiamo monitorando l'uso settimanale di strumenti di codifica AI come Claude Code e Codex, e stiamo misurando quanto rapidamente i team possono passare dall'idea al prototipo al feedback degli utenti. La metrica che conta ora è la velocità del ciclo di apprendimento, non il volume di codice prodotto.

      La direzione in cui ci stiamo dirigendo è ciò che chiamerei sviluppo in modalità automatica: cicli serrati dal prototipo al test utente, alla spedizione e al perfezionamento. L'agile viene sostituito da qualcosa di ancora più veloce, qualcosa in cui il divario tra avere un'intuizione e testarla contro la realtà si riduce a quasi nulla.

      Quindi la domanda che conta per ogni leader di ingegneria che legge questo non è più "possiamo costruire questo?" Quella domanda ha già avuto risposta. Puoi costruire quasi tutto, in modo straordinariamente veloce, con un piccolo team e gli strumenti giusti.

      La domanda ora è: cosa dovresti costruire? E hai il giudizio per saperlo?