Sviluppatore Migliore

12/10/2026

Un sistema può restare tecnicamente integro e consegnare comunque dati sensibili alla persona sbagliata.

Secondo ANSA, un gruppo di hacker sostiene di avere ottenuto 147 gigabyte di dati e informazioni relative a 680 clienti internazionali di Revolut. La rivendicazione resta da verificare, mentre Revolut ha dichiarato che i propri sistemi e i fondi dei clienti non sono stati compromessi.

Il punto interessante per un’azienda è il metodo descritto: richieste apparentemente provenienti dalle forze dell’ordine italiane, distribuite nell’arco di sei mesi. Gli investigatori devono ancora stabilire se una casella istituzionale sia stata violata oppure clonata.

A mio giudizio, questo caso mostra un limite importante nel modo in cui misuriamo la sicurezza. Firewall, antivirus e server integri non bastano se una richiesta credibile può attraversare il processo previsto e portare una persona autorizzata a consegnare informazioni riservate.

In una PMI può succedere con una richiesta di modifica delle coordinate bancarie di un fornitore, con documenti tecnici richiesti da un presunto consulente o con dati del personale domandati da un soggetto apparentemente istituzionale.

Il sistema può registrare tutto come perfettamente regolare: l’utente possiede i permessi, accede con le proprie credenziali ed esporta i dati attraverso una funzione autorizzata.

Il costo emerge dopo: analisi dei log, verifiche interne, consulenza legale, eventuali notifiche e ore sottratte alle normali attività. Per misurarlo servono almeno tempo impiegato, persone coinvolte, dati esposti e impatto operativo.

Prima di acquistare nuovi strumenti, controllerei quindi tre cose: chi può esportare dati sensibili, chi autorizza la consegna e come viene verificata l’identità di chi li richiede.

Il criterio operativo è semplice: più una richiesta espone dati o privilegi, meno deve dipendere dalla credibilità di una singola e-mail. Verifica indipendente, doppia autorizzazione e tracciabilità devono far parte del sistema tanto quanto firewall e antivirus.

24/09/2026

Anthropic ha rilasciato Claude Opus 5.5 e gli YouTuber fanno i video con la bocca aperta.

Il prezzo dei token di un nuovo modello rappresenta spesso la voce di spesa più bassa e ingannevole nei conti di un'azienda produttiva.

Hanno fissato il costo a 4 dollari per milione di token in ingresso e 20 dollari in uscita, con una riduzione dichiarata del 30% sui tempi di risposta.

Tra le specifiche tecniche ci sono i filtri di salvaguardia, progettati per deviare in automatico verso versioni precedenti, come Opus 4.8 o Opus 5, le richieste che toccano temi legati alla cybersicurezza o alla biologia.

Di fronte a queste uscite, molti reparti tecnici pianificano subito di aggiornare le integrazioni nel software aziendale. Considero questa abitudine dannosa per la redditività.

I centesimi risparmiati sulle chiamate API incidono poco sui margini complessivi.

La vera spesa emerge durante le venti o trenta ore di lavoro impiegate dagli sviluppatori per riadattare i flussi, collaudare le risposte e verificare i casi limite.

Ipotizziamo una tariffa oraria interna compresa tra 40 e 60 euro, ciascun ciclo di modifica comporta un assorbimento compreso tra 800 e 1.800 euro di personale. Per recuperare questo importo con il solo sconto sui token servirebbero volumi di utilizzo che la quasi totalità delle aziende manifatturiere non raggiungerà mai.

A questo costo si somma un'incertezza operativa introdotta dai meccanismi di protezione descritti nel comunicato. Quando una richiesta intercetta le regole di sicurezza, il traffico scala su Opus 4.8, alterando il livello qualitativo della risposta.

Nei processi di fabbrica, dove i dati alimentano avanzamenti di produzione, ordini o schede tecniche, una variazione imprevista nel comportamento del software impone controlli manuali continui, cancellando i vantaggi di velocità promessi.

Ritengo che l'adozione di un modello all'interno dei sistemi gestionali o produttivi trovi giustificazione solo in presenza di un impatto documentabile su tre indicatori: tempi di attraversamento della commessa, marginalità operativa o riduzione degli scarti. In assenza di queste misure, inseguire ogni annuncio equivale a disperdere ore lavorative su strumenti privi di ritorno economico.

Prima di autorizzare il passaggio a Opus 5.5 o a qualsiasi nuova versione, suggerisco di applicare questo criterio decisionale:
1. Calcolare il costo orario delle giornate necessarie per testare e integrare il modello.
2. Identificare un collo di bottiglia concreto del ciclo produttivo, misurando quante ore settimanali assorbe attualmente.
3. Dare il via libera all'aggiornamento unicamente se il risparmio di tempo stimato ripaga l'investimento di sviluppo entro novanta giorni.

