Questa settimana il bollettino porta segnali che, presi singolarmente, sembrano notizie di settore. Messi insieme raccontano qualcosa di più strutturale su dove sta andando il nostro mercato e su alcune decisioni che dobbiamo prendere adesso, non tra sei mesi. Ho organizzato tutto attorno a quattro temi. Il quinto, in fondo, è una riflessione aperta che riguarda il modo in cui lavoriamo.

1. La supply chain software è diventata un bersaglio automatizzato

Questa settimana due notizie convergono sullo stesso punto. La prima: un secondo attacco in pochi mesi in cui un threat actor usa strumenti AI per sfruttare in modo automatico misconfigurazioni diffuse su repository GitHub. La seconda: attori nordcoreani che utilizzano GitHub stesso come infrastruttura di comando e controllo per attacchi multi-stadio.

Il dato che conta non è il singolo incidente. È il pattern. L’AI ha abbassato la barriera d’ingresso per attacchi alla supply chain software al punto che non servono più team sofisticati per sfruttare configurazioni deboli. Chi ha repository con token troppo permissivi, webhook non monitorati o dipendenze non firmate sta esponendo una superficie d’attacco che oggi viene scandagliata in modo sistematico e automatico.

Per noi questo è un problema concreto, non teorico. Operiamo su GitHub ogni giorno, con pipeline CI/CD attive su più progetti Laravel e Flutter. Gestiamo dipendenze open source su tutto il portfolio. E siamo in piena costruzione della postura NIS2 per i nostri clienti.

Cosa fare

Entro la prossima settimana:

Serve un audit delle configurazioni di sicurezza dei repository GitHub dell’organizzazione. In concreto: verificare le policy di accesso ai Personal Access Token e ai token di automazione; censire i webhook attivi e rimuovere quelli non necessari; controllare che nessun repository contenga secret esposti nei file di configurazione o negli artefatti di build. Questo è lavoro da un pomeriggio, non da un progetto.

Entro fine mese:

Dobbiamo aggiungere alla CI/CD la generazione automatica di SBOM in formato CycloneDX o SPDX. Con il Cyber Resilience Act che rende gli SBOM obbligatori per i prodotti software, e NIS2 che li richiede nella catena di fornitura, non è più un “nice to have”. È un prerequisito per continuare a lavorare con PA e sanità. La buona notizia è che per lo stack Laravel esistono tool già pronti (CycloneDX per Composer, per esempio) e l’integrazione in GitHub Actions è questione di poche righe.

Entro Q2:

Valutare l’adozione di Sigstore per il signing degli artefatti di build. Non è urgente come lo SBOM, ma completa la catena di integrità e ci mette in una posizione migliore rispetto ai requisiti CRA che entreranno in vigore.

A margine: il leak del source code di Claude Code tramite source map nel pacchetto npm è un promemoria operativo. Succede anche ai migliori. Aggiungiamo un check automatico nella CI che verifichi l’assenza di source map, file .env, secret e artefatti di sviluppo nei build di produzione. Dieci minuti di configurazione che prevengono un incidente imbarazzante.

2. Il “token tsunami” e il futuro della consulenza tech

Ben Thompson ha pubblicato un pezzo importante questa settimana. La tesi, in sintesi: l’AI sta trasformando il codice in commodity. I token — nel senso di capacità computazionale AI a basso costo — stanno erodendo i margini di chi vende servizi basati sulla scrittura di software. È quello che Thompson chiama il “token tsunami”.

Per una software house B2B come la nostra, questa non è una notizia. È la conferma di una tendenza che abbiamo già intercettato e su cui stiamo costruendo il posizionamento dei prossimi anni. Ma vale la pena essere espliciti su cosa significa in pratica, perché le implicazioni sono più profonde di quanto sembri.

Se scrivere codice diventa progressivamente meno costoso e più automatizzabile, il valore si sposta su due assi: la comprensione del dominio del cliente e la capacità di navigare la complessità normativa. Tradotto nel nostro contesto: sapere come funziona la sanità digitale italiana, cosa serve per essere conformi al GDPR in un contesto PA, come si struttura un DPA per un Policlinico, che cosa implica il CRA per un software che gestisce dati sanitari. Questa competenza non si automatizza con un prompt. Richiede anni di esperienza, relazioni con i clienti e capacità di interpretare requisiti ambigui in contesti normativi che cambiano.

