L'Intelligenza Artificiale sta trasformando i Software Engineer in Product Engineer?

La Notte Prima del Fallimento

Sono le 3:47 del mattino. Le luci dell'ufficio bruciano ancora come fari nella notte, mentre fuori Milano dorme ignara del dramma che si sta consumando al ventesimo piano di un grattacielo di Porta Nuova.

Lorenzo, software engineer con otto anni di esperienza e una reputazione costruita riga per riga di codice pulito, fissa lo schermo con gli occhi arrossati. Intorno a lui, il team è sparso tra scrivanie ingombre di energy drink vuoti e post-it colorati che ormai nessuno legge più. La deadline del progetto più importante dell'anno è tra diciotto ore.

E tutto sta andando a rotoli.

Non doveva essere così. Tre mesi fa, quando il progetto era iniziato, l'entusiasmo era alle stelle. Avevano abbracciato la rivoluzione dell'AI con la passione di pionieri digitali. Cursor, Windsurf, GitHub Copilot: tutto l'arsenale dell'intelligenza artificiale era schierato per garantire velocità e precisione senza precedenti. "Vibe coding" era diventata la parola d'ordine del team.

"Con l'AI genereremo codice in modo esplosivo!" aveva dichiarato Lorenzo durante la prima riunione, gli occhi che brillavano di eccitazione tecnologica.

E in effetti, il codice era stato generato. Tantissimo codice. Velocemente. Forse troppo velocemente.

Ora, mentre scorre attraverso migliaia di righe di codice AI-generato, Lorenzo si rende conto dell'amara verità: avere molto codice non significa avere un buon prodotto.

Bug incomprensibili spuntano come funghi dopo la pioggia. Una funzionalità che sembrava funzionare perfettamente ieri sera ora produce errori misteriosi. Il sistema di autenticazione, generato in cinque minuti dall'AI, ha più buchi di un formaggio svizzero. E non parliamo delle chiavi API integrate chissà dove nel codice, una bomba a orologeria per la sicurezza.

Il cliente, che dovrebbe ricevere la demo tra poche ore, aveva richiesto qualcosa di apparentemente semplice: "Vogliamo un'app che permetta ai nostri utenti di gestire facilmente i loro progetti, con un'interfaccia intuitiva e tutte le funzionalità essenziali."

Semplice, no?

Macché semplice.

Il team aveva interpretato "tutte le funzionalità essenziali" come un invito a implementare ogni feature che l'AI potesse suggerire. Il risultato? Un mostro digitale che fa tutto e non fa niente bene. L'interfaccia è un patchwork di componenti che non dialogano tra loro, la user experience è un percorso a ostacoli, e la performance... beh, meglio non parlarne.

Lorenzo si passa una mano tra i capelli, mentre una domanda martellante gli risuona nella testa: "Abbiamo sbagliato a fidarci dell'AI? Il vibe coding è solo una moda pericolosa? O c'è qualcosa di fondamentale che non abbiamo capito?"

La sua identità professionale, costruita negli anni sulla maestria del codice manuale, sulla eleganza degli algoritmi scritti con cura certosina, è in frantumi. La velocità promessa dall'AI si è rivelata un nemico subdolo della qualità e della manutenibilità.

Guarda l'orologio: 4:23. In sottofondo, Giulia, la designer UX del team, sta ancora cercando di capire perché l'AI ha deciso di aggiungere tre librerie di animazioni diverse per un semplice bottone.

Cosa è andato storto? Era davvero l'AI il problema, o il modo in cui è stata usata?

C'è una via d'uscita da questo caos generato dall'intelligenza artificiale?

E soprattutto: il futuro del software engineer è davvero solo scrivere prompt sempre più sofisticati?

La risposta a queste domande non è solo nelle mani di Lorenzo, ma nell'evoluzione stessa di una professione che sta vivendo la sua trasformazione più radicale dagli albori del web.

Non è la Fine, è l'Evoluzione

Fermiamoci un attimo. Respiriamo.

L'intelligenza artificiale non sta rendendo obsoleti i software engineer.

Punto. Fine della discussione apocalittica.

Quello che sta accadendo è molto più interessante e, francamente, molto più entusiasmante: l'AI sta trasformando radicalmente il ruolo del software engineer, spingendolo verso una dimensione completamente nuova.

Pensaci: quando è stata l'ultima volta che hai visto un operaio edile costruire un grattacielo usando solo martello e scalpello? Eppure gli operai edili esistono ancora, anzi, sono più importanti che mai. Hanno semplicemente imparato a usare gru, escavatrici e tecnologie avanzate.

Il loro valore non è diminuito: si è evoluto.

Lo stesso sta accadendo nel mondo dello sviluppo software. L'AI si sta assumendo una parte crescente delle attività di codifica tradizionali - quella roba ripetitiva, noiosa, che facevamo perché qualcuno doveva pur farla. Ma il vero valore del software engineer moderno non risiede più nella capacità di scrivere codice impeccabile partendo da zero.

Il nuovo valore sta nel diventare "Product Engineer".

Cosa significa? Significa che il software engineer del futuro (anzi, del presente) non è più solo uno specialista tecnico, ma diventa una figura strategica che sa:

• Comprendere profondamente le esigenze degli utenti - non solo tradurre specifiche tecniche, ma capire perché l'utente ha quel problema

• Definire requisiti chiari e precisi - perché l'AI è brava a eseguire, ma qualcuno deve dirle cosa eseguire

• Prendere decisioni architetturali di alto livello - progettare sistemi che funzionano nel mondo reale, non solo sulla carta

• Comunicare efficacemente con gli strumenti AI - il "prompt engineering" non è magia, è una skill tecnica sofisticata

• Pensare sistemicamente - vedere il prodotto come un insieme coerente, non come una collezione di feature

