Tech Lead
Non scrivi più il codice. Scrivi le specifiche che fanno accadere il codice e validi i risultati. Il lavoro è più veloce, la tua portata è più ampia e le tue decisioni contano di più.
Il lavoro
Sei responsabile di una fetta di prodotto. All'interno di quella fetta, decidi cosa viene costruito, come viene costruito e se ciò che è stato rilasciato è corretto. Sei responsabile dei risultati, non di specifiche righe di codice.
Nel quotidiano:
- Scrivi le specifiche che un agente IA può implementare end-to-end senza supervisione in tempo reale. Ogni specifica include criteri di accettazione, casi limite, classificazione del rischio e le porte di validazione che si applicano.
- Conduci dialoghi di chiarimento con l'agente prima che l'esecuzione inizi. Rispondi alle domande che risolvono ambiguità genuine, rinvii quelle che andrebbero risposte durante l'implementazione e rifiuti quelle che segnalano una specifica nebulosa da parte tua.
- Validi l'output a porte calibrate sul rischio. Il lavoro reversibile passa attraverso il revisore agente con campionamento. Il lavoro irreversibile (deploy in produzione, cambiamenti di schema, testi rivolti al cliente, confini di sicurezza) richiede la tua approvazione diretta.
- Conduci sessioni di ricalibrazione quando una funzionalità si blocca. L'agente ha raggiunto un limite strutturale, la specifica ha tralasciato un vincolo, oppure il contesto è sbagliato. Diagnostichi quale e ricostruisci la comprensione dell'agente con il team.
- Imposti gli standard per la fetta: cosa conta come specifica completa, quando fare escalation, come è configurato il revisore agente, quali pattern sono lo stile della casa.
- Fai mentoring dei tuoi ingegneri sulla qualità delle specifiche, sul giudizio in revisione e sulla differenza tra debugging e ricalibrazione. È qui che si concentra il mestiere del ruolo.
- Rimani vicino all'utente. Test UX con i primi utenti, sessioni sui casi limite e validazione qualitativa: sono tuoi da condurre, non da delegare.
- Ti fai carico delle decisioni irreversibili. Deploy in produzione, migrazioni di dati, impegni con i vendor, pivot architetturali. L'agente fa il lavoro reversibile; tu firmi per il resto.
Come si misura il successo
Risultati concreti a questo livello:
- Throughput. La tua fetta rilascia funzionalità in giorni, non in sprint. Le storie si completano end-to-end (specifica → implementa → revisione → merge) in ore-giorni per il lavoro tipico.
- Qualità. I difetti in produzione per funzionalità sono pochi e in calo. Il revisore agente cattura la maggior parte di ciò che avresti catturato manualmente.
- Costo. La spesa in token per PR mergiata è tracciata e visibile. Il costo per risultato migliora nel tempo, non solo il throughput assoluto.
- Capacità del team. Altri ingegneri della tua fetta scrivono specifiche utilizzabili senza che tu rivisiti ogni parola. Le sessioni di ricalibrazione non richiedono tutte la tua facilitazione.
- Risultati per l'utente. Le funzionalità che rilasci corrispondono alle esigenze reali dell'utente alla prima release. Il numero di funzionalità ritirate o sostanzialmente revisionate è basso.
Cosa non conta come successo a questo livello: righe di codice rilasciate, conteggio dei PR, ore registrate, metriche interne di velocity che non si traducono in risultati per l'utente.
Cosa rende questo lavoro interessante
La parte interessante non è ciò che fa l'IA. È ciò che rimane umano.
Le tue decisioni si moltiplicano. Una specifica ben scritta produce decine di output corretti. Una porta di validazione ben progettata cattura una classe di bug per sempre. La tua portata non è più limitata dalla velocità di battitura o dalle ore di sonno.
Rilasci velocemente e vedi l'impatto. Ciò che prima richiedeva uno sprint richiede un giorno. La funzionalità che hai specificato martedì mattina è in produzione mercoledì pomeriggio. Il ciclo di feedback con l'utente si chiude entro la settimana.
Lavori al livello dell'intento. Decidi cosa dovrebbe esistere e perché. Non passi tre ore a cablare un modulo per fare qualcosa che un junior avrebbe cablato in due. Il lavoro si concentra sulle parti dell'ingegneria che sono genuinamente difficili: progettare sistemi, anticipare le modalità di fallimento, definire bene i confini.
I problemi più difficili sono ora i più interessanti. Il lavoro di ricalibrazione (capire perché un sistema competente si è confuso) si trova all'intersezione tra ingegneria, linguaggio e psicologia. Non è "debugging su scala". È più vicino all'insegnamento, o alla terapia. Quando una storia è bloccata al T3, la risposta è raramente nel codice.
Passi più tempo con gli umani. Stakeholder, designer, utenti, il tuo team. L'agente gestisce la battitura; tu gestisci le conversazioni che rendono utile la battitura. Per gli ingegneri che si sono messi a fare questo lavoro anche per costruire cose che le persone usano, è un ritorno alle origini.
Sei responsabile di risultati più grandi di ciò che avresti potuto costruire da solo. La tua fetta rilascia al throughput di un team di 10 persone nel vecchio modello. La responsabilità è reale e la portata è reale.
Cosa potrebbe non piacerti. Scrivi meno righe di codice. Vedi meno mestiere riga per riga in produzione. Lo stato di flow di codifica concentrata per ore avviene meno spesso. Se la tua soddisfazione veniva principalmente dalla produzione dell'artefatto, quella soddisfazione si sposterà; alcune persone trovano una versione più profonda nel nuovo lavoro, altre no. Sii onesto con te stesso su che tipo di ingegnere sei.
Chi prospera in questo ruolo
Le attitudini che contano di più al T3 sono diverse da quelle che definivano i Tech Lead nell'era precedente.
Sai articolare ciò che vuoi. Le specifiche sono prima scrittura, poi codice. Le persone che pensano in parole e immagini, non solo in codice, scrivono specifiche migliori.
Pensi prima di agire. La velocità di battitura ha smesso di contare. La qualità del pensiero a monte ha iniziato a contare molto. Le persone che si fermano per porre le domande giuste prima di iniziare superano chi pattern-matcha e si butta.
Sei a tuo agio nell'essere responsabile di risultati che non hai prodotto personalmente. È un cambiamento reale. L'agente ha scritto il codice; tu hai dato l'ok; se fallisce, ti fai carico tu. Le persone che sanno reggere quella responsabilità senza vacillare, e senza micromanaging dell'agente, prosperano qui.
Sai gestire bene la diagnosi disordinata. Il lavoro di ricalibrazione è raramente soddisfacente nell'immediato. L'agente ha fatto qualcosa di sottilmente sbagliato, devi capire perché, la risposta di solito è nella specifica o nel contesto, e la correzione è a monte. Le persone che si divertono con questo tipo di lavoro investigativo se la cavano bene; chi vuole problemi puliti con risposte pulite fatica.
Sai insegnare. Ogni specifica è un artefatto didattico. Ogni sessione di ricalibrazione è una sessione di coaching. Ogni code review è uno scambio di feedback. I Tech Lead che potevano "farlo da soli" prima, ma che non riuscivano a far scalare la qualità del team, scoprono che questo ruolo premia ciò in cui erano già bravi.
Hai gusto. Quando l'agente produce tre implementazioni plausibili, sai dire quale è giusta per questo codebase. Il gusto è difficile da intervistare e più difficile da insegnare, ma è il singolo vantaggio più duraturo al T3.
Meno essenziale di prima: velocità di codifica grezza, curiosità sugli algoritmi, pedanteria sul linguaggio, la capacità di passare di contesto tra cinque file in testa. Erano i marker dell'ingegneria senior pre-IA. Aiutano ancora. Non sono più ciò che differenzia il ruolo.
Competenze da sviluppare per arrivarci
Le attitudini sopra descrivono chi sei. Le competenze qui sotto sono ciò che costruisci attivamente. Nessuna è misteriosa. Tutte richiedono pratica deliberata.
Specification engineering. Scrivere specifiche che un agente possa eseguire end-to-end senza supervisione in tempo reale. Criteri di accettazione, casi limite, classificazione del rischio, porte di validazione: espliciti, testabili, completi. Come esercitarsi: scrivi la specifica prima di qualsiasi codice, anche per piccoli compiti. Affianca qualcuno che scrive buone specifiche e fai reverse engineering delle sue bozze. Rileggi le tue specifiche un mese dopo; quelle invecchiate male sono il tuo materiale di apprendimento. Vedi la Guida alle specifiche.
Giudizio in revisione a livello di diff. Sapere su cosa controbattere senza leggere ogni riga. Individuare il caso mancante, l'astrazione sbagliata, la rottura silenziosa. Come esercitarsi: rivedi i PR generati dall'IA del tuo team. Articola perché controbatteresti, non solo dove. Traccia le contestazioni che si sono rivelate sbagliate: è lì che il tuo giudizio è mal calibrato.
Diagnosi ricalibrazione vs debugging. Quando una storia si blocca, sapere se il problema è nella specifica, nel contesto o nell'implementazione. La diagnosi sbagliata costa giorni. Come esercitarsi: tieni un breve diario delle storie bloccate. Classifica ogni post-mortem come ricalibrazione (problema di specifica o contesto) o debugging (problema di implementazione). Traccia quali interventi hanno effettivamente sbloccato. Il pattern emergerà.
Progettazione della validazione calibrata sul rischio. Separare il lavoro reversibile da quello irreversibile e assegnare la giusta porta di validazione a ciascuno. Troppi cancelli rallentano il team; troppo pochi rilasciano le cose sbagliate. Come esercitarsi: per ogni storia che specifichi, nomina le porte esplicitamente. Giustifica perché. Adatta man mano che impari dagli errori di classificazione. Vedi Standard di esecuzione IA.
Giudizio cross-stack. Prendere decisioni solide al di fuori della tua specializzazione storica. Convergence al T3 significa che un Tech Lead con background backend ora può possedere funzionalità rivolte all'utente end-to-end. Come esercitarsi: leggi PR in aree adiacenti (frontend, infra, dati). Non commentare ancora. Nota cosa trovi confuso: lo scarto è la tua superficie di apprendimento. Affianca la persona la cui specialità era quella.
Insegnare tramite la scrittura. Ogni specifica è anche materiale di onboarding. Ogni voce del diario di ricalibrazione è futuro training. I Tech Lead che fanno scalare la qualità del team sono quelli i cui artefatti scritti possono essere riutilizzati senza la loro presenza. Come esercitarsi: scrivi le specifiche come se un ingegnere junior le leggesse tra sei mesi senza alcun contesto. Se le tue specifiche richiedono il tuo chiarimento in tempo reale per essere utili, non sono finite.
Abitudini sotto le competenze. Fermarsi prima di agire. Porre domande di chiarimento prima di assumere. Documentare il ragionamento, non solo le decisioni. Queste non sono competenze da spuntare: sono discipline da mantenere. Le competenze sopra si compongono solo se queste abitudini sono intatte.
Se sei ancorato alla versione legacy del ruolo, l'ingresso onesto è: scegli una di queste competenze, esercitati per due settimane su lavoro reale, e nota come cambia il tuo rapporto con il ruolo. Provare a sviluppare tutte e sei contemporaneamente è il fallimento più comune.
Come differisce dal ruolo legacy di Tech Lead
Il Tech Lead è il produttore più prolifico di codice funzionante del team.
Il Tech Lead è il più chiaro nello specificare e il più discernente nella revisione del team.
Una storia bloccata significa sedersi accanto all'ingegnere e scrivere codice insieme finché non si sblocca.
Una storia bloccata significa che la specifica o il contesto sono sbagliati. Le sessioni di ricalibrazione ricostruiscono la comprensione dell'agente.
Programmare è il mestiere primario e gran parte della giornata.
Specifica, validazione e ricalibrazione sono il mestiere primario. Programmare è occasionale.
La responsabilità è per artefatto: ogni PR rivisto personalmente.
La responsabilità è per processo: il sistema di validazione cattura i problemi; il Tech Lead ha progettato il sistema.
Il ruolo non è un "Senior Engineer" rinominato. Il quotidiano è strutturalmente diverso. Il throughput è limitato dalla qualità delle specifiche e dalla progettazione della validazione, non dalla dimensione del team e dalle ore di focus; stand-up e rituali si riducono a favore di revisione asincrona delle specifiche; i migliori ingegneri nel ruolo sono specificatori chiari e revisori discernenti, non produttori prolifici.
Quali pattern di evoluzione dei ruoli sono in gioco
Tre dei cinque pattern di evoluzione dei ruoli modellano questo ruolo.
- Elevation (primario). Il passaggio dal produrre codice allo specificarlo e validarlo. Il valore migra dalla velocità di esecuzione alla qualità della specifica e al giudizio in revisione.
- Convergence (secondario). I confini tra frontend, backend, infrastruttura e QA si sfumano. Un Tech Lead con giudizio solido dirige l'agente su tutto lo stack su una singola funzionalità.
- Emergence (parziale). Alcune responsabilità sono genuinamente nuove: configurare il revisore agente, progettare porte di validazione calibrate sul rischio, condurre sessioni di ricalibrazione.
Specialization e Absorption non si applicano in modo significativo: il ruolo si espande invece di restringersi, e non si contrae né scompare.
Ruoli correlati nel catalogo
Contributor individuale al T2-T3 senza ambito di leadership. La maggior parte dei Tech Lead viene da questo ruolo.
Ruolo emergente focalizzato sulla progettazione di flussi di lavoro agentici cross-team. Un passo naturale dal Tech Lead.
Quando ambito e people-leadership crescono oltre una fetta, il percorso si dirama verso il management.
Fonti e letture di approfondimento
- Patel, N. (2026). From Tasks to Roles: How Agentic AI Reconfigures Occupational Structures.
- Stack Overflow (2025). Developer Survey: AI Tools.
- GitClear (2025). AI Assistant Code Quality Research.
- Di questo framework: Scala di ingegneria, gradini 0-5.
- Di questo framework: Laboratorio IA, unità operativa e Ingegneria dell'affidabilità.
← Torna ai ruoli · Pattern di evoluzione dei ruoli · Quadro di riferimento · Trasformare il tuo ruolo · Guida alle specifiche · Standard di esecuzione IA
