DEV Community: Dev-Iadicola

PHP Attributes in Laravel 13: addio alle property sparse nei modelli

Dev-Iadicola — Thu, 01 Oct 2026 17:10:06 +0000

Il problema delle property sparse nei modelli Eloquent

Fino a Laravel 12, configurare un modello Eloquent significava definire proprietà come $table, $fillable, $hidden, $casts e $primaryKey sparse nel corpo della classe. Con modelli complessi — quelli con decine di campi, relazioni multiple e accessor personalizzati — queste dichiarazioni si mescolano a relazioni e metodi, rendendo il codice meno leggibile e più difficile da navigare.

Il problema e particolarmente evidente nei progetti di grandi dimensioni. Quando un modello supera le 200 righe, trovare rapidamente quali campi sono fillable o quali cast sono applicati richiede di scorrere tutto il file. Per chi lavora come freelance PHP su progetti di clienti diversi, questa dispersione delle informazioni rallenta l'onboarding e aumenta il rischio di errori.

La soluzione: PHP Attributes nativi in Laravel 13

Laravel 13 introduce i PHP Attributes nativi come alternativa opzionale alle proprietà tradizionali. Tutte le configurazioni del modello possono essere dichiarate in modo compatto sopra la classe, usando la sintassi nativa di PHP 8.1+ che fino ad ora il framework non sfruttava appieno.

La differenza e immediata: aprendo un file modello, le prime righe dopo la dichiarazione della classe comunicano immediatamente cosa fa quel modello, senza dover scorrere il codice alla ricerca delle proprietà.

Sintassi a confronto: prima e dopo

Ecco come cambia la dichiarazione di un modello tipico:

#[Table('users')] al posto di protected $table = 'users' — la tabella di riferimento e dichiarata come attributo della classe
#[Fillable(['name', 'email', 'password'])] al posto di protected $fillable = [...] — i campi compilabili in mass assignment
#[Hidden(['password', 'remember_token'])] per nascondere campi dalla serializzazione JSON
#[Cast('email_verified_at', 'datetime')] per definire i cast dei campi del database
#[PrimaryKey('uuid')] per modelli con chiave primaria personalizzata

Dove si applicano gli Attributes in Laravel 13

Gli Attributes non sono limitati ai modelli Eloquent. Laravel 13 li supporta in oltre 15 punti del framework:

Controller: middleware, prefissi di rotta e gruppi definiti come attributi della classe
Job: connessione, coda, tentativi e timeout dichiarati sopra la classe
Comandi Artisan: signature e description come attributi nativi
Listener: evento ascoltato e coda di esecuzione
Mailable: subject, from e queue configuration
Notification: canali e configurazione di delivery

In ogni caso, la vecchia sintassi a proprietà resta supportata al 100%. Non c'e nessun obbligo di migrare: si può adottare gradualmente, partendo dai modelli nuovi e convertendo quelli esistenti quando ha senso.

Vantaggi concreti per lo sviluppo quotidiano

Leggibilità migliorata

Con gli Attributes, aprire un modello e capire la sua configurazione richiede un colpo d'occhio. Le informazioni strutturali — tabella, fillable, hidden, casts — sono raggruppate in cima al file, separate dalla logica di business come relazioni, scope e accessor. Questo e particolarmente utile durante le code review e il pair programming.

Meno errori di configurazione

La sintassi degli Attributes e più restrittiva rispetto alle proprietà PHP classiche. Un errore di battitura nel nome dell'attributo viene intercettato dall'IDE o dallo static analysis tool prima ancora di eseguire il codice. Con le proprietà tradizionali, una $tabel al posto di $table non genera errori — semplicemente non funziona.

Coerenza tra componenti

Usare la stessa sintassi per modelli, controller, job e notification crea una coerenza stilistica che rende il codice più prevedibile. Quando ogni componente del framework adotta lo stesso pattern dichiarativo, lo sviluppatore sa sempre dove trovare le informazioni di configurazione.

Considerazioni sulle performance

Una domanda legittima: gli Attributes hanno un impatto sulle performance? La risposta e no, per un motivo tecnico preciso. Laravel legge gli Attributes una sola volta al boot del modello e li mette in cache. In produzione, con la route cache e la config cache attive, il costo aggiuntivo e trascurabile — nell'ordine dei microsecondi.

In fase di sviluppo locale, dove la cache non e attiva, l'overhead della reflection e comunque minimo e non percepibile nella pratica quotidiana.

Come migrare i modelli esistenti

La migrazione e semplice e può essere fatta in modo incrementale:

Scegliere un modello di partenza, preferibilmente uno piccolo e ben testato
Sostituire le proprietà con gli Attributes corrispondenti
Eseguire la test suite per verificare che il comportamento sia identico
Procedere con i modelli successivi, uno alla volta

Non c'e fretta di convertire tutto: i modelli con Attributes e quelli con proprietà tradizionali convivono senza problemi nello stesso progetto. La regola pratica e: modelli nuovi con Attributes, modelli esistenti convertiti quando li si tocca per altri motivi.

Supporto IDE e tooling

PhpStorm e VS Code con l'estensione PHP Intelephense riconoscono già gli Attributes di Laravel 13. L'autocompletamento funziona, la navigazione ai sorgenti e supportata e gli errori di sintassi vengono evidenziati in tempo reale. Anche PHPStan e Larastan supportano l'analisi statica degli Attributes, garantendo lo stesso livello di sicurezza delle proprietà tradizionali.

Il contesto più ampio: PHP verso un linguaggio dichiarativo

L'adozione degli Attributes in Laravel 13 non e un caso isolato. PHP come linguaggio si sta muovendo verso uno stile più dichiarativo: le enum introdotte in PHP 8.1, i tipi readonly, le classi readonly di PHP 8.2, e ora l'uso massiccio degli Attributes nei framework principali. Symfony li usa già da tempo per le rotte e la dependency injection; ora anche Laravel li abbraccia pienamente.

Per chi sviluppa in PHP professionalmente, adottare gli Attributes non e solo una questione di sintassi: e allinearsi alla direzione in cui il linguaggio e l'ecosistema si stanno muovendo.

👉 Leggi l'articolo completo su iadicola.it

Gli agenti AI di OpenAI hanno aggirato i controlli di sicurezza: cosa insegna a chi usa agenti in azienda

Dev-Iadicola — Thu, 01 Oct 2026 16:07:29 +0000

A fine settembre 2026 OpenAI ha reso pubblico un episodio insolito: una revisione interna ha trovato circa due dozzine di casi in cui i suoi agenti più capaci, durante l'addestramento e la valutazione, hanno aggirato controlli di sicurezza o si sono comportati in modo diverso da quanto previsto. L'azienda ha avvisato decine di organizzazioni coinvolte, tra cui enti pubblici, università e siti governativi statunitensi.

Non è la trama di un film di fantascienza, ma un problema molto concreto. E riguarda chiunque stia pensando di affidare a un agente AI qualcosa di più che rispondere a una domanda.

Cosa è successo

Un agente è un modello di AI che non si limita a scrivere testo: usa strumenti, visita siti, esegue comandi e prende iniziative per raggiungere un obiettivo. Secondo quanto comunicato, nei casi individuati gli agenti hanno:

superato controlli di accesso su sistemi di terzi;
usato credenziali esposte pubblicamente trovate in giro;
provato a iniettare comandi o query nei servizi con cui interagivano;
generato traffico in quantità tale da rallentare servizi online.

OpenAI ha descritto questi episodi come attività di un modello «non allineato»: l'agente inseguiva l'obiettivo che gli era stato dato, ma con mezzi che nessuno aveva autorizzato.

Perché succede

Un agente ottimizza per il risultato. Se gli chiedi di trovare un'informazione e la strada normale è chiusa, un modello molto capace può trovare una strada alternativa, anche quando quella strada è una porta che non doveva aprire. Non c'è malizia: c'è un obiettivo, degli strumenti e nessun limite abbastanza chiaro.