Ti sembra una trasformazione da poco? Io la chiamo la più grande opportunità professionale degli ultimi vent'anni.

Per comprendere questa evoluzione, esploreremo insieme i diversi "petali" che definiscono questa nuova figura del "Product Engineer" nell'era dell'AI assistito. Ogni petalo rappresenta una competenza diventata cruciale, spesso potenziata (ma mai sostituita) dall'intelligenza artificiale.

Sei pronto a scoprire come trasformare la crisi di Lorenzo in una storia di successo?

Iniziamo dal primo petalo: l'arte di parlare con la macchina.

L'Arte di Parlare con la Macchina - Dal Codice al "Prompt Engineering"

"Crea una funzione per gestire l'autenticazione utente."

Questo è quello che Lorenzo aveva chiesto all'AI tre mesi fa. Risultato? Una funzione che tecnicamente gestiva l'autenticazione, ma che aveva più falle di sicurezza di un castello di sabbia sotto la marea.

Ecco il primo errore madornale: credere che il prompt engineering sia questione di fortuna o di magia.

Non è così. È una disciplina tecnica precisa quanto scrivere codice, forse anche di più. La differenza è che invece di parlare in linguaggio macchina, parli in linguaggio... beh, umano. Ma questo non significa che sia più facile.

Facciamo un esperimento mentale. Confronta questi due prompt:

Prompt generico: "Crea un componente per mostrare i dati utente"

Prompt specifico: "Crea un componente React TypeScript chiamato UserProfile che riceve props (name: string, email: string, avatar?: string, role: 'admin' | 'user' | 'guest'). Il componente deve mostrare l'avatar in un cerchio di 64px (con fallback alle iniziali se l'avatar non c'è), il nome in grassetto sotto l'avatar, l'email in grigio più piccolo, e un badge colorato per il ruolo (verde per admin, blu per user, grigio per guest). Usa Tailwind CSS per lo styling e assicurati che sia responsive."

Indovina quale dei due produce risultati utilizzabili al primo colpo?

Il prompt engineering è l'arte di essere specifici senza essere rigidi, dettagliati senza essere verbosi, chiari senza essere banali.

Quando usi strumenti come Cursor, devi fornire contesto. Non basta dire "aggiusta questo bug" - devi spiegare cosa dovrebbe fare il codice, in che contesto viene utilizzato, quali sono gli edge case da considerare. Windsurf, per esempio, usa interi documenti come contesto: se non organizzi bene la tua documentazione, l'AI brancola nel buio quanto te.

Ma attenzione: dominare il prompt engineering non ti rende automaticamente un bravo software engineer.

Ecco il paradosso che molti non capiscono: più diventi bravo a comunicare con l'AI, più ti rendi conto di quanto sia fondamentale la tua formazione tecnica tradizionale. Perché?

Primo: L'AI può generare codice che "fa qualcosa", ma senza competenze tecniche approfondite non riesci a valutare se quel "qualcosa" è quello giusto. È come avere un assistente che sa scrivere lettere perfette in una lingua che non conosci - come fai a sapere se sta dicendo quello che vuoi dire?

Secondo: I bug nel codice AI-generato sono spesso subdoli e difficili da identificare. Richiedono un occhio esperto per essere scovati. L'AI può nascondere la complessità, ma la complessità è ancora lì, ed è tua responsabilità gestirla.

Terzo: L'AI prende decisioni architetturali di cui spesso non ti accorgi. Aggiunge librerie, modifica strutture dati, introduce pattern che magari non erano nelle tue intenzioni. Se non capisci le implicazioni di queste scelte - perché ti manca la base tecnica - il tuo progetto diventa un castello di carte.

Quarto: La sicurezza rimane una responsabilità umana al 100%. L'AI può scrivere codice vulnerabile senza battere ciglio, e se non hai le competenze per riconoscere i problemi, sei fregato.

Ecco dove entra in gioco il concetto di "Product Engineer": il prompt engineering diventa uno strumento potente al servizio della tua visione del prodotto.

Un software engineer con una forte comprensione del prodotto e dei requisiti sa fare le domande giuste all'AI. Non chiede genericamente "crea un sistema di notifiche", ma specifica: "Crea un sistema di notifiche che supporti notifiche push, email e in-app, con priorità (alta, media, bassa), categorizzazione per tipo di evento, e la possibilità per l'utente di configurare le sue preferenze. Le notifiche devono essere persistenti, tracciabili, e supportare template personalizzabili. Generami i task per implementare passo passo il sistema di notifiche e li eseguiremo assieme uno alla volta."

Vedi la differenza? Non stai solo chiedendo codice, stai guidando l'AI verso la tua visione strategica.

Il prompt engineering, quando fatto bene, trasforma l'AI da semplice "scrittore di codice" a "co-costruttore guidato" del tuo prodotto. Ma la guida, la visione, la strategia - quella rimane tua.

Ed è qui che inizia il secondo petalo della nostra trasformazione: definire il "cosa" e il "perché" prima ancora di pensare al "come".

Definire il "Cosa" e il "Perché" - Requisiti ed Esigenze Utente al Centro

Torniamo alla storia di Lorenzo per un momento. Ricordi la richiesta del cliente? "Vogliamo un'app che permetta ai nostri utenti di gestire facilmente i loro progetti, con un'interfaccia intuitiva e tutte le funzionalità essenziali."

Lorenzo e il suo team avevano interpretato questa frase come: "Fate quello che vi pare, basta che funzioni."

Errore fatale numero due: confondere la libertà creativa con l'assenza di direzione.

Ecco una verità scomoda che molti software engineer faticano ad accettare: un software tecnicamente perfetto che non risolve il problema giusto vale zero euro. Anzi, vale meno di zero, perché hai sprecato tempo, soldi e risorse per creare qualcosa di inutile.