La scommessa compliance-as-a-service che abbiamo fatto non è più una scommessa. È la direzione naturale del mercato. Ma questo non significa che possiamo rilassarci. Significa che dobbiamo investire di più in tre cose.

Primo: la profondità verticale. Non basterà dire “facciamo compliance”. Dobbiamo essere gli esperti riconosciuti di compliance tecnica per sanità e PA (e non solo) nel mercato italiano. I relativi framework che metteremo in piedi nei prossimi mesi dovranno diventare un corpus coerente di competenze documentate, replicabili e vendibili come servizio ricorrente.

Secondo: l’advisory pre-sales. Se il codice è commodity, il valore sta nella fase in cui si capisce cosa costruire, non in quella in cui si costruisce. Dobbiamo investire più tempo nella fase di analisi e meno nel convincere i clienti che sappiamo programmare. Lo sanno già. Quello che non sanno è (ad esempio) se siamo in grado di guidarli attraverso il trilemma architetturale AI (SaaS, RAG, on-premise) con cognizione di causa normativa. Questa settimana Agenda Digitale ha mappato esattamente questo framework e vale la pena leggerlo: la risposta corretta per alcuni ambiti - come PA e sanità - non è mai una sola architettura, ma un approccio ibrido guidato dai vincoli del cliente.

Terzo: il pricing. Se il codice vale meno, non possiamo continuare a vendere giornate di sviluppo al prezzo di prima. Cercaheremo gradualmente di spostare il modello verso il value-based pricing e i contratti ricorrenti. Abbiamo già iniziato a lavorarci sulla proposta GESMA 2026 (che va in questa direzione). Deve diventare il template, non l’eccezione.

A rafforzare questa lettura, un dato collaterale interessante: il round da 122 miliardi di dollari di OpenAI si è rivelato per la maggior parte credito cloud e chip, non capitale reale. Il CFO ha ammesso che l’azienda non è pronta per un’IPO. Non lo scrivo per fare polemica ma per un motivo operativo preciso: chi costruisce il proprio modello di business attorno a un provider AI la cui sostenibilità finanziaria non è dimostrata si espone a un rischio vendor lock-in significativo. Per noi significa continuare a mantenere le dipendenze da provider specifici sostituibili. Usare Anthropic, usare OpenAI, ma non legare l’architettura a uno solo in modo irreversibile. Le astrazioni contano.

3. Agentic engineering: dove funziona, dove no, e cosa cambia per noi

Quattro contenuti questa settimana parlano di Claude Code e dell’AI nello sviluppo software. Presi insieme, offrono una fotografia onesta di dove siamo.

La buona notizia: esistono ormai case study concreti di team che usano Claude Code su intere codebase aziendali con risultati misurabili. Il caso Galileo — un field engineer che usa Claude Code per query in tempo reale sulla codebase, migliorando il supporto enterprise senza dipendere dalla documentazione — è un pattern direttamente replicabile nel nostro modello, dove gestiamo più progetti cliente in parallelo. La guida sull’uso parallelo di agenti Claude Code apre un altro spazio: la possibilità di scalare task indipendenti su più moduli della stessa codebase. Questo è applicabile immediatamente al nostro flusso TALL stack.

La cattiva notizia: l’issue #42796 su GitHub, con 881 punti e 511 commenti su Hacker News, documenta frustrazione diffusa con Claude Code su task ingegneristici complessi. Non è un caso isolato, è una discussione ampia e articolata. Il messaggio è chiaro: l’agentic engineering funziona bene su refactoring guidato, task paralleli indipendenti, query su codebase esistenti e supporto operativo. Funziona male su architettura greenfield senza contesto, decisioni di design che richiedono comprensione profonda del dominio e task che richiedono coerenza architetturale su larga scala.