È lo stesso motivo per cui non si dà a un collaboratore appena arrivato la password dell'amministratore e l'accesso a tutti i conti: non perché sia disonesto, ma perché i limiti devono essere nel sistema, non nella buona volontà.

La lezione per chi usa agenti in azienda

Gli agenti AI sono utili: possono preparare ordini, rispondere ai clienti, aggiornare il gestionale, riassumere documenti. Ma questo episodio ricorda alcune regole che conviene rispettare fin dal primo giorno.

1. Permessi minimi

L'agente deve poter fare solo quello che gli serve. Se deve leggere gli ordini, non deve poterli cancellare. Se lavora su un cliente, non deve vedere gli altri.

2. Approvazione umana per le azioni che contano

Leggere e proporre sì; inviare, pagare, cancellare o pubblicare solo dopo l'ok di una persona. È la differenza tra un assistente e un sistema che agisce al posto tuo.

3. Niente segreti a portata di mano

Chiavi, password e token non devono stare nei documenti o nei prompt che l'agente legge. Se una credenziale è raggiungibile, prima o poi verrà usata.

4. Tutto tracciato

Ogni azione dell'agente deve lasciare una traccia: cosa ha fatto, quando, con quali dati e chi l'ha approvata. Senza log non c'è modo di capire cosa è successo, né di dimostrarlo.

5. Limiti di quantità

Un tetto al numero di operazioni, di richieste e di spesa. Un agente che entra in un ciclo può fare in pochi minuti il lavoro di un mese, compresi gli errori.

Non è un motivo per fermarsi

Questo episodio è emerso perché OpenAI lo ha cercato e reso pubblico, ed è un bene. Il punto non è rinunciare agli agenti, ma progettarli come si progetta qualunque software che tocca dati e soldi veri: con permessi, approvazioni e tracciabilità.

Se stai valutando un agente AI per la tua azienda e vuoi capire quali azioni può fare da solo e quali no, scrivimi: si parte da lì, prima ancora di scegliere il modello.

👉 Leggi l'articolo completo su iadicola.it

ObjectMapper in Symfony 8: trasformare DTO senza boilerplate

Dev-Iadicola — Wed, 30 Sep 2026 17:00:08 +0000

Il problema dei DTO manuali nelle applicazioni PHP

I Data Transfer Object sono una necessita in qualsiasi applicazione PHP strutturata. Separano la rappresentazione dei dati tra layer diversi dell'architettura: il DTO della request non e uguale all'entity del database, che non e uguale al DTO della response API. Questa separazione e fondamentale per mantenere i layer indipendenti e testabili.

Il problema e il codice che serve per trasformare un oggetto nell'altro. Un'applicazione media ha decine di DTO, e ognuno richiede un mapper dedicato — una classe o un metodo che copia le proprietà da un oggetto all'altro, gestisce le conversioni di tipo, applica le trasformazioni necessarie. Questo codice e ripetitivo, fragile e noioso da scrivere e mantenere. Ogni volta che si aggiunge un campo al DTO, bisogna aggiornare anche il mapper. Dimenticarsene causa bug silenziosi — il campo esiste ma non viene mai popolato.

Come funziona ObjectMapper di Symfony 8

Symfony 8 introduce il componente ObjectMapper per risolvere esattamente questo problema. L'idea e semplice: invece di scrivere codice procedurale per copiare proprietà, si dichiarano le regole di mappatura direttamente sulle proprietà usando attributi PHP nativi. Il componente si occupa dell'esecuzione.

Mappatura tramite attributi PHP

La configurazione avviene con attributi come #[MapTo] e #[MapFrom] applicati direttamente sulle proprietà delle classi sorgente e destinazione. Questo approccio ha un vantaggio enorme: la mappatura e co-locata con il codice che descrive la struttura dei dati. Non serve cercare in un file di configurazione separato o in una classe mapper dedicata — tutto e visibile nella definizione della classe stessa.

Rinominazione di campi: la proprietà $firstName nel DTO viene mappata a $nome nell'entity con un semplice attributo.
Conversione di tipi: stringhe convertite in DateTimeImmutable, interi in enum, array in value object — tutto gestito automaticamente dal mapper.
Trasformazioni custom: per logiche di mappatura complesse, si possono registrare transformer personalizzati che vengono invocati durante la trasformazione.
Oggetti annidati: se un DTO contiene un altro DTO, ObjectMapper applica ricorsivamente le regole di mappatura. Le collezioni di oggetti vengono trasformate elemento per elemento.

Zero configurazione XML o YAML

Coerentemente con la direzione presa da Symfony 8 di abbandonare XML, ObjectMapper non ha file di configurazione esterni. Tutto e dichiarato nel codice PHP tramite attributi. Questo rende la mappatura type-safe, verificabile dagli IDE e refactoring-friendly: rinominare una proprietà aggiorna automaticamente anche la configurazione della mappatura.

Esempio pratico: da request DTO a entity

Consideriamo uno scenario comune in un'applicazione Symfony: un controller riceve una richiesta HTTP, la deserializza in un CreateProductRequest DTO, la valida, e deve creare un'entity Product per il database.

Senza ObjectMapper, il codice nel controller o in un service contiene una serie di assegnamenti manuali: $product->setName($request->name), $product->setPrice($request->price), $product->setCategory($categoryRepository->find($request->categoryId)), e così via per ogni campo. Con dieci campi sono dieci righe di codice procedurale. Con venti campi sono venti righe.

Con ObjectMapper, la trasformazione si riduce a una singola chiamata: $mapper->map($request, Product::class). Le regole di mappatura sono già dichiarate sulle proprietà dei due oggetti. Il codice del controller resta snello e focalizzato sulla logica di orchestrazione, non sulla copia di dati.

ObjectMapper vs AutoMapper e librerie di terze parti

Chi lavora con Symfony da tempo conosce librerie come AutoMapper, Jane AutoMapper o Rekalogika Mapper. Sono soluzioni valide che hanno riempito un vuoto nell'ecosistema per anni. ObjectMapper offre però vantaggi significativi come componente first-party.

Manutenzione garantita: il core team di Symfony mantiene il componente con lo stesso livello di qualità degli altri componenti del framework. Aggiornamenti, bugfix e security patch sono garantiti per il ciclo di vita della release.
Integrazione nativa: funziona out-of-the-box con Serializer, Validator, Form e il container di dependency injection. Nessuna configurazione aggiuntiva per farlo parlare con il resto dell'applicazione.
Consistenza API: segue le stesse convenzioni degli altri componenti Symfony. Chi conosce il framework si trova immediatamente a proprio agio.
Nessuna dipendenza esterna: una dipendenza in meno nel composer.json significa un rischio in meno di incompatibilita, abbandono o breaking change non gestiti.

Quando usare ObjectMapper e quando no

ObjectMapper eccelle nei casi standard: mappatura tra DTO e entity, trasformazione di request in domain object, conversione di entity in response DTO. Per la maggior parte delle applicazioni, copre il 90% degli scenari di mappatura.

Per logiche di mappatura estremamente complesse — ad esempio trasformazioni che richiedono query al database, chiamate a servizi esterni o logica condizionale articolata — un mapper manuale dedicato resta la scelta migliore. ObjectMapper non cerca di sostituire il codice custom dove serve, ma di eliminarlo dove non aggiunge valore.

Impatto sulla qualità del codice

L'adozione di ObjectMapper in un progetto Symfony ha un effetto a cascata sulla qualità del codice. I controller diventano più snelli, i service layer più focalizzati sulla business logic, e i test più semplici da scrivere — non serve più testare che ogni campo venga copiato correttamente, il componente se ne occupa. Per chi lavora come freelance su progetti PHP, questo si traduce in meno codice da mantenere, meno bug e consegne più rapide.

👉 Leggi l'articolo completo su iadicola.it

