Full-Stack Engineer

Rilasci funzionalità end-to-end. L'agente scrive il codice; tu architetti, specifichi, validi e ti fai carico del risultato. Ti muovi veloce su tutto lo stack perché l'agente non ha preferenze di stack, e tu hai smesso di averle anche tu.

Elevationprimary Convergencesecondary Emergencepartial

Famiglia

Ingegneria

Ruolo legacy equivalente

Full-Stack Engineer, Senior Software Engineer, Staff Engineer (percorso IC)

Riporta a

Tech Lead, Engineering Manager o Director of Engineering

Collabora con

Tech Lead · Product Designer · Product Manager · Agent Supervisor

Il lavoro

Rilasci funzionalità. End-to-end significa end-to-end: livello dati, API, frontend, test, deploy, observability. Non perché fai tutto personalmente, ma perché ti fai carico del risultato e l'agente si occupa del livello che serve.

Nel quotidiano:

Specifichi le funzionalità in modo completo. Criteri di accettazione, casi limite, implicazioni sui dati, comportamento UX, classificazione del rischio, porte di validazione. La specifica è l'artefatto che permette all'agente di eseguire senza supervisione in tempo reale.
Conduci dialoghi di chiarimento con l'agente prima dell'esecuzione. Rispondi alle domande che risolvono ambiguità genuine, rinvii quelle che andrebbero risposte durante l'implementazione e rifiuti quelle che segnalano che la tua specifica era vaga.
Architetti a livello di funzionalità. Decisioni sul modello dati, forma dell'API, confini dei componenti, scelte di dipendenze: spettano a te decidere, all'agente implementare.
Rivedi i PR prodotti dall'agente. Al T2, riga per riga. Al T3, a livello di diff e comportamento. Cerchi il caso mancante, l'astrazione sbagliata, la rottura silenziosa, non i refusi.
Validi a porte calibrate sul rischio. Campionamento per le modifiche reversibili. Approvazione diretta per quelle irreversibili. Progetti le porte per le tue funzionalità mentre le specifichi.
Ricalibri quando le storie si bloccano. Le implementazioni sbagliate sono di solito sintomo di una specifica sbagliata o di un contesto sbagliato. Diagnostichi, ri-specifichi e riprendi, invece di fare debugging sull'output dell'agente.
Mantieni il contesto del codebase. Template di prompt condivisi, file di contesto, guide di stile, librerie di scenari. Sono artefatti di prima classe; ci contribuisci e li usi.
Sei responsabile dell'observability di ciò che rilasci. Telemetria, alert, error budget. Li progetti nella specifica; l'agente li implementa; tu verifichi che il segnale sia reale.
Fai coppia con ingegneri adiacenti sulle decisioni cross-stack. L'agente assorbe gran parte di ciò che prima richiedeva handoff tra specialisti, ma il giudizio umano è ancora migliore in coppia.

Come si misura il successo

Risultati concreti a questo livello:

Throughput. Rilasci funzionalità in giorni, non in sprint. Le storie si completano (specifica → implementa → revisione → merge) in ore-giorni per il lavoro tipico.
Qualità. I difetti in produzione dalle tue funzionalità sono rari e in calo. Il revisore agente cattura ciò che avresti catturato manualmente; i tuoi interventi catturano il resto.
Disciplina di costo. La spesa in token per PR mergiata è tracciata. Il costo per risultato migliora nel tempo, non solo il throughput assoluto.
Lavoro cross-stack. Rilasci funzionalità che toccano frontend, backend e infrastruttura nella stessa settimana. L'agente gestisce il livello; tu gestisci il giudizio.
Salute del codebase. Il refactoring avviene, il debito tecnico viene ripagato, il codebase invecchia bene invece di ossificarsi.

Cosa non conta come successo: righe di codice rilasciate, conteggio dei PR, ore registrate, punti di sprint velocity che non si traducono in risultati per l'utente.

Cosa rende questo lavoro interessante

La parte interessante non è la velocità, è ciò che diventa possibile a quella velocità.