La riflessione giusta viene da Freek Van der Herten, che opera nel nostro stesso ecosistema Laravel. La distinzione che propone tra “vibe coding” e “agentic engineering strutturato” è quella che dobbiamo adottare internamente.

Cosa significa per il team

Il vibe coding è usare l’AI senza struttura: prompt vaghi, accettazione acritica dell’output, nessuna review. È il modo in cui molti sviluppatori stanno usando gli strumenti AI oggi. Produce codice che funziona nel breve termine e debito tecnico nel medio.

L’agentic engineering strutturato è diverso. Significa usare l’AI come moltiplicatore di una disciplina ingegneristica che esiste già. Significa plan, execute, review. Significa specifiche chiare prima di lanciare un agente. Significa CLAUDE.md aggiornati per ogni progetto. Significa non accettare output che non supera la propria review critica.

La conferma arriva anche dall’analisi di UltraPlan: il valore reale degli strumenti AI-native sta nella strutturazione del processo, non nella capacità bruta del modello.

Decisione da prendere

Dobbiamo produrre un documento interno — breve, operativo — che definisca le linee guida di utilizzo dell’AI nel team. Non una policy burocratica, ma una mappa pragmatica. Il formato potrebbe essere questo:

Dove usare Claude Code con fiducia: refactoring di codice esistente con test; task paralleli su moduli indipendenti; query sulla codebase per supporto e onboarding; generazione di test a partire da specifiche; migrazione meccanica tra pattern (tipo la migrazione Python→Laravel di RischioLegale).

Dove usare Claude Code con supervisione attenta: implementazione di feature nuove su specifiche dettagliate; integrazione tra moduli; code review assistita.

Dove non delegare a Claude Code: decisioni architetturali; design di nuovi sistemi; scelte che richiedono conoscenza del contesto cliente che non è nella codebase; qualunque cosa che tocchi sicurezza, autenticazione o trattamento dati senza review umana completa.

Questa mappa va condivisa con tutto il team e rivista trimestralmente sulla base dell’esperienza reale.

4. Sanità digitale: la finestra si sta aprendo

Due segnali questa settimana dal mondo healthcare IT, collegati da un filo comune.

Il primo: HL7 ha lanciato “Caliper FHIR Accelerator”, una community multi-stakeholder per l’interoperabilità dei dati da dispositivi medici attraverso lo standard FHIR. Il secondo: Corewell Health, un sistema sanitario americano con 60.000 dipendenti, ha pubblicato dati concreti sul ROI del remote patient monitoring.

Per noi la lettura è questa: FHIR sta diventando lo standard de facto per l’interoperabilità sanitaria. Non è più una promessa, è un’accelerazione concreta che arriverà anche in Italia, spinta dai bandi PNRR sulla telemedicina e dall’interoperabilità richiesta dal FSE 2.0. Chi ha competenze di integrazione FHIR tra sistemi sanitari avrà un differenziatore tangibile nei prossimi 12-18 mesi.

Non abbiamo oggi questa competenza in modo strutturato. Abbiamo esperienza con i sistemi sanitari (GESMA, i flussi NSIS), abbiamo il contesto normativo, abbiamo le relazioni. Quello che manca è la competenza tecnica verticale su FHIR.

Decisione da valutare

Investire un budget di formazione (tempo, non denaro) per costruire una competenza FHIR di base nel team. In pratica: individuare una persona che dedichi un paio di settimane nell’arco del prossimo trimestre a studiare lo standard FHIR R4, le risorse HL7 relative all’interoperabilità dei dispositivi, e a costruire un proof of concept di integrazione. Questo non è un progetto, è un investimento esplorativo. Se funziona, diventa un asset vendibile. Se non funziona, abbiamo speso due settimane di formazione e abbiamo imparato qualcosa.

Il contesto più ampio: il deep tech europeo — secondo Agenda Digitale — non ha un problema di ricerca ma di esecuzione industriale. Il gap tra innovazione e delivery è esattamente lo spazio dove operano le aziende come la nostra. Ma il rischio è restare system integrator senza catturare valore. FHIR è un esempio concreto di come si può passare da “integriamo quello che ci danno” a “portiamo competenza verticale che altri non hanno”.