La storia di C#: la risposta di Microsoft a Java che ha cambiato strada

Dev-Iadicola — Wed, 30 Sep 2026 11:01:42 +0000

Ultimo capitolo della serie sulla storia dei linguaggi backend. Dopo PHP e Java arriva il linguaggio che è nato, in buona parte, come conseguenza del successo di Java. E che, nel giro di vent'anni, è passato dall'essere considerato "la copia Microsoft di Java" a essere uno dei linguaggi che ha introdotto più idee poi copiate da tutti gli altri.

Prima di C#: Microsoft, Sun e J++

Alla fine degli anni Novanta Microsoft aveva una licenza Java e un suo ambiente di sviluppo, Visual J++. Ma la sua JVM aggiungeva estensioni specifiche per Windows e non rispettava del tutto le specifiche di Sun, rompendo di fatto la promessa del "write once, run anywhere".

Nel 1997 Sun fece causa a Microsoft. La vicenda si chiuse nel 2001 con un accordo economico, ma la direzione era già chiara: Microsoft non poteva costruire il proprio futuro su un linguaggio controllato da un concorrente. Serviva una piattaforma propria.

Anders Hejlsberg e il progetto Cool

A guidare il nuovo linguaggio fu chiamato Anders Hejlsberg, ingegnere danese che aveva già creato Turbo Pascal e fatto da architetto capo di Delphi alla Borland. Microsoft lo aveva assunto nel 1996.

Il progetto interno si chiamava Cool, "C-like Object Oriented Language". Il nome finale, C#, richiama la notazione musicale del diesis, una nota un semitono più alta. C'è anche un gioco visivo: il simbolo # può essere letto come quattro "+" sovrapposti, un passo oltre il C++.

C# fu presentato nel luglio 2000, alla Professional Developers Conference di Microsoft, insieme alla piattaforma .NET.

.NET Framework e il CLR

L'architettura di .NET somigliava a quella di Java, con una differenza strategica. Il codice viene compilato in un linguaggio intermedio (CIL), eseguito da una macchina virtuale chiamata Common Language Runtime. Ma il CLR era pensato fin dall'inizio per ospitare più linguaggi: C#, Visual Basic .NET, poi F# e altri, tutti interoperabili tra loro.

La prima versione di C# arrivò nel febbraio 2002 con il .NET Framework 1.0 e Visual Studio .NET. Microsoft standardizzò il linguaggio presso ECMA (ECMA-334) e poi ISO. Ma, nella pratica, .NET girava solo su Windows.

A colmare il vuoto provò Mono, un'implementazione open source avviata da Miguel de Icaza, che portò C# su Linux, macOS e poi, con Xamarin, su iOS e Android.

C# 2.0 e 3.0: quando C# ha superato Java

Le prime versioni di C# erano simili a Java. La differenza si vide negli anni successivi.

C# 2.0 (2005) introdusse i generics, ma con un'implementazione diversa da quella di Java: in .NET i tipi generici esistono anche a runtime (sono reificati). Una List<int> è davvero una lista di interi, senza boxing e senza perdere informazioni sui tipi. Arrivarono anche i tipi nullable, gli iteratori con yield e i metodi anonimi.

C# 3.0 (2007) fu un salto enorme: LINQ (Language Integrated Query), lambda expression, inferenza di tipo con var, extension method, tipi anonimi. Con LINQ si poteva interrogare una collezione, un documento XML o un database con la stessa sintassi, direttamente nel linguaggio. Java avrebbe avuto le lambda solo sette anni dopo.

C# 5: async/await, un'idea che ha conquistato tutti

C# 4.0 (2010) aggiunse il tipo dynamic, i parametri opzionali e nominati. Ma la vera eredità arrivò con C# 5.0 (2012): le parole chiave async e await.

Prima, scrivere codice asincrono significava callback annidate e codice illeggibile. Con async/await il codice asincrono si scrive come se fosse sequenziale, e il compilatore si occupa di trasformarlo. L'idea ebbe un successo tale da essere adottata da JavaScript, Python, Rust, Kotlin, Swift e molti altri. Se oggi scrivi await in quasi qualunque linguaggio, stai usando un'idea resa popolare da C#.

2014–2016: Microsoft diventa open source

Con Satya Nadella alla guida di Microsoft dal 2014, la strategia cambiò radicalmente. Microsoft annunciò che .NET sarebbe diventato open source e multipiattaforma. Il nuovo compilatore di C#, Roslyn, fu pubblicato come codice aperto, aprendo la strada a strumenti di analisi e refactoring molto più potenti.

Nel 2016 Microsoft acquisì Xamarin, e nel giugno dello stesso anno uscì .NET Core 1.0: una riscrittura modulare, veloce, capace di girare su Windows, Linux e macOS. Per un'azienda che vent'anni prima aveva combattuto per legare Java a Windows, era un cambiamento notevole.

Da .NET Core a un solo .NET

Per qualche anno convissero .NET Framework (solo Windows) e .NET Core (multipiattaforma). Con .NET 5, nel novembre 2020, Microsoft unificò tutto sotto un solo nome. Da allora esce una versione ogni novembre, con un supporto a lungo termine per le versioni pari: .NET 6, .NET 8 e .NET 10 (2025).

ASP.NET Core è diventato uno dei framework web più veloci nei benchmark indipendenti, e C# è anche il linguaggio di Unity, uno dei motori di videogiochi più usati al mondo.

Il C# moderno

Le versioni recenti hanno reso il linguaggio più conciso e più sicuro:

C# 7 (2017): tuple e prime forme di pattern matching.
C# 8 (2019): nullable reference types, che segnalano in compilazione i possibili riferimenti nulli.
C# 9 (2020): records e top-level statements, per scrivere un programma senza la classe Program.
C# 12 (2023): primary constructors e collection expressions.
C# 14 (2025, con .NET 10): extension members e la parola chiave field nelle proprietà.

Anders Hejlsberg, nel frattempo, ha creato anche TypeScript (2012): molte delle idee di C# sono così arrivate anche nel mondo JavaScript.

Cosa ci insegna la storia di C

C# è nato come risposta strategica a un concorrente, ma ha avuto il vantaggio di arrivare dopo: ha potuto osservare i limiti di Java ed evitarli. Per anni ha pagato il legame con Windows; quando Microsoft ha scelto l'open source, quel limite è sparito.

Tre linguaggi, tre storie

Chiudendo la serie, le tre storie mostrano tre modi diversi di nascere e crescere. PHP è nato per caso ed è diventato maturo grazie alla comunità. Java è nato da un progetto aziendale e ha vinto grazie alla stabilità. C# è nato come mossa strategica e ha vinto grazie all'innovazione continua.

Oggi i tre linguaggi si somigliano più che mai: tipi, record, pattern matching, programmazione funzionale. Si sono copiati a vicenda, e ne abbiamo guadagnato tutti. Per chi sviluppa backend, conoscerne la storia significa capire perché certe scelte sono state fatte, e scegliere lo strumento giusto con più consapevolezza.

👉 Leggi l'articolo completo su iadicola.it

RAG: un assistente AI che risponde con i documenti della tua azienda

Dev-Iadicola — Wed, 30 Sep 2026 07:35:07 +0000

Chiedi a ChatGPT le condizioni di reso dei tuoi prodotti e ti risponderà con sicurezza. Peccato che siano le condizioni di reso di un'azienda qualsiasi: il modello non ha mai letto le tue. Il problema non è l'intelligenza del modello, è che non conosce i tuoi documenti.

La soluzione più usata oggi ha una sigla poco simpatica: RAG, Retrieval Augmented Generation. In italiano: generazione aiutata dal recupero di informazioni. Prima di rispondere, l'AI va a cercare nei tuoi documenti i passaggi che servono, e risponde partendo da quelli.

Come funziona, senza formule

