Dopo il coding: la commoditizzazione dell’implementazione

C’è un effetto dell’agentic coding di cui si parla ancora poco: non sta solo riducendo il costo di costruire software. Sta riducendo anche il costo di ricostruirlo.

La differenza non è banale.

Fino a poco tempo fa, anche avendo davanti un prodotto già esistente, copiarne il comportamento richiedeva comunque una quantità significativa di lavoro. Bisognava analizzare l’interfaccia, capire i flussi, ricostruire la logica, scegliere un’architettura, implementare frontend e backend, gestire edge case, testare tutto e correggere ciò che non funzionava.

Il fatto che il prodotto originale esistesse già eliminava il problema dell’idea, ma non quello dell’esecuzione.

Oggi quel secondo problema si sta comprimendo rapidamente.

Con gli strumenti attuali si può partire da screenshot, screen recording, documentazione, API pubbliche e comportamento osservabile di un’applicazione e trasformare tutto questo in una specifica abbastanza dettagliata da essere eseguita da uno o più agenti.

Il passaggio interessante è proprio questo: il software osservabile tende sempre più a diventare software descrivibile, e il software descrivibile tende sempre più a diventare software generabile.

Prendiamo un’app desktop abbastanza complessa.

Un agente può analizzare screenshot e ricavare una prima struttura dei componenti. Un secondo agente può implementare il layout. Un altro può lavorare sui flussi principali. Un altro ancora può generare test, confrontare il risultato con l’originale e correggere le differenze.

Se l’app usa comportamenti standard, gran parte della complessità non deve nemmeno essere dedotta. Esistono già pattern noti per autenticazione, sincronizzazione, command palette, drag and drop, sidebar, editor, gestione dello stato, caching, pagamenti e persistence.

Il modello non deve inventare un sistema nuovo. Deve riconoscere quale sistema probabilmente è stato usato e ricostruirne uno equivalente.

Questo cambia molto il significato di reverse engineering.

Tradizionalmente il reverse engineering software richiedeva una forte comprensione tecnica dell’oggetto che si stava analizzando. Oggi una parte crescente del lavoro può essere spostata dal reverse engineering dell’implementazione al reverse engineering del comportamento.

Non serve necessariamente sapere come è stato costruito il prodotto originale.

Serve capire cosa fa.

Se conosco input, output, flussi principali e vincoli osservabili, posso costruire un sistema diverso internamente ma sufficientemente simile dal punto di vista dell’utente.

Naturalmente ci sono limiti evidenti. Un’interfaccia può essere riprodotta molto più facilmente di un algoritmo proprietario. Un workflow può essere imitato più facilmente di un dataset costruito in dieci anni. Un SaaS CRUD è più semplice da ricostruire di un motore grafico, di un database distribuito o di un sistema con un forte componente infrastrutturale.

Ma una parte enorme del software commerciale non vive nella categoria dei problemi tecnicamente irripetibili.

Vive nella categoria dei problemi già risolti, assemblati bene e distribuiti meglio.

Ed è qui che l’agentic coding può diventare particolarmente destabilizzante.

Per anni, il codice ha rappresentato una barriera competitiva anche quando non conteneva nulla di straordinariamente innovativo.

Non perché fosse impossibile replicarlo, ma perché farlo costava.

• Serviva un team.
• Servivano settimane o mesi.
• Serviva qualcuno capace di occuparsi del frontend, qualcuno del backend, qualcuno dell’infrastruttura, qualcuno dei test.

Quel costo proteggeva indirettamente il prodotto. Oggi un singolo sviluppatore può delegare parti di quel lavoro a più agenti e coordinare il risultato. La produttività non cresce solo perché il codice viene scritto più velocemente. Cresce perché molte attività che prima erano seriali o richiedevano persone diverse possono essere eseguite in parallelo.

A quel punto la domanda diventa inevitabile: cosa succede quando il costo di replica di una feature scende sotto il valore economico della feature stessa?

Immaginiamo che un’azienda introduca qualcosa di realmente utile. Fino a ieri un concorrente poteva impiegare sei mesi per replicarla. Oggi potrebbe impiegarne uno. Domani magari una settimana.

Il vantaggio temporale esiste ancora, ma ha una durata molto più breve.

Questo non significa che tutti i software diventeranno indistinguibili. Significa piuttosto che molte differenze puramente implementative avranno una vita più corta. Anche il concetto di moat tecnico va quindi usato con maggiore cautela. Avere una codebase complessa non significa necessariamente avere una barriera competitiva. Avere dieci anni di codice non significa necessariamente avere dieci anni di vantaggio. In alcuni casi significa semplicemente avere dieci anni di decisioni tecniche accumulate, molte delle quali possono essere evitate da chi arriva dopo. Il nuovo concorrente non deve necessariamente replicare la tua architettura. Deve replicare il valore percepito dall’utente. E può farlo con uno stack completamente diverso.

Questa è forse la parte più interessante: l’AI non accelera soltanto chi costruisce per primo. Accelera anche chi arriva secondo.

Anzi, in alcuni casi chi arriva secondo può avere un vantaggio.

• Ha già davanti un prodotto validato.
• Conosce le feature che gli utenti usano.
• Può osservare quali scelte di design hanno funzionato.
• Può evitare anni di tentativi sbagliati.
• E ora può anche comprimere enormemente il costo dell’implementazione.

Il first mover continua ad avere dei vantaggi, ma una parte del vantaggio derivante semplicemente dall’aver scritto il software prima degli altri si riduce.

Questo sposta il valore verso elementi più difficili da ricostruire da screenshot e documentazione.

• Distribuzione.
• Dati proprietari.
• Network effect.
• Community.
• Reputazione.
• Accordi commerciali.
• Integrazioni difficili da ottenere.
• Conoscenza del dominio.
• Capacità di iterare più velocemente degli altri.

Anche quest’ultimo punto è importante.

Se tutti possono copiare una feature, il vantaggio non è più possedere quella feature. Il vantaggio può diventare essere già alla feature successiva quando gli altri finiscono di copiarla.

La velocità quindi non scompare come vantaggio competitivo. Cambia forma.

Prima poteva significare “riusciamo a costruire qualcosa che gli altri non riescono a costruire”. Sempre più spesso potrebbe significare “riusciamo a capire prima degli altri cosa vale la pena costruire dopo”. È una differenza sostanziale. Scrivere codice e decidere cosa scrivere sono sempre state due competenze diverse. L’AI sta abbassando molto più rapidamente il costo della prima rispetto alla seconda. Ed è probabilmente qui che nasce la sensazione di vedere improvvisamente comparire cloni di prodotti che fino a poco tempo fa avrebbero richiesto team interi.

Non è solo una democratizzazione dello sviluppo.

È una democratizzazione della capacità di replica.

La stessa tecnologia che permette a una persona di costruire qualcosa che prima richiedeva dieci sviluppatori permette a quella stessa persona di ricostruire qualcosa che prima richiedeva dieci sviluppatori. Le due cose sono inseparabili. Ed è difficile immaginare che questo non abbia conseguenze sull’economia del software.

Potremmo arrivare a un punto in cui produrre un’applicazione funzionante diventa relativamente economico, mentre diventano sempre più costose tutte le cose che non possono essere generate automaticamente: trovare utenti, conquistarne la fiducia, ottenere dati, costruire una community, capire un mercato e prendere continuamente decisioni corrette.

✨ Il codice continuerà a contare. Semplicemente, potrebbe non essere più la parte difficile da copiare.