La settimana scorsa, uno dei nostri product manager (PM) ha sviluppato e lanciato una funzionalità. Non specificato. Non è stato inviato alcun ticket per questo. L’ho costruito, testato e mandato in produzione. In un giorno.
Qualche giorno fa il nostro designer ha notato che l’aspetto visivo dei nostri plugin IDE si discostava dal sistema di progettazione. Nel vecchio mondo, ciò significava screenshot, un ticket JIRA, una conversazione che spiegava lo scopo e uno slot per lo sprint. Invece, ha aperto uno strumento, ha modificato lui stesso il layout, ha sperimentato in tempo reale, ha ripetuto e apportato modifiche, quindi ha applicato 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. Era un desiderio. Quando ho condiviso i dati su come i nostri ingegneri hanno raddoppiato la produttività, sono passati dalla codifica alla verifica, hanno portato la progettazione in primo piano per esperimenti rapidi, era ancora una storia di ingegneria. Ciò che è cambiato è stata la trasformazione della teoria in pratica. Ecco come funziona effettivamente.
Il collo di bottiglia si è spostato
Quando diamo priorità all’intelligenza artificiale nel 2025, i costi di implementazione crollano. I rappresentanti hanno preso in mano le impalcature, i test e il codice di colla ripetitivo che ha consumato metà dello sprint. I tempi di ciclo sono diminuiti da settimane a giorni a ore. Gli ingegneri hanno iniziato a pensare meno a file e funzioni e più ad architettura, vincoli e piani di esecuzione.
Ma una volta che la capacità ingegneristica non è più stata un collo di bottiglia, ci siamo resi conto di una cosa: la velocità del processo decisionale. Tutti i meccanismi di coordinamento che avevamo creato per preservare i tempi di progettazione (specifiche, richieste di supporto, delegati, riduzione del carico di lavoro) erano ora la parte più lenta del sistema. Stavamo ottimizzando per un vincolo che non esisteva più.
E se la costruzione fosse più economica del coordinamento?
Abbiamo iniziato a porci una domanda diversa: e se le persone più vicine alla causa potessero spedire direttamente il software?
I Project Manager stanno già pensando alle specifiche. I progettisti stanno già definendo struttura, layout e comportamento. Non pensano in termini di sintassi. Pensano alle conseguenze. Una volta che il costo di conversione delle intenzioni in software funzionante è diminuito a sufficienza, non è più necessario modificare questi ruoli. "Impara a programmare." Il costo di attuazione è semplicemente sceso al loro livello.
Ho chiesto a uno dei nostri primi ministri, Dmitrij, di spiegare cosa, dal suo punto di vista, è cambiato. Mi ha detto: "Ci sono alcuni minuti di inattività quando gli agenti creano attività in Zenflow. Solo aria morta. Volevo creare un piccolo gioco con cui puoi interagire mentre aspetti."
Se hai mai gestito un team di prodotto, conosci questo tipo di idee. Non sposta un KPI. Ciò è impossibile da giustificare in una riunione sulla definizione delle priorità. È rinviato per sempre. Ma aggiunge personalità. Dà al prodotto la sensazione che qualcuno abbia prestato attenzione ai piccoli dettagli. Queste sono esattamente le cose che vengono ottimizzate in ogni sessione di modifica del backlog e sono esattamente ciò che gli utenti ricordano.
L’ha costruito in un giorno.
In passato, questa idea sarebbe scomparsa nel foglio di calcolo delle priorità. Non perché sia un male, ma perché il costo dell’app rende irragionevole perseguirla. Quando questo costo si avvicina allo zero, il calcolo cambia completamente.
La spedizione è diventata più economica di quanto descritto
Man mano che sempre più persone iniziarono a costruire direttamente, interi strati del processo scomparvero silenziosamente. Meno biglietti. Meno trasferimenti. Meno "Puoi spiegare cosa intendi…" discorsi. Ci sono meno momenti persi nella traduzione.
Per una classe di compiti significativa, è diventato più veloce semplicemente costruire qualcosa, piuttosto che spiegare cosa si vuole e aspettare che qualcun altro lo faccia. Pensateci per un secondo. Ogni moderna organizzazione software è strutturata sul presupposto che l’implementazione sia la parte costosa. Quando questo presupposto viene meno, l’organizzazione deve cambiare con esso.
Un esempio perfetto è il nostro designer che aggiusta l’interfaccia utente del plugin. Il vecchio flusso di lavoro (fare uno screenshot del problema, segnalare, spiegare il divario tra intenti e implementazione, attendere la finestra dello sprint, rivedere il risultato, richiedere aggiustamenti) esisteva esclusivamente per risparmiare larghezza di banda ingegneristica. Tutto questo disordine scompare quando la persona dotata di intuito progettuale può agire direttamente. Non perché eliminiamo il processo fine a se stesso, ma perché il processo risolve un problema che non esiste più.
effetto della composizione
Ecco cosa mi ha sorpreso di più: si riunisce.
Quando i Project Manager creano le proprie idee, le loro specifiche diventano più precise perché ora capiscono di cosa ha bisogno il rappresentante per eseguirle bene. Funzionalità più nitide forniscono un migliore output dell’agente. Un output migliore significa meno cicli di iterazione. Ogni settimana vediamo una combinazione di velocità, non solo perché i modelli stanno migliorando, ma anche perché le persone che li utilizzano si avvicinano al lavoro.
Dmitry lo ha spiegato bene: il ciclo di feedback tra intenzione e risultato è passato da settimane a minuti. Quando vedi immediatamente il risultato delle tue specifiche, apprendi la precisione di cui il sistema ha bisogno 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 lamentarsi delle cose che possono aggiustare. "costruttore" Non è più un titolo professionale. È diventato il comportamento predefinito.
Cosa significa questo per il settore?
Molti "chiunque può programmare" La narrazione dell’anno scorso era teorica o focalizzata su fondatori solisti e piccoli team. Ciò che sperimentiamo è diverso. Abbiamo circa 50 ingegneri che lavorano su una complessa base di codice brownfield: molteplici sfaccettature e linguaggi di programmazione, integrazioni aziendali, tutto il peso di un vero sistema di produzione.
Non penso che siamo unici. Penso che siamo arrivati presto. 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 sta per scoprire che i propri Project Manager e progettisti si stanno concentrando sullo sviluppo di capacità non realizzate, ostacolato dai costi di implementazione, non dalle competenze. Poiché questo costo continua a diminuire, il suo impatto organizzativo si aggrava.
Abbiamo iniziato con l’intenzione di accelerare l’ingegneria del software. Ci stiamo evolvendo in qualcosa di diverso: un’azienda in cui tutti spediscono.
Andrew Filev è il fondatore e CEO di Zencoder.