In tutte le altre circostanze, la decisione più efficiente resta quella di mantenere invariato il sistema esistente e concentrare il reparto tecnico sulle priorità di produzione.

12/09/2026

Un modello di AI visiva può riconoscere scatole, leggere etichette e guidare un robot.

Il costo nascosto emerge quando deve farlo ogni giorno, con tempi compatibili con la produzione e senza trasformare un errore in un fermo impianto.

Perceptron, startup fondata da due ex ricercatori di Meta, ha presentato Isaac.

Secondo l’azienda, il modello può aiutare le macchine a percepire l’ambiente, ragionare e agire in contesti come fabbriche e magazzini. È distribuito a pesi aperti ed è stato addestrato, sempre secondo Perceptron, su un milione di ore di video generici, oltre a filmati egocentrici e traiettorie robotiche.

Per una PMI, la disponibilità del modello è soltanto il punto di partenza. Prima di collegarlo a un processo reale servono almeno quattro verifiche.

1. La prima riguarda l’accuratezza nelle condizioni dello stabilimento: illuminazione variabile, oggetti parzialmente coperti, vibrazioni, sporco e confezioni fuori standard. Un dato medio può nascondere errori concentrati proprio nei casi più costosi.

2. La seconda è la latenza. Una risposta corretta arrivata troppo tardi può rallentare la linea o rendere inutilizzabile l’automazione.

3. La terza riguarda la gestione degli errori. Occorre stabilire quando il sistema deve fermarsi, chiedere una verifica umana o passare a una procedura sicura. Questa decisione incide direttamente sul rischio operativo.

4. Infine serve un conto economico completo: hardware, integrazione con macchine e software esistenti, raccolta dei dati, monitoraggio, manutenzione e gestione delle eccezioni. Il confronto va fatto con il costo attuale del processo, compresi scarti, controlli manuali, rallentamenti e fermi.

L’opportunità è concreta: modelli più flessibili possono ampliare i processi industriali affrontabili con l’AI visiva.

La decisione deve arrivare dopo una prova circoscritta, eseguita sul processo reale e misurata con soglie definite prima dell’esperimento.

25/04/2026

L'AI che si ferma da sola e chiede i documenti

Stiamo sviluppando un'applicazione super segreta che non può conoscere nemmeno la NASA.

Scherzo, è coperta perché non voglio far sapere tutti i fatti nostri.

Stiamo facendo scraping di dati con una libreria potente, Scrapling, che riduce drasticamente i problemi legati a siti che cambiano struttura, DOM, pagine aggiornate e parsing HTML.

Divago un attimo per spiegare cosa fa con un caso concreto.

Un cliente manifatturiero che aggrega dati da portali fornitori europei, ognuno con struttura diversa.

Prima era in manutenzione continua ad ogni rilascio. Adesso il sistema regge i cambiamenti senza intervento.

Con Scrapling la pipeline è diventata più stabile e resistente ai cambiamenti, senza toccare il codice ogni volta che il sito viene aggiornato.

Se entri in contesti con protezioni aggressive, tipo sistemi anti-bot avanzati o Cloudflare Enterprise, non basta. Devi cambiare approccio. Ma per la maggior parte dei casi reali, funziona.

Molto interessante.

Tornando a noi.

È successa una cosa nuova usando OpenAI Codex per lo sviluppo.

Alterniamo Claude Code, GitHub Copilot e Codex di continuo, per vedere chi produce output migliori su task specifiche, con dati reali.

Codex in questo caso è un fulmine. E ora integra ChatGPT Images 2.0, per cui ha fatto una cosa sbalorditiva: ha generato layout e codice coerente senza divergenze. Non simile, identico al pixel.

La cosa notabile è successa dopo.

Quando ha capito che stavamo implementando scraping, si è fermato e ha chiesto verifica dell'identità con documento e video live. Video KYC. Prima volta che mi capitava.

Non so se sia un nuovo comportamento standard o un test lato piattaforma, ma è un segnale preciso: i vendor si stanno muovendo per mettere controlli su utilizzi ad alto rischio.

Finalmente ci stanno lavorando.

Perché finora gli LLM hanno aperto voragini reali nel codice, e molti sviluppatori non se ne sono accorti.

Questi sistemi non ragionano: ottimizzano. Generano output plausibile, non output corretto.

Sono strumenti non intelligenti, al contrario del nome che gli hanno affibbiato i reparti marketing di OpenAI, Anthropic.

Bisogna controllarli in modo sistematico e strutturato.

Se non hai un processo di controllo, stai delegando bug in produzione.

24/04/2026