Rilasci più velocemente di quanto pensassi possibile. 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 e lo senti.

Il full-stack diventa naturale. Smetti di avere preferenze di stack perché l'agente non ne ha. Ti muovi fluido tra decisioni sul modello dati, design API e comportamento UX perché l'attrito del context-switching tra livelli dello stack si è ridotto quasi a zero. Il premio è una vera ampiezza di ambito.

Progetti di più, batti meno. La maggior parte del tuo mestiere vive ora nella specifica e nelle decisioni architetturali, non nella battitura. Per gli ingegneri che si sono messi a fare questo lavoro perché amavano la parte di design più della parte di battitura, è un ritorno a ciò che era divertente.

I problemi difficili sono quelli soddisfacenti. Cablare un altro endpoint CRUD richiede minuti. I problemi rimasti per te sono quelli che richiedono giudizio: ottenere bene una macchina a stati, scegliere il confine tra due domini, decidere cosa testare e cosa fidare. Questi sono i problemi che distinguono l'ingegneria senior da quella junior, e sono il grosso di ciò che resta.

Collabori con un altro agente, non solo con altri umani. Lavorare con un agente capace è una competenza in sé: diversa dal pair programming, diversa dal lavoro solitario. I dialoghi di chiarimento sono interessanti di per sé. Le sessioni di ricalibrazione sono interessanti di per sé.

Vedi il tuo lavoro nel mondo rapidamente. Le funzionalità in produzione entro ore dalla specifica significano che il tuo senso di agency nel ruolo è più forte di quanto sia stato per la maggior parte degli ingegneri senior negli ultimi anni. Il ritardo tra pensiero e impatto si è compresso.