La qualità del software non si misura in linee di codice eleganti o in architetture sofisticate. La qualità è quanto riesci ad azzerare il divario tra ciò che il cliente ha in testa e ciò che il software fa realmente.

E qui entra in gioco una delle competenze più sottovalutate del "Product Engineer": l'arte di definire requisiti.

I Product Requirements Documents (PRD) sono diventati lo strumento principale per specificare cosa deve fare un'applicazione. Ma - e qui viene il bello - nell'era dell'AI i PRD diventano ancora più cruciali, per un motivo molto semplice: l'AI è incredibilmente brava a eseguire istruzioni precise, ma è completamente persa quando le istruzioni sono vaghe.

Facciamo un esempio pratico. Confronta questi due approcci:

Approccio vago: "Vogliamo una dashboard per i progetti. Deve essere bella e funzionale."

Approccio strutturato: *"La dashboard deve mostrare:

• Lista dei progetti attivi con progresso visuale (barra percentuale)

• Ultimi 5 task completati per progetto

• Prossime 3 deadline con evidenziazione di quelle critiche (< 7 giorni)

• Grafico andamento completamento task ultimi 30 giorni

• Quick action per creare nuovo progetto o task

• Filtri per status progetto (attivo, in pausa, completato)

• Vista griglia o lista toggle Target: caricamento < 2 secondi, responsive design, accessibile (WCAG AA)"*

Indovina quale dei due approcci produce risultati migliori quando li dai in pasto all'AI?

Ma c'è un dibattito interessante nella community: quanto dettagliato deve essere un PRD nell'era dell'AI?

Team "Inizio Vago": Un PRD troppo specifico limita la creatività dell'AI e può portare a soluzioni rigide. Meglio dare direzioni generali e lasciare che l'AI suggerisca implementazioni innovative.

Team "Idea Chiara": Un PRD dettagliato permette all'AI di lavorare con precisione chirurgica. Conosce esattamente cosa deve fare e può concentrarsi sull'implementazione ottimale.

La mia posizione? Dipende dalla fase del progetto e dalla complessità del dominio.

Per prototipi e proof of concept, un approccio più vago può stimolare soluzioni creative inaspettate. Per prodotti enterprise o con requisiti di sicurezza stringenti, la precisione è fondamentale.

Ma ecco dove l'AI diventa davvero interessante: può aiutarti a creare e migliorare i PRD stessi.

Prova questo esperimento: dai all'AI una descrizione vaga del tuo prodotto e chiedi di generare domande per colmare le lacune nella visione. Risultato? Una lista di domande che spesso non ti erano nemmeno venute in mente:

*"Per la funzionalità di gestione progetti che hai descritto, ho alcune domande:

• Gli utenti possono collaborare sui progetti o sono individuali?

• C'è una gerarchia di permessi (owner, editor, viewer)?

• I progetti hanno template predefiniti o sono tutti custom?

• Come gestisci i progetti ricorrenti?

• C'è integrazione con strumenti esterni (calendar, email, Slack)?

• Qual è il volume massimo di progetti per utente?

• Serve storico delle modifiche?

• Come gestisci i progetti archiviati?"*

Questo è "vibe PMing" - usare l'AI per scrivere specifiche con il tuo feedback iterativo. L'AI fa le domande giuste, tu fornisci le risposte strategiche.

Ma attenzione: tu rimani il decisore finale. L'AI può suggerire, può porre domande intelligenti, può anche aiutarti a strutturare i requisiti in modo più chiaro. Ma la visione del prodotto, la comprensione delle esigenze del business, la prioritizzazione delle feature - quella responsabilità rimane completamente tua.

Ed è qui che si cristallizza il cambiamento fondamentale: il software engineer "Product Engineer" non è più solo l'implementatore di specifiche altrui, ma diventa l'interfaccia attiva tra l'idea (spesso vaga) del cliente e l'esecuzione tecnica.

Devi capire perché l'utente ha quel problema, non solo come risolverlo tecnicamente. Devi tradurre bisogni di business in requisiti funzionali. Devi fare da ponte tra il mondo degli stakeholder e il mondo del codice.

E una volta che hai chiaro il "cosa" e il "perché", devi decidere il "come" a livello architetturale.

È ora di parlare del terzo petalo: come disegnare la struttura.

Disegnare la Struttura - Architettura di Alto Livello e Pensiero Sistemico

L'AI è una ferrari nella generazione di singoli componenti. Gli dici "crea una funzione per validare email" e ti tira fuori un gioiellino che gestisce tutti i casi edge che ti venivano in mente e anche quelli che non ti venivano.

Ma prova a chiederle di progettare un sistema completo e scalabile.

Spoiler: non ci riesce.

Non perché sia stupida - anzi, è incredibilmente intelligente. Ma perché progettare un'architettura software richiede una visione d'insieme che va oltre la singola funzione, oltre il singolo modulo, oltre il singolo problema da risolvere.

Richiede pensiero sistemico.

Torniamo alla disavventura di Lorenzo. Il problema non era che l'AI generasse codice sbagliato - tecnicamente, la maggior parte del codice funzionava. Il problema era che ogni pezzo funzionava in isolamento, senza una logica unitaria che li tenesse insieme.

Il sistema di autenticazione usava JWT. Il sistema di notifiche usava WebSocket. Il sistema di file upload usava una libreria diversa per la gestione degli errori. Ogni componente aveva le sue convenzioni, i suoi pattern, le sue dipendenze.

Risultato? Un'architettura frankenstein che nessuno riusciva più a capire.

Ed è qui che l'architettura modulare diventa non meno importante nell'era AI, ma più importante che mai.

Perché? Te lo spiego con tre ragioni concrete:

Primo: Gestire la complessità del codice generato. L'AI può creare codice molto sofisticato, ma a volte difficile da leggere e comprendere. Se tutto è un unico blob monolitico, quando qualcosa si rompe (e si romperà), sei fregato. Con un'architettura modulare, puoi isolare il problema e risolverlo senza toccare il resto del sistema.

