L'AI non sta cambiando solo quello che costruiamo: sta trasformando radicalmente il modo in cui lavoriamo. Le organizzazioni di product engineering, in tutte le aree Dev, PM, Program e QA, devono evolvere i propri principi per sfruttare appieno questo cambiamento. In Fynd, stiamo attivamente guidando queste trasformazioni per poter davvero sfruttare la potenza dell'AI in tutta la nostra organizzazione di Product Engineering.

Di seguito i modi di lavorare proposti affinché i nostri team possano accelerare realmente ogni ruolo all'interno di Product ed Engineering, riducendo significativamente i passaggi di consegna che tipicamente avvengono tra le diverse funzioni aziendali.

1. Un Singolo Repository per Prodotto

Consolida tutti i microservizi correlati di ciascun prodotto in un unico repository Git. L'obiettivo a lungo termine è ridurre i repository, semplificandone la configurazione e la gestione.

Questo non significa collassare tutto in un monolite. Si continua con un'architettura a microservizi. Il cambiamento avviene a livello di repository Git/codice, creando un codebase unificato per prodotto che migliora l'accessibilità, semplifica l'onboarding, garantisce la coerenza dello stack e rende il codebase più facile da navigare.

Il vero vantaggio: anche i membri non tecnici del team possono ora contribuire in modo significativo. I Product Manager dovrebbero essere in grado di contribuire a un livello equivalente a un SDE-1 con l'assistenza dell'AI. I team di design dovrebbero poter supportare direttamente i miglioramenti UI/UX. Le attività di sviluppo facili e medie diventano davvero accessibili a tutti.

2. Il Repository come Hub Centrale della Conoscenza

Il tuo repository dovrebbe diventare l'unica fonte di verità per tutta la conoscenza e la documentazione. Crea una directory /docs e archivia tutto lì, invece di disperdere le informazioni tra sistemi di ticketing, strumenti documentali, PDF e altre piattaforme frammentate.

Skill, documentazione, regole, hook e versioni runtime dovrebbero essere centralizzati. Anche se il contenuto nasce come immagine, PDF o diagramma, convertilo in Markdown per migliorare la visibilità e la comprensione contestuale da parte dell'AI.

Il repository diventa di fatto una knowledge base completamente indicizzata per IDE potenziati dall'AI come Cursor o Claude Code. Questi strumenti consumano automaticamente le informazioni contestuali e abilitano una superficie operativa unificata per tutti gli stakeholder: QA engineer, program manager e product manager possono esplorare e interrogare il codice direttamente, minimizzando la perdita di informazioni durante la traduzione tra ruoli.

3. Smetti di Scrivere API, Inizia a Costruire Agenti

Invece di costruire API tradizionali, inizia a costruire agenti. Cambia mentalità e orientati verso la progettazione di sistemi intelligenti e autonomi, capaci di ragionare, decidere e agire.

Esplora framework come LangGraph, OpenAI Agents, CrewAI e strumenti simili. Questi ecosistemi forniscono già le basi di cui hai bisogno: non sprecare tempo a reinventare infrastrutture di base.

Il CRUD non è più un elemento differenziante. Equivale sostanzialmente a un prompt "hello world". Con gli IDE potenziati dall'AI, chiunque sappia scrivere in un inglese chiaro può generare applicazioni CRUD in meno di un'ora.

4. Team Basati sulle Feature, Non sui Servizi

Basta con team Frontend, team Backend o gruppi basati sulle funzioni. Operate come team orientati alle feature e guidati dai risultati.

Ogni team possiede una feature end-to-end, dalla definizione del problema e dal design fino allo sviluppo, integrazione, testing, rilascio e impatto post-lancio. Nessuna ownership frammentata, nessun passaggio di consegna per livelli, nessun "quella è responsabilità di un altro team".

Quando arriva una feature, un singolo team si assume la piena responsabilità di rilasciarla, in modo completo e corretto. Ownership end-to-end. Responsabilità chiara. Risultati concreti.

5. Vai Oltre i Confini del Ruolo

I confini tra Dev, QA, PM e Program stanno diventando invisibili.

L'AI ha abbassato drasticamente la barriera all'esecuzione. Non serve più una specializzazione profonda per contribuire in modo significativo su frontend, backend, testing, automazione o documentazione. Con gli IDE AI e le interfacce in linguaggio naturale, chiunque può costruire app CRUD, generare interfacce, scrivere script o creare test.

PM e Program Manager dovrebbero acquisire fluenza tecnica e prototipare con l'AI. Gli ingegneri dovrebbero interagire direttamente con i clienti e modellare le soluzioni, non limitarsi a implementare ticket. Il futuro appartiene a chi ragiona in termini di ownership end-to-end del problema, piuttosto che in silos funzionali.

6. Il Codice Costa Poco: Contano Ownership, Innovazione e Velocità

Generare codice non è più una competenza rara. Ciò che è raro è la chiarezza di pensiero, il buon giudizio, la comprensione profonda dei problemi e la capacità di muoversi velocemente con convinzione.

