Come diventare un Forward Deployed Engineer in 10 passaggi: 785.000 $ / anno (corso completo)

Ingegnere Forward Deployed: da curiosità di Palantir al ruolo più richiesto nell'AI in dodici mesi - annunci aumentati del 729%.

Questa è la roadmap in 10 passi per entrarci: cosa fa realmente il lavoro, lo stack che ti fa entrare, e il round di colloquio che elimina il 60% delle persone che superano la prova di coding.

Segui il mio Substack per ricevere le ultime novità sull'AI:

movez.substack.com

Non è il pacchetto di uno scienziato della ricerca. Non è quello di un ingegnere senior in una grande azienda tech.

È la tariffa corrente per un ingegnere che fa qualcosa che quasi nessuno ottimizza nella propria carriera: far funzionare davvero l'AI dentro un'azienda reale.

Nessuno chiede a questa persona di addestrare un modello. Non serve un PhD, e non serve battere nessuno in puzzle di algoritmi.

Devono entrare in un'azienda con sistemi legacy, un reparto compliance e un team operativo scettico - e uscirne sei settimane dopo con qualcosa che funziona.

Il motivo per cui paga così tanto è una sola statistica. Uno studio MIT NANDA su 300 progetti AI enterprise ha rilevato che il 95% ha prodotto un impatto scarso o nullo su profitti e perdite.

I modelli funzionavano bene. Le implementazioni fallivano - perché nessuno riusciva a farli parlare con un database legacy, superare una revisione di compliance, o sopravvivere al passaggio di consegne al team che li aveva ereditati.

Il nome è preso in prestito dal militare: forward deployed significa posizionare unità specializzate vicino al teatro operativo piuttosto che al quartier generale.

Palantir ha costruito la versione moderna nei primi anni 2010 e li ha chiamati Deltas - e fino al 2016, l'azienda aveva più Deltas che ingegneri software.

La premessa era che i clienti non avevano bisogno di più funzionalità del prodotto. Avevano bisogno di ingegneri che potessero far funzionare il prodotto nei loro ambienti frammentati, legacy, regolamentati e politicamente complicati.

Quella premessa è stata di nicchia per un decennio. Poi l'AI ha distrutto il SaaS generico, ed è diventata il gioco completo.

Questa non è una descrizione del lavoro. È una strategia di go-to-market - e le persone che la eseguono sono gli ingegneri non ricercatori più pagati del settore.

01. Impara cosa fa realmente il lavoro

Un FDE è l'ingegnere che l'azienda invia dal cliente. Non per una chiamata di vendita, non per una riunione di kickoff - per settimane alla volta, seduto accanto alle persone che utilizzeranno realmente il prodotto, imparando il loro flusso di lavoro in dettaglio doloroso, e scrivendo codice personalizzato che fa funzionare la loro versione.

Il miglior modello mentale non è il consulente e non è l'ingegnere delle soluzioni. È l'ingegnere fondatore, che lavora sul prodotto di qualcun altro.

Non c'è un PM nella stanza per decidere l'ambito, nessun ingegnere senior a cui escalare l'architettura, e nessun backlog che ti dice cosa conta - decidi tu cosa costruire, cosa simulare e a cosa opporti, nella stanza, quella settimana.

Il ritmo tipico nelle migliori aziende AI è sorprendentemente coerente: un FDE si siede con un cliente per quattro-otto settimane, pubblica qualcosa che funziona, e poi il team di ingegneria principale lentamente rende prodotto ciò che si è rivelato generale.

Questo ciclo è l'intero punto strategico del ruolo. Stai contemporaneamente generando fatturato e facendo la ricerca di prodotto più fedele dell'azienda.

02. Capisci perché il ruolo è esploso

Quel numero del 95% dell'incipit è il fondamento di tutto questo percorso di carriera, quindi vale la pena capirlo con precisione.

• Quei progetti AI enterprise non sono falliti perché i modelli erano scadenti.
• Sono falliti sull'integrazione: sistemi che non potevano parlare con database SQL legacy, non potevano gestire l'autenticazione SAML del cliente, non potevano soddisfare i requisiti di residenza dei dati, e non potevano essere mantenuti dal team operativo che li aveva ereditati.

Poi tre forze hanno puntato nella stessa direzione contemporaneamente.