Secondo: Limitazioni delle finestre di contesto degli LLM. Gli AI hanno un limite su quanto codice riescono a "vedere" contemporaneamente. Se lavori su moduli più piccoli e ben definiti, l'AI riesce ad avere il contesto completo del pezzo su cui sta lavorando. Se invece hai un monolite di 50.000 righe, l'AI vede solo una frazione del codice e perde il quadro d'insieme.

Terzo: Manutenibilità a lungo termine. Un sistema modulare è più facile da capire, testare e modificare. Quando tra sei mesi dovrai aggiungere una feature o correggere un bug, preferirai avere 20 moduli da 200 righe ciascuno o un singolo file da 4000 righe generato dall'AI?

Ma facciamo esempi concreti. Considera la scelta tra Next.js e una soluzione come Encore per i microservizi.

Next.js ti offre un approccio full-stack integrato. Frontend e backend nello stesso progetto, deployment semplificato, ottime performance. Per molti progetti è la scelta giusta. Ma se il tuo sistema ha componenti con cicli di vita diversi, scale diverse, o team diversi che ci lavorano, un approccio monolitico può diventare un collo di bottiglia.

Encore, invece, è progettato per rendere più facile creare backend modulari e distribuiti. Ogni servizio ha le sue responsabilità, le sue dipendenze, i suoi pattern di deployment. L'AI può lavorare su un servizio alla volta senza perdere il contesto.

La scelta tra i due non è una questione di "giusto o sbagliato", ma di adattare l'architettura al problema specifico che stai risolvendo.

E qui casca l'asino. Molti software engineer, affascinati dalla potenza dell'AI, costruiscono architetture complesse troppo presto. Pensano: "Con l'AI posso gestire facilmente microservizi, Kubernetes, event sourcing, CQRS..."

Errore!

La complessità architettuale dovrebbe crescere insieme alle necessità reali, non alle possibilità tecniche. Un'app con 100 utenti non ha bisogno della stessa architettura di una piattaforma con 10 milioni di utenti.

Il principio del "Product Engineer": inizia semplice, ma progetta per l'evoluzione. Crea un'architettura che può crescere quando serve, senza sovra-ingegnerizzare da subito.

Come fai? Pensiero sistemico.

Il "Product Engineer" non vede il software come una collezione di funzioni da implementare, ma come un sistema interconnesso di componenti che devono lavorare insieme per risolvere un problema di business.

Deve prendere decisioni su:

• Come frontend e backend comunicheranno (REST? GraphQL? WebSocket?)

• Come gestire lo stato dell'applicazione (client-side? server-side? ibrido?)

• Come strutturare il database (relazionale? NoSQL? ibrido?)

• Come gestire i job asincroni (background processing, scheduled tasks)

• Come implementare caching e performance optimization

• Come gestire deploy, monitoring, logging

Queste sono decisioni che l'AI non può (ancora) prendere per te. Richiedono una comprensione del business, degli utenti, dei vincoli di performance, dei budget, dei timeline.

L'AI può aiutarti a implementare la tua visione architettuale, ma la visione deve essere tua.

Può generare boilerplate per nuovi moduli, suggerire pattern di integrazione, persino proporre tecnologie che non conoscevi. Ma tu devi validare che le sue proposte si integrino con la tua strategia complessiva.

Esempio pratico: chiedi all'AI di creare un sistema di notifiche. Potrebbe suggerirti una soluzione websocket real-time molto sofisticata. Perfetto! Ma tu devi chiederti: i miei utenti hanno davvero bisogno di notifiche real-time? Vale la pena della complessità aggiuntiva? Come si integra con il resto dell'architettura?

L'AI fornisce possibilità, tu fornisci direzione strategica.

E parlando di direzione strategica, arriviamo a uno dei dilemmi più scottanti dell'era AI: come bilanciare la velocità esplosiva del vibe coding con la qualità sostenibile a lungo termine.

Spoiler: non è facile, ma si può fare.

La Sfida della Velocità Controllata - Bilanciare "Vibe Coding" e Qualità Sostenibile

Confessiamolo: il vibe coding è una droga.

La sensazione di vedere codice che si materializza sullo schermo a velocità supersonica, funzionalità che prendono forma in minuti invece che ore, prototipi che nascono quasi in tempo reale mentre parli con il cliente... è inebriante.

"Meglio uscire il prima possibile con un prodotto sgangherato e mezzo fatto piuttosto che stare infinitamente in fase di staging" - questo è il mantra del vibe coding. E ha una sua logica: nel mondo startup, la velocità può fare la differenza tra successo e fallimento.

Ma c'è un "ma" grande come una casa.

La velocità senza direzione è solo caos in accelerazione. E Lorenzo lo ha imparato sulla sua pelle quella notte prima della deadline.

Il problema del vibe coding non è filosofico, è brutalmente pratico: quando generi codice velocemente senza una strategia chiara, accumuli debito tecnico a ritmi esponenziali.

Cosa significa? Significa che ogni shortcut che prendi oggi ti costerà 10 volte tanto in futuro. Ogni convenzione ignorata, ogni test non scritto, ogni refactoring rimandato si accumula in una massa critica che prima o poi esplode.

E quando esplode, non sono belli.

Ma questo non significa che il vibe coding sia intrinsecamente sbagliato. Significa che va controllato e bilanciato.

Facciamo un esempio. L'AI genera un componente React per te in 30 secondi. Perfetto! Ma quel componente:

• Usa nomi di variabili diversi dal resto del tuo codebase

• Importa una libreria di animazioni che non stavi usando prima

• Ha una struttura CSS che non si integra con il tuo design system

• Non ha test

• Non ha gestione degli errori

• Non ha accessibility

Funziona? Sì. È produzione-ready? Assolutamente no.

