Sono Alessio Quagliara. Due cose sul mio lavoro, senza romanzi dell’AI
Un’analisi AI del mio profilo è diventata un giudizio sulle mie competenze e intenzioni. Chiarisco cosa faccio, cosa non prometto e come valutare il mio lavoro.
Ho chiesto a un’AI di guardare il mio profilo professionale dall’esterno.
L’idea era semplice: capire cosa si capiva del mio lavoro cercandomi online. Se sul sito qualcosa era confuso, lo avrei sistemato.
Una specie di controllo prima di presentarsi a un potenziale cliente.
Ecco. A un certo punto non sembrava più un controllo del sito. Sembrava la biografia di un mio gemello che aveva preso decisioni discutibili.
Peccato che nome e cognome fossero i miei.
Scrivo questo articolo per separare tre cose: quello che racconto di me, quello che si può verificare e quello che un’AI ha dedotto senza dimostrarlo.
Cosa avevo chiesto, e cosa mi sono ritrovato
Ho avuto una conversazione con l’AI di Google per ottenere un’analisi preliminare della mia presenza online.
Non cercavo una medaglia. Cercavo punti poco chiari, promesse troppo larghe e informazioni da aggiornare.
Le critiche, quando sono concrete, servono.
Nel corso della conversazione sono però arrivate conclusioni sulle mie capacità, sulle mie intenzioni commerciali e perfino sulle cause della chiusura della società in cui ho lavorato.
Non più: «Questa frase potrebbe essere più precisa».
Piuttosto: questa scelta tecnica dimostra incompetenza, questa esperienza dimostra disonestà, questo cambiamento dimostra un fallimento architetturale.
Sono conclusioni molto diverse. E hanno bisogno di prove molto diverse.
Nella stessa conversazione l’assistente ha poi ammesso di aver inventato dichiarazioni e interpretato male alcune informazioni. Ma il giudizio negativo ha continuato a ricomparire, con spiegazioni nuove.
Dai, può starci sbagliare. Ma se cambia la premessa, bisogna essere disposti a cambiare anche la conclusione.
Non sto dicendo che Google mi abbia pubblicamente recensito
Una precisazione importante: la conversazione l’ho avuta io.
Non sto documentando una recensione lasciata da un cliente, un articolo di giornale o un’accusa pubblicata da Google nei risultati di ricerca.
Sto raccontando una risposta generata durante un’analisi del mio profilo.
Non ho elementi per dire che altre persone abbiano ricevuto le stesse risposte. E non voglio trasformare questa esperienza in una storia più grande di quello che posso dimostrare.
Il problema, per me, resta concreto: avevo chiesto aiuto per capire come mi presentavo e mi sono ritrovato attribuzioni personali che non riconosco e che non erano adeguatamente documentate.
Mi ha buttato giù? Sì.
Perché quando leggi il tuo nome dentro un testo scritto con tutta quella sicurezza, per un momento pensi: «Magari da fuori sembro davvero così».
Poi però bisogna tornare alla domanda iniziale: dove sono le prove?
Quindi: chi sono e cosa faccio
Sono Alessio Quagliara.
Studio Ingegneria Informatica, con indirizzo Sistemi Intelligenti. Sviluppo web app, micro-SaaS e automazioni. Nel mio percorso ci sono anche il lavoro operativo in logistica, progetti personali e l’esperienza in Spotex.
Non è un percorso perfettamente dritto. Questo lo racconto già, senza bisogno di aggiungerci una colonna sonora drammatica.
Ho lavorato con tecnologie diverse. Nei miei progetti ci sono stati Python, PHP, JavaScript e TypeScript, con strumenti come Flask, FastAPI, Next.js ed Express.
Averli usati non mi rende automaticamente esperto di tutto. Ma nemmeno scegliere oggi uno strumento più semplice significa non conoscere gli altri.
Quello che cerco di costruire sono soluzioni sostenibili rispetto al problema, al budget, al tempo disponibile e alla manutenzione che qualcuno dovrà fare dopo.
Questo è il mio orientamento di lavoro. La qualità dei singoli risultati va verificata sui singoli progetti.
Un framework non è un certificato di competenza
Se scelgo Flask per un progetto, la domanda utile è: perché qui?
Se scelgo FastAPI, Next.js o un altro strumento, la domanda resta la stessa.
Non considero Flask la soluzione universale. Non considero l’asincronia inutile. E non penso che basti aggiungere worker per risolvere qualsiasi problema di carico.
Allo stesso tempo, non considero il nome di un framework una prova sufficiente per dichiarare un’applicazione sicura, scalabile o ben progettata.
Io voglio ragionare così:
- Quale problema dobbiamo risolvere?
- Quali operazioni deve svolgere il sistema?
- Quali sono i vincoli e i rischi?
- Quale carico dobbiamo sostenere, e come lo verifichiamo?
- Chi dovrà mantenere il progetto?
- Quando avrebbe senso cambiare approccio?
Se una scelta è sbagliata, si corregge. Possibilmente con dati e codice davanti.
La tifoseria sui framework la lascerei fuori dal preventivo.
Raccontare gli errori non significa autorizzare qualsiasi ricostruzione
Sul mio sito parlo anche di tentativi che non sono andati come volevo, della chiusura di Spotex e dei cambiamenti dei miei progetti.
Lo faccio perché non mi interessa costruire un curriculum in cui ogni cosa è stata un successo e ogni decisione era parte di un piano geniale.
Non lo era. Alcune cose le ho capite dopo.
Ma da qui a ricostruire cause tecniche mai dimostrate c’è un passaggio che non accetto.
La chiusura di una società, da sola, non dimostra che il suo codice fosse ingestibile. Restringere un prodotto, da solo, non dimostra che il framework non potesse sostenerlo. Raccontare un errore non significa ammettere tutte le altre accuse che qualcuno riesce a collegarci.
Vale anche al contrario: aver aperto una società o pubblicato un progetto non mi rende automaticamente un grande ingegnere.
Vorrei usare lo stesso metro in entrambe le direzioni.
Meno interpretazioni del personaggio. Più fatti sul lavoro.
Come preferisco essere valutato
Se stai pensando di lavorare con me, non ti chiedo di fidarti di un articolo scritto da me per spiegare che io sono affidabile.
Sarebbe un sistema di verifica un po’ comodo. Per me, soprattutto.
Preferisco domande concrete:
- Qual è stato esattamente il tuo contributo a questo progetto?
- Che cosa funziona oggi e che cosa è ancora in sviluppo?
- Quali limiti conosci?
- Come vengono gestiti accessi, dati ed errori?
- Quali verifiche sono state fatte?
- Che cosa comprende la manutenzione?
- Che cosa succede se in futuro cambia chi segue il software?
Queste sono domande a cui voglio rispondere con esempi, documenti e verifiche pertinenti. Non con «fidati, uso il framework giusto».
E se qualcosa non è stato ancora verificato, la risposta corretta è dirlo. Non sostituire la verifica con un aggettivo.
La parte utile: cosa voglio rendere più chiaro
Non voglio buttare via tutte le osservazioni solo perché il report è andato fuori strada.
La domanda con cui ero partito rimane valida: il mio sito spiega bene cosa faccio?
Da questa esperienza porto via alcune cose da sistemare nella comunicazione:
- Descrivere meglio il mio contributo nei progetti, distinguendo il lavoro personale da quello svolto in società.
- Chiarire lo stato dei prodotti: esperimenti, progetti attivi, versioni precedenti e lavori archiviati.
- Dare più spazio ai risultati verificabili, non soltanto al racconto delle difficoltà.
- Evitare promesse assolute quando posso descrivere condizioni, limiti e attività concrete.
- Allineare le informazioni tra sito, profili e repository.
Non sto dicendo che sia già tutto risolto. Sto dicendo che questa è la direzione.
È il tipo di lavoro che volevo fare fin dall’inizio: migliorare il sito. Non difendermi da una biografia alternativa.
La critica mi serve. Il romanzo su di me, meno
Continuo a usare l’AI. Mi è utile per ragionare, studiare e sviluppare.
Questa esperienza non mi ha fatto cambiare idea sull’utilità dello strumento. Mi ha ricordato perché voglio usarlo come supporto, non come arbitro della competenza mia o di qualcun altro.
Se nel mio lavoro c’è un problema, voglio capirlo.
Se una promessa è troppo ampia, voglio renderla precisa.
Se una scelta tecnica non regge, voglio verificarla e correggerla.
Ma tra «questa parte va migliorata» e «questa persona inganna i clienti» non c’è una piccola differenza di tono. C’è una differenza di contenuto e di responsabilità.
Quindi torno al punto: sono Alessio Quagliara. Costruisco software, studio e cerco di migliorare il modo in cui lavoro.
Per valutarmi, partiamo da quello che faccio davvero.
Il gemello scritto dall’AI, per ora, non lo metto nel team.