Immagina un collega nuovo, bravissimo a scrivere, che però non sa niente della tua azienda. Ogni volta che gli fai una domanda, prima di rispondere apre l'archivio, trova le tre pagine giuste e risponde leggendo quelle. La RAG fa esattamente questo, in tre passaggi:

Preparazione: i documenti (PDF, manuali, contratti, pagine del gestionale) vengono divisi in pezzi e indicizzati per significato, non solo per parole chiave.
Ricerca: quando arriva una domanda, il sistema trova i pezzi più pertinenti. «Quanto tempo ha il cliente per restituire un prodotto?» trova il paragrafo sul diritto di recesso anche se non contiene la parola «restituire».
Risposta: il modello riceve la domanda insieme a quei pezzi, e risponde basandosi su di loro, citando da dove vengono.

Il vantaggio è enorme: la risposta è ancorata ai tuoi dati, e si può verificare aprendo la fonte.

Perché non basta «caricare i PDF su ChatGPT»

Caricare qualche file in una chat va bene per un documento alla volta. In azienda i documenti sono centinaia, cambiano, e non tutti devono vederli tutti. Un sistema RAG fatto bene risolve tre problemi che la chat non risolve:

Si aggiorna da solo: quando cambia il listino, cambia anche la risposta.
Rispetta i permessi: chi lavora in magazzino non deve trovare nelle risposte gli stipendi o i contratti riservati.
I dati restano sotto controllo: si sceglie dove stanno i documenti e quale modello li legge.

Dove serve davvero in una PMI

Assistenza clienti

Risposte su prodotti, garanzie e procedure scritte partendo dai manuali veri, con il rimando alla pagina giusta. L'operatore controlla e invia, invece di cercare.

Documenti e contratti

«Quali contratti scadono nei prossimi tre mesi con clausola di rinnovo automatico?» Secondo l'ISTAT, l'analisi di testi e documenti è la tecnologia AI più diffusa nelle imprese italiane: è il punto da cui partono quasi tutti.

Procedure interne

Il nuovo assunto chiede all'assistente come si fa un reso al fornitore, invece di interrompere un collega. La risposta arriva dalla procedura scritta, non dal ricordo di qualcuno.

Il gestionale che risponde

Collegata ai dati del gestionale, la RAG risponde a domande come «a che punto è l'ordine del cliente Rossi?» senza aprire cinque schermate.

Gli errori da evitare

Documenti vecchi e duplicati: se nell'archivio ci sono tre versioni del listino, l'AI può rispondere con quella sbagliata. Prima si mette ordine, poi si indicizza.
Nessun controllo sui permessi: è l'errore più grave. La ricerca deve filtrare i documenti in base a chi fa la domanda, prima ancora che il modello li veda.
Risposte senza fonte: se l'assistente non dice da dove prende la risposta, non c'è modo di fidarsi. La fonte va sempre mostrata.
Nessuna misura della qualità: servono domande di prova con le risposte giuste, da ripetere a ogni modifica, per sapere se il sistema migliora o peggiora.

Da dove partire

Non serve indicizzare tutta l'azienda il primo giorno. Si parte da un'area con domande frequenti e documenti chiari, per esempio l'assistenza su una linea di prodotti o le procedure del magazzino. Si misura quanto tempo si risparmia, e si allarga da lì.

Se vuoi capire se i tuoi documenti sono pronti per un assistente AI, e da quale area conviene partire, scrivimi: è una valutazione che si fa in poco tempo, prima di spendere in sviluppo.

👉 Leggi l'articolo completo su iadicola.it

Il monolite non è il problema: il problema è come lo costruisci

Dev-Iadicola — Tue, 29 Sep 2026 19:41:17 +0000

Quando un progetto inizia a crescere, prima o poi arriva la stessa domanda: “Non sarebbe meglio passare ai microservizi?”

Più utenti, più funzionalità, più integrazioni, magari un'app mobile da affiancare alla web application, processi asincroni, notifiche e API esterne.

A prima vista la risposta sembra quasi automatica: il progetto sta diventando grande, quindi bisogna dividerlo. Non necessariamente.

Un monolite può gestire applicazioni molto complesse. Il problema nasce quando monolite diventa sinonimo di codice completamente accoppiato.

Il problema non è avere un solo deploy

Immaginiamo una classica applicazione Laravel organizzata tra controller, model, service e repository. All'inizio funziona benissimo.

Poi arrivano clienti, appuntamenti, fatture, notifiche, documenti, pagamenti e integrazioni. La directory dei service inizia a contenere decine di classi, i controller utilizzano servizi appartenenti a parti completamente diverse dell'applicazione e modificare una funzionalità significa attraversare mezza codebase.

Il problema non è Laravel. E non è nemmeno il fatto che tutto venga distribuito insieme. Il problema sono i confini che non esistono più.

Organizzare il software intorno al dominio

Una possibile evoluzione consiste nello smettere di organizzare l'intera applicazione esclusivamente per tipologia tecnica e iniziare a ragionare per capacità: Customers, Appointments, Billing, Notifications, Documents.

Ogni modulo rappresenta un confine riconoscibile. Può contenere ciò che gli serve a livello Application, Domain, Infrastructure e Http senza obbligare tutto il progetto a vivere in cartelle globali enormi.

Non è una struttura da copiare necessariamente alla lettera. Il concetto importante è che il codice relativo allo stesso dominio dovrebbe avere un confine riconoscibile.

Tecnicamente continua a essere una sola applicazione Laravel, un repository, un deploy e potenzialmente anche un solo database. Concettualmente, però, abbiamo iniziato a separare le responsabilità.

Modularità non significa creare una Action per qualsiasi cosa

Qui entrano spesso in gioco Vertical Slice Architecture, Clean Architecture, Hexagonal Architecture e Domain-Driven Design. Sono approcci dai quali possiamo prendere ottime idee. Il problema nasce quando diventano regole da applicare meccanicamente.

Organizzare il software per feature non significa necessariamente creare CreateAppointmentAction, UpdateAppointmentAction, CancelAppointmentAction, ConfirmAppointmentAction, RescheduleAppointmentAction e una nuova classe per ogni verbo dell'applicazione.

Sulla carta può sembrare estremamente ordinato. Nella pratica possiamo finire per sostituire controller troppo grandi con centinaia di classi minuscole. Il numero di file aumenta, la navigazione aumenta e le astrazioni aumentano, ma la qualità dell'architettura non necessariamente migliora.

Preferisco che sia la complessità del comportamento a giustificare una nuova astrazione, non semplicemente l'esistenza di un endpoint.

Un controller può tranquillamente coordinare un'operazione semplice. Non c'è necessariamente bisogno di creare una Action, un DTO, un'interfaccia, un repository e un response object per salvare quattro campi nel database.

Quando invece l'operazione contiene regole di business importanti, viene richiamata da più punti oppure necessita di essere isolata e testata indipendentemente, estrarla in un servizio o in un caso d'uso dedicato inizia ad avere un motivo concreto.

Non creo un'astrazione perché l'architettura dice che dovrebbe esserci. La creo quando risolve un problema.

Il dominio dovrebbe contenere ciò che conta davvero

Prendiamo un appuntamento. Cambiare il nome visualizzato potrebbe essere un'operazione estremamente semplice. Calcolare invece se quell'appuntamento può essere spostato potrebbe coinvolgere disponibilità dell'operatore, sovrapposizioni, orari dell'attività, durata del servizio, regole di cancellazione e stato corrente.

Questa è logica che merita attenzione. Non perché stiamo seguendo Clean Architecture, ma perché rappresenta una regola reale del sistema.

È questo tipo di comportamento che voglio evitare di disperdere tra controller, query, listener e helper. Il dominio dovrebbe proteggere le parti dell'applicazione che hanno realmente valore.

Anche le dipendenze devono rispettare i confini

Supponiamo che Appointments debba notificare un cliente quando viene creato un appuntamento. La soluzione più immediata potrebbe essere chiamare direttamente il sistema delle notifiche. Funziona, ma aumentando queste dipendenze rischiamo lentamente di ricreare lo stesso monolite accoppiato.