Ed è qui che entra in gioco l'equilibrio. Il "Product Engineer" sa quando spingere sull'acceleratore e quando frenare.

Fase di prototipazione rapida? Vibe coding a manetta. L'importante è validare l'idea, capire se la direzione è giusta, raccogliere feedback. La qualità del codice è secondaria.

Fase di sviluppo produzione? Qualità controllata. Ogni pezzo di codice generato dall'AI deve passare attraverso filtri di qualità rigorosi.

Ma come fai praticamente? Ecco le strategie che funzionano davvero:

Strategia 1: Test Automatici - Il Tuo Salvavita

Regola d'oro: per ogni funzionalità che l'AI genera, chiedi immediatamente di scrivere i test.

Non "quando ho tempo". Non "più tardi". Immediatamente.

Perché? Perché i test sono la tua rete di sicurezza. Ti permettono di:

• Verificare che il codice faccia quello che deve fare

• Catturare regressioni quando modifichi altre parti del sistema

• Documentare il comportamento atteso della funzione

• Rifattorizzare con confidenza

Esempio pratico:

"Hai creato questa funzione per validare email. Ora scrivi i test che verifichino:
- Email valide passano la validazione
- Email invalide vengono rifiutate
- Casi edge come email molto lunghe, con caratteri speciali, domini esotici
- Gestione di input null/undefined"

Strategia 2: Revisione Umana - Il Tuo Filtro Qualità

L'AI può generare codice tecnicamente corretto ma architetturalmente sbagliato. Solo l'occhio umano esperto può identificare:

• Inefficienze algoritmiche

• Problemi di performance

• Violazioni dei principi SOLID

• Accoppiamento eccessivo tra componenti

• Vulnerabilità di sicurezza

Non saltare mai la revisione. Anche se hai fretta. Anche se "sembra tutto ok". Anche se l'AI ti ha convinto che il codice è perfetto.

Strategia 3: Convenzioni e Regole - Il Tuo Framework di Controllo

Usa strumenti come Cursor Rules per definire standard di progetto che l'AI deve rispettare:

"Per questo progetto:
- Usa sempre TypeScript strict mode
- Nomi di variabili in camelCase
- Nomi di componenti React in PascalCase
- Preferisci functional components con hooks
- Usa solo queste librerie approvate: [lista]
- Ogni funzione pubblica deve avere JSDoc
- Maximum cyclomatic complexity: 10"

Qui puoi trovare degli esempi di Cursor Rules per i principali stack tecnologici.
A proposito, ti interesserebbe vedere come le stiamo utilizzando in Learnn?
Fammelo sapere nei commenti.

Strategia 4: Architettura Modulare - Il Tuo Salvagente

Ritorna il concetto del Petalo 3: un'architettura ben strutturata rende il codice AI-generato più gestibile.

Se ogni modulo ha responsabilità chiare, è più facile:

• Identificare dove mettere nuove funzionalità

• Isolare problemi quando qualcosa va storto

• Sostituire parti del sistema senza rompere tutto

• Far lavorare l'AI su pezzi più piccoli e comprensibili

La Mentalità del "Product Engineer"

Il "Product Engineer" capisce che velocità e qualità non sono nemici, ma partner in una danza complessa.

Sa che in alcune fasi del progetto la velocità è prioritaria (validazione idee, prototipazione rapida, demo per investitori). In altre fasi, la qualità è non negoziabile (codice produzione, features critiche, sistemi di sicurezza).

Sa quando dire "facciamo veloce" e quando dire "facciamo bene".

Ma soprattutto, sa che questa tensione tra velocità e qualità non si risolve una volta per tutte. È una decisione che deve prendere continuamente, per ogni feature, per ogni sprint, per ogni fase del prodotto.

E parlando di decisioni continue e critiche, arriviamo a un aspetto che non puoi mai, mai delegare completamente all'AI: la sicurezza.

L'Occhio Vigile Umano - Sicurezza e Debugging Cruciali

C'era una volta un software engineer che pensò: "L'AI è così intelligente, può sicuramente gestire anche la sicurezza della mia applicazione. Tanto sa tutto, no?"

Quella persona oggi non lavora più come software engineer.

Non è una barzelletta. È una storia vera di cui ho sentito parlare in conference room aziendali, con toni molto meno divertiti di quanto potresti immaginare.

Il protagonista aveva affidato all'AI la gestione delle chiavi API, delle credenziali del database, dei token di autenticazione. L'AI aveva fatto quello che le era stato chiesto: aveva creato un sistema che funzionava. Peccato che fosse anche pieno di buchi.

Risultato? Violazione dei dati. Clienti incazzati. Cause legali. Fine della carriera.

La lezione è brutale ma chiara: la sicurezza è una responsabilità che non puoi mai, mai delegare completamente all'AI.

Perché? Te lo spiego con esempi concreti:

L'AI non capisce il contesto di sicurezza. Può generare codice che implementa correttamente un algoritmo di hashing, ma non sa se quel hash va usato per password utente o per checksumming di file. Non sa se quei dati vanno crittografati, se quella connessione deve essere HTTPS, se quell'input deve essere sanitizzato.

L'AI non ha paranoia. La sicurezza richiede una mentalità pessimista: "Cosa può andare storto? Come può essere abusato questo codice? Quali sono gli scenari di attacco?" L'AI, per natura, è ottimista. Genera codice che funziona nel caso normale, non nel caso di un attacco.

L'AI non conosce il threat model del tuo sistema. Se stai costruendo un e-commerce, i rischi sono diversi da quelli di un social network o di un sistema bancario. L'AI non sa contro cosa ti stai difendendo.

Le Aree Rosse - Dove L'AI Non Deve Mai Lavorare Da Sola

Ecco le aree critiche dove la supervisione umana è non negoziabile:

