Per molto tempo ho pensato che i colloqui tecnici fossero sbagliati. Se ho del codice open source pubblico, pensavo, dovrebbe bastare quello per dimostrare cosa so fare. Non parlo di un repository creato domenica sera con tre commit chiamati "fix", ma di anni di progetti, issue, pull request, librerie usate da persone vere e bug corretti alle due di notte mentre qualcuno apriva una issue scrivendo soltanto "not work".

Il colloquio ideale, nella mia testa, era semplice: un tecnico si faceva un giro sul mio GitHub, sceglieva un progetto e mi chiedeva perché avessi usato quella struttura, perché avessi scartato un'altra soluzione e quale errore mi avesse costretto a riscrivere tutto un martedì pomeriggio. Io spiegavo le scelte, lui capiva come ragionavo e poi arrivava la proposta.

La realtà era leggermente diversa. Domande tecniche a raffica, giochini mentali, quiz di LeetCode, alberi binari da capovolgere alla lavagna e array da ordinare senza consultare internet. Tutto per prepararti al lavoro vero, dove avresti passato il lunedì a centrare un bottone e il martedì in una call per decidere se chiamarlo button-primary o primary-button.

Poi sono arrivati i primi chatbot nel 2022, gli agenti nel 2025 e, improvvisamente, ChatGPT ha smesso di essere una scheda aperta di nascosto ed è diventato un'app chiamata Codex, perennemente aperta e operativa sul tuo MacBook. È diventato uno stagista efficiente: non prende ferie, non si offende se gli chiedi di riscrivere la stessa funzione sei volte e, soprattutto, non dice mai: "Questa parte l'ha fatta il collega precedente che non lavora più in azienda".

Mi sono imbattuto nel post di @antirez, "Control the ideas, not the code". Il punto non è che la competenza non serva più o che basti scrivere "fammi Redis, ma più carino" e andare a pranzo. Racconta di aver implementato con l'AI parti complesse di DwarfStar, un motore di inferenza per LLM, concentrandosi su architettura, design, prestazioni, verifiche e QA invece di leggere ogni funzione riga per riga.

Non ha smesso di programmare. Ha spostato il lavoro un piano più in alto.

Se oggi un developer può guidare un agente goal dopo goal, costruire un sistema enorme e controllarne qualità e direzione senza aver scritto ogni singola riga di codice (ma soprattutto, e questa è la cosa che mi ha colpito di più, senza averla letta), cosa dovremmo chiedere durante i colloqui? "Implementami un bubble sort in C": praticamente, questo comincia ad avere lo stesso valore di chiedere a un architetto di fabbricare un mattone davanti a noi. In effetti, lo assumerei se ci riuscisse.

Nel frattempo Apple ha fatto causa a OpenAI accusandola, tra le altre cose, di aver sollecitato informazioni riservate durante il reclutamento di suoi dipendenti e persino di aver chiesto a candidati di portare componenti hardware ai colloqui. Sono accuse ancora da dimostrare, ma la scena è meravigliosa: per vent'anni ci hanno detto di portare il curriculum. Nel 2026, a quanto pare, basta una scheda logica prototipo nella tasca della giacca. Se suona l'antitaccheggio, probabilmente hai passato il primo step.

Quindi cosa devo portare io? La cronologia dei prompt? Le conversazioni in cui ho guidato un agente fino alla soluzione? La lista dei processi interni che ho automatizzato? I segreti aziendali, magari ordinati per importanza in un file Excel?

Forse il colloquio del 2026 dovrebbe assomigliare al lavoro del 2026. Date al candidato un problema piccolo ma ambiguo e lasciategli usare gli strumenti che userebbe davvero, AI compresa. Guardate quali domande fa prima di partire, come divide il lavoro, quale contesto fornisce all'agente, come riconosce una risposta plausibile ma sbagliata e quali test inventa per provare a distruggerla.

Chiedetegli perché ha scelto quell'architettura, cosa succede quando il modello allucina, quanto costa la soluzione, come torna indietro dopo un deploy sbagliato e quale parte non affiderebbe mai all'AI. Fategli spiegare un fallimento. I progetti riusciti dimostrano che una volta è andata bene, ma i fallimenti spiegati bene dimostrano che la volta dopo potrebbe andare meglio. Il codice open source resta utile, forse più di prima, ma quello che conta è oramai la storia che c'è dietro quel repository, non il codice stesso.

Nel 2026 non voglio essere valutato solo per quanto velocemente ordino un array. Voglio essere valutato per la capacità di capire se quell'array andava ordinato, se potevamo non crearlo, se l'agente AI che lo ha ordinato ha appena cancellato il database in produzione e quanto ci ho messo per accorgermene.

La nostra vita da developer va riscritta: siamo diventati codice legacy da mandare in pensione e dobbiamo portare in produzione una nuova versione di noi stessi.