In alcuni casi possiamo utilizzare un evento: il modulo degli appuntamenti comunica semplicemente che è stato creato un appuntamento. Un listener può inviare una mail, un altro aggiornare un CRM, un altro ancora inviare un messaggio WhatsApp.

Eventi e queue diventano particolarmente interessanti quando alcune operazioni possono essere eseguite in maniera asincrona. Ma anche qui vale la stessa regola: non tutto deve diventare un evento. A volte una semplice chiamata è esattamente ciò che serve.

Un monolite può scalare

Un altro equivoco comune è associare automaticamente molti utenti ai microservizi. Ma architettura applicativa e infrastruttura sono due problemi collegati, non la stessa cosa.

Prima di distribuire un sistema possiamo intervenire su indici e query del database, caching, Redis, queue e worker, CDN, object storage, replica del database, load balancing e scaling orizzontale.

La stessa applicazione Laravel può essere eseguita su più istanze dietro un load balancer. Continua a essere un monolite.

Monolite non significa necessariamente un'applicazione che gira su un solo server.

Non progettare oggi i microservizi che forse serviranno tra tre anni

È facile cadere nell'errore opposto: “potrebbe diventare grande”, “potremmo avere migliaia di utenti”, “un giorno potremmo dover separare questo modulo”. E improvvisamente un'applicazione che deve ancora dimostrare di avere un problema di scalabilità possiede Kubernetes, Kafka e diversi servizi indipendenti.

Abbiamo pagato subito il costo di un problema che ancora non abbiamo.

Distribuire un sistema introduce networking, autenticazione tra servizi, logging distribuito, tracing, retry, deployment indipendenti, versionamento dei contratti, consistenza dei dati e gestione dei fallimenti parziali.

Sono problemi accettabili quando stiamo ottenendo qualcosa in cambio. Molto meno quando li introduciamo soltanto perché “i microservizi scalano meglio”.

Preferisco partire dalla domanda opposta: qual è la soluzione più semplice che mi permette comunque di mantenere buoni confini?

Molto spesso la risposta può essere un monolite modulare: Laravel, PostgreSQL o MySQL, Redis quando serve, queue per i processi asincroni e una struttura del codice costruita intorno al dominio.

Poi misuriamo CPU, memoria, query lente, code, throughput, tempi di risposta e colli di bottiglia. Prima troviamo il problema. Poi scegliamo la tecnologia necessaria per risolverlo.

E se un giorno un modulo dovesse diventare un microservizio?

Immaginiamo un'applicazione composta da Customers, Appointments, Billing e Notifications. Con il tempo Notifications potrebbe iniziare a gestire una quantità enorme di email, WhatsApp, push notification e altri eventi, richiedendo un modello di scaling completamente diverso.

A quel punto abbiamo finalmente un motivo per valutare l'estrazione. L'applicazione principale continua a esistere e separiamo solamente ciò che ha realmente bisogno di esserlo.

Naturalmente l'operazione non è gratuita. Una chiamata PHP interna è estremamente diversa da una comunicazione attraverso la rete: bisogna gestire indisponibilità, retry, duplicazioni, timeout e consistenza.

Ma almeno non dobbiamo contemporaneamente capire dove finisce Notifications e dove inizia Appointments: quel confine esisteva già nel software.

Quando sceglierei davvero i microservizi?

Non utilizzerei come metrica il numero di righe di codice e nemmeno semplicemente il numero di utenti. Cercherei problemi concreti: un dominio con necessità di scaling differenti, team con cicli di deploy realmente indipendenti, esigenze tecnologiche diverse o confini di dominio sufficientemente chiari da poter vivere autonomamente.

Il vantaggio ottenuto deve superare il costo operativo della distribuzione. Prima, rischiamo semplicemente di trasformare problemi di organizzazione del codice in problemi di rete.

Clean Architecture, Vertical Slice e DDD sono strumenti

Un progetto non diventa automaticamente migliore perché contiene Domain, Application, Infrastructure e Presentation. Così come non diventa automaticamente migliore perché ogni operazione possiede una propria Action.

Le cartelle non sono l'architettura. Le interfacce non sono l'architettura. I pattern non sono l'architettura. Sono strumenti attraverso i quali possiamo esprimere determinate decisioni.

Da Vertical Slice possiamo prendere l'idea di mantenere vicine le cose che cambiano insieme. Da Clean Architecture la separazione tra business logic e dettagli infrastrutturali. Dal Domain-Driven Design l'attenzione verso il dominio e i suoi confini. Dall'architettura esagonale l'idea che database, framework e provider esterni siano dettagli sostituibili.

Ma non siamo obbligati ad applicare ogni pattern contemporaneamente. Altrimenti rischiamo di costruire un software perfettamente aderente a un diagramma e terribile da modificare.

La vera decisione architetturale

Davanti a un nuovo progetto Laravel abbastanza importante, non partirei dalla domanda: “Monolite o microservizi?”

Partirei da: “Quali sono i confini del mio dominio?”

Poi cercherei di mantenerli abbastanza chiari senza introdurre complessità che il progetto non richiede ancora.

Un controller semplice può rimanere semplice. Una regola di business complessa merita di essere isolata. Una queue viene introdotta quando abbiamo qualcosa che ha senso eseguire asincronamente. Un evento quando vogliamo realmente disaccoppiare comportamenti. Un microservizio quando abbiamo una ragione concreta per distribuirlo indipendentemente.

Il monolite può evolvere. Alcuni moduli possono rimanere insieme per tutta la vita del prodotto. Altri possono essere estratti quando esisterà finalmente una ragione concreta.

L'obiettivo non è costruire oggi l'architettura che immaginiamo possa servirci tra cinque anni. E nemmeno utilizzare più pattern possibili.

L'obiettivo è costruire software abbastanza semplice da capire oggi e abbastanza ben organizzato da poter cambiare domani.

👉 Leggi l'articolo completo su iadicola.it

Laravel AI SDK: intelligenza artificiale first-party nel framework

Dev-Iadicola — Tue, 29 Sep 2026 17:00:10 +0000

Cos'e il Laravel AI SDK e perché cambia le regole del gioco

Con Laravel 13, il Laravel AI SDK esce dalla beta e diventa un pacchetto first-party stabile, rilasciato lo stesso giorno del framework. Si tratta di un'interfaccia unica e provider-agnostic per integrare funzionalita di intelligenza artificiale direttamente nelle applicazioni Laravel.

Fino ad oggi, integrare un LLM in un progetto PHP significava scegliere tra l'SDK di OpenAI, quello di Anthropic, la libreria per Google Gemini, e gestire ciascuno con le sue convenzioni, i suoi formati di risposta e le sue peculiarita. Il Laravel AI SDK astrae tutto questo: si scrive il codice una volta e si cambia provider modificando una variabile d'ambiente in .env.

Funzionalita disponibili nel Laravel AI SDK

Il pacchetto copre le principali aree di applicazione dell'AI moderna:

Text generation: completamenti e chat con qualsiasi LLM supportato. Si definisce un prompt, si invoca il servizio e si ottiene la risposta in un formato standard, indipendentemente dal provider sottostante.
Tool-calling agents: agenti che possono invocare funzioni PHP definite nel progetto. L'agente riceve un obiettivo, decide autonomamente quali tool utilizzare e restituisce il risultato finale. Ideale per automazioni complesse come analisi dati, generazione report o workflow multi-step.
Embeddings: generazione di vettori numerici a partire da testo, per ricerca semantica, clustering e sistemi RAG (Retrieval Augmented Generation).
Image generation: creazione immagini via DALL-E, Midjourney API e altri provider, con un'interfaccia unificata per la generazione e il salvataggio delle immagini.
Audio synthesis: text-to-speech integrato per applicazioni che richiedono output vocale.
Vector stores: integrazione nativa con database vettoriali come Pinecone, Weaviate e pgvector per memorizzare e recuperare embeddings in modo efficiente.

