La settimana scorsa, uno dei nostri product supervisor (PM) ha creato e distribuito una funzionalità. Non l’ho specificato. Non ho presentato un biglietto per questo. Lo abbiamo costruito, testato e spedito in produzione. In un giorno.
Pochi giorni prima, il nostro progettista aveva notato che l’aspetto visivo dei nostri plugin IDE si period allontanato dal sistema di progettazione. Nel vecchio mondo, ciò significava screenshot, un ticket JIRA, una conversazione per spiegare l’intento e uno slot per lo dash. Invece, ha aperto un agente, ha modificato lui stesso il structure, ha sperimentato, ripetuto e messo a punto in tempo reale, quindi ha inviato la correzione. La persona con l’intuizione progettuale più forte ha fissato direttamente il progetto. Nessun livello di traduzione richiesto.
Niente di tutto questo è nuovo in teoria. La codifica Vibe ha aperto a milioni di persone le porte della creazione di software program. Quella period l’aspirazione. Quando ho condiviso i dati su come i nostri ingegneri hanno raddoppiato la produttività, sono passati dalla codifica alla convalida, hanno portato la progettazione in primo piano per una sperimentazione rapida, period ancora una storia di ingegneria. Ciò che è cambiato è che la teoria è diventata pratica. Ecco come è andata effettivamente a finire.
Il collo di bottiglia si è spostato
Quando nel 2025 siamo passati all’intelligenza artificiale, i costi di implementazione sono crollati. Gli agenti hanno preso il controllo delle impalcature, dei take a look at e del codice ripetitivo della colla che consumava metà dello dash. I tempi di ciclo sono scesi da settimane a giorni, da giorni a ore. Gli ingegneri hanno iniziato a pensare meno ai file e alle funzioni e più all’architettura, ai vincoli e ai piani di esecuzione.
Ma una volta che la capacità ingegneristica ha smesso di rappresentare il collo di bottiglia, abbiamo notato qualcosa: la velocità decisionale lo period. Tutti i meccanismi di coordinamento che avevamo creato per proteggere i tempi di progettazione (specifiche, ticket, trasferimenti, gestione degli arretrati) erano ora la parte più lenta del sistema. Stavamo ottimizzando per un vincolo che non esisteva più.
Cosa succede quando costruire costa meno che coordinare?
Abbiamo iniziato a porci una domanda diversa: come sarebbe se le persone più vicine all’intento potessero spedire direttamente il software program?
I PM già pensano alle specifiche. I progettisti definiscono già struttura, structure e comportamento. Non pensano in sintassi. Pensano in termini di risultati. Quando il costo per trasformare l’intento in un software program funzionante è sceso abbastanza, questi ruoli non hanno più avuto bisogno di “imparare a programmare”. Il costo di implementazione è semplicemente sceso al loro livello.
Ho chiesto a uno dei nostri PM, Dmitry, di descrivere cosa è cambiato dal suo punto di vista. Mi ha detto: “Mentre gli agenti generano compiti in Zenflow, ci sono alcuni minuti di inattività. Solo aria morta. Volevo creare un piccolo gioco, qualcosa con cui interagire mentre aspetti.”
Se hai mai gestito un group di prodotto, conosci questo tipo di concept. Non sposta un KPI. È impossibile giustificarsi in una riunione sulle priorità. Viene rinviato per sempre. Ma aggiunge personalità. Fa sembrare il prodotto come se qualcuno si preoccupasse dei piccoli dettagli. Queste sono esattamente le cose che vengono ottimizzate da ogni sessione di ripulitura del backlog e esattamente le cose che gli utenti ricordano.
L’ha costruito in un giorno.
In passato, quell’concept sarebbe morta in un foglio di calcolo per la definizione delle priorità. Non perché fosse un male, ma perché il costo di attuazione rendeva irrazionale perseguirlo. Quando il costo scende quasi a zero, il calcolo cambia completamente.
La spedizione è diventata più economica della spiegazione
Man mano che sempre più persone iniziarono a costruire direttamente, interi livelli di processo svanirono silenziosamente. Meno biglietti. Meno trasferimenti. Meno conversazioni “puoi spiegare cosa intendi con…”. Meno momenti persi durante la traduzione.
Per una classe di compiti significativa, è diventato più veloce costruire semplicemente l’oggetto piuttosto che descrivere ciò che volevi e aspettare che qualcun altro lo costruisse. Pensateci per un secondo. Ogni moderna organizzazione software program è strutturata sul presupposto che l’implementazione sia la parte costosa. Quando questo presupposto viene meno, l’organizzazione deve cambiare con esso.
Il nostro designer che ha sistemato l’interfaccia utente del plugin è un esempio perfetto. Il vecchio flusso di lavoro (fare uno screenshot del problema, inviare un ticket, spiegare il divario tra intenti e implementazione, attendere uno slot di dash, rivedere il risultato, richiedere aggiustamenti) esisteva interamente per proteggere la larghezza di banda della progettazione. Quando la persona con l’intuizione progettuale può agire direttamente su di esso, l’intero stack scompare. Non perché abbiamo eliminato il processo high-quality a se stesso, ma perché il processo risolveva un problema che non esisteva più.
L’effetto cumulativo
Ecco cosa mi ha sorpreso di più: è composto.
Quando i PM sviluppano le proprie idee, le loro specifiche diventano più exact, perché ora comprendono ciò di cui l’agente ha bisogno per eseguire bene. Specifiche più nitide producono un migliore output dell’agente. Un output migliore significa meno cicli di iterazione. Stiamo osservando un aumento della velocità di settimana in settimana, non solo perché i modelli sono migliorati, ma perché le persone che li utilizzano si sono avvicinate al lavoro.
Dmitry lo ha spiegato bene: il ciclo di suggestions tra intenzione e risultato è passato da settimane a minuti. Quando puoi vedere immediatamente il risultato delle tue specifiche, impari di quale precisione ha bisogno il sistema e inizi a fornirla istintivamente.
C’è un effetto di secondo ordine che è più difficile da misurare ma impossibile da non notare: la proprietà. La gente smette di aspettare. Smettono di presentare multe per cose che potrebbero semplicemente aggiustare. “Costruttore” ha smesso di essere un titolo professionale. È diventato il comportamento predefinito.
Cosa significa questo per il settore
Gran parte della narrativa “tutti possono programmare” lo scorso anno period teorica o focalizzata su fondatori singoli e piccoli group. Ciò che abbiamo vissuto è diverso. Abbiamo circa 50 ingegneri che lavorano in una complessa codebase brownfield: molteplici superfici e linguaggi di programmazione, integrazioni aziendali, tutto il peso di un sistema di produzione reale.
Non penso che siamo unici. Penso che siamo in anticipo. E con ogni nuova generazione di modelli, il divario tra chi può costruire e chi non può farlo si sta riducendo più velocemente di quanto la maggior parte delle organizzazioni si renda conto. Ogni azienda di software program sta per scoprire che i propri PM e progettisti si ritrovano con capacità di sviluppo non realizzate, bloccate non dalle competenze, ma dai costi di implementazione. Poiché story costo continua a diminuire, le implicazioni organizzative sono profonde.
Abbiamo iniziato con l’intento di accelerare l’ingegneria del software program. Ciò che stiamo diventando è qualcosa di diverso: un’azienda in cui tutti spediscono.
Andrew Filev è fondatore e CEO di Zencoder.
Benvenuto nella comunità VentureBeat!
Il nostro programma di visitor posting è il luogo in cui gli esperti tecnici condividono approfondimenti e forniscono approfondimenti neutrali e non conferiti su intelligenza artificiale, infrastruttura dati, sicurezza informatica e altre tecnologie all’avanguardia che plasmano il futuro dell’impresa.
Per saperne di più dal nostro programma di put up per gli ospiti e dai un’occhiata al nostro linee guida se sei interessato a contribuire con un tuo articolo!