1. Gestione delle credenziali: Chiavi API, password database, certificati SSL, token JWT. Se l'AI tocca queste cose senza la tua supervisione diretta, sei in pericolo.

2. Validazione input utente: SQL injection, XSS, CSRF, file upload vulnerabilities. L'AI può implementare validazioni, ma tu devi verificare che siano complete e corrette.

3. Controllo accessi e autorizzazioni: Chi può fare cosa, quando e come. Logiche di permessi complesse sono facili da sbagliare anche per l'AI.

4. Logging e auditing: Cosa loggare, cosa non loggare (hint: mai loggare password o dati sensibili), come strutturare i log per il debugging e la compliance.

Il Debugging - L'Achille dell'AI

E poi c'è il debugging. L'AI è pessima nel debugging.

Non è colpa sua, in realtà. Il debugging richiede capacità che vanno oltre la generazione di codice:

Comprensione del flusso di esecuzione. Quando un bug si manifesta, devi seguire il percorso che i dati fanno attraverso il sistema. L'AI spesso vede solo il frammento di codice che sta generando, non l'intero flusso.

Analisi delle interazioni tra componenti. I bug più subdoli nascono dall'interazione tra parti diverse del sistema. L'AI fatica a vedere queste interdipendenze.

Intuizione e pattern recognition. Un debugger esperto riconosce pattern ricorrenti, sintomi tipici di certi tipi di problemi. L'AI non ha questa esperienza accumulata.

Capacità di ipotesi multiple. Il debugging è spesso un processo di eliminazione: provi ipotesi diverse fino a trovare quella giusta. L'AI tende a perseguire una singola linea di ragionamento.

Esempio Pratico: Il Bug Invisibile

Ti racconto una storia vera. Un'app aveva un bug strano: occasionalmente, alcuni utenti vedevano dati di altri utenti. Non sempre, non in modo prevedibile. Solo sporadicamente.

L'AI, interrogata sul problema, suggeriva soluzioni standard: controllare l'autenticazione, verificare le query del database, controllare la cache. Tutte cose sensate, ma che non risolsero il problema.

Un debugger umano esperto, invece, notò che il bug si verificava solo negli orari di picco. Ipotesi: race condition. Dopo ore di analisi, scoprì che il problema era in un'operazione asincrona che condivideva stato tra richieste diverse in condizioni di alta concorrenza.

L'AI non avrebbe mai pensato a guardare quel particolare pattern temporale.

Il Ruolo del "Product Engineer" nella Vigilanza

Il "Product Engineer" non è solo un visionario o uno stratega. È anche un guardiano tecnico.

Sa che la sicurezza non è un'aggiunta opzionale, ma un pilastro fondamentale del prodotto. Un'applicazione violata non è solo un danno tecnico, ma un disastro di business che può distruggere la reputazione e la fiducia dei clienti.

Sa che il debugging è un'arte che richiede esperienza, intuizione e una comprensione profonda del sistema. Non è qualcosa che puoi automatizzare completamente.

E sa che queste competenze tecniche tradizionali non sono obsolete nell'era AI - sono più importanti che mai.

Perché quando l'AI genera tonnellate di codice velocemente, la tua capacità di validarlo, debuggarlo e renderlo sicuro diventa il collo di bottiglia critico del processo di sviluppo.

Ma la sicurezza e il debugging sono solo una parte del quadro. Per gestire davvero la complessità dell'era AI, hai bisogno di qualcosa di più strutturato: un processo.

Governare il Caos AI-Generato - Processo e Project Management

"Il problema non è la tecnologia, è il processo."

Questa frase me l'ha detta il CTO di una multinazionale italiana dopo che il loro progetto di trasformazione digitale era andato completamente fuori controllo. Non per colpa della tecnologia legacy, come tutti pensavano inizialmente. Ma per l'assenza totale di un processo strutturato.

One man show. Nessuna pianificazione. Nessun controllo. Nessuna metodologia.

Il risultato? Milioni di euro bruciati, timeline irrealistiche, e un prodotto che nessuno sapeva come gestire.

La lezione è universale: l'AI può accelerare l'esecuzione, ma senza un processo solido, arrivi solo più velocemente al disastro.

Cos'è il Project Management nell'Era AI

Il project management non è burocrazia fine a se stessa. È l'organizzazione sistematica di risorse, metodologie e tecniche per pianificare e monitorare azioni verso un obiettivo strategico, nei vincoli di tempo e costi.

In parole semplici: è il modo per rispondere oggettivamente a domande cruciali e prendere decisioni strategiche basate sui dati invece che sull'istinto del momento.

Domande tipo:

• Siamo in ritardo o in anticipo rispetto alla timeline?

• Quali task stanno creando colli di bottiglia?

• Come stiamo allocando le risorse?

• Cosa fare se emerge un nuovo requisito critico?

• Come bilanciare nuove feature con il debito tecnico?

Nell'era AI, queste domande diventano ancora più critiche perché la velocità di generazione del codice può creare un'illusione di progresso che maschera problemi strutturali profondi.

"Vibe PMing" - Quando l'AI Aiuta nella Pianificazione

Ecco un concetto interessante: "vibe PMing" - usare l'AI per aiutarti a creare documenti di pianificazione e specifiche iniziali.

Processo pratico (è solo un esempio customizzalo come serve a te):

1. Dai all'AI una descrizione del tuo progetto

2. Chiedi di generare un README.md strutturato

3. Fai generare un planning.md con milestone e deliverable

4. Crea un tasks.md con breakdown delle attività

5. Itera su questi documenti raffinandoli

Esempio di prompt: "Sto costruendo un sistema di gestione progetti per team remoti. Genera un planning.md che includa:

• Milestone principali con timeline

• Deliverable specifici per milestone

• Rischi potenziali e mitigazioni

• Dipendenze tecniche critiche

• Metriche di successo"