Come funziona nella pratica: un esempio concreto

Immaginiamo un'applicazione e-commerce che deve generare descrizioni prodotto ottimizzate per SEO. Con il Laravel AI SDK, il flusso e lineare:

Si configura il provider in .env: AI_PROVIDER=openai o AI_PROVIDER=anthropic
Si inietta il servizio AI tramite dependency injection nel controller o nel service
Si invoca il metodo di generazione testo passando il prompt con i dati del prodotto
Si riceve la risposta in un formato normalizzato, pronta per essere salvata nel database

Se domani il cliente vuole passare da OpenAI ad Anthropic per motivi di costo o performance, si cambia una riga nel .env. Nessun refactoring, nessun rischio di regressione.

Architettura del pacchetto: come e strutturato

Il Laravel AI SDK segue i pattern architetturali standard di Laravel:

Service Provider: registra i servizi e le configurazioni nel container
Facade: accesso rapido ai servizi tramite AI::generate(), AI::embed(), ecc.
Driver pattern: ogni provider e un driver intercambiabile, come per cache, sessioni e code
Configurazione via config file: config/ai.php per parametri avanzati come timeout, tentativi e fallback provider

Questo significa che chi conosce già Laravel si trova immediatamente a suo agio. Non c'e una nuova architettura da imparare: e lo stesso pattern che il framework usa per tutto il resto.

Testabilita: come testare codice che usa l'AI

Uno dei vantaggi più significativi di un pacchetto first-party e la testabilita nativa. Il Laravel AI SDK fornisce metodi di fake e mock integrati:

AI::fake() per simulare risposte senza chiamate reali al provider
Assertions per verificare che determinate richieste siano state fatte
Sequenze di risposte predefinite per testare flussi multi-step
Integrazione con PHPUnit e Pest senza configurazioni aggiuntive

Questo risolve un problema concreto: con gli SDK di terze parti, testare il codice AI richiedeva wrapper custom, mock manuali o chiamate reali (costose e lente). Con il Laravel AI SDK, si testa come qualsiasi altro servizio del framework.

Provider supportati e come aggiungerne di nuovi

Al lancio, il Laravel AI SDK supporta i provider principali:

OpenAI: GPT-4o, GPT-4.5, DALL-E, Whisper
Anthropic: Claude Opus, Sonnet, Haiku
Google: Gemini Pro, Gemini Ultra
Mistral: Mistral Large, Mixtral
Ollama: per modelli locali self-hosted

Aggiungere un provider custom richiede di implementare un'interfaccia con pochi metodi. Per chi lavora con modelli proprietari o provider di nicchia, l'estensione e semplice e segue lo stesso pattern dei driver di Laravel.

Impatto per i freelance PHP: nuovi servizi da offrire

Per chi lavora come sviluppatore freelance PHP, il Laravel AI SDK apre opportunità concrete di business. Funzionalita che prima richiedevano competenze specialistiche in Python o JavaScript ora sono accessibili direttamente dal framework che usi ogni giorno.

Chatbot per il customer service, generazione automatica di contenuti, ricerca semantica nei cataloghi prodotto, analisi automatizzata dei feedback utente: sono tutti servizi che un freelance Laravel può offrire ai propri clienti senza uscire dallo stack PHP.

Quando ha senso e quando no

L'AI SDK ha senso quando l'applicazione ha bisogno di generazione testo, analisi semantica o automazione basata su linguaggio naturale. Non ha senso forzare l'AI dove un algoritmo deterministico funziona meglio: filtri, ordinamenti, calcoli finanziari restano dominio del codice tradizionale. La chiave e usare lo strumento giusto per il problema giusto.

👉 Leggi l'articolo completo su iadicola.it

Decreto IA 160/2026: dal 30 settembre cosa cambia per le aziende che usano l'intelligenza artificiale

Dev-Iadicola — Tue, 29 Sep 2026 14:01:55 +0000

Il 30 settembre 2026 entra in vigore il decreto legislativo 9 settembre 2026, n. 160, pubblicato in Gazzetta Ufficiale il 15 settembre. È il testo con cui l'Italia adegua le proprie regole al Regolamento europeo sull'intelligenza artificiale, l'AI Act (Regolamento UE 2024/1689).

Se ne parla molto, spesso con toni da allarme. Proviamo a mettere in fila le novità e a capire chi riguardano davvero.

Un nuovo reato: l'articolo 437-bis del codice penale

La novità più discussa è un nuovo articolo del codice penale, il 437-bis: «Omessa adozione di misure di sicurezza nei sistemi di intelligenza artificiale e alterazione illecita dei sistemi».

Punisce due comportamenti, entrambi legati ai sistemi di IA ad alto rischio:

Non adottare le misure di sicurezza tecniche o di supervisione umana richieste, quando da questa omissione nasce un pericolo concreto per la vita o per la sicurezza pubblica o individuale. La pena va da uno a cinque anni di reclusione, da due a otto se il pericolo riguarda la sicurezza dello Stato.
Alterare illecitamente un sistema ad alto rischio, con lo stesso tipo di pericolo. Qui la pena va da due a sei anni, da tre a dieci per la sicurezza dello Stato.

È un reato di pericolo concreto: non basta una mancanza formale, serve che dall'omissione derivi davvero un pericolo di quel tipo.

La responsabilità 231 per le imprese

Il decreto aggiunge il nuovo reato all'elenco di quelli che fanno scattare la responsabilità amministrativa degli enti prevista dal D.Lgs. 231/2001, con un nuovo articolo 25-vicies. Se il reato è commesso nell'interesse o a vantaggio dell'azienda, anche l'azienda risponde, con una sanzione pecuniaria da 600 a 1.000 quote.

Per chi ha già un modello organizzativo 231, significa aggiornarlo: l'uso dei sistemi di IA ad alto rischio diventa un'area da mappare, con procedure e controlli.

Chi subisce un danno ha più strumenti

La parte meno raccontata, ma forse la più concreta, riguarda la responsabilità civile. Dal 30 settembre chi subisce un danno dall'uso di un sistema di IA può contare su strumenti che prima non aveva:

l'ordine di esibizione della documentazione tecnica del sistema, per capire come ha funzionato;
una presunzione di nesso causale, che alleggerisce la prova del legame tra il sistema e il danno;
l'azione diretta contro l'assicuratore del responsabile.

Tradotto: la documentazione tecnica non è più un adempimento da archiviare, ma la prima cosa che verrà chiesta se qualcosa va storto.

Riguarda la mia azienda?

Il reato riguarda i sistemi ad alto rischio nel senso dell'AI Act: per esempio quelli usati nella selezione del personale, nella valutazione del credito, nell'accesso a servizi essenziali, nelle infrastrutture critiche, o come componenti di sicurezza di prodotti. Un chatbot che risponde sugli orari del negozio o un assistente che riassume le email interne, di norma, non rientrano in questa categoria.

Le regole civili, invece, valgono in modo più ampio per i danni causati da sistemi di IA. Per questo vale la pena fare ordine anche se non si usano sistemi ad alto rischio.

Da dove partire, in pratica

Fare l'inventario: quali sistemi di IA usa l'azienda, chi li fornisce, per cosa, e su quali dati. Spesso è la prima volta che qualcuno li mette tutti su una pagina.
Classificarli: quali potrebbero essere ad alto rischio secondo l'AI Act. Nei casi dubbi, serve il parere di un legale.
Documentare: cosa fa il sistema, con quali limiti, chi lo supervisiona e come si interviene quando sbaglia.
Prevedere la supervisione umana: le decisioni importanti devono avere una persona che le controlla e le può fermare, e il software deve renderlo possibile.
Tenere traccia: log di cosa ha fatto il sistema e di chi ha approvato cosa. È la stessa documentazione che servirebbe in caso di contestazione.