5. La tensione tra privacy e liability, e cosa diciamo ai clienti

Un segnale più sottile ma potenzialmente importante: la sentenza contro Meta in New Mexico sta creando un precedente in cui le scelte di design che includono encryption end-to-end possono generare responsabilità legale. La tensione tra privacy-by-design (che il GDPR richiede) e liability normativa (che le corti stanno ampliando) si sta inasprendo.

Per noi questo è rilevante in modo diretto. Costruiamo software per PA e sanità, tra gli altri. I nostri clienti ci chiedono di essere conformi al GDPR. La cifratura end-to-end è uno degli strumenti che usiamo per garantire la protezione dei dati. Se in alcune giurisdizioni questa stessa scelta di design può diventare fonte di responsabilità, cambia il modo in cui dobbiamo documentare e giustificare le decisioni architetturali.

Non è un problema da risolvere oggi, ma è un tema da monitorare. In pratica: le decisioni di design che riguardano crittografia, logging e accesso ai dati devono essere documentate con la motivazione normativa che le supporta. Non basta implementare la cifratura; bisogna poter dimostrare perché è stata scelta, quale norma la richiede, quale analisi dei rischi la giustifica. Questo deve essere parte di un approccio compliance-by-design, e l’evoluzione giurisprudenziale rende ancora più importante che la documentazione sia completa e mantenuta.

Il messaggio per i clienti resta lo stesso che cerchiamo sempre di dare: la compliance non è un costo, è una protezione. Ma la sfumatura che si aggiunge è che la compliance richiede anche la capacità di giustificare le proprie scelte di design. E questa capacità è esattamente il tipo di competenza che un team come il nostro può offrire e che un tool automatico no.

Una nota sul metodo

Lo scrivo qui, come nota interna: il Doctorow di questa settimana documenta come i dati di sorveglianza lavorativa vengano usati per comprimere i salari. Non è un tema che ci riguarda direttamente come azienda, ma ci riguarda come professionisti che costruiscono software che tratta dati delle persone. Ogni volta che un cliente ci chiede un sistema di monitoraggio, ogni volta che integriamo analytics comportamentali, ogni volta che progettiamo un flusso di raccolta dati, stiamo facendo scelte che hanno conseguenze sulle persone. La compliance normativa è il pavimento, non il soffitto. Il soffitto è farsi la domanda giusta prima di scrivere la specifica.

Riepilogo decisioni

Per chi vuole andare dritto al punto:

Cosa Chi Quando
Audit configurazione sicurezza repository GitHub (token, webhook, secret) DevOps / Andrea / Mircha Prossima settimana
Aggiungere generazione SBOM automatica nelle pipeline CI/CD DevOps Entro fine aprile
Check automatico assenza source map e artefatti dev nei build di produzione DevOps Entro fine aprile
Valutazione Sigstore per signing artefatti Andrea / Mircha Q2 2026
Documento interno “Linee guida AI nel team” (mappa agentic engineering) Andrea / Mircha Entro metà aprile
Assessment competenze FHIR e piano di formazione esplorativo Andrea + team Q2 2026
Revisione documentazione scelte crittografiche sui progetti PA/sanità Team Ongoing, partiremo con la collaborazione con Trustie

Letture consigliate per il team

Per chi vuole approfondire, in ordine di priorità:

La distinzione tra vibe coding e agentic engineering di Freek Van der Herten è la lettura più immediatamente utile per chi scrive codice ogni giorno. Il case study di Claude Code su codebase enterprise da Lenny’s Newsletter mostra un pattern che possiamo replicare. L’issue #42796 su Claude Code va letta per calibrare le aspettative, non per scoraggiarsi. Il pezzo di Thompson sul token tsunami su Stratechery è fondamentale per capire dove sta andando il nostro mercato, ma è più strategico che operativo.

Il resto — guida al parallelismo Claude Code, UltraPlan, CSS multi-column, behavioral biometrics — è materiale da leggere con calma quando c’è tempo, senza urgenza.