Due storie sono uscite nella stessa settimana e la maggior parte delle persone le leggerà separatamente. Una riguarda i licenziamenti. L’altra riguarda un ricercatore di sicurezza che mette alla prova le schede madri dei server. Letti insieme, indicano un cambiamento di carriera che trova pochissimo spazio nell’attuale conversazione sulle competenze nell’IA: scendere, non salire, nello stack.
Il livello applicativo si sta affollando — per scelta progettuale
L’ingresso di Meta nella programmazione agentica, Muse Code, è degno di nota meno per il modello che lo alimenta che per il flusso di lavoro che automatizza. Zuckerberg lo ha descritto mentre si dirama «verso sotto-agenti separati che lavorano in parallelo in worktree isolati», sostenendo che in una prova il sistema abbia realizzato simultaneamente sei funzionalità per un gioco senza collisioni. Ormai è il minimo indispensabile: Anthropic, OpenAI e una nuova ondata di startup offrono già versioni della stessa cosa. Pianificare, scrivere e validare codice del livello applicativo all’interno di repository di grandi dimensioni sta diventando una capacità standardizzata, che diversi fornitori si affrettano a offrire gratuitamente o a includere a basso costo.
Nel frattempo, Monday.com ha ridotto il proprio organico di circa il 20% — circa 600 persone — citando una ristrutturazione legata alla «trasformazione» del prodotto e delle attività go-to-market, aggiungendosi a un elenco in continua crescita di oltre 20 aziende che quest’anno hanno indicato l’IA come un fattore nei tagli. Nessuno può dire con precisione quanto ciò sia dovuto alla sostituzione tramite IA e quanto all’IA usata come formula conveniente in un documento depositato presso la SEC. Ma la direzione è la stessa in entrambe le storie: il codice che vive in un repository git, viene sottoposto a revisione tramite una PR e viene eseguito in una normale pipeline CI è esattamente il codice che gli strumenti agentici vengono costruiti per gestire dall’inizio alla fine.
Ciò che gli agenti non toccano
E ora l’altra storia. Questa settimana i ricercatori hanno presentato risultati secondo cui migliaia di server connessi a Internet, prodotti dai principali produttori, possono essere compromessi da remoto attraverso vulnerabilità nei loro controller di gestione della scheda madre (BMC) — i piccoli computer integrati presenti praticamente su ogni scheda madre aziendale, che consentono agli amministratori di riavviare, applicare patch o ricreare l’immagine di una macchina anche quando è spenta. Alcune delle vulnerabilità sottostanti nel protocollo IPMI su cui questi controller fanno affidamento sono note almeno dal 2013. I ricercatori hanno definito l’infrastruttura BMC una «superficie d’attacco parallela pervasiva, scarsamente monitorata e poco aggiornata» — non perché nessuno sapesse che il rischio esisteva, ma perché quasi nessuno aveva le risorse per risolverlo.
È questo il punto rivelatore. Non si tratta di codice applicativo. È firmware, che esegue un proprio sistema operativo e uno stack di rete, in gran parte invisibile agli strumenti e ai flussi di lavoro per cui gli assistenti di programmazione agentici sono ottimizzati. Un agente che pianifica una PR per un repository di grandi dimensioni qui non ha nulla contro cui pianificare: non c’è un repository, non c’è una suite di test, spesso non c’è alcun incentivo del fornitore a distribuire rapidamente una correzione e il processo di applicazione delle patch passa dai produttori hardware, non da un `git push`. Le competenze che contano — C embedded, debugging a livello di protocollo, reverse engineering del firmware, ricerca sulla sicurezza adiacente all’hardware — si trovano in una parte dello stack che gli agenti di programmazione di questa generazione non sono costruiti per raggiungere e in cui la maggior parte delle organizzazioni ingegneristiche ha cronicamente investito troppo poco; la prova sono vulnerabilità note da decenni e ancora presenti.
La copertura, detta chiaramente
Non è un invito a ogni sviluppatore a riqualificarsi come ingegnere del firmware: è un mercato di nicchia e la domanda non sarà paragonabile a quella dei ruoli software tradizionali. L’argomento è più circoscritto: se il tuo ruolo attuale si trova esattamente nella parte dello stack verso cui gli strumenti agentici stanno convergendo più rapidamente — codice applicativo di routine, ben all’interno di un singolo repository e ben coperto dai test — vale la pena sapere che esistono livelli adiacenti e più bassi, dove la frontiera dell’automazione non è ancora arrivata, dove le competenze si possono apprendere senza un dottorato in informatica e dove il segnale della domanda — una superficie d’attacco vecchia di un decennio, priva di patch e appena dimostrata pubblicamente su vasta scala — è insolitamente concreto.
Da dove iniziare davvero, questo mese
- Leggi la ricerca primaria, non soltanto il riepilogo. L’articolo di Ars Technica indica il protocollo (IPMI) e la classe di hardware (BMC dei principali fornitori di server): sono i termini di ricerca da cui partire per gli avvisi dei fornitori e la cronologia delle CVE.
- Metti le mani su uno stack BMC aperto. OpenBMC e progetti simili di firmware open source permettono di leggere e modificare vero codice BMC senza aver bisogno di un datacenter: basta un fine settimana per capire quanto sia diverso dallo sviluppo web o applicativo.
- Riformula subito il linguaggio del tuo curriculum, anche prima di riqualificarti. «Gestione out-of-band», «amministrazione lights-out» e «superficie d’attacco al di sotto del sistema operativo» sono le espressioni che faranno trovare il tuo profilo ai team che assumono in questo ambito, e non costano nulla da aggiungere se l’esperienza è realmente adiacente a ciò che hai fatto.
- Consideralo una diversificazione, non una svolta. Continua a distribuire codice applicativo — è ancora la parte più ampia del mercato del lavoro — ma dedica intenzionalmente una parte del tuo budget di apprendimento a un ambito in cui un agente non può ancora diramarsi in un worktree e risolvere il problema al posto tuo.