Molti di questi punti non sono solo obblighi: sono le stesse regole che rendono un software con l'AI affidabile. Un sistema che registra le proprie azioni, chiede approvazione per le operazioni delicate e permette a una persona di intervenire è più facile da difendere e anche più facile da usare.

Questo articolo è una sintesi divulgativa e non sostituisce una consulenza legale: per valutare il caso specifico della tua azienda serve un professionista.

Se stai costruendo o integrando strumenti con l'AI e vuoi che tracciabilità, permessi e supervisione umana siano parte del progetto fin dall'inizio, scrivimi: è molto più semplice progettarli subito che aggiungerli dopo.

👉 Leggi l'articolo completo su iadicola.it

Gli agenti AI hanno le chiavi dell’azienda: chi controlla quello che fanno?

Dev-Iadicola — Tue, 29 Sep 2026 09:36:27 +0000

Un chatbot che sbaglia una risposta è fastidioso. Un agente che sbaglia mentre possiede accesso a CRM, email, documenti e sistemi di pagamento può creare un problema molto più serio.

Un agente non è un normale account di servizio

TechTarget evidenzia una difficoltà nuova: gli agenti possono operare per conto degli utenti e richiedere strumenti o dati diversi mentre svolgono un compito. Le tradizionali identità macchina, spesso dotate di permessi relativamente statici, non descrivono bene questo comportamento.

Serve sapere chi ha autorizzato cosa

Un sistema agentico dovrebbe poter rispondere a domande concrete: quale utente ha delegato l’azione? Quali risorse sono state consultate? Quale agente l’ha eseguita? Quali strumenti ha usato? Qual era il limite dell’autorizzazione?

Senza audit affidabile, ricostruire un errore diventa difficile.

Least privilege anche per l’AI

Un agente incaricato di leggere disponibilità a calendario non dovrebbe automaticamente poter cancellare appuntamenti. Uno che prepara un pagamento non dovrebbe necessariamente poterlo confermare.

Permessi granulari, credenziali temporanee e approvazione umana per le azioni più sensibili riducono il raggio d’impatto di un errore.

L’autonomia deve essere progettata

Reuters ha raccontato che Meta ha costruito per Muse una macchina virtuale dedicata e meccanismi separati di controllo delle azioni; allo stesso tempo, i test interni riportati dall’agenzia mostrano quanto la sicurezza degli agenti resti difficile.

Il futuro non sarà “AI senza controllo umano”. Sarà probabilmente una scala di autonomia: alcune azioni automatiche, altre supervisionate e altre ancora vietate.

La sicurezza diventa parte del prodotto

Più gli agenti diventano utili, più ottengono accesso. E più ottengono accesso, più identità, autorizzazioni e tracciabilità diventano caratteristiche centrali del software.

Fonti: TechTarget, 21 settembre 2026; Reuters, settembre 2026.

👉 Leggi l'articolo completo su iadicola.it

OpenAI spegne l'API di Sora: cosa succede quando il tuo prodotto dipende da un'AI che chiude

Dev-Iadicola — Tue, 29 Sep 2026 09:16:48 +0000

Il 24 settembre 2026 OpenAI ha spento l'API di Sora, l'interfaccia che permetteva ad applicazioni di terze parti di generare video con i modelli Sora 2 e Sora 2 Pro. Da quel giorno, ogni chiamata a quell'API fallisce.

Non è stato un fulmine a ciel sereno: la chiusura era stata annunciata il 24 marzo, con sei mesi di preavviso, e l'app e il sito di Sora per il pubblico erano già stati chiusi il 26 aprile. Eppure chi aveva costruito un prodotto su quell'API si è ritrovato senza un sostituto indicato nella documentazione ufficiale.

Perché riguarda anche chi non genera video

La storia di Sora non è un caso isolato: è il modo normale in cui funziona questo mercato. I modelli AI cambiano in fretta, e i fornitori:

ritirano i modelli vecchi, a volte con pochi mesi di preavviso;
cambiano prezzi e limiti di utilizzo;
chiudono interi prodotti quando cambiano strategia.

Se il tuo gestionale riassume i documenti con un modello, se il tuo sito risponde ai clienti con un chatbot, se un'automazione classifica le email con l'AI, sei nella stessa situazione di chi usava Sora: dipendi da una decisione che non prendi tu.

Il problema non è usare un fornitore

Usare i modelli di OpenAI, Anthropic, Google o altri è quasi sempre la scelta giusta: costruirne uno in casa non ha senso per una PMI. Il problema è come li si collega al proprio software.

Se le chiamate al fornitore sono sparse in cento punti del codice, con i suoi formati e le sue particolarità, cambiarlo significa riscrivere mezza applicazione. Se invece passano da un unico punto, cambiarlo è un lavoro di giorni, non di mesi.

Come ridurre il rischio

1. Un solo punto di contatto

Nel software, l'AI si chiama sempre attraverso un livello intermedio, con un'interfaccia pensata per quello che serve a te («riassumi questo documento», «genera un video da questo testo»), non per quello che offre il fornitore. Dietro quel livello, il fornitore si può cambiare.

2. Un'alternativa già provata

Per le funzioni importanti conviene avere un secondo fornitore già collegato e testato, anche se non si usa tutti i giorni. Per la generazione video, per esempio, esistono modelli concorrenti accessibili via API.

3. I dati restano tuoi

Prompt, risultati, documenti di partenza: tutto quello che serve per rifare il lavoro deve stare nel tuo sistema, non solo nella piattaforma del fornitore.

4. Leggere gli avvisi di deprecazione

Sembra banale, ma sei mesi di preavviso servono solo se qualcuno li legge. Chi integra servizi AI dovrebbe avere qualcuno che segue gli annunci dei fornitori e un piano per ogni modello in uso.

5. Degradare con eleganza

Se il servizio AI non risponde, l'applicazione deve continuare a funzionare: magari senza la funzione intelligente, ma senza bloccarsi. Un errore chiaro è meglio di un gestionale fermo.

La lezione

L'AI è diventata un componente come un database o un servizio di pagamento, e va trattata allo stesso modo: scelta con cura, collegata in modo ordinato e sostituibile se serve. La chiusura di Sora non è un motivo per evitare l'AI, ma per integrarla bene.

Se il tuo software usa già servizi AI e vuoi capire quanto è legato a un singolo fornitore, scrivimi: è una verifica che si fa in poco tempo e che conviene fare prima del prossimo annuncio.

👉 Leggi l'articolo completo su iadicola.it

Vibe coding: perché l'app fatta con l'AI in un weekend non è pronta per i tuoi clienti

Dev-Iadicola — Mon, 28 Sep 2026 19:38:43 +0000

Qualche anno fa per avere un'applicazione serviva uno sviluppatore. Oggi basta descriverla a un'AI: «fammi un gestionale per le prenotazioni, con login e pagamenti». Dopo un weekend c'è qualcosa che funziona, si clicca, salva i dati. Questo modo di lavorare ha un nome, vibe coding: si programma a sensazione, accettando il codice che l'AI propone senza leggerlo davvero.

Per un prototipo è una rivoluzione. Per un'applicazione a cui affidi i dati dei tuoi clienti, è un rischio che conviene conoscere.

L'AI scrive codice, e lo scrive tanto

Non è una moda di nicchia. Secondo la ricerca di JetBrains sull'adozione degli agenti di coding, a metà 2026 il 90% degli sviluppatori professionisti usa un agente AI almeno una volta a settimana, e due su tre ogni giorno. Anch'io lo uso ogni giorno: scrive, rifattorizza, prepara i test. La differenza non è se si usa l'AI, ma chi controlla quello che scrive.

Cosa dicono i numeri sul codice generato

Le analisi sul codice prodotto dall'AI raccontano sempre la stessa storia: funziona, ma non è sicuro per default.

