eSimphony è costruita da un team di ingegneria di cinque persone. Il prodotto copre oltre 150 Paesi, rilascia app native per iOS e Android, gestisce uno stack di integrazioni con operatori multi-regione, supporta cinque lingue dall'inizio alla fine e pubblica modifiche ogni settimana. Non siamo una telco da mille dipendenti. Siamo un piccolo team che lavora con una leva deliberata.

La leva nasce da un approccio preciso all'ingegneria che abbiamo interiorizzato negli ultimi 18 mesi. Lo chiamiamo sviluppo AI-native. Ecco com'è davvero nella pratica.

Com'è fatto il team

Cinque ingegneri. Un product designer. Un CEO che scrive ancora una parte delle specifiche di prodotto. Nessun product manager formale: le specifiche nascono dal CEO, da bozze assistite da Moza e dal giudizio di chi sviluppa. Nessun team QA dedicato: il testing fa parte del ciclo di sviluppo. Nessun DevOps separato: l'infrastruttura è di chi rilascia la funzionalità.

Non è un vanto. È un vincolo. Con un team di queste dimensioni, l'unico modo per rilasciare un prodotto ampio come eSimphony è moltiplicare la produttività di ogni ingegnere. L'AI è il moltiplicatore su cui abbiamo puntato.

Il flusso di lavoro in cinque fasi

Ogni modifica in eSimphony — dalla correzione di una frase a una nuova integrazione con un operatore — attraversa le stesse cinque fasi. Ogni fase è assistita dall'AI; ogni fase ha un essere umano dentro il ciclo.

1. Esplorazione (nessuna barriera tecnica)