• L'AI ha distrutto il SaaS generico - la promessa orizzontale di compralo-e-collegalo sopravvive nelle categorie mature ma non nell'AI, dove ogni azienda ha dati unici, flussi di lavoro unici, vincoli di compliance unici e la propria definizione di "abbastanza buono". Vendere AI a una Fortune 500 è ora sempre anche vendere un progetto di integrazione.
• I laboratori devono implementare alla velocità con cui la tecnologia si muove - un'integrazione di sei mesi uccide un pilota prima che atterri.
• E gli strumenti AI hanno reso i conti economici sostenibili: con Claude Code e lo stack moderno, un singolo FDE forte fa ciò che richiedeva un team di tre qualche anno fa, che è l'unico motivo per cui inviare una persona in sede per sei settimane ha senso economicamente.

Nota cosa significa per te. Il collo di bottiglia nell'AI non è più la capacità. È l'implementazione - e il mercato si sta riprezzando di conseguenza.

03. Mappa il mercato e scegli i target

Il titolo è instabile, e questa è la prima cosa pratica da sapere - cercare solo "Forward Deployed Engineer" ti nasconderà la maggior parte del mercato.

Lo stesso lavoro viene pubblicato come Applied AI Engineer (il nome di Anthropic), Forward Deployed Software Engineer o FDSE (quello di Palantir), Solutions Engineer, Deployment Engineer e Founding Engineer (Customer Facing) nelle startup più piccole. Cercali tutti.

La crescita non è sottile. Gli annunci FDE su Indeed sono passati da 643 nell'aprile 2025 a 5.330 nell'aprile 2026 - un aumento del 729% in dodici mesi.

A metà 2026 c'erano 224 ruoli FDE aperti in 39 aziende AI, e questo conta solo ciò che era pubblicamente pubblicizzato. Salesforce si è impegnata ad assumerne mille. EY ha lanciato una pratica FDE dedicata nel Regno Unito e Irlanda nell'aprile 2026 - la prima grande società di consulenza ad adottare formalmente il modello.

La compensazione riflette la scarsità, e si divide nettamente per livello. I dati Levels fyi mettono la retribuzione totale media USA intorno a $238.000, con un range tipico di $205.000–$486.000 e FDE di livello senior che superano $630.000. La mediana di Palantir si aggira intorno a $215.000.

Nei laboratori all'avanguardia è un mercato completamente diverso: gli FDE senior in Anthropic e OpenAI superano $785.000, con gli Applied AI Engineers di Anthropic oltre $300.000 di base a livelli senior e la retribuzione totale che supera regolarmente $500.000.

Una nota di pianificazione utile da sapere subito: Anthropic tipicamente non negozia le offerte.

04. Costruisci ampiezza ingegneristica

Questa è la parte controintuitiva, ed è qui che gli ingegneri provenienti da un percorso specialistico sbagliano.

Gli FDE più forti non sono gli ingegneri più profondi della loro azienda.

Sono quelli che possono tenere sei domini in testa contemporaneamente e passare dall'uno all'altro con poco sforzo. La profondità in un'area vale meno qui che essere genuinamente solidi in tutto.

Concretamente, il livello base è questo. Python e TypeScript coprono la maggior parte del terreno che toccherai. Un cloud - AWS, GCP o Azure, scegli quello su cui i tuoi clienti target girano effettivamente.

Un database che conosci bene e che puoi debuggare sotto pressione, e un framework frontend con cui puoi mettere insieme un'interfaccia funzionante.

Questo è sufficiente per iniziare. Non devi essere il miglior ingegnere nella stanza; devi essere l'unica persona nella stanza che sa fare tutto.

Due strati più soft contano quanto quelli tecnici, e sono ciò che il colloquio sonderà realmente.

Il giudizio di prodotto, perché sei tu il PM nella stanza e nessun altro deciderà cosa costruire versus cosa simulare.

E acume imprenditoriale - qualcuno chiederà qual è il ROI di questo, e avranno bisogno della risposta per difendere il progetto davanti alla propria dirigenza.

Inquadrare il tuo lavoro in dollari e ore risparmiate è un'abilità reale e apprendibile che la maggior parte degli ingegneri non pratica mai.

05. Impara a pubblicare AI, non ad addestrarlo

Ecco l'equivoco più comune che separa gli ingegneri da questo lavoro: presumono di dover saper addestrare modelli.

Non è così. Nessuno chiede a un FDE di fare fine-tuning di nulla. Devi assolutamente saperli pubblicare - che è un set di abilità completamente diverso e molto più apprendibile.

Il livello AI-native è ben definito a questo punto. Buona ingegneria dei prompt. Fluidità con le principali API dei modelli.

