L'ingegneria dell'AI è uno dei lavori meglio pagati e in più rapida crescita nel settore tech in questo momento. E la porta d'ingresso non è mai stata così larga.
La maggior parte delle guide sbaglia. Ti propinano un muro di teoria, ti dicono di padroneggiare algebra lineare e matematica delle reti neurali, e ti perdono entro la seconda settimana.
Oppure ti seppelliscono con 80 link senza ordine né giudizio, così passi più tempo a decidere cosa studiare che a studiare davvero.
Ho letto le roadmap più popolari, testato gli strumenti che raccomandano e costruito la versione che darei a un amico che cambia carriera e ha del vero lavoro da fare.
Niente laurea in matematica. Nessun piano quadriennale.
Quattro mesi mirati, una scelta chiara per ogni competenza, prompt veri che puoi copiare, e gli errori che silenziosamente uccidono la maggior parte dei cambi di carriera prima ancora che inizino.
Ecco perché penso che il tempismo sia importante, poi il percorso completo.
Perché la porta è aperta (e posso dimostrarlo)
Probabilmente ti hanno detto che l'AI toglierà posti di lavoro.
Ecco la parte che riceve meno attenzione: sta creando una categoria specifica e ben pagata di lavoro più velocemente di quasi qualsiasi altra cosa nel mercato, e il solito guardiano si sta ritirando.
Il Global AI Jobs Barometer 2026 di PwC ha analizzato oltre un miliardo di annunci di lavoro in sei continenti. Tre risultati contano per chiunque stia pensando a un cambiamento.
Primo, i lavori che richiedono competenze AI crescono circa otto volte più velocemente del mercato complessivo. I ruoli con competenze AI sono cresciuti del 69% mentre il mercato totale del lavoro è cresciuto del 9%.
Non è un arrotondamento. È una categoria che si distacca da tutto ciò che la circonda.
Secondo, il premio salariale è reale e in aumento. I lavoratori con competenze AI ottengono un premio salariale del 62% rispetto a ruoli comparabili senza, in aumento dal 57% dell'anno precedente.
Le aziende pagano di più, non di meno, per le persone che sanno davvero costruire con questi strumenti.
Terzo, e questo è quello che cambia le carte in tavola per chi cambia carriera: il requisito della laurea sta calando, e cala più rapidamente proprio per questi ruoli.
PwC ha scoperto che la percentuale di lavori potenziati dall'AI che richiedono una laurea è scesa dal 66% al 59% tra il 2019 e il 2024.
Per i lavori in cui l'AI automatizza parti del lavoro, è scesa ulteriormente, dal 53% al 44%. I datori di lavoro stanno eliminando il filtro del titolo di studio più velocemente nei lavori esposti all'AI che altrove.
C'è un altro numero che vale la pena considerare. Negli Stati Uniti, i ruoli entry-level più esposti all'AI sono cresciuti del 35% dal 2019.
Nello stesso periodo, altri ruoli entry-level sono diminuiti del 10%. L'ultimo gradino della scala dell'AI si sta allargando mentre il resto del mercato entry-level si restringe.
Ora il contrappeso onesto, perché non sono qui per venderti una fantasia.
PwC ha anche scoperto che i ruoli entry-level esposti all'AI richiedono sempre più spesso competenze che un tempo erano riservate ai senior: giudizio, comunicazione, la capacità di possedere un risultato invece di un compito.
L'asticella non è più bassa dappertutto. Si è spostata. È meno "hai il titolo?" e più "riesci davvero a far funzionare questa cosa e a spiegare perché funziona?".
Consideralo una brutta notizia se sei un neolaureato senza esperienza lavorativa. Consideralo una buona notizia se stai cambiando carriera, perché hai già la cosa che ora ti chiedono.
Hai portato a termine progetti. Hai avuto a che fare con stakeholder. Hai gestito risultati sotto pressione.
Un ventiduenne con una laurea in informatica di solito non lo ha fatto. Se abbini il tuo giudizio esistente con le competenze tecniche di questa guida, non sei indietro rispetto ai neolaureati.
Sull'asse che interessa di più ai datori di lavoro, sei davanti a loro.
Questo è il vantaggio di chi cambia carriera, e quasi nessuna roadmap te lo dice. Tienilo a mente per tutti e quattro i mesi. È il motivo per cui questo è realistico proprio per te.
Una parola veloce sui soldi, perché vorrai i numeri veri prima di impegnarti per quattro mesi.
Darò la ripartizione completa alla fine con le fonti, ma la versione breve: a metà 2026, Glassdoor colloca lo stipendio medio di un ingegnere AI negli Stati Uniti a circa $143.500, con un intervallo tipico di circa $115.000 a $181.000.
I ruoli senior sono molto più alti. I recruiter che collocano persone in lavori AI di produzione riferiscono stipendi base di medio livello che si aggirano tra $155.000 e $200.000.
Non sono cifre gonfiate prese da un thread hype. Sono attuali, e ti mostrerò da dove viene ciascuna.
Cosa fa realmente un ingegnere AI (la versione da 60 secondi)
Prima del piano, eliminiamo la più grande fonte di intimidazione, perché ferma più persone di qualsiasi ostacolo tecnico.
Quando la maggior parte delle persone sente "ingegnere AI", immagina qualcuno in un laboratorio che addestra un modello gigante da zero, circondato da GPU e matematica che non capiranno mai.
Quello è un lavoro diverso. Si chiama ricercatore scientifico o ricercatore ML, ce ne sono relativamente pochi, e di solito richiede effettivamente titoli di studio avanzati.
Il lavoro di ingegnere AI che cresce otto volte più velocemente del mercato è una cosa completamente diversa.
Costruisci prodotti e funzionalità sopra modelli che già esistono. Prendi Claude, o GPT, o un modello open-source, e lo fai fare un lavoro specifico e affidabile all'interno di un'applicazione reale.
In pratica, significa che ti connetti alle API dei modelli, progetti i prompt e il contesto che gli fornisci, ottieni dati strutturati in output, colleghi il modello a strumenti e database, lo fai recuperare le informazioni giuste, gestisci tutto ciò che può andare storto e lo distribuisci in modo che persone reali possano usarlo.
Si colloca tra ingegneria del software, lavoro di prodotto e AI applicata. Sei un costruttore, non un ricercatore.
Ecco il test in una riga che userei. Se riesci a far fare a un LLM un lavoro specifico e affidabile all'interno di un'app, e capisci abbastanza per aggiustarlo quando si rompe, sei un ingegnere AI. Tutto qui.
Tutto in questa guida è mirato a rendere vera quella frase per te.
Non hai bisogno di sapere come funziona internamente un trasformatore. Non hai bisogno di calcolo infinitesimale. Non hai bisogno di saper derivare la backpropagation.
Hai bisogno di essere un costruttore competente che capisce come lavorare con questi modelli nel mondo reale.
Questa è un'abilità che si impara, e quattro mesi mirati sono sufficienti per diventare funzionale.
Leggi questo prima del Mese 1: i 4 errori che uccidono i cambi di carriera
Metto questo prima della roadmap di proposito.
La maggior parte delle guide nasconde gli errori alla fine, ma gli errori che mettono fine a un cambiamento di carriera avvengono nella seconda settimana, non al terzo mese. Se ricordi solo una sezione di questa guida, falla essere questa.
Ho visto persone, inclusa una versione precedente di me stesso, fare ognuno di questi. Nessuno di essi riguarda l'intelligenza.
Riguardano la strategia. Correggi la strategia e i quattro mesi funzionano davvero.
Errore 1: Iniziare con teoria e matematica.
Ti entusiasmi, vuoi fare le cose per bene, quindi vai a cercare un corso di machine learning e inizi con algebra lineare, gradient descent e la matematica dietro le reti neurali.
Tre settimane dopo hai visto un sacco di lezioni, non sai costruire niente e ti senti un impostore. Così molli.
La soluzione: saltalo. Per il lavoro a cui miri, non hai bisogno di derivare la matematica.
Hai bisogno di costruire.
Acquisirai i concetti che ti servono davvero man mano che li incontri in progetti reali, e ti rimarranno perché saranno legati a qualcosa che hai costruito.
La teoria prima di tutto è la ragione più comune per cui le persone intelligenti abbandonano questa strada. Non iniziare da lì.
Errore 2: Guardare tutorial invece di costruire.
Questo è subdolo perché sembra progresso. Guardi un corso Python di quattro ore, annuisci, senti di aver imparato qualcosa. Non è vero.
Hai guardato qualcun altro imparare qualcosa. Nel momento in cui apri un file vuoto, non c'è più niente.
La soluzione: la regola dei 30 minuti. Per ogni ora che passi a guardare o leggere, passa almeno 30 minuti a costruire qualcosa senza un tutorial aperto.
Digita tu stesso gli esempi. Rompili. Modificali. Ottieni errori e correggili. Gli errori sono l'apprendimento.
Una persona che costruisce male per quattro mesi batte una persona che guarda perfettamente per quattro mesi, sempre.
I datori di lavoro vedono la differenza in dieci secondi guardando il tuo GitHub.
Errore 3: Imparare strumenti invece di competenze.
Senti che LangChain è la cosa giusta, quindi approfondisci LangChain.
Sei mesi dopo il settore si è spostato, tutti usano qualcos'altro, e la tua conoscenza di LangChain sembra sprecata. Così insegui il nuovo strumento.
Poi anche quello cambia. Sei sempre indietro perché ottimizzi per lo strato sbagliato.
La soluzione: impara la competenza sotto lo strumento. L'abilità di scrivere un prompt che produce output affidabile non scade quando un framework si aggiorna.
L'abilità di ottenere dati strutturati da un modello, o di valutare se il tuo sistema funziona davvero, o di decidere quando un compito ha bisogno di un agente rispetto a una singola chiamata, queste si trasferiscono attraverso qualsiasi strumento mai esisterà.
Impara gli strumenti come un modo per praticare le competenze, non come obiettivo. Questa guida è organizzata intorno alle competenze proprio per questo motivo.
Errore 4: Aspettare di sentirsi pronti per costruire in pubblico.
Decidi che inizierai a condividere il tuo lavoro, candidarti per ruoli o offrire servizi freelance quando sarai "pronto".
Non ti sentirai mai pronto. La prontezza è una sensazione che arriva dopo che inizi, non prima.
Nel frattempo, le persone che vengono assunte e ottengono clienti sono quelle che hanno iniziato a condividere lavori grezzi mesi prima di sentirsi qualificati.
La soluzione: inizia a costruire in pubblico dal Mese 1. Pubblica la piccola cosa che hai fatto. Scrivi cosa hai imparato.
Metti ogni progetto su GitHub il giorno in cui lo finisci, anche quelli brutti.
Il divario tra "sto imparando" e "sto costruendo visibilmente" è dove la maggior parte di chi cambia carriera rimane bloccato per un anno. Chiudilo presto.
Nessuno sta guardando abbastanza attentamente perché i tuoi primi lavori ti mettano in imbarazzo, e la capitalizzazione inizia dal giorno in cui inizi.
Tieni a mente questi quattro per tutto il percorso.
La roadmap qui sotto è progettata per evitarli tutti per impostazione predefinita: prima le competenze, prima la costruzione, agnostica sugli strumenti, pubblica dal primo giorno.
Mese 1: Python e l'infrastruttura
Il tuo obiettivo questo mese: diventare uno sviluppatore Python funzionale che sa chiamare un'API, gestire un piccolo progetto e smettere di cercare su Google la sintassi di base.
Non un esperto. Funzionale.
Tutto nei Mesi 2-4 presuppone che tu sappia scrivere Python pulito e lavorare in un terminale. Questa è la base, e affrettarla ti danneggerà dopo.
Ecco cosa interiorizzare prima di iniziare: l'ingegneria dell'AI è prima di tutto ingegneria del software. La parte AI si trova sopra un normale stack software.
Se lo stack sottostante è traballante, la parte AI non diventa mai affidabile. Quindi il Mese 1 riguarda l'acquistare sufficiente dimestichezza con le basi in modo che non ti intralcino più.
Ti darò una scelta principale per ogni competenza, con un verdetto chiaro sul perché. Volutamente non ti offro cinque opzioni per argomento. La scelta è nemica dello slancio.
Scegli quella che ti indico e dirama solo se non funziona davvero per te.
Python
Python è il linguaggio di tutto questo settore. Quasi ogni libreria, API, tutorial e lavoro che toccherai nei prossimi quattro mesi è in Python. Lo impari, e tutto il resto diventa più facile.
La mia scelta: CS50P, Introduzione alla programmazione con Python di Harvard. Gratuito, rigoroso, e ti costringe a risolvere problemi invece di guardare qualcun altro risolverli.
I set di problemi sono tutto il valore. È più impegnativo di un corso YouTube leggero, ed è proprio questo il punto.
Vuoi la versione che ti fa faticare un po', perché la fatica è dove si forma l'abilità.
Lo trovi su cs50.harvard.edu/python.
Se CS50P ti sembra troppo ripido come principiante assoluto, il corso Python di freeCodeCamp su YouTube è un'introduzione più morbida, ma trattalo come un riscaldamento, non come l'evento principale.
Torna a CS50P quando non avrai più paura di un file vuoto.
Su cosa concentrarsi effettivamente, in ordine approssimativo: variabili e tipi di dati, cicli e condizionali, funzioni, poi i tipi di raccolta (liste, dizionari, insiemi, tuple).
Poi gestione dei file e lettura/scrittura di JSON, che userai costantemente con le API AI.
Poi abbastanza classi e basi di orientamento agli oggetti per leggere il codice altrui senza panico.
Poi gestione degli errori con try ed except.
Infine, ambienti virtuali e pip, in modo da installare pacchetti senza rompere il sistema.
Non cercare di memorizzare nulla di tutto ciò. Comprendilo abbastanza bene da trovarlo velocemente, e costruisci con esso finché non ti rimane impresso.
Il tuo obiettivo di costruzione del Mese 1 per Python: un piccolo strumento da riga di comando che faccia qualcosa di reale.
Un contatore di spese che legge e scrive su un file JSON è una buona idea. O uno script che chiama un'API pubblica gratuita e stampa i risultati in un formato pulito.
Qualcosa con forse 60-100 righe di codice tuo.
Non importa se è brutto. Importa che l'hai scritto tu.
Imparare con l'AI dal primo giorno
Qui è dove farei qualcosa che le vecchie roadmap non fanno: usare l'AI per imparare l'AI, iniziando dalla prima settimana.
Hai accesso al miglior tutor paziente mai costruito, e non costa nulla sui piani gratuiti. Quando incontri un errore che non capisci, non passare 40 minuti su un forum.
Incollalo in Claude o ChatGPT e chiedigli di spiegare l'errore in inglese semplice e guidarti verso la soluzione senza darti direttamente la risposta.
Ecco un prompt copia-incolla che imposterei dal primo giorno. Salvalo.
Questo è il primo di diversi artefatti in questa guida che vale la pena segnare.
Prompt: Il tuo partner di apprendimento Python
(Framework: FAG Learning Partner, di AI Guides)
1Il tuo compito: fare da tutor Python paziente mentre imparo a programmare come persona che cambia carriera.23Contesto su di me:4- Sto imparando Python per diventare un ingegnere AI.5- Sono un principiante assoluto nella programmazione, ma non nel lavorare sodo.6- Imparo meglio facendo, non ricevendo risposte già pronte.78Cosa fare:9- Quando incollo un errore, spiega in italiano semplice cosa significa e cosa10 probabilmente lo causa. Non darmi solo il codice corretto.11- Indicami la soluzione con un suggerimento prima. Mostra la soluzione completa12 solo se te lo chiedo due volte.13- Quando condivido codice che ho scritto, dimmi una cosa che funziona e una14 cosa che potrei migliorare. Limitati a queste due.15- Dopo che ho fatto funzionare qualcosa, fammi una breve domanda per verificare16 se l'ho davvero capita.1718Regole:19- Niente gergo senza una definizione in italiano semplice accanto.20- Supponi che voglio imparare, non solo superare. Un po' più lento va bene.21- Se sto per prendere una cattiva abitudine, dillo direttamente e gentilmente.2223Output: colloquiale, breve, un concetto alla volta.
Usalo ogni giorno questo mese. Trasforma le parti frustranti dell'imparare a programmare in una conversazione invece che in un muro.
Ti rende anche fluente nel fare prompt, che è l'abilità centrale del Mese 2, prima ancora che tu sappia che sta succedendo.
Una cautela per non costruire l'abitudine sbagliata: usa l'AI per capire e sbloccare, non per scrivere tutto al posto tuo.
Se lasci che scriva il tuo codice mentre guardi, sei di nuovo all'Errore 2.
Fai spiegare a lui. Scrivi tu.
Git e GitHub
Git è il modo in cui gli sviluppatori salvano, versionano e condividono il codice.
GitHub è dove il tuo lavoro vive in pubblico e diventa un portfolio.
Li userai entrambi costantemente, e per chi cambia carriera, GitHub è la cosa più vicina a un curriculum finché non ne hai uno.
La mia scelta: GitHub Skills. Gratuito, interattivo, e costruito da GitHub dentro GitHub stesso, così impari lo strumento usandolo. Inizia da lì piuttosto che leggere di Git in astratto.
Lo trovi su skills.github.com.
Se il modello di branching e merging ti confonde, e confonde tutti all'inizio, lo strumento visivo Learn Git Branching lo chiarisce facendoti vedere i rami muoversi.
Su cosa concentrarsi: il ciclo base di init, add, commit, push e pull. Poi branching e merging.
Poi cosa fa un file .gitignore e perché non si committano mai segreti o chiavi API in un repo pubblico, cosa che conta enormemente quando lavorerai con API a pagamento.
Poi come scrivere un README di base, perché i tuoi README faranno un vero lavoro nella tua ricerca di lavoro più avanti.
L'abitudine da costruire questo mese: ogni progetto che tocchi, anche uno script di 20 righe, finisce in un repo GitHub il giorno in cui lo crei.
Questa è la soluzione all'Errore 4 in pratica. Stai costruendo in pubblico, tranquillamente, dall'inizio.
Entro il Mese 4 avrai una traccia di lavoro invece di un profilo vuoto.
Il terminale
Eseguirai script, installerai pacchetti e gestirai progetti dalla riga di comando costantemente.
Essere lento o spaventato nel terminale è un vero freno per tutto il resto, ed è una cosa facile da sistemare.
La mia scelta: un breve corso per principianti sul terminale per coprire le basi, poi viverci dentro. I materiali "Missing Semester" del MIT vanno più in profondità se li vuoi, ma per il Mese 1 ti servono solo navigazione ed esecuzione.
Impara cd, ls, pwd, mkdir e rm per muoverti e gestire file.
Impara cat e grep per leggere e cercare.
Impara come eseguire uno script Python dal terminale e come impostare una variabile d'ambiente, cosa che ti servirà nel momento in cui gestirai chiavi API.
Non devi diventare un mago della shell. Devi smettere di esitare.
Una settimana a usare il terminale per tutto, anche per cose che faresti normalmente con il mouse, ti porta lì.
API, JSON e HTTP
Questo è il ponte verso il Mese 2.
Dal primo giorno di costruzione con gli LLM, farai chiamate API, il che significa che devi capire come funzionano le API web prima di toccare gli strumenti di OpenAI o Anthropic.
La mia scelta: la panoramica HTTP di MDN Web Docs per i concetti, più la documentazione della libreria Python requests per farlo nel codice.
MDN spiega come funzionano richieste e risposte più chiaramente di qualsiasi altra cosa gratuita.
Poi requests ti mostra come fare quelle chiamate in Python in poche righe.
Su cosa concentrarsi: cosa sono le richieste GET e POST e come farle in Python.
Leggere e scrivere JSON, che è il formato parlato da ogni API AI.
I codici di stato HTTP e cosa significano quelli comuni, specialmente 200 per successo, 401 per chiave API errata, 429 per limitazione di velocità e 500 per errore del server, perché li vedrai tutti costantemente.
Cos'è una chiave API e come funziona l'autenticazione di base.
E una leggera introduzione a cosa fanno async e await in Python, che ti servirà quando inizierai a ricevere risposte in streaming dai modelli più avanti.
Non approfondire async ora.
Sappi solo che esiste e approssimativamente quale problema risolve.
Il tuo obiettivo di costruzione qui: uno script Python che chiama un'API pubblica gratuita, una che non necessita di chiave come l'API meteo Open-Meteo, e stampa il risultato come output formattato pulito.
Questa è una versione ridotta di esattamente ciò che farai per tutto il Mese 2, solo senza la parte AI ancora.
Una nota veloce su SQL
Non devi essere una persona da dati, ma ti servirà regolarmente guardare e interrogare dati, e un SQL di base ti salva costantemente.
La mia scelta è SQLBolt, che è gratuito, interattivo e ti insegna il nucleo di SQL in circa 20 brevi lezioni nel browser.
Lo trovi su sqlbolt.com.
Concentrati su SELECT, WHERE, GROUP BY, JOIN e ORDER BY.
Per ora è sufficiente.
Potrai approfondire nel momento in cui un progetto lo richiederà.
Traguardo del Mese 1
Entro la fine del mese, dovresti essere in grado di scrivere un programma Python che legge e scrive file, chiama un'API e gestisce i propri errori senza crash.
Dovresti versionare quel codice con Git e averlo in un repo GitHub.
Dovresti muoverti nel terminale senza esitare. Dovresti capire cos'è una richiesta HTTP e farne una in Python.
E dovresti essere in grado di eseguire una query SQL di base.
Se sai fare queste cose, hai le basi.
La maggior parte delle persone che mollano non arrivano mai qui, e arrivare qui è genuinamente la parte più difficile perché è la meno entusiasmante.
Diventa più divertente dal Mese 2 in poi, perché da qui costruisci con l'AI.
Mese 2: Costruire con le API degli LLM
Il tuo obiettivo questo mese: costruire funzionalità AI reali usando le API dei modelli.
Alla fine, dovresti essere a tuo agio nello scrivere prompt che producono output affidabile, ottenere dati strutturati da un modello, far sì che il modello chiami le tue funzioni, gestire una conversazione e gestire tutto ciò che può rompersi.
Questo è il nucleo dell'intero lavoro. Tutto il resto si basa su questo.
Questo è il mese in cui inizia a sembrare reale. Smetti di fare configurazione e inizi a far fare cose ai modelli.
Prenditi il tuo tempo qui.
La profondità nel Mese 2 ripaga più della profondità in qualsiasi altra parte della guida.
Prompt che funzionano davvero
Fare prompt non significa fare una domanda a un chatbot gentilmente.
È l'abilità di scrivere istruzioni che producono output coerenti e affidabili da un sistema fondamentalmente probabilistico.
Come ingegnere AI, passerai più tempo qui di quanto ti aspetteresti, e diventare bravo è la cosa a più alto ritorno che puoi fare questo mese.
La mia scelta: il tutorial interattivo di prompt engineering di Anthropic su GitHub. È la risorsa più pratica che esista, suddivisa in capitoli con esercizi reali da eseguire contro l'API di Claude.
Praticheresti a scrivere e correggere prompt da solo invece di leggerne, che, se ricordi l'Errore 2, è il punto centrale.
Lo trovi nel repo anthropics/prompt-eng-interactive-tutorial. Una volta che lo hai eseguito, i documenti ufficiali di prompt engineering di Anthropic e OpenAI sono il riferimento a cui tornerai.
Su cosa concentrarsi: la differenza tra un messaggio di sistema e un messaggio utente, e perché quella differenza conta.
Perché la specificità batte la cortesia ogni volta.
Chain-of-thought prompting, in cui chiedi al modello di ragionare passo dopo passo prima di rispondere, che migliora misurabilmente i risultati su qualsiasi cosa con logica.
Usare esempi all'interno del prompt, chiamato few-shot prompting, per mostrare al modello il formato che desideri.
E sviluppare la sensibilità per come piccole modifiche alle parole producono grandi cambiamenti nell'output, che viene solo facendolo molto.
Un esercizio di costruzione che insegna velocemente: prendi un compito reale, come riassumere un documento o classificare un feedback, e scrivi cinque prompt diversi per esso.
Esegui tutti e cinque.
Confronta gli output fianco a fianco. Vedrai immediatamente quanto il design del prompt guidi l'affidabilità, e quella lezione rimane meglio di qualsiasi lezione.
Output strutturati
In un'applicazione reale, non vuoi quasi mai un paragrafo di testo indietro dal modello.
Vuoi dati strutturati che il tuo codice possa analizzare, memorizzare e usare. Gli output strutturati risolvono questo problema costringendo il modello a restituire dati che corrispondono a uno schema che definisci.
Questa è una di quelle abilità che separano una demo da qualcosa che funziona davvero all'interno del software.
La mia scelta: la libreria Instructor per Python, supportata dai documenti ufficiali sugli output strutturati di OpenAI e Anthropic.
Instructor è il modo più pulito per ottenere dati strutturati da qualsiasi modello principale usando Pydantic, che è una libreria Python per definire la forma dei tuoi dati.
Funziona attraverso diversi provider con lo stesso codice e riprova automaticamente quando il modello restituisce qualcosa di malformato.
È vicino a ciò che molti ingegneri in attività usano effettivamente, il che lo rende degno di essere imparato su progetti reali piuttosto che su una versione giocattolo.
Su cosa concentrarsi: definire un modello Pydantic che descriva i dati che vuoi, passare quello schema all'API e gestire il caso in cui il modello rifiuta o restituisce qualcosa di inaspettato.
Capire la differenza tra veri output strutturati, dove lo schema è applicato, e la modalità JSON più lasca, dove non è garantito.
Ecco il tuo secondo artefatto da segnare, un pattern di prompt per l'estrazione strutturata affidabile che funziona anche prima di aggiungere una libreria sopra.
Prompt: Estrazione di dati strutturati
(Framework: FAG Extractor, di AI Guides)
1Il tuo compito: estrarre dati strutturati dal testo che ti fornisco e restituirli2come JSON pulito.34Cosa fare:5- Leggi attentamente il testo di input.6- Estrai solo i campi elencati in Output qui sotto.7- Se un campo manca nel testo, usa null. Non indovinare né inventare.8- Restituisci solo l'oggetto JSON. Nessuna spiegazione, nessun markdown, nessun preambolo.910Regole:11- Ogni valore deve essere riconducibile a qualcosa nel testo di input.12- Date in formato AAAA-MM-GG. Numeri come numeri, non come stringhe.13- Se il testo è ambiguo, preferisci null piuttosto che una risposta sbagliata con sicurezza.1415Output: un oggetto JSON con questi campi:16{17 "field_one": stringa o null,18 "field_two": numero o null,19 "field_three": elenco di stringhe o elenco vuoto20}2122Testo di input:23[INCOLLA QUI IL TESTO]
La nota sul fallimento testato, perché ti ho promesso la versione onesta: la prima volta che lo fai, il modello a volte avvolgerà il JSON nei fence di markdown del codice, o aggiungerà una frase amichevole prima, e il tuo parser si incepperà.
È normale. La soluzione è rimuovere i fence di codice prima di fare il parsing ed essere espliciti nel prompt che vuoi solo l'oggetto JSON, cosa che lo schema sopra fa.
Una volta che ti è capitato e lo hai gestito, lo gestirai per sempre.
Il tuo obiettivo di sviluppo: un parser per ricevute o fatture.
Dagli in pasto testo grezzo e disordinato come "Fattura 123, 45,99 € per 3 widget, scadenza 30 marzo" e ottieni un oggetto strutturato pulito con numero fattura, importo, numero di articoli e data di scadenza.
È un piccolo strumento genuinamente utile e un buon pezzo da portfolio.
Tool calling
Il tool calling è ciò che trasforma un generatore di testo in qualcosa in grado di compiere azioni: cercare sul web, interrogare un database, chiamare la tua API, eseguire codice.
È una delle competenze più importanti in tutta questa guida, ed è il fondamento di tutto ciò che riguarda il Mese 3.
Il modello mentale che lo fa funzionare: il modello non esegue le tue funzioni.
Osserva la conversazione, decide che uno strumento dovrebbe essere usato e restituisce una richiesta strutturata che nomina la funzione e gli argomenti.
Il tuo codice esegue la funzione e restituisce il risultato al modello. Il modello è il decisore. Il tuo codice sono le mani.
La mia scelta: la guida al function calling di OpenAI e la documentazione sull'uso degli strumenti di Anthropic, da leggere insieme.
I concetti sono identici in entrambe, la sintassi differisce leggermente, e vedere entrambi rende evidente lo schema sottostante.
Poi lavora su un esempio di notebook eseguibile, come quello nel cookbook di OpenAI, in modo da vedere l'intero ciclo dall'inizio alla fine invece che a pezzi.
Su cosa concentrarsi: descrivere le tue funzioni chiaramente in uno schema, analizzare la risposta di tool-call del modello, eseguire la funzione e reinserire il risultato, e gestire il caso in cui il modello decide che nessuno strumento è necessario.
La qualità delle descrizioni dei tuoi strumenti è più importante di quanto i principianti si aspettino, un tema che torna prepotentemente nel Mese 3.
Il tuo obiettivo di sviluppo: un piccolo assistente con tre strumenti, come get_weather, calculate e search_notes, dove search_notes cerca solo in un dizionario硬codato.
Collegali tutti e guarda il modello decidere quale chiamare in base a ciò che chiedi.
Nel momento in cui lo vedi scegliere lo strumento giusto da solo, il concetto si fissa definitivamente.
Stato della conversazione e streaming
Due competenze più piccole ma essenziali completano il mese.
I modelli non hanno memoria tra una chiamata e l'altra. Una conversazione è qualcosa che gestisci inviando l'intera cronologia dei messaggi ad ogni richiesta.
Capire questo è fondamentale, e sorprende quasi tutti all'inizio.
La mia scelta è la documentazione sui messaggi di OpenAI e Anthropic.
Concentrati su come è strutturato l'array dei messaggi, perché aggiungi sia i messaggi dell'utente che le risposte del modello, cosa succede quando superi la finestra di contesto e le strategie di base per troncare i messaggi vecchi.
Costruisci un semplice chatbot terminale multi-turno che mantenga la cronologia e abbia un comando di reset. È piccolo e insegna il concetto completamente.
Streaming significa mostrare l'output del modello mentre viene generato, parola per parola, invece di far aspettare l'utente per l'intera risposta.
Fa sembrare le app drasticamente più veloci.
La mia scelta sono i documenti ufficiali sullo streaming di uno dei due provider, più l'analisi chiara di Simon Willison su come funziona lo streaming internamente.
Concentrati sull'impostare l'opzione stream, sull'iterare sui chunk e sull'assemblare la risposta completa dai pezzi.
Per qualsiasi cosa usata da una persona reale, lo streaming è quasi sempre la scelta giusta.
Nessuno vuole fissare uno spinner per dieci secondi.
Costi, fallimenti e un'idea sulla sicurezza
Tre cose che separano un progetto hobbistico da qualcosa che metteresti di fronte agli utenti.
Costi e token: i modelli fanno pagare per token, che corrisponde grosso modo a tre quarti di una parola.
I token di input e output hanno prezzi diversi.
Impara a stimare quanto costerà una richiesta prima di inviarla, tieni segnalibro le pagine dei prezzi dei provider e interiorizza una regola che fa risparmiare soldi veri: non usare il modello più grande e costoso per compiti semplici.
Un modello più economico è spesso più che sufficiente, e la differenza di costo su larga scala è enorme.
Gestione dei fallimenti: le API falliscono.
I limiti di frequenza vengono raggiunti, le richieste vanno in timeout, il modello restituisce output malformato.
Gestire questo con eleganza è ciò che rende qualcosa pronto per la produzione.
Impara a intercettare gli errori di limite di frequenza e riprova con un ritardo crescente tra i tentativi, chiamato backoff esponenziale.
La libreria Tenacity in Python fa questo con un singolo decoratore.
Impara a convalidare l'output del modello prima di fidartene e non lasciare mai che una risposta inaspettata faccia crashare l'intera app.
Iniezione di prompt, brevemente: questo è il principale rischio di sicurezza nelle app LLM.
Succede quando input utente non fidato viene combinato con le tue istruzioni, permettendo a un utente di sovrascrivere o dirottare ciò che il tuo sistema fa.
Non devi diventare un esperto di sicurezza questo mese, ma devi sapere che esiste prima di pubblicare qualsiasi cosa.
La guida OWASP su questo è il riferimento autorevole.
Le difese principali: non fidarti dell'output del modello non convalidato per intraprendere azioni consequenziali automaticamente e dai ai tuoi strumenti il minimo accesso necessario per fare il loro lavoro.
Traguardo del Mese 2
Entro la fine del mese, dovresti essere in grado di scrivere prompt che producono output affidabili per un dato compito, ottenere JSON strutturato da un modello con Pydantic e Instructor, configurare il tool calling in modo che un modello possa eseguire le tue funzioni Python, trasmettere una risposta in tempo reale, gestire la cronologia delle conversazioni multi-turno, stimare il costo in token di una richiesta prima di inviarla, gestire errori API e output errati senza crash e spiegare cos'è l'iniezione di prompt.
Questa è una serie di competenze reali e spendibili da sola.
Molte funzionalità AI a pagamento in produzione fanno esattamente questo e niente più.
Ma il mese prossimo è dove costruisci la cosa che ti fa effettivamente assumere.
Mese 3: RAG e agenti, le competenze che ti fanno assumere
Il tuo obiettivo questo mese: costruire sistemi che permettano ai modelli di rispondere usando i tuoi documenti invece che solo i loro dati di addestramento, e costruire sistemi che compiano più passi autonomamente.
Queste due competenze, recupero delle informazioni (retrieval) e agenti, sono le abilità pratiche più richieste nell'ingegneria AI in questo momento.
Quasi ogni caso d'uso aziendale reale, dai bot di supporto agli strumenti di conoscenza interni all'analisi dei documenti, si basa su di esse.
Ho compresso ciò che molte roadmap distribuiscono su due mesi in uno solo, perché non devi padroneggiare ogni variazione avanzata per essere assumibile.
Devi costruire un sistema di recupero solido e un agente solido, capire perché ogni pezzo è lì ed essere in grado di fare debugging quando si rompono.
Questo è il livello. Raggiungiamolo.
RAG, prima in parole semplici
RAG sta per retrieval-augmented generation (generazione aumentata da recupero).
Togli il gergo ed è semplice: dai al modello una libreria in cui cercare le cose, così non deve aver memorizzato tutto, e così può rispondere a domande sui tuoi documenti specifici.
Il flusso è: prendi i tuoi documenti, li suddividi in chunk, converti ogni chunk in un elenco di numeri che ne cattura il significato e li memorizzi.
Quando un utente fa una domanda, converti la sua domanda in numeri allo stesso modo, trovi i chunk i cui numeri sono più vicini e passi quei chunk al modello insieme alla domanda.
Il modello risponde usando ciò che gli hai dato. Questo è RAG. Tutto il resto è perfezionamento.
Costruiamo i pezzi.
Embedding
Un embedding è un pezzo di testo trasformato in un lungo elenco di numeri che ne rappresenta il significato.
La proprietà utile: il testo che significa cose simili finisce con numeri simili, vicini tra loro in questo spazio numerico.
Questa vicinanza è ciò che rende possibile la ricerca per significato, che è il motore alla base del RAG.
La mia scelta per costruire l'intuizione: l'introduzione intuitiva agli embedding testuali del blog di Stack Overflow, che si concentra sul modello mentale piuttosto che sulla matematica, più la guida agli embedding di OpenAI quando sei pronto a generarli in codice.
Concentrati sul capire cos'è un vettore a livello concettuale, perché testi simili producono vettori simili e approssimativamente come si misura la distanza tra due di essi.
Non hai bisogno della matematica dietro come vengono prodotti gli embedding. Devi sapere come usarli.
Una piccola costruzione che insegna tutto questo: prendi 20 frasi su argomenti correlati, trasforma ciascuna in un embedding e scrivi una piccola funzione che, data una nuova frase, restituisca le tre più simili dal tuo set.
Questo è RAG in miniatura. Una volta costruito questo, la versione completa è solo la stessa idea su larga scala.
Chunking
I tuoi documenti sono troppo grandi per essere incorporati interamente, quindi li suddividi in chunk prima di incorporarli.
Il modo in cui suddividi controlla direttamente quanto bene il tuo sistema trova le informazioni giuste.
Anche una configurazione di recupero perfetta fallisce se i chunk sottostanti sono scadenti.
La mia scelta: inizia con RecursiveCharacterTextSplitter di LangChain, con una dimensione del chunk di circa 500 caratteri e una sovrapposizione di circa 50.
Quella sovrapposizione è importante, perché impedisce di perdere significato al confine dove un chunk finisce e il successivo inizia.
Questa è l'impostazione predefinita sensata che ti dà una base di partenza funzionante.
Il compromesso fondamentale da tenere a mente: chunk troppo grandi perdono precisione, chunk troppo piccoli perdono contesto.
Inizia con l'impostazione predefinita, poi regola in base a ciò che il tuo recupero sta effettivamente sbagliando.
Database vettoriali
Una volta che hai gli embedding, hai bisogno di un posto dove memorizzarli e cercarli velocemente. Questo è ciò che fa un database vettoriale.
La mia scelta per imparare: Chroma. Funziona localmente senza bisogno di configurare infrastrutture, che è esattamente ciò che vuoi mentre impari.
Non hai ancora bisogno di scalabilità cloud gestita, e aggiungerla presto ti dà solo più cose da configurare e rompere.
Chroma ti permette di concentrarti sui concetti.
Trovalo su docs.trychroma.com.
Impara a creare una collezione, inserire embedding insieme a metadati come la fonte e la sezione, interrogare per similarità per ottenere le migliori corrispondenze e filtrare per metadati al momento dell'interrogazione.
Non hai bisogno di capire gli algoritmi di indicizzazione sottostanti. Devi usarli.
Quando avrai bisogno di scala di produzione, pgvector è il passo successivo naturale se la tua app usa già un database Postgres, e ci sono opzioni gestite quando vuoi che qualcun altro lo gestisca.
Ma questa è una preoccupazione del Mese 4 o del lavoro. Per ora, Chroma, in locale, è sufficiente.
Migliorare il recupero
La ricerca di similarità di base ti dà una demo.
Alcuni perfezionamenti ti danno qualcosa che funziona in modo affidabile, e conoscerli è ciò che separa le persone che hanno copiato un tutorial da quelle che capiscono il sistema.
Filtraggio dei metadati: etichetta ogni chunk con informazioni utili quando lo memorizzi, come il file di origine, la data, la sezione o la categoria.
Poi filtra su quelli al momento dell'interrogazione. Questa è la differenza tra un giocattolo e un sistema in cui un utente può chiedere "mostrami solo i risultati del rapporto Q4" e ottenerli effettivamente.
Reranking: la tua prima ricerca è veloce ma approssimativa.
Un reranker prende i primi risultati e li ri-valuta per la reale pertinenza alla domanda, migliorando notevolmente la qualità con un piccolo costo in velocità.
Lo schema è: recupera un set ampio rapidamente, poi ri-ordina fino ai migliori pochi. I documenti di reranking di Cohere sono il posto più pulito per imparare questo, e spesso è una riga da aggiungere.
Debug del recupero, perché la maggior parte dei fallimenti RAG sono fallimenti di recupero, non fallimenti del modello.
Quando il tuo sistema dà una risposta sbagliata, di solito il modello non è il problema.
Il recupero gli ha passato i chunk sbagliati.
Impara le modalità di fallimento comuni: la domanda e il chunk pertinente non corrispondono nello spazio numerico anche se l'informazione è lì (risolvibile riscrivendo la query), l'informazione pertinente è divisa tra due chunk (risolvibile con più sovrapposizione), o il chunk giusto esiste ma non è tra i primi risultati (risolvibile recuperando di più, poi riordinando).
Quando una risposta è sbagliata, controlla cosa è stato recuperato prima di incolpare il modello. Questa abitudine ti farà risparmiare un'enorme frustrazione.
Ancoraggio e citazioni: un buon sistema RAG non si limita a rispondere, dice da dove arriva la risposta, il che costruisce fiducia e rende il debugging molto più facile.
Passa le informazioni sulla fonte per ogni chunk nel tuo prompt e istruisci il modello a citarla.
Ecco il tuo terzo artefatto, il prompt di ancoraggio che mantiene onesto un sistema RAG.
Questo è quello che metterei tra i preferiti sopra tutti gli altri, perché è la differenza tra un sistema che inventa le cose e uno di cui ci si può fidare.
Prompt: Risposta RAG ancorata
(Framework: FAG Grounding, di AI Guides)
1Il tuo compito: rispondere alla domanda dell'utente usando solo il contesto fornito.23Cosa fare:4- Leggi i chunk di contesto qui sotto. Ognuno ha un'etichetta di fonte.5- Rispondi alla domanda usando solo le informazioni trovate nel contesto.6- Dopo ogni affermazione, cita l'etichetta della fonte da cui proviene, come [fonte: nomefile, p.3].7- Se il contesto non contiene la risposta, di' esattamente:8 "Non ho abbastanza informazioni nei documenti forniti per rispondere a questo."910Regole:11- Non usare mai conoscenze al di fuori del contesto fornito.12- Non indovinare mai. Non colmare le lacune con ciò che sembra plausibile.13- Se il contesto risponde parzialmente alla domanda, rispondi a quella parte e di'14 chiaramente cosa manca.1516Contesto:17[INCOLLA QUI I CHUNK RECUPERATI CON LE ETICHETTE DI FONTE]1819Domanda:20[DOMANDA DELL'UTENTE QUI]
Quell'istruzione "di' esattamente questo quando non sai" sta facendo un lavoro pesante. È il singolo modo più efficace per ridurre le allucinazioni in un sistema di recupero, perché dà al modello un modo approvato per ammettere l'ignoranza invece di inventare una risposta per sembrare utile.
La tua costruzione RAG
Usa un framework per unire il tutto piuttosto che costruire ogni pezzo da zero.
La mia scelta per un primo sistema RAG è LlamaIndex, che è costruito con priorità alla ricerca e ti permette di ottenere una pipeline funzionante con poco codice.
LangChain è l'altra opzione principale e brilla di più per il lavoro con agenti multi-step che verrà dopo, quindi lo incontrerai tra un momento.
Il tuo obiettivo di sviluppo, e questo è un vero pezzo da portfolio: un'app "chat con i tuoi documenti".
Inserisci da 10 a 20 PDF o file di testo, i tuoi appunti o un set di documenti di prodotto funzionano bene, costruisci qualcosa che prende una domanda, recupera i chunk più pertinenti con reranking e restituisce una risposta citata.
Mettigli un'interfaccia semplice sopra.
Questo è il progetto che fa sì che i responsabili delle assunzioni ti prendano sul serio, perché è esattamente il tipo di cosa per cui le aziende stanno pagando per essere costruita in questo momento.
Agenti
A metà mese, passa agli agenti.
Un agente suona come magia ed è genuinamente semplice una volta che lo vedi: è un ciclo in cui il modello decide ripetutamente il passo successivo, lo compie usando uno strumento, guarda il risultato e decide di nuovo, finché il compito non è completato.
Il modello mentale: un agente è un ciclo while con un modello che prende le decisioni di diramazione.
Il pensiero avviene nel prompt. La diramazione è il modello che sceglie quale strumento usare. L'esecuzione è il tuo codice che esegue quello strumento.
Tutto il resto è infrastruttura. Una volta che questo scatta, anche i framework di agenti complicati diventano leggibili.
La mia scelta, e la leggerei prima di scrivere una singola riga di codice per agenti: "Building Effective Agents" di Anthropic.
È lo scritto più chiaro su come funzionano gli agenti nella pratica, dal team che costruisce i modelli.
Abbinalo a un corso pratico sul framework quando sei pronto a costruire, come l'introduzione a LangGraph, che è il framework più usato per orchestrare gli agenti.
Su cosa concentrarsi: il ciclo di percepire, decidere, agire, osservare e come sa quando fermarsi.
Cosa succede quando una chiamata a uno strumento fallisce all'interno del ciclo. Come scrivere descrizioni degli strumenti che il modello possa effettivamente usare, perché uno strumento descritto vagamente viene chiamato male o ignorato.
E la gestione dello stato, che è la memoria condivisa che scorre attraverso l'agente mentre lavora.
L'esercizio singolo più prezioso di questo mese: costruisci un piccolo agente da zero senza alcun framework, usando solo l'API del modello direttamente.
Dagli tre strumenti, un obiettivo e un ciclo. Questo ti insegna cosa i framework stanno nascondendo, e fa sì che ogni framework che toccherai in seguito abbia senso.
Fallo prima di toccare LangGraph.
Quando non usare un agente
Questa è una delle competenze più trascurate nel campo, e conoscerla ti contraddistingue come qualcuno con giudizio piuttosto che qualcuno che insegue l'ultima novità.
Gli agenti sono entusiasmanti, e sono anche più lenti, più costosi, meno prevedibili e più difficili da debuggare rispetto agli approcci più semplici.
Ricorrere alla cosa più semplice che funziona è un segno che sai cosa stai facendo.
Il quadro decisionale, da memorizzare: usa una singola chiamata al modello se il compito sta in un prompt con il contesto giusto.
Usa un flusso di lavoro fisso, una catena di passi che definisci, se i passi sono prevedibili.
Usa un agente solo quando il numero di passi è genuinamente imprevedibile e necessita che il modello decida dinamicamente.
Una catena di tre chiamate fisse sarà sempre più veloce, più economica e più facile da debuggare di un agente che potrebbe fare tre chiamate. Riserva gli agenti per compiti genuinamente aperti.
Tra una singola chiamata e un agente completo c'è un ampio e produttivo territorio di mezzo: i flussi di lavoro.
Concatenamento, dove l'output di una chiamata alimenta la successiva.
Instradamento, dove classifichi l'input e lo invii a un gestore specializzato.
Parallelizzazione, dove esegui diverse chiamate contemporaneamente e le combini.
La maggior parte dei problemi reali sono risolti al meglio con un flusso di lavoro, non con un agente, e l'articolo sugli agenti di Anthropic copre bene questi schemi.
Eval, brevemente ma seriamente
Devi sapere se il tuo sistema funziona effettivamente, non solo se ha funzionato sui due esempi che hai provato a mano.
Ecco a cosa servono le valutazioni. Costruisci un piccolo set di 20-30 input rappresentativi con output attesi o una rubrica di punteggio, ed esegui il tuo sistema su tutti loro ogni volta che cambi un prompt, cambi un modello o regoli il tuo recupero.
Strumenti come DeepEval per uso generale e Ragas specificamente per RAG rendono questo gestibile.
La mentalità che conta più dello strumento: ogni cambio di prompt o sostituzione di modello che fai senza eseguire valutazioni è una scommessa.
Le persone che pubblicano AI affidabile eseguono valutazioni costantemente, e iniziare questa abitudine ora, anche in piccolo, ti mette avanti a molte persone che già lavorano nel campo.
Traguardo del Mese 3
Entro la fine del mese, dovresti essere in grado di spiegare cos'è un embedding e perché testi simili producono vettori simili, suddividere un documento in modo sensato, memorizzare e interrogare embedding in un database vettoriale con filtraggio dei metadati, aggiungere reranking per migliorare i risultati, fare debugging di un fallimento di recupero invece di incolpare il modello, costruire una pipeline RAG completa che restituisca risposte ancorate e citate, implementare un ciclo agente da zero, decidere correttamente se un compito necessita di una singola chiamata, un flusso di lavoro o un agente, ed eseguire una valutazione di base per controllare il tuo lavoro.
Questo è il nucleo spendibile.
Se i Mesi da 1 a 3 sono solidi, puoi costruire le cose per cui le aziende stanno assumendo.
Il Mese 4 riguarda il dimostrarlo e farsi pagare.
Mese 4: Pubblicalo, mostralo, fatti assumere
Il tuo obiettivo questo mese: prendi tutto ciò che hai costruito e rendilo reale, poi trasformalo in un lavoro o in un lavoro pagato.
Qui è dove la maggior parte delle persone si blocca.
Sanno costruire una demo ma non sanno pubblicare qualcosa che sopravviva all'uso reale, e non sanno convertire le loro competenze in reddito.
Questo mese risolve entrambe le cose. È più corto su nuovi concetti e più pesante sul fare, perché a questo punto fare è ciò che conta.
Abbastanza deployment per essere pericolosi
Non devi diventare un esperto di infrastrutture.
Devi essere in grado di mettere un'app AI funzionante in un posto dove persone reali possano usarla, senza che cada o ti faccia fallire.
La conoscenza minima vitale: impara abbastanza Docker per impacchettare la tua app in modo che funzioni allo stesso modo ovunque, il che elimina il problema "funziona sulla mia macchina".
Impara a distribuire quel contenitore da qualche parte.
E impara le basi di costo e affidabilità che impediscono a un bug di diventare un disastro: imposta limiti di spesa rigidi sui tuoi account API, aggiungi caching in modo da non pagare per la stessa richiesta due volte e aggiungi limitazione della frequenza in modo che un singolo utente non possa far lievitare il tuo conto.
La guida introduttiva ufficiale di Docker copre l'impacchettamento.
Per il lato dei costi specifico dell'AI, le mosse principali sono: caching delle richieste identiche, usare modelli più economici dove sono abbastanza buoni e impostare un limite di spesa mensile duro in modo che un ciclo fuori controllo non possa costarti 500 € in una notte.
Vuoi anche un'osservabilità di base, che è una parola elegante per essere in grado di vedere cosa sta facendo la tua app.
Le app LLM hanno un problema specifico: il modello può restituire una risposta perfettamente riuscita che è anche inutile o sbagliata, e il monitoraggio normale non lo rileverà.
Uno strumento come Langfuse traccia ogni chiamata al modello, mostrandoti il prompt, la risposta, il costo in token e la latenza, il che rende il debugging e il controllo dei costi molto più facili.
Configuralo su un progetto in modo da capire lo schema.
Non investire troppo qui.
Un'app, distribuita correttamente, con controlli dei costi e tracciamento di base, ti insegna tutto ciò di cui hai bisogno e ti dà qualcosa di reale da mostrare.
La profondità nel deployment può venire sul lavoro.
La parte che ogni altra roadmap salta: trasformare i progetti in un lavoro.
Hai costruito tre progetti reali. Ora fanne in modo che lavorino per te, perché un grande progetto che nessuno vede non fa nulla per la tua carriera.
Il tuo portfolio è composto da tre progetti distribuiti, ognuno con un README che fa un lavoro effettivo.
Ed ecco la mossa che quasi nessuno fa, quella che ti farà distinguere: in ogni README, includi una sezione su cosa è andato storto e cosa faresti diversamente.
La maggior parte dei portfolio finge che tutto abbia funzionato perfettamente, il che suona come disonesto o superficiale.
Un README che dice "ecco dove il mio primo approccio ha fallito, ecco cosa ho imparato, ecco come l'ho risolto" segnala esattamente il giudizio che i datori di lavoro hanno detto di cercare ora.
È il vantaggio del cambiatore carriera dall'introduzione, reso visibile.
Nessuno si aspetta che un cambiatore di carriera abbia un progetto perfetto. Sono colpiti da qualcuno che capisce chiaramente il proprio lavoro abbastanza a fondo da criticarlo.
Struttura ogni README in questo modo: il problema che il progetto risolve, chi lo userebbe, l'approccio che hai seguito e perché, cosa è andato storto e cosa hai imparato, e come eseguirlo.
Cinque sezioni.
Questo è un portfolio migliore di quello che ha la maggior parte delle persone con una laurea in informatica.
La mossa per curriculum e profilo: non devi fingere di avere anni di esperienza.
Hai bisogno di una frase chiara che dica cosa sai fare.
Qualcosa come "Costruisco applicazioni LLM per la produzione: sistemi RAG, agenti e integrazioni API. Ecco tre che ho pubblicato."
Poi collega i progetti. La tua carriera esistente è un asset, non qualcosa da nascondere.
"Ex [tuo campo] che ora costruisce sistemi AI" è una storia più forte di "sviluppatore junior", perché arriva con la conoscenza del dominio e il giudizio che a un puro junior mancano.
Se provieni dalla finanza, capisci i problemi finanziari che un'IA potrebbe risolvere.
Se vieni dal settore sanitario, stesso discorso. Sfruttalo.
Costruire in pubblico come tuo pipeline: per tutto questo mese, continua a postare ciò che costruisci e ciò che impari.
Le migliori opportunità che ho visto sono arrivate a persone che erano visibili, non a quelle che hanno inviato silenziosamente 500 candidature.
Scrivi i tuoi progetti. Condividi l'errore che hai risolto. L'effetto cumulativo è reale, e ormai hai lavoro reale da condividere, quindi è più facile rispetto al Mese 1.
Scegli una direzione
Entro il Mese 4 puoi indirizzare le tue competenze verso ciò che si adatta ai tuoi obiettivi. Tre direzioni, scegline una in cui approfondire invece di disperderti.
Il percorso di ingegnere di prodotto AI, ideale se vuoi un lavoro in una startup velocemente: costruisci prodotti basati sull'AI che utenti reali usano.
Hai già la maggior parte di questo dai Mesi 1 a 3.
Approfondisci la costruzione di app complete e rifinite, e sul lato prodotto, ovvero come l'app gestisce gli errori del modello, come mostra gli stati di caricamento, come gli utenti danno feedback.
Rilascia due o tre cose che le persone possano effettivamente provare.
Il percorso di ML applicato, ideale se vuoi ruoli tecnici più profondi: vai oltre le chiamate API, esplora il fine-tuning, quando fare fine-tuning rispetto a scrivere prompt migliori, eseguire modelli open-source localmente con uno strumento come Ollama e ottimizzazione dell'inferenza.
Il framework decisionale da tenere a mente: inizia con il prompting, aggiungi il retrieval se il modello ha bisogno dei tuoi dati specifici, e fai fine-tuning solo quando prompting e retrieval non riescono davvero a raggiungere la qualità necessaria.
Il fine-tuning viene spesso tentato troppo presto.
Il percorso di automazione AI, ideale se vuoi guadagnare dalle aziende immediatamente: concentrati sull'automazione di flussi di lavoro aziendali reali, collegando l'AI tra strumenti come email, CRM, documenti e fogli di calcolo.
Strumenti come n8n per flussi di lavoro visivi e LangGraph per quelli più incentrati sul codice.
Un progetto vendibile qui: un sistema di qualificazione dei lead che importa lead, usa un modello per ricercare e valutare ciascuno, redige un outreach personalizzato e registra tutto.
Le aziende pagano soldi veri esattamente per questo.
Traguardo del Mese 4
Entro la fine del mese, dovresti avere un'app AI distribuita con controlli dei costi adeguati, tre progetti nel portfolio ciascuno con un README onesto, una chiara frase di presentazione di ciò che costruisci, una traccia visibile del lavoro in pubblico e una direzione scelta su cui stai approfondendo.
A quel punto non sei "qualcuno che sta imparando l'AI." Sei qualcuno che rilascia sistemi AI, che è ciò per cui il mercato paga.
La parte onesta
Ti ho detto all'inizio che non ti avrei venduto una fantasia, quindi ecco la versione diretta prima dei numeri sui soldi.
Quattro mesi di lavoro mirato ti rendono assumibile a livello junior o pronto per lavori freelance. Non ti rendono un ingegnere senior.
Senior si diventa con anni di rilascio di cose reali sotto vincoli reali, e nessuna guida può comprimere questo.
Ciò che quattro mesi ti danno è la capacità di costruire, rilasciare e distribuire sistemi AI che risolvono problemi reali, che è una posizione genuinamente preziosa e genuinamente assumibile.
Questo presuppone lavoro reale, circa 15-20 ore a settimana, costruire effettivamente e non solo guardare.
Se puoi dedicargli solo 7 ore a settimana, questo è un percorso di 8 mesi, ed è perfettamente ok.
La tempistica si allunga, la destinazione non cambia. Ciò che uccide le persone non è un ritmo lento. È fermarsi.
La costanza batte l'intensità qui ogni volta.
E tutto si basa su un comportamento della sezione sugli errori: costruisci, non limitarti a guardare.
Ogni mese ha un progetto. Fai i progetti. Una persona che costruisce quattro progetti approssimativi in quattro mesi è assumibile.
Una persona che guarda quattro mesi di tutorial perfetti non lo è. Questo è l'intero gioco.
I soldi, con fonti
Ora i numeri che vuoi davvero, tutti aggiornati e tutti con fonti, perché affermazioni vaghe sugli stipendi sono il modo in cui queste guide perdono credibilità.
A partire da giugno 2026, Glassdoor colloca lo stipendio medio di un ingegnere AI negli USA a circa $143,500, con un range tipico di circa $115,000 al 25° percentile e $181,000 al 75°, e i guadagni migliori riportati fino a circa $223,000.
Gli ingegneri AI senior guadagnano in media circa $285,000, con un range tipico di circa $221,000 a $375,000, il che mostra quanto sia ripido il salto una volta che hai esperienza reale.
Queste sono le cifre di Glassdoor basate sugli stipendi inviati.
I recruiter che collocano persone in ruoli AI di produzione genuini riportano stipendi base di medio livello che si aggirano tra $155,000 e $200,000, basati su offerte firmate piuttosto che su sondaggi, il che si allinea con il range di Glassdoor e ti dà una seconda lettura indipendente.
E il contesto di mercato più ampio dal Barometro 2026 di PwC, che ho citato all'inizio: i lavori che richiedono competenze AI crescono circa otto volte più velocemente del mercato complessivo, un premio salariale del 62% per le competenze AI, e i requisiti di laurea che calano più rapidamente proprio in questi ruoli.
Non provengono da un thread pubblicitario. Provengono da un'analisi di oltre un miliardo di annunci di lavoro.
I numeri del freelance e della consulenza variano troppo per essere citati con precisione senza fuorviarti, quindi dirò solo questo: le tariffe per implementazione RAG, costruzione di agenti e integrazione LLM sono alte, e un convertito con tre progetti solidi distribuiti e una chiara presentazione può iniziare a farsi pagare per quel lavoro ben prima di ottenere un ruolo full-time.
I progetti sono la prova. Costruiscili e le opzioni di guadagno si aprono.
Inizia questa settimana
Ecco cosa farei davvero, oggi, se fossi in te.
Scegli il progetto Python del Mese 1, il piccolo strumento da riga di comando. Apri un editor di codice.
Inizia il primo set di problemi di CS50P. Imposta il prompt del partner di apprendimento in modo che l'AI ti faccia da tutor nelle parti frustranti.
Crea un repository GitHub e mettici dentro il tuo primo file brutto. Questa è l'intera prima settimana.
Non aspettare di sentirti pronto, perché la preparazione arriva dopo aver iniziato, non prima.
Non pianificare tutti e quattro i mesi in dettaglio perfetto prima di scrivere una riga di codice, perché il piano è già qui e la pianificazione è solo un modo comodo per evitare di iniziare.
Il divario tra imparare e costruire è dove le persone perdono un anno. Chiudilo questa settimana.
Quattro mesi di lavoro reale cambiano genuinamente ciò che è possibile per te.
La porta è più aperta di quanto sia mai stata prima, la barriera delle credenziali sta cadendo e il mercato paga di più per queste competenze rispetto a quasi qualsiasi altra cosa nel tech.
Hai la guida. L'unica variabile rimasta è se costruisci.
Salva questo e torna a consultarlo ogni mese mentre procedi. Lo terrò aggiornato man mano che strumenti e numeri cambiano.
Segui @free_ai_guides per gli aggiornamenti ❤️