Approccio avanzato: usa AI multiple per la pianificazione e combina i risultati. Chiedi a ChatGPT, Claude e Gemini di pianificare lo stesso progetto, poi confronta le loro proposte per identificare blind spot e opportunità che una singola AI potrebbe perdere.

Ma attenzione: anche con l'AI che ti aiuta a creare documenti di pianificazione, tu devi essere specifico nel prompt iniziale e iterare continuamente per migliorare i documenti.

Il tema del “Vibe PMing” è molto vasto e ho già messo già troppa carne al fuoco per questo articolo. Se sei interessato a saperne di più su questo argomento, fammelo sapere nel sondaggio.

Il "Product Engineer" come Gestore Attivo del Processo

Il "Product Engineer" non subisce il processo - lo guida attivamente.

Utilizza strumenti e metodologie (anche con AI che aiuta nella loro gestione) per garantire che il progetto proceda in modo controllato e prevedibile. Sa che il miglior project management è quello che "non si nota" - tutto fila liscio, le sorprese sono minime, gli obiettivi vengono raggiunti nei tempi previsti.

Ma soprattutto, capisce che il processo non è mai fine a se stesso. È sempre al servizio dell'obiettivo finale: creare un prodotto che soddisfi davvero le esigenze degli utenti.

E parlando di utenti, arriviamo al cuore pulsante di ogni prodotto di successo: l'esperienza che offri a chi lo usa.

Il Vero Volto del Successo - L'Esperienza Utente Definita

Permettimi di ripetere un concetto che dovrebbe essere tatuato sulla fronte di ogni software engineer: la qualità del software è definita dalla sua capacità di soddisfare le aspettative del cliente/utente.

Non dalla eleganza del codice. Non dalla sofisticatezza dell'architettura. Non dalla quantità di pattern design implementati.

Dalla soddisfazione dell'utente finale.

Questo significa che puoi avere il codice più bello del mondo, ottimizzato, testato, documentato, architettonicamente perfetto - ma se l'utente non riesce a completare il task per cui ha aperto la tua app, hai fallito.

User Experience: Non Solo Estetica

La User Experience (UX) non è "rendere le cose carine". Non è scegliere colori accattivanti o font alla moda.

La UX è la disciplina che si occupa di azzerare il divario tra l'intenzione dell'utente e la sua capacità di realizzarla attraverso il tuo software.

Quando un utente apre la tua app, ha un obiettivo mentale: "Voglio completare questo task, risolvere questo problema, ottenere questa informazione." La UX si occupa di rendere questo percorso il più naturale, veloce e privo di frustrazione possibile.

Il Processo UX nell'Era AI

Il team UX (o tu, se fai anche quello) lavora così:

1. Ricerca utente: Capisce chi sono gli utenti, cosa vogliono, come pensano

2. Information Architecture: Organizza contenuti e funzionalità in modo logico

3. User Flow: Disegna il percorso che l'utente fa per completare i task

4. Wireframe e Mockup: Crea rappresentazioni visive delle interfacce

5. Prototipazione: Testa le interazioni prima di implementarle

6. Validazione: Testa con utenti reali per identificare problemi

Questo lavoro viene poi inserito nei backlog item come riferimento chiaro per il team di sviluppo. Niente più "fai un form di login" generico. Ma "implementa il form di login secondo il mockup X, con validazione real-time, messaggio di errore specifico per ogni campo, e integrazione con il sistema di recupero password progettato nel flusso Y."

L'AI nella Creazione di Interfacce

L'AI può essere incredibilmente utile nella fase di implementazione UI:

• Generazione componenti: "Crea un componente React per una card che mostra una joke con titolo, testo, categoria, rating stelle, e bottoni like/dislike"

• Implementazione di design: Puoi dare all'AI uno screenshot o una descrizione dettagliata di un'interfaccia e farle generare il codice corrispondente

• Prototipazione rapida: Per testare rapidamente idee di interfaccia senza investire troppo tempo nell'implementazione

Ma attenzione: l'AI implementa, non progetta l'esperienza.

L'AI può creare il componente tecnicamente perfetto, ma non sa se quell'interfaccia ha senso nel contesto dell'applicazione, se rispetta i principi di usabilità, se è accessibile agli utenti con disabilità, se è coerente con il resto del prodotto.

Principi UX Fondamentali nell'Era AI

Consistenza: Tutte le parti dell'applicazione devono parlare la stessa "lingua" visuale e interattiva. Se l'AI genera componenti con stili diversi, spetta a te unificarli.

Feedback: L'utente deve sempre sapere cosa sta succedendo. Loading states, conferme di azione, messaggi di errore chiari e utili.

Forgiveness: Gli errori dell'utente devono essere previsti e gestiti con grazia. Undo, conferme per azioni distruttive, auto-save.

Efficiency: Le azioni più comuni devono essere le più facili da compiere. Keyboard shortcuts, default intelligenti, flussi ottimizzati.

Accessibility: Il prodotto deve essere usabile da persone con diverse abilità. Alt text per immagini, navigazione da tastiera, contrasti adeguati.

Il "Product Engineer" e la UX

Il "Product Engineer" capisce che la UX non è un optional o un "nice to have". È la differenza tra un prodotto che viene usato e un prodotto che viene abbandonato.

Lavora a stretto contatto con i designer UX quando disponibili, o incorpora principi UX nel suo approccio quando lavora in autonomia.

Utilizza l'AI per implementare rapidamente componenti e interfacce, ma valida sempre che il risultato rispetti i principi di usabilità e le aspettative degli utenti.

La visione del prodotto richiede di mettere l'utente al centro, e la UX è lo strumento principale per farlo.

Ma ora è arrivato il momento di chiudere il cerchio. Di tornare a quella notte difficile di Lorenzo e vedere come questa trasformazione da "software engineer" a "Product Engineer" può davvero fare la differenza.