Cosa potrebbe non piacerti. Scrivi meno codice a mano. Lo stato di flow di codifica concentrata per ore avviene meno spesso, e quando avviene tende ad essere in luoghi insoliti (sessioni di ricalibrazione, lavoro di infrastruttura che l'agente non sa ancora fare bene). I confini tra "il tuo lavoro" e quello dell'agente si sfumano: se la tua identità artigianale è radicata nel produrre l'artefatto personalmente, quell'identità dovrà migrare. Alcuni ingegneri trovano una versione più profonda della soddisfazione nel nuovo lavoro; altri 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 l'ingegneria senior pre-IA.

Pensi prima di battere. La velocità di battitura ha smesso di contare; la qualità del pensiero a monte conta molto. Ti fermi a considerare i casi limite prima di specificare; non pattern-matchi e ti butti.

Scrivi chiaramente. Le specifiche sono prima scrittura, poi codice. Le persone il cui ragionamento scritto è nebuloso scrivono specifiche nebulose e ottengono output nebulosi.

Sei a tuo agio nell'essere responsabile di risultati che non hai prodotto personalmente. 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 micromanaging dell'agente prosperano.

Sai gestire bene la diagnosi disordinata. Quando una storia si blocca, la causa è di solito nella specifica o nel contesto, non nel codice. Il lavoro investigativo (capire quale assunzione si è rotta) fa parte del mestiere ora. Chi si diverte trova il lavoro ricco; chi vuole problemi puliti con risposte pulite fatica.

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.

Ti interessano i sistemi, non solo le funzionalità. Le funzionalità si rilasciano una dopo l'altra. Gli ingegneri che prosperano nel tempo sono quelli che fanno attenzione a come invecchia il codebase, quali pattern ricorrono, cosa la prossima decisione architetturale deve anticipare.

Meno essenziale di prima: velocità di codifica grezza, curiosità sugli algoritmi, pedanteria sul linguaggio, la capacità di tenere cinque file in testa contemporaneamente. 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 la disposizione. Le competenze qui sotto sono ciò che costruisci attivamente.

Specification engineering. Scrivere specifiche che un agente possa eseguire end-to-end. Criteri di accettazione, casi limite, classificazione del rischio, porte di validazione. Come esercitarsi: scrivi la specifica prima di qualsiasi codice, anche per piccoli compiti. 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. Leggere l'output dell'agente per individuare il caso mancante, l'astrazione sbagliata, la rottura silenziosa, senza leggere ogni riga. Come esercitarsi: rivedi i PR generati dall'IA del tuo team. Articola perché controbatteresti. Traccia le contestazioni che si sono rivelate sbagliate: è lì che il tuo giudizio è mal calibrato.

Diagnosi ricalibrazione vs debugging. Quando il lavoro si blocca, sapere se il problema è nella specifica, nel contesto o nell'implementazione. Come esercitarsi: tieni un breve diario delle storie bloccate. Classifica ogni post-mortem come ricalibrazione (problema di specifica/contesto) o debugging (problema di implementazione). Traccia quali interventi hanno effettivamente sbloccato.

Classificazione del rischio. Distinguere il lavoro reversibile da quello irreversibile e assegnare la giusta porta di validazione. 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 ingegnere senior con background backend ora può possedere funzionalità rivolte all'utente end-to-end. Come esercitarsi: leggi PR in aree adiacenti (frontend, infra, dati). Nota cosa trovi confuso: lo scarto è la tua superficie di apprendimento. Affianca la persona la cui specialità era quella.

Mestiere del dialogo di chiarimento. Q&A produttivo con l'agente prima dell'esecuzione. Sapere a quali domande rispondere pienamente, quali rinviare, quali segnalano una specifica nebulosa. Come esercitarsi: nota le domande che un agente pone prima di implementare. Categorizzale. La categorizzazione ti mostrerà dove le tue specifiche hanno bisogno di lavoro.

Cura del contesto. Mantenere i template di prompt condivisi, i file di contesto e le librerie di scenari da cui attingono gli agenti del team. Come esercitarsi: contribuisci con un miglioramento per sprint. Gli artefatti si compongono; i piccoli contributi contano.

Scegli una competenza, esercitati per due settimane su lavoro reale e nota come si sposta il tuo rapporto con il ruolo. Provare a sviluppare tutte e sette contemporaneamente è il fallimento più comune.

Come differisce dal ruolo legacy di Senior Engineer

Senior Engineer legacy (pre-IA)	Senior Engineer (IA-nativo)
Scrive codice complesso di persona; rivede quello degli altri	Scrive specifiche; rivede l'output dell'agente a porte calibrate sul rischio
Si specializza in frontend o backend o infrastruttura	Opera su tutto lo stack perché lo fa l'agente
Passa il 50-70% del tempo a programmare	Passa meno del 20% del tempo a programmare
Throughput limitato dalle ore di focus individuale	Throughput limitato dalla qualità delle specifiche e dal giudizio in revisione
Handoff a specialisti per il lavoro cross-stack	Si abbina agli specialisti sul giudizio, rilascia su tutto lo stack da solo
I migliori ingegneri sono i produttori più veloci e prolifici	I migliori ingegneri sono i più chiari nello specificare e i più discernenti nella revisione
Test scritti riga per riga dagli umani	Scenari di test specificati dagli umani, scritti dall'agente, rivisti dagli umani

Il ruolo non è un "senior" rinominato. Il quotidiano è strutturalmente diverso.

Quali pattern di evoluzione dei ruoli sono in gioco

Elevation (primario). Il baricentro del ruolo si sposta dall'esecuzione alla specifica e validazione. Il valore migra dalla velocità di battitura alla qualità della specifica e al giudizio in revisione.
Convergence (secondario). I confini tra frontend, backend e infrastruttura si sfumano. Un ingegnere senior con giudizio solido può dirigere l'agente su tutto lo stack su una funzionalità che prima richiedeva il coordinamento di tre specialisti.
Emergence (parziale). Alcune responsabilità sono genuinamente nuove: dialoghi di chiarimento con agenti, sessioni di ricalibrazione, contributi alla configurazione del revisore agente.

Specialization e Absorption non si applicano in modo significativo: il ruolo si espande invece di restringersi, e non si contrae né scompare.