Faccio il Manager, il Padre e lo Sviluppatore. Un quarto d'ora alla volta

Oooooh, è sabato pomeriggio e dopo un bel pranzo a base di spaghetti allo scoglio io e mia moglie mettiamo i bimbi a nanna. Mi aspettano 2 ore ininterrote in cui posso lavorare al mio sito! Peccato che dopo 10 minuti… “Papà, devo fare la cacca!”. Fine del mio focus e, fino a qualche mese fa, fine della mia voglia di scrivere codice.

A lavoro non vengo interrotto da frasi simili, ma essendo un Engineering Manager di 3 team, la parte di crescita delle persone occupa la maggior parte del mio tempo, con context switch continui e richieste estemporanee via chat.

Non fraintendermi: amo il mio lavoro di manager e amo essere padre. Ma amo anche scrivere codice e progettare software. Tentare di restare sul pezzo come sviluppatore in queste condizioni è una sfida che ho perso continuamente fino a circa un anno fa.

Sviluppo Assistito dall’AI (no, non faccio vibe coding) 🤖

Ho visto con i miei occhi quanto sia importante per un Software Engineer avere dei blocchi di tempo ininterrotti da meeting o altre distrazioni perché scrivere codice richiede la massima concentrazione.

Questo concetto non è nuovo, ma troppo spesso dimenticato soprattutto da chi fissa meeting nel mezzo della mattina o del pomeriggio (e magari non sono nemmeno efficaci).

Poi è arrivato lo sviluppo assistito dall’AI.

Con la nascita di Emma ho sfruttato il mio mese di congedo parentale per rifare questo sito usando Astro, TypeScript e Docker, tecnologie che conoscevo solo superficialmente o che non usavo attivamente da molto.

Ho iniziato con Cursor anche se ora uso principalmente GitHub Copilot in VS Code in modalità Agent.

Ti fermo subito: non faccio vibe coding: tutto il codice prodotto è rivisto, a volte modificato, e sempre compreso da me. Anzi, se qualcosa non è chiaro passo in modalità Ask e continuo a fare domande finché non capisco il perché di certe scelte.

Quindi, Sonnet & Co. non ha “scritto il sito per me”; mi ha permesso di sviluppare con continuità nonostante fossi arruginito sulla sintassi di typescript e non conoscessi Astro e Docker perfettamente. Il tutto mentre un cambio pannolino improvviso o la voglia di giocare con l’altro mio figlio interrompevano il flusso di lavoro.

Mi sembra di programmare in linguaggio “Inglese” ✍️

Con questi strumenti ho avuto un incredibile AHA Moment quando ho inserito i miei prompt con la mia voce grazie all’icona del microfono in VS Code.

“Voglio realizzare una sezione del sito in cui elenco i miei post più recenti da X. La chiamata alle API deve avvenire lato server quindi la pagina in cui uso questo componente deve essere Server-side rendered. Dividi le responsabilità in una funzione che si occupa della chiamata REST, una che applica uno strato di Cache e una che adatta i dati per il rendering in un componente di mera presentazione senza logica. Aspettati di ricevere l’API key come secret dall’environemnt. Scrivi unit tests per questi componenti. Fammi domande di chiarimento se ti servono più dettagli.”

Questo è un esempio di prompt simile a quelli che uso (anche se recentemente ho aggiunto un template nelle copilot-instructions.md).

Io rimango il massimo conoscitore del sistema: guido il design, chiedo di applicare certi design pattern, comunico i requisiti funzionali e cross-funzionali. Lancio il prompt e vado a fare quello che il mio team o la mia famiglia necessitano. Quando torno, ritrovo il diff pronto e posso validare rapidamente se l’output rispetta l’intenzione, altrimenti rifinisco il prompt oppure faccio piccole modifiche manuali.

A tutti gli effetti invece di dare in input al “computer” linguaggio typescript, sto scrivendo in un linguaggio ancora di più alto livello: l’inglese.

Ovviamente poi NON genero i messaggi di commit con AI, ma scrivo io il perché (qui ne spiego l’importanza) della modifica.

Prompt Context Engineering: è come lavorare con un Junior 🎯