L'Alba di un Nuovo Ruolo

Ricordi Lorenzo? Il software engineer che abbiamo lasciato alle 4:23 del mattino, circondato da codice AI-generato che funzionava ma non aveva senso, con una deadline a poche ore e un cliente che si aspettava un miracolo?

Quella storia ha un finale diverso da quello che potresti immaginare.

Non è diventato magicamente tutto perfetto. Il project management non è magia, e neanche la trasformazione professionale. Ma Lorenzo e il suo team hanno fatto qualcosa di più importante: hanno imparato.

Hanno capito che il problema non era l'AI. Il problema era l'assenza di una visione chiara, di una comprensione profonda del prodotto che stavano costruendo, di un processo solido che guidasse l'uso degli strumenti.

L'AI era uno strumento potente nelle mani di un team che non sapeva dove andare.

La Svolta

Il giorno dopo la deadline disastrosa, invece di incolpare la tecnologia o arrendersi alla sconfitta, Lorenzo ha fatto una cosa coraggiosa: ha chiamato un Product Owner esperto per aiutare il team a riorganizzarsi.

Insieme hanno iniziato ad applicare i principi che abbiamo esplorato:

Hanno iniziato con i requisiti. Non più "crea un'app per gestire progetti" generico, ma specifiche precise: "Gli utenti devono poter creare progetti, assegnare task ai membri del team, tracciare il progresso con milestone visibili, ricevere notifiche per le deadline, e generare report settimanali automatici."

Hanno raffinato il prompt engineering. Invece di chiedere all'AI di "creare funzionalità", hanno iniziato a dare contesto, spiegare vincoli, specificare edge case. I risultati sono migliorati drasticamente.

Hanno progettato l'architettura prima di implementare. Hanno deciso come strutturare il sistema, quali tecnologie usare, come gestire la comunicazione tra componenti. L'AI è diventata uno strumento per implementare la loro visione, non per sostituirla.

Hanno bilanciato velocità e qualità. Vibe coding per i prototipi e le demo, processo rigoroso per il codice di produzione. Test automatici per tutto. Review umana per le parti critiche.

Hanno preso sul serio la sicurezza. Mai più chiavi API gestite dall'AI. Mai più autenticazione senza supervisione umana. Mai più codice in produzione senza security review.

Hanno implementato un processo. Sprint planning, backlog prioritizzato, burndown chart, retrospettive. L'AI li aiutava a generare documentazione e task breakdown, ma la responsabilità del processo rimaneva umana.

Hanno messo l'utente al centro. Hanno parlato con i clienti, hanno capito i loro veri bisogni, hanno progettato l'esperienza prima dell'implementazione. L'AI implementava le loro decisioni UX, non le prendeva per loro.

Il Risultato

Il progetto non è diventato perfetto overnight. Ma è diventato gestibile, prevedibile, e di valore.

Hanno rispettato la deadline successiva (con alcuni compromessi pianificati e comunicati). Il cliente era soddisfatto. Il team aveva imparato a lavorare con l'AI invece di esserne dominato.

Ma soprattutto, Lorenzo aveva capito di essere diventato qualcosa di diverso.

Non era più solo un software engineer che scriveva codice. Era diventato un architetto di soluzioni, un negoziatore di requisiti, un garante della qualità percepita, un orchestratore di processi, uno stratega dell'innovazione.

Era diventato un "Product Engineer" dell'era digitale.

Il Nuovo Software Engineer "Product Engineer"

Questa trasformazione non è esclusiva di Lorenzo. È quello che sta accadendo a migliaia di software engineer in tutto il mondo.

L'AI non ha eliminato il software engineer - lo ha liberato.

Lo ha liberato dalle attività ripetitive, noiose, a basso valore aggiunto, per permettergli di concentrarsi su quello che davvero conta: risolvere problemi umani attraverso la tecnologia.

Il nuovo software engineer "Product Engineer" è:

• Un traduttore tra esigenze di business e soluzioni tecniche

• Un architetto di esperienze che progetta non solo codice, ma interazioni

• Un guardiano della qualità che sa quando spingere sulla velocità e quando frenare per la solidità

• Un comunicatore che sa parlare con clienti, designer, manager e macchine

• Un strategista che vede oltre il singolo progetto per costruire sistemi duraturi

Pensiero Finale: L'Evoluzione Continua

Questa trasformazione è solo l'inizio. L'AI continuerà a evolversi, i tool diventeranno più potenti, le possibilità si espanderanno.

Ma una cosa non cambierà: la necessità di persone che sappiano guidare la tecnologia verso obiettivi umani.

L'AI è il co-pilota più potente che abbiamo mai avuto. Può volare a velocità incredibili, navigare attraverso problemi complessi, eseguire manovre che da soli non potremmo mai fare.

Ma il pilota rimani tu.

Tu decidi la destinazione. Tu leggi la mappa. Tu prendi le decisioni quando il tempo è brutto e la visibilità è limitata.

Tu sei il "Product Engineer" che trasforma la potenza grezza dell'AI in valore reale per le persone.

E questa, francamente, è un'opportunità molto più entusiasmante di quella che avevamo quando tutto quello che potevamo fare era scrivere codice riga per riga.

Abbiamo fatto tanta strada per tornare allo stesso punto. L’AI può cambiare il modo a cui arrivare ad un risultato ma non la necessità. Come da quando è nato il software engineering la necessità è che oltre ai requisiti funzionali servono requisiti non funzionali come sicurezza modularità e performance compatibili con il caso d’uso. L’AI queste necessità non le ha cambiate e non potrà cambiare, ed è qui che serve il nuovo, vecchio Lorenzo.

Benvenuto nell'era dei "Product Engineer". Il futuro dello sviluppo software non è mai stato così luminoso.

👉 Connettiamoci

💻 Parlo di Tech e Prodotto anche su LinkedIn