• Pattern RAG - e specificamente, sapere quando il recupero è la risposta sbagliata.
• Output strutturati, perché i sistemi di produzione hanno bisogno di forme validate, non di prosa.
• Disciplina di base degli eval, che è il livello che separa chi fa demo da chi pubblica.

E almeno un framework per agenti in cui hai effettivamente costruito qualcosa.

Pesa la tua preparazione verso eval e modalità di fallimento, perché è di questo che è fatta l'implementazione enterprise. Debug di allucinazioni, fallimenti di recupero, chiamate errate a strumenti, flussi di lavoro multi-step fragili.

Saper ragionare su latenza, costo, affidabilità e sicurezza come compromessi piuttosto che come checkbox.

1# Valuta da 1 a 5. Qualsiasi cosa sotto 3 è il tuo prossimo mese di lavoro.
2
3## Ampiezza ingegneristica          # solido, non eccellente
4[ ] Python // backend, script, dati
5[ ] TypeScript // integrazioni + un frontend utilizzabile
6[ ] Un cloud, averci distribuito qualcosa di reale
7[ ] Un database, saperlo debuggare sotto pressione
8[ ] Saper mettere in piedi una UI funzionante in un giorno
9
10## AI native                     # pubblica, non addestrare
11[ ] Ingegneria dei prompt oltre il tentativo ed errore
12[ ] API dei modelli: streaming, uso di strumenti, budget di token
13[ ] RAG // e sapere quando il recupero è la RISPOSTA SBAGLIATA
14[ ] Output strutturati + validazione dello schema
15[ ] Eval // il livello che separa la demo dalla produzione
16[ ] Un framework per agenti, qualcosa effettivamente costruito
17
18## La metà che nessuno pratica
19[ ] Ho condotto un workshop con uno stakeholder non tecnico
20[ ] Ho detto "non dovremmo costruirlo" a un cliente pagante
21[ ] Ho espresso il mio lavoro in dollari o ore risparmiate
22[ ] Ho imparato un settore sconosciuto abbastanza bene da pubblicarci
236
24Costruisci lo stack

Chiunque può far funzionare una demo; l'intero valore di un FDE è essere la persona che sa perché la demo non sopravviverà al contatto con un'azienda reale, e cosa fare al riguardo.

06. Costruisci i tre artefatti che le aziende comprano

Qui è dove una roadmap generica "impara l'AI" smette di essere utile e i dettagli iniziano a contare.

Le stesse offerte di lavoro FDE di Anthropic descrivono i deliverable chiaramente: ti integri con clienti strategici per costruire applicazioni di produzione con Claude, e pubblichi server MCP, subagenti e competenze per agenti.

Questi tre artefatti sono l'unità concreta di lavoro.

• I server MCP sono il livello di integrazione - la cosa che collega Claude ai sistemi reali del cliente: il loro ticketing, il loro magazzino, la loro API interna che non ha documentazione e una sola persona che la capisce.
• Le competenze per agenti codificano il flusso di lavoro specifico del cliente e la conoscenza istituzionale in modo che Claude segua il loro processo piuttosto che uno generico.
• I subagenti gestiscono il lavoro che altrimenti farebbe esplodere una finestra di contesto in un'attività di lunga durata.

Costruiscine uno di ciascuno, contro un sistema reale, e hai qualcosa che quasi nessun candidato ha: un portfolio esattamente degli artefatti che il lavoro produce.

1# L'artefatto che un FDE pubblica realmente: Claude, collegato a un sistema
2# che nessuno ha progettato per questo. API legacy, nessuna documentazione, un tizio che la capisce.
3
4from mcp.server.fastmcp import FastMCP
5
6mcp = FastMCP("warehouse-ops")
7
8@mcp.tool()
9def find_stalled_shipments(hours_stalled: int = 24) -> list[dict]:
10    """Spedizioni senza eventi di scansione da N ore. Usa quando l'operations
11    chiede cosa è bloccato, o prima di una revisione di escalation cliente."""
12    # Il lavoro reale: il loro schema legacy, la loro stranezza di fuso orario,
13    # la loro colonna di soft-delete che nessuno ha documentato.
14    return query(STALLED_SQL, hours_stalled)
15
16@mcp.tool()
17def reroute(shipment_id: str, hub: str, reason: str) -> dict:
18    """Reindirizza una spedizione. Scrive una riga di audit — la compliance
19    richiede una stringa di motivazione per ogni intervento manuale."""
20    return post_with_audit(shipment_id, hub, reason)
21
22# Nota cosa rende questo un artefatto FDE e non una demo:
23#   - le docstring dicono QUANDO usare lo strumento, non solo cosa fa
24#   - la riga di audit esiste perché il loro team di compliance la richiede
25#   - le stranezze dello schema sono gestite qui, non lasciate al modello