Credo che il termine “prompt engineering” sia fuorviante: non stai “ingegnerizzando” un prompt, stai fornendo contesto a un assistente che deve aiutarti a realizzare un compito complesso. E onestamente non è così diverso da quello che fai quando assumi una persona nuova, in particolare se è junior, nel chiedere loro di sviluppare le prime features:

• fornisci quanto più contesto di business per fare in modo che le decisioni da prendere siano allineate agli obiettivi
• fornisci esempi di attività simili come Merge Requests passate o parti di codice da cui prendere ispirazione
• chiedi di procedere a piccoli step così da poter correggere la rotta se necessario
• resti aperto a spiegare ulteriormente o chiarire eventuali dubbi rimasti

La qualità dell’output dipende dalla bravura di chi esegue il task, ma anche da come viene fornito il contesto: come per i modelli di machine learning, garbage in = garbage out.

Sai un altro modo per migliorare la qualità del codice prodotto? Scrivi tu gli unit test! E permetti all’Agent di eseguire il comando di test (tipo npm test) senza che devi continuamente dargli il permesso finché non passano tutti. Alla fine scrivere i test è un modo estremamente preciso di fornire i requisiti.

Rischi e Caveat ⚠️

Non credo che “ho copiato e incollato da StackOverflow” sia molto diverso da “l’AI ha scritto il codice per me”. La vera differenza sta sempre nel tuo grado di comprensione del codice incollato (o generato). Se prima con alcune domande in StackOverlflow c’era il rischio di ricevere risposte maleducate, ora puoi davvero sfruttare l’LLM di turno per farti spiegare il perché di ogni scelta. E stai sicuro che ti dirà sempre che è una bella domanda! Non era sicuro incollare codice senza capirlo prima, non è sicuro fare vibe-coding ora.

C’è poi chi dice di essere preoccupato dal fatto che scrivendo meno codice si perda la memoria muscolare in particolare sulla sintassi. Questo è potenzialmente vero, così come è vero che da quando esiste Google Maps le nostre abilità di orientamento sono peggiorate. Ma non per questo smettiamo di usare le mappe digitali, perché il beneficio complessivo supera di gran lunga il costo.

E poi diversi studi hanno confermato che l’apprendimento maggiore si ha scrivendo a mano, eppure non vedo (più) nessuno scrivere i programmi sui fogli protocollo come alle superiori! 😁

Ovviamente è importante essere consapevoli di quanto siamo già dipendenti da questi strumenti. Io stesso, se venissi privato dell’AI oggi, avrei già difficoltà a essere produttivo come lo sono ora.

Ricordati di committare spesso, l’allucinazione è dietro l’angolo!

Se sei un Junior 👶

Se non hai padroneggiato i concetti di base come:

• strutture dati
• flusso end to end di una richiesta web
• design patterns
• ereditarietà e composizione
• sistemi di storage come database, cache, buckets

l’AI ti farà andare veloce su una strada di cui non hai letto i cartelli.

A lungo termine rischi:

• Difficoltà a debuggare
• Mancanza di taste architetturale (sapere cosa è troppo complesso)
• Scarsa leggibilità del tuo codice
• Incomprensione su come funzionino sistemi complessi (anche non per forza distruibiti)

Ovviamente non sono per vietarla categoricamente, ma devi usarla per imparare, non per andare veloce saltando le basi. L’informatica è una scienza relativamente giovane, sei ancora in tempo per capire come funziona il processore x86 e i suoi registri, passando poia cose di alto livello come Docker.

Conclusione 💡

Mi sono reso conto che lo sviluppo assisito dall’AI ha anche un beneficio emotivo: anche con agenda piena (lavoro e famiglia), posso toccare il mio sito o progetti di lavoro ogni giorno. Questo crea un senso di continuità che alimenta motivazione e appagamento: ho riscoperto la gioia di scrivere codice. 🤗

Nonostante sia un Senior Engineering Manager che gestisce più team inclusi altri Engineering Manager, continuo a credere che sia fondamentale rimanere sul pezzo come sviluppatore per essere ancora più efficace nel mio ruolo.