L'elemento differenziante non è "Sai programmare?" ma "Sai identificare il problema giusto, progettare l'approccio corretto e portarlo rapidamente a un impatto concreto?" Man mano che l'AI comprime i tempi di esecuzione, il valore si sposta sulla qualità delle decisioni e sullo spirito di iniziativa.

O espandi il tuo ruolo oltre i confini definiti, oppure diventa un ultra-esperto in problemi che vanno ben oltre ciò che l'AI può gestire: deep performance engineering, analisi avanzata della sicurezza, progettazione architetturale su larga scala e sfide di dominio complesse basate su conoscenze non pubbliche.

7. Il QA Deve Andare Oltre il Lavoro Manuale

I quality engineer devono evolversi in ingegneri della qualità e dell'automazione a tutto tondo.

Non è mai stato così facile automatizzare. Quello che prima richiedeva codice estensivo ora si crea in appena 15 minuti con l'assistenza dell'AI, e con la massima qualità del codice possibile. Il QA ha il miglior vantaggio in questo momento: costruire è diventato facile, ma la verifica è ancora un problema irrisolto. Servono persone capaci di testare sia attraverso l'automazione che manualmente.

I QA engineer possono iniziare a correggere da soli i bug minori. Se stai ancora facendo solo lavoro manuale, questo riflette una mancanza di iniziativa nel pensare oltre il compito immediato.

8. Mantieni l'Architettura Semplice Finché Non Hai Scala

Non introdurre stack tecnologici complessi prima di avere una scala reale. Nelle fasi iniziali, velocità e chiarezza contano molto più della sofisticatezza architetturale. Inizia con qualcosa di semplice, facile da comprendere e con il minor numero possibile di componenti in movimento.

Aggiungere Kafka, Redis o altri componenti pesanti per piccole estensioni è spesso uno spreco di memoria, di sforzo ingegneristico e di costi operativi. La complessità va guadagnata, non data per scontata.

Ottimizza prima i fondamentali. Se gli indici del tuo database non sono completamente ottimizzati, aggiungere un livello di caching significa solo mascherare l'inefficienza. Costruisci in modo semplice, scala quando necessario e introduci componenti avanzati solo quando il problema lo richiede davvero.

9. Non Cadere nella Bufala del "L'AI Mi Farà Dimenticare Come Programmare"

L'argomento secondo cui usare l'AI ci farà dimenticare come programmare è come dire che non dovremmo usare la lavatrice perché potremmo dimenticare come lavare i vestiti a mano. Ciò che conta davvero è il risultato e il valore generato, non lo sforzo manuale che sta dietro.

Non scriviamo più la maggior parte dei sistemi in Assembly o nemmeno in C, nonostante la loro efficienza. Strumenti di livello superiore ci permettono di andare più veloci e costruire sistemi più complessi. L'AI è semplicemente il passo successivo in questa evoluzione: accelera lo sviluppo e ci permette di concentrarci sulla risoluzione dei problemi a un livello più alto.

Nella nostra essenza, siamo risolutori di problemi. Scrivere codice è solo uno strumento nel nostro kit. Abilita la soluzione, ma non è la soluzione stessa.

10. Sii Curioso, Chiedi Tutto all'AI

Non aver paura di fare all'AI ogni singola domanda, per quanto banale possa sembrare. Non c'è giudizio: l'AI è infinitamente paziente e disponibile 24 ore su 24, 7 giorni su 7.

Usa l'AI come il tuo insegnante personale. Lascia che ti spieghi i concetti passo dopo passo finché non comprendi qualcosa da cima a fondo. Il modo più veloce per colmare le lacune di conoscenza è semplicemente chiedere, invece di fingere di sapere qualcosa o passare ore a cercare.

L'apprendimento è una strada a doppio senso. Mentre fai domande all'AI, le insegni anche il tuo contesto: il tuo codebase, il tuo prodotto, i tuoi vincoli. Più interagisci, meglio riesce ad aiutarti.

Le persone che cresceranno più velocemente non sono quelle che sanno già tutto, ma quelle abbastanza curiose da continuare a chiedere finché non capiscono davvero.

Enjoyed this thought?

Get notified when I publish new insights.

Subscribe to Newsletter

Related Thoughts

Da Ingegnere a CTPO: Leadership Tecnica su Scala

Il viaggio dallo scrivere codice al guidare organizzazioni di ingegneria: come la profondità tecnica si combina con la leadership, e cosa conta davvero su scala.

AI-Powered Media Processing: What We Learned Building PixelBin

Lessons from building AI media tools at scale: inference optimization, API design, and balancing quality with latency.

Perché il Design Organizzativo AI-First Non Riguarda gli Strumenti

La maggior parte delle trasformazioni AI fallisce perché il design organizzativo viene ignorato. Ecco come costruire organizzazioni AI-first che funzionano davvero.