Un server MCP che incapsula un'API genuinamente disordinata è un segnale di assunzione più forte di qualsiasi certificazione, perché prova la cosa che altrimenti non possono testare - che sai rendere utile un modello all'avanguardia dentro un sistema che nessuno ha progettato per questo.

07. Padroneggia Claude Code come tuo moltiplicatore

Ricorda la terza forza del Passo 2 - quella sottovalutata. Gli strumenti AI hanno reso gli FDE drammaticamente più produttivi, e questo è ciò che ha reso il ruolo economicamente sostenibile su larga scala.

Un singolo FDE forte ora fa il lavoro che richiedeva un team di tre qualche anno fa. Inviare una singola persona in sede per sei settimane ha senso solo grazie a quel moltiplicatore.

Quindi gli strumenti non sono un optional in aggiunta al lavoro; sono portanti per il business case del tuo posto.

Praticamente, questo significa che la fluidità con Claude Code fa parte dello stack di competenze, non è adiacente.

I punti di leva specifici si mappano direttamente sul lavoro FDE: entrare rapidamente in un codebase sconosciuto quando arrivi da un nuovo cliente, scrivere la colla di integrazione che costituisce la maggior parte del tuo output, e delegare la ricerca a subagenti in modo che un'attività di distribuzione lunga non collassi sotto il suo stesso contesto.

C'è anche una ragione di segnale di assunzione per diventare bravo in questo, ed è insolitamente diretta. Nello screen del caso d'uso tecnico di Anthropic, potresti ricevere accesso a Claude e ti viene chiesto di risolvere il problema con esso - deliberatamente, perché rispecchia il lavoro reale.

Come guidi il modello fa parte di ciò che viene valutato. Praticarlo significa prepararsi per il colloquio e fare il lavoro allo stesso tempo.

1› Usa un subagente per mappare come gli ordini fluiscono dal caricamento all'evasione in
2questo repo. Mi serve il modello dati, i punti di integrazione, e qualsiasi punto in cui
3lo stato può essere scritto due volte. Scrivilo in notes/orders.md.
4
5● Lancio subagente di ricerca · finestra di contesto separata
6● Letto 23 file · 41.2k token — nessuno nella tua finestra
7
8✓  Restituito riepilogo di 680 token → notes/orders.md Trovato: il caricamento scrive in `orders` E `legacy_orders`. Il job di riconciliazione viene eseguito
9nottetempo. Qualsiasi cosa fallisca tra le 18:00 e il job delle 02:00 è invisibile alle operations.
10
11 › Quel buco è il reclamo reale del cliente. Prepara lo strumento MCP
12che mostra quegli ordini in volo, poi lo esaminiamo con le operations.
13giorno 2. il fornitore precedente ha impiegato sei settimane per trovarlo.

08. Pubblica una implementazione reale per un utente reale

Ogni annuncio di lavoro FDE cerca la stessa frase in qualche forma: sistemi AI pubblicati in produzione. Non studiati, non prototipati - pubblicati, per qualcuno che dipendeva da essi.

Questo è il muro che la maggior parte dei candidati colpisce, ed è l'unica cosa in questa lista che non puoi superare leggendo.

Quindi crea l'esperienza deliberatamente. Trova un flusso di lavoro reale che appartiene a qualcuno che non sei tu - una piccola impresa, un'organizzazione no-profit, un team dentro la tua azienda attuale, il processo operativo di un amico.

Siediti con loro. Guardali lavorare. Costruisci la cosa che rimuove la parte peggiore della loro settimana, distribuiscila dove la usano realmente, e poi rimani abbastanza a lungo da sistemare ciò che si rompe.

Quell'ultima parte non è opzionale - l'intero lavoro è ciò che accade dopo la demo.

Poi scrivilo nel modo in cui un FDE riferisce, perché la descrizione è metà dell'artefatto. Non "costruito un chatbot RAG con LangChain."

Invece: quanto costava il loro flusso di lavoro prima in ore, quali vincoli non potevi cambiare, cosa hai deliberatamente scelto di non costruire, cosa si è rotto nella seconda settimana, e quanto costa loro ora.