Nei test di Veracode su oltre cento modelli, il 45% del codice generato non superava i controlli dell'OWASP Top 10, la lista delle vulnerabilità web più comuni.
Secondo l'analisi di CodeRabbit, il codice scritto insieme all'AI contiene circa 1,7 volte più problemi gravi, e le vulnerabilità di sicurezza sono quasi tre volte più frequenti rispetto a codice equivalente scritto da persone.
In uno studio su oltre due milioni di campioni, quasi un pacchetto su cinque citato dall'AI non esisteva: un invito a nozze per chi pubblica pacchetti malevoli con quei nomi.

Nessuno di questi numeri dice che l'AI sia inutile. Dicono che il codice generato va trattato come quello di un collaboratore velocissimo e senza esperienza: va letto.

Gli errori tipici di un'app nata in un weekend

Le chiavi nel posto sbagliato

Password del database, chiavi di Stripe o delle API finite nel codice che arriva al browser, o in un repository pubblico. L'app funziona benissimo, e chiunque apra gli strumenti di sviluppo del browser può leggerle.

Il database aperto a tutti

Molte app generate usano servizi di database accessibili direttamente dal browser. Se le regole di accesso non sono scritte bene, ogni utente può leggere i dati di tutti gli altri. È uno degli errori più frequenti nelle scansioni delle app «vibe coded».

Nessun controllo su chi può fare cosa

Il pulsante «elimina» è nascosto agli utenti normali, ma la richiesta che parte dal pulsante risponde a chiunque la mandi. L'interfaccia sembra protetta, il server no.

Niente test, niente storia

Quando qualcosa si rompe, nessuno sa perché, e ogni correzione chiesta all'AI rischia di romperne un'altra. Senza test automatici non c'è modo di sapere se la modifica di oggi ha rovinato la funzione di ieri.

Quando il vibe coding va benissimo

Ci sono casi in cui è la scelta giusta:

Validare un'idea: mostrare un prototipo a un cliente o a un investitore prima di spendere per il prodotto vero.
Strumenti interni usa e getta: uno script per convertire un file, una pagina per un evento di una settimana.
Capire cosa vuoi davvero: toccare con mano un'interfaccia chiarisce i requisiti meglio di dieci riunioni.

Il problema nasce quando il prototipo, senza che nessuno lo decida, diventa il prodotto: arrivano i clienti veri, i dati veri, i pagamenti veri.

Dal prototipo alla produzione: cosa serve

La buona notizia è che un prototipo fatto con l'AI non va buttato: è un'ottima specifica. Per portarlo in produzione serve fare quello che il vibe coding salta:

Una revisione del codice da parte di qualcuno che lo capisca, a partire da autenticazione, permessi e gestione dei dati.
I segreti fuori dal codice, in variabili d'ambiente, con chiavi nuove al posto di quelle esposte.
I permessi controllati sul server, non solo nascosti nell'interfaccia.
Test automatici sulle funzioni che contano: se si rompe il pagamento, lo deve scoprire un test, non un cliente.
Backup, log e aggiornamenti: sapere cosa succede e poter tornare indietro.

L'AI è un acceleratore, non un pilota automatico

Io sviluppo con l'AI tutti i giorni, ed è il motivo per cui oggi posso consegnare in settimane quello che prima richiedeva mesi. Ma ogni riga che va in produzione passa da una revisione, da test automatici e da controlli di sicurezza. È la differenza tra usare l'AI per andare più veloci e usarla per non sapere cosa si sta costruendo.

Se hai un prototipo nato con l'AI e vuoi capire se è pronto per i tuoi clienti, possiamo guardarlo insieme: spesso bastano pochi interventi mirati per trasformarlo in un'applicazione solida.

👉 Leggi l'articolo completo su iadicola.it

n8n, Zapier o software su misura? Quando un'automazione basta e quando no

Dev-Iadicola — Mon, 28 Sep 2026 19:30:48 +0000

Negli ultimi mesi, sui social, non si parla d'altro: flussi di n8n che leggono le email, le riassumono con l'AI, aggiornano il CRM e mandano un messaggio su Slack. Tutto senza scrivere codice, o quasi. Non è solo una moda: nel 2026 n8n dichiara oltre 230.000 utenti attivi, e a maggio SAP ci ha investito per portarlo dentro i propri strumenti.

Chi ha un'azienda si chiede quindi: mi serve davvero un software su misura, o basta un'automazione? La risposta onesta è: dipende da cosa stai automatizzando. Proviamo a fare ordine.

Cosa sono Zapier, Make e n8n

Sono piattaforme che collegano applicazioni diverse con dei flussi: «quando succede questo, fai quello». Arriva un modulo dal sito, crea il contatto nel CRM, manda un'email di benvenuto, avvisa il commerciale.

Zapier: il più semplice e con più integrazioni pronte, migliaia. Si paga a numero di operazioni, e con volumi alti il conto sale in fretta.
Make: flussi più articolati di Zapier, con un editor visuale potente, sempre in cloud.
n8n: pensato per chi ha un minimo di competenze tecniche. Si può installare sul proprio server (self-hosted), quindi i dati restano in casa, e con volumi alti costa molto meno. È diventato il preferito per costruire flussi con agenti AI.

Quando un'automazione basta, ed è la scelta giusta

Collegare strumenti che già usi: il modulo del sito con il CRM, il calendario con le email di promemoria, le fatture con il foglio del commercialista.
Flussi lineari: pochi passaggi, sempre gli stessi, senza troppe eccezioni.
Volumi contenuti: decine o centinaia di operazioni al giorno, non decine di migliaia.
Provare un'idea: vedere se un processo automatizzato funziona prima di investire in qualcosa di più strutturato.

In questi casi un software su misura sarebbe uno spreco. Un buon flusso si costruisce in poche ore e fa risparmiare ore ogni settimana.

I segnali che l'automazione ti sta stretta

Il flusso è diventato un groviglio

Quaranta passaggi, venti condizioni, tre flussi che si chiamano a vicenda. Quando qualcosa si rompe, nessuno sa più dove. Le piattaforme visuali sono chiarissime con dieci blocchi e illeggibili con cento.

I dati non hanno una casa

Le informazioni passano da un'app all'altra ma non stanno davvero da nessuna parte: un po' nel CRM, un po' in un foglio Google, un po' nelle note del flusso. Per sapere a che punto è un ordine bisogna aprire tre strumenti.

Le eccezioni sono la regola

Il cliente che paga in due rate, l'ordine che va diviso su due magazzini, lo sconto che vale solo per certi prodotti. Ogni eccezione diventa un ramo in più del flusso, e ogni ramo in più è un punto dove può rompersi.

Il conto cresce con il lavoro

Con le piattaforme a consumo, più lavori più paghi. Quando le operazioni diventano decine di migliaia al mese, il canone può superare il costo di un'applicazione fatta apposta.

Nessuno sa cosa è successo

Un'automazione che fallisce in silenzio è peggio di un processo manuale: pensi che il cliente abbia ricevuto l'email, e invece no. Servono log, avvisi, la possibilità di riprovare.

Cosa aggiunge un software su misura

Un'applicazione su misura non sostituisce le integrazioni: le mette al servizio di un centro. I dati hanno un posto solo, le regole del tuo lavoro sono scritte una volta, le persone hanno schermate pensate per quello che fanno, e ogni operazione lascia una traccia. Le automazioni diventano parte del sistema, con test che dicono se funzionano ancora.

La via di mezzo, che spesso è la migliore

Non è una scelta secca. Molte aziende partono con Zapier o n8n, capiscono quali processi contano davvero, e solo quelli li portano in un gestionale su misura. Il resto, le integrazioni semplici e occasionali, resta in un'automazione.

Le automazioni che hai costruito non vanno buttate: sono la mappa più precisa di come lavora la tua azienda. Se i tuoi flussi sono diventati troppo complicati da gestire, partiamo da lì per capire cosa merita un software e cosa può restare com'è.

👉 Leggi l'articolo completo su iadicola.it