Quando arriva un nuovo requisito («dobbiamo integrare l'operatore X per la copertura in Egitto»), la prima mossa dell'ingegnere non è dare per scontato ciò che non sa. È usare l'AI per esplorare il territorio sconosciuto in 20 minuti invece che in 2 giorni.

In pratica: un ingegnere che non ha mai integrato un MVNO egiziano può passare a un assistente AI la documentazione dell'API dell'operatore, ottenere una sintesi strutturata della superficie di integrazione, fare domande di approfondimento sui casi limite («qual è il tipico flusso di eKYC in questo mercato?») e produrre una valutazione di una pagina su sforzo, rischi e incognite prima di pranzo.

Cosa cambia: il collo di bottiglia non è più «abbiamo un ingegnere che conosce questo dominio?», ma «l'ingegnere che abbiamo, affiancato dall'AI, può diventare abbastanza competente in questo dominio in poche ore?». Quasi sempre la risposta è sì.

2. Specifiche (ore, non settimane)

Nella maggior parte delle aziende una specifica di prodotto richiede 1-3 settimane: un PM scrive la bozza, gli stakeholder la rivedono, si aggiungono i casi limite, si affinano i criteri di accettazione, poi l'ingegneria ridimensiona lo scope. Quando la specifica è «finita», l'opportunità iniziale si è già spostata.

Il nostro approccio: l'ingegnere (o il CEO, a seconda della funzionalità) butta giù l'idea di prodotto in una riga. L'AI la espande in un PRD strutturato: flusso utente, casi limite, metriche di successo, criteri di accettazione, domande aperte. Il team lo affina in una sessione di lavoro da 45 minuti. La specifica arriva all'ingegneria lo stesso giorno.

Il compromesso: le specifiche prodotte così sono un po' più grezze di una specifica tradizionale scritta da un PM in due settimane. Lo accettiamo. La compressione del tempo che porta alla prima implementazione vale l'ambiguità in più, che viene risolta durante lo sviluppo e non prima.

3. Design (ciclo di feedback rapido)

Per le funzionalità con un'interfaccia importante, il nostro designer lavora accanto all'ingegnere in un ciclo «design-sviluppo-feedback» misurato in minuti, non in giorni. I mockup generati dall'AI (plugin Figma più generatori di immagini) esplorano rapidamente le varianti. L'ingegnere rilascia un prototipo in poche ore. Il designer lo valuta su hardware reale. L'iterazione si misura in cicli nello stesso giorno.

Il risultato è che design e ingegneria non sono sequenziali: sono simultanei. Quando il design è «definitivo», l'implementazione è già a buon punto verso la produzione.

4. Sviluppo (il codice lo scrive l'AI; gli umani rivedono ogni diff)

È la parte AI-native più visibile. Il processo di ingegneria oggi in eSimphony:

L'AI genera circa il 90% del codice nuovo (Cursor, Claude, GitHub Copilot, spesso insieme)
Gli ingegneri scrivono le decisioni architetturali, i confini delle integrazioni, la logica di business più delicata che richiede una conoscenza profonda del sistema
Il 100% del codice viene rivisto da un umano prima del merge. Ogni diff. Ogni PR. Nessuna eccezione.

Quest'ultimo punto è cruciale e spesso frainteso. «Il codice lo scrive l'AI» non significa «nessun umano guarda il codice». Significa che il ruolo dell'ingegnere passa dallo scrivere l'implementazione al rivederla. Il lavoro cognitivo — corrisponde alla specifica? gestisce i casi limite? si incastra nell'architettura? regge la scala? — resta dell'ingegnere. Il lavoro meccanico — tradurre l'intenzione in codice sintatticamente corretto e idiomatico — è delegato.

Una PR tipica in eSimphony ha:

200-800 righe di codice modificate (contro le circa 100-200 dei team dell'era 2024)
1 ingegnere che la rivede nel dettaglio
Spesso test unitari generati dall'AI con oltre l'80% di copertura sul codice nuovo
Commenti del revisore concentrati sull'architettura, non sulla sintassi

5. Rilascio (adattarsi in pochi minuti)

Il rilascio è graduale: feature flag per le modifiche rischiose, deployment canary per i servizi di backend, telemetria monitorata dall'AI che fa emergere le anomalie entro pochi minuti dal rollout. Quando un rilascio rompe qualcosa, il rollback si misura in minuti, non in ore.

Sulla «telemetria monitorata dall'AI» vale una frase in più: dopo il deploy, un agente AI sorveglia le anomalie su tassi di errore, latenza, segnalazioni degli utenti e conversione. Quando le anomalie superano una soglia, l'ingegnere di turno riceve una notifica con la sintesi delle cause probabili. Questo comprime il tempo di rilevamento da «un utente segnala un bug alle 9» a «l'allarme scatta alle 09:03».

I numeri

Metriche approssimative degli ultimi 12 mesi:

Ciclo di sprint: 1 settimana. Le nuove funzionalità escono ogni settimana; le piccole correzioni ogni giorno.
5 ingegneri a tempo pieno sul prodotto. Un ingegnere aggiuntivo a contratto part-time.
Oltre il 90% del codice nuovo è generato dall'AI (soprattutto Cursor e Claude).
Il 100% del codice unito al main è stato rivisto da un umano.
Tempo mediano dalla specifica alla produzione: 5-10 giorni.
Incidenti in produzione per trimestre: 1-2. Sotto la media di settore per il nostro perimetro.
Ticket di assistenza escalati all'ingegneria: circa 5 a settimana. Quasi tutti risolti in giornata.

Non sono numeri teorici. Sono il ritmo operativo reale del nostro team.

Che cosa non è

Vale la pena essere espliciti su cosa NON significa lo sviluppo AI-native in eSimphony.

Non è «vibe coding». Il codice viene rivisto riga per riga. Le decisioni architetturali le prendono gli umani. L'AI accelera la digitazione, non il ragionamento.

Non è «niente test». I test generati dall'AI hanno debolezze precise (tendono a coprire i percorsi felici meglio dei casi limite), quindi gli ingegneri aggiungono test scritti a mano per i bordi. La copertura resta stabilmente sopra l'80% sul codice nuovo.

Non è «non servono ingegneri senior». Al contrario. L'AI aumenta enormemente il valore del giudizio senior, perché un ingegnere esperto può rivedere e rifinire l'output dell'AI 5-10 volte più in fretta di quanto lo scriverebbe da zero. Gli ingegneri junior che usano l'AI senza revisione senior tendono a produrre codice che compila ma è strutturalmente fragile.

Non è «niente design né pensiero di prodotto». L'AI è inutile senza specifiche chiare e flussi utente ben ragionati. Il lavoro cognitivo del «cosa costruiamo, perché e per chi» resta umano.

Che cosa richiede

Tre cose, in ordine di importanza.

1. Revisione umana rigorosa

Ogni riga di codice generata dall'AI passa dalla revisione di un ingegnere senior prima del merge. La tentazione di saltare la revisione per modifiche piccole e «ovviamente corrette» è reale e pericolosa. Abbiamo tenuto duro sul 100% di revisione.

2. Guardrail architetturali stretti

Quando l'AI genera codice, segue le convenzioni locali. Convenzioni forti significano output dell'AI forte. Abbiamo investito parecchio in confini di modulo chiari, naming coerente, interfacce ben tipizzate e documentazione esplicita di «come si fanno le cose qui», così l'AI può riconoscere i pattern con precisione.

3. Accettazione culturale dell'AI come impostazione predefinita

Il team ha concordato, esplicitamente, che l'assistenza dell'AI è la modalità predefinita in ogni flusso di lavoro. I nuovi ingegneri entrano in questa impostazione. Le obiezioni («ma preferisco scriverlo io») vengono ascoltate e discusse, ma la norma condivisa è che l'AI si occupa del lavoro meccanico, salvo che ci sia un motivo specifico per fare altrimenti.

Per cosa non usiamo l'AI

Rivedere il codice generato dall'AI (vogliamo occhi umani freschi)
Decidere cosa costruire (la strategia di prodotto è umana)
Le escalation dirette dell'assistenza clienti (i casi difficili li gestiscono le persone)
Le valutazioni delle prestazioni e i feedback al team (solo umani)
Le decisioni di assunzione (solo umane, con l'AI a supporto di ricerca e screening)

Lo schema è questo: l'AI potenzia l'esecuzione; gli umani possiedono le decisioni.

Perché tutto questo conta per il prodotto

Il risultato di questo flusso di lavoro si vede nel prodotto. Abbiamo rilasciato:

L'architettura della eSIM a vita (in quasi tutte le aziende sarebbe un progetto da più trimestri)
Moza, la compagna di viaggio AI, in cinque lingue
I piani dinamici con AI in tre regioni
La diagnostica AI con auto-riparazione
App native iOS e Android con rilasci settimanali
Un backend multi-regione con uptime superiore al 99,9%
La localizzazione in 5 lingue su tutta la superficie di prodotto

Di norma questa lista richiede 30-50 ingegneri e più di 3 anni. Noi l'abbiamo rilasciata con 5 ingegneri in 18 mesi.

Una nota sulle assunzioni

Stiamo facendo crescere il team con attenzione. Gli ingegneri che si trovano bene qui condividono tre tratti:

Giudizio più che produttività bruta. La digitazione la fa l'AI; noi cerchiamo ingegneri che eccellano nel rivedere, decidere e dare forma.
A proprio agio con l'AI come collega. Ingegneri che trattano l'AI come un compagno di lavoro (le delegano, la rivedono, la contraddicono) e non come un oracolo magico o come una minaccia alla propria identità.
Attenzione all'utente. I flussi AI-native sono abbastanza rapidi da produrre un mucchio di codice che compila ma non serve a nulla. Gli ingegneri che sanno ancorare ogni PR alla domanda «questo aiuta l'utente?» fanno il lavoro migliore.

Se ti riconosci, stiamo assumendo. Scrivici dalla pagina carriere oppure contatta Trung direttamente.

Cosa arriva dopo

Lo stesso flusso di lavoro che ha costruito il prodotto attuale sta rilasciando la roadmap:

Gestione multi-eSIM (maggio 2026)
Piani famiglia (giugno 2026)
Programma fedeltà e premi (agosto 2026)
Copertura mondiale con accordi diretti con gli operatori (2027)

Per una telco tradizionale ognuno di questi è un progetto da diversi mesi. Le nostre stime interne li vedono tutti e quattro in uscita nei tempi previsti, con lo stesso team di cinque persone.

Questa è la leva. Questa è la scommessa. È così che un team piccolo rilascia contro l'inerzia di un intero settore.

Guarda eSimphony all'opera, leggi il nostro posizionamento oppure dai un'occhiata alla presentazione da MVNO Nation Americas.

Come un team di 5 persone rilascia a 10×: ingegneria AI-native in eSimphony