1# Triage della spedizione per un'azienda idraulica con 14 furgoni
2// Struttura questo come un post-mortem FDE, non come un README di progetto.
3
4## Il flusso di lavoro prima
5Il dispatcher passava ~2.5h/giorno a leggere le note dei lavori e riassegnare i furgoni.
6Due persone si sono licenziate per questo in un anno. Nessuno l'aveva mai cronometrato.
7
8## Vincoli che non potevo cambiare
9- I dati di scheduling vivono in uno strumento ospitato con un'API di sola lettura.
10- Il dispatcher non userà una nuova app. Doveva vivere in SMS.
11- Il proprietario non avrebbe approvato nulla che toccasse i dati di pagamento dei clienti.
12
13## Cosa ho deliberatamente NON costruito
14Riassegnazione automatica. Non si fidavano e l'avrebbero disattivata nella
15prima settimana. Invece: suggerimento + approvazione con un tocco.
16// Avevo ragione su questo più importante della scelta del modello.
17
18## Cosa si è rotto nella seconda settimana
19Le note dei lavori avevano soprannomi incoerenti per i furgoni ("grande blu" vs "F-3").
20Risolto con una tabella di alias che il dispatcher modifica da sola.
21// Questa è la parte che separa ciò che è pubblicato da ciò che è solo una demo.
22
23## Dopo
24~40 min/giorno. Andato avanti 5 mesi. Lo usa ancora. Il proprietario ha aggiunto 2 furgoni.

Quel documento è il tuo colloquio. Ogni hiring manager che lo legge impara più di te di quanto qualsiasi riga del curriculum potrebbe dirgli.

09. Impara la scoperta del cliente

Questo è il passo da leggere due volte. Il ciclo di Applied AI Engineer di Anthropic include un round di conversazione con il cliente, e porta un peso nascosto: filtra circa il 60% dei candidati che hanno già superato le fasi di coding.

Ingegneri forti, eliminati al round per cui non si erano preparati. Nel frattempo, il 73% degli FDE dei laboratori all'avanguardia riferisce che condurre conversazioni di scoperta era l'abilità per cui erano meno preparati provenendo da un background software tradizionale.

La modalità di fallimento è prevedibile e quasi universale: il candidato sente un problema del cliente e inizia a risolverlo. Propongono un'architettura. Alcuni aprono un editor.

• I candidati che avanzano fanno l'opposto - gestiscono il round come un'intervista di ricerca. Chiedono quali sono gli attuali criteri di valutazione dell'acquirente.
• Chiedono delle precedenti implementazioni AI fallite, che è dove sono sepolti tutti i vincoli reali. Chiedono cosa non può genuinamente cambiare: compliance, latenza, residenza dei dati.
• Chiedono quale flusso di lavoro specifico questo sostituirebbe e chi perde il lavoro se ha successo. Prendono appunti. Riflettono su ciò che hanno sentito. Non scrivono codice.

Anthropic verifica questo esplicitamente perché gli accordi enterprise con Claude non si chiudono solo con la profondità tecnica. È un'abilità apprendibile - e puoi praticarla esattamente nelle stesse sessioni del Passo 8.

1# Gestisci il round come un ricercatore. Risolvere troppo presto è il segnale rivelatore.
2
3## Porta alla luce i vincoli reali
4- Cosa avete già provato qui, e perché si è fermato?
5  // le implementazioni fallite nascondono ogni vincolo che conta
6- Cosa non può cambiare, qualunque cosa costruiamo?
7  // compliance, latenza, residenza dei dati, il contratto sindacale
8- Chi deve approvare questo, e a cosa si opporrà?
9
10## Trova il flusso di lavoro effettivo
11- Raccontami l'ultima volta che è andato storto.
12- Chi fa questo oggi, e quanto costa loro a settimana?
13- Cosa succede a valle se sbagliamo alle 3 del mattino?
14
15## Definisci "abbastanza buono" — il loro, non il tuo
16- Quale accuratezza ti farebbe disattivare questo?
17- Come saprai tra 90 giorni se ha funzionato?
18- Cosa farà invece la persona che fa questo oggi, dopo?
19
20## Chiudi il ciclo
21- Rifletti su ciò che hai sentito. Fatti correggere.
22- Nomina cosa NON costruiresti, e perché.
23// Dire "non dovremmo costruirlo" è un segnale da senior, non una scusa.

Ogni volta che ti siedi con la persona di cui stai sistemando il flusso di lavoro, stai provando questo round.

10. Esegui il ciclo di colloquio

Il ciclo è insolitamente coerente tra le migliori aziende, ed è costruito per filtrare in entrambe le direzioni contemporaneamente - contro gli ingegneri puramente algoritmici che non sanno comunicare, e contro i consulenti fluidi che non sanno programmare.

Aspettati circa cinque fasi:

• Uno screen del recruiter su motivazione, background e adeguatezza del livello.
• Uno screen del caso d'uso tecnico - in Anthropic, uno scenario pratico sull'implementazione di Claude con strumenti MCP, dove pianifichi ed esegui un'attività di lunga durata e ragioni su affidabilità, gestione della finestra di contesto e coerenza in produzione.
• Un round di coding che è pratico piuttosto che LeetCode: un rate limiter, elaborazione di streaming di dati, una coda di job distribuita, un allocatore di budget di token, un orchestratore di uso strutturato di strumenti - spesso con nuovi vincoli del cliente aggiunti a metà esercizio per vedere se rifattorizzi in modo pulito.
• Un round con l'hiring manager su progetti passati e ragionamento sul cliente. Poi un panel finale su progettazione della soluzione e valori. Due note di preparazione che la gente salta.
• L'allineamento con la missione è valutato seriamente in Anthropic - leggi i Core Views on AI Safety, la Responsible Scaling Policy e i recenti lavori di interpretabilità prima di candidarti; l'entusiasmo generico non passa.

E i loro annunci chiedono "giudizio calibrato sui rischi del modello", che è il punto che elimina silenziosamente candidati altrimenti forti. Essere in grado di dire chiaramente dove non implementeresti un modello, e perché, fa parte del livello.

Sei punti di partenza - trova il tuo

• Aggiungi il livello AI, mantieni il rigore. I tuoi istinti di produzione sono la metà rara - la maggior parte dei candidati AI-native non ha mai gestito nulla di reale. Aggiungi prompting, API dei modelli, output strutturati ed eval, poi pubblica un server MCP contro un sistema interno disordinato.
• Smetti di addestrare, inizia ad atterrare. Sei sovraqualificato sulla modellistica e sottosqualificato su tutto il resto. Il lavoro è integrazione, vincoli e stakeholder. Costruisci deliberatamente qualcosa di noioso che sopravvive a una revisione di compliance e a un passaggio di consegne alle operations.
• Vai dove sono le implementazioni. I ruoli FDE dei laboratori all'avanguardia sono raramente entry level. Punta un anello più in là - le startup e le società di consulenza che implementano AI nelle imprese - dove farai lo stesso lavoro con meno barriere, poi sali tra due anni.
• Colma il divario di coding, velocemente. Hai già la metà che elimina il 60% dei candidati. Ora supera il round di coding: esercizi pratici, non LeetCode - rate limiter, streaming, code di job, orchestratori di uso di strumenti, scritti in modo pulito sotto vincoli mutevoli.
• Prova che sai effettivamente costruire. La scoperta e la gestione degli stakeholder sono già tue. Il ciclo è esplicitamente progettato per filtrare chi parla bene ma non sa programmare - quindi tutta la tua preparazione è un sistema pubblicato, mantenuto e documentato pubblicamente.
• Potresti già fare questo lavoro. Gli ingegneri di piattaforma interna che lavorano con le unità aziendali stanno eseguendo il movimento FDE sotto un titolo diverso. Riscrivi la tua esperienza nel linguaggio del ruolo - flussi di lavoro modificati, ore risparmiate, vincoli navigati - e sei un candidato vivo oggi.

Conclusione:

La cosa rara non è mai stata il modello. È la persona che sa atterrarlo.

La capacità ha smesso di essere il collo di bottiglia negli ultimi due anni.

Ciò che è raro ora è l'ingegnere che può entrare in un'azienda con sistemi legacy, un reparto compliance e un team operativo scettico - e uscirne sei settimane dopo con qualcosa che funziona realmente.

È una combinazione strana di competenze, che è esattamente il motivo per cui paga così. Ampiezza ingegneristica sopra la profondità. Giudizio senza un PM su cui appoggiarsi. La pazienza di sedersi nella realtà disordinata di qualcun altro abbastanza a lungo da capirla prima di scrivere una riga di codice.

La maggior parte degli ingegneri continuerà a ottimizzare per i ruoli che esistevano nel 2020. Quelli che imparano a implementare possederanno il decennio - perché ogni modello che viene pubblicato d'ora in poi deve ancora sopravvivere al contatto con un'azienda reale.