[{"data":1,"prerenderedAt":967},["ShallowReactive",2],{"post-un-umano-se-serve":3,"related-un-umano-se-serve":89},{"id":4,"title":5,"body":6,"categories":70,"coverImage":72,"date":73,"description":74,"extension":75,"legacy":76,"meta":77,"navigation":78,"path":79,"seo":80,"stem":81,"sticky":78,"tags":82,"updated":87,"__hash__":88},"articles/un-umano-se-serve.md","Un umano, se serve",{"type":7,"value":8,"toc":63},"minimark",[9,13,16,19,22,27,30,33,40,44,47,50,54,57,60],[10,11,12],"p",{},"Ogni volta che esce un modello nuovo, il feed si riempie di recensioni. \"L'ho provato. Ecco le mie impressioni.\" Screenshot, benchmark casalinghi, verdetti.",[10,14,15],{},"Non capisco cosa ci si senta di speciale a chattare con lo stesso modello a cui hanno accesso altri cento milioni di persone. È come recensire la corrente elettrica.",[10,17,18],{},"Attenzione: non sto dicendo che i modelli non contino. Contano al punto che qualunque LLM di frontiera è già, francamente, magia. Sto dicendo il contrario: è proprio perché sono magia disponibile a tutti, allo stesso prezzo, dallo stesso giorno, che hanno smesso di essere un argomento interessante. Quando tutti hanno la stessa capacità, la capacità non è più la variabile.",[10,20,21],{},"La variabile è cosa ci costruisci intorno.",[23,24,26],"h2",{"id":25},"la-domanda-che-mi-interessa","La domanda che mi interessa",[10,28,29],{},"La domanda che mi interessa non è quale modello sia migliore questo mese. È cosa fa questa tecnologia alle organizzazioni. E lì vedo una cosa precisa, che mi sembra ancora sottovalutata.",[10,31,32],{},"Oggi le aziende \"adottano l'AI\": prendono l'organigramma esistente — persone, ruoli, gerarchie — e attaccano strumenti alle persone. Un copilot per lo sviluppatore, un assistente per il marketing, un chatbot per il supporto. L'umano resta l'esecutore di default; l'AI assiste.",[10,34,35,36],{},"L'azienda AI-native di domani farà l'esatto contrario: ",[37,38,39],"strong",{},"un agente per ogni ruolo, e un umano se serve.",[23,41,43],{"id":42},"lorganigramma-invertito","L'organigramma invertito",[10,45,46],{},"Non è una provocazione. È la conseguenza logica di dove siamo già. Se un agente copre il primo giro di codice, il primo report, la prima risposta al cliente, il ruolo non è più una persona con uno strumento: è un processo automatizzato con un punto di escalation. L'organigramma si inverte. L'umano smette di essere la forza lavoro e diventa il livello di giudizio — quello a cui si sale quando il giudizio cambia davvero il rischio.",[10,48,49],{},"Questo cambia domande molto concrete. \"Dove ci servono mani\" diventa \"dove serve giudizio\". E il giudizio non si assume: si sedimenta. Sale di livello chi i failure modes li ha già visti, chi sa distinguere un output plausibile da uno corretto, chi sa quando fermare la macchina. Soglie, review, escalation smettono di essere compliance decorativa e diventano il design stesso dell'organizzazione.",[23,51,53],{"id":52},"il-rovescio","Il rovescio",[10,55,56],{},"C'è anche il rovescio, e va detto: un agente per ruolo senza un'escalation vera non è un'organizzazione, è automazione che nasconde complessità. E l'umano \"se serve\" funziona solo se quando serve c'è davvero — con il contesto, l'autorità e il tempo per intervenire. Altrimenti hai costruito una fabbrica velocissima con un campanello d'allarme che nessuno sente.",[10,58,59],{},"L'agente esegue. L'umano risponde — nei due sensi: risponde quando serve, e risponde delle conseguenze.",[10,61,62],{},"Il resto — quale modello, quale benchmark, quale recensione — è rumore.",{"title":64,"searchDepth":65,"depth":65,"links":66},"",2,[67,68,69],{"id":25,"depth":65,"text":26},{"id":42,"depth":65,"text":43},{"id":52,"depth":65,"text":53},[71],"ai","https://i2.wp.com/enricodeleo.s3.eu-south-1.amazonaws.com/images/umano-se-serve.png","2026-07-08T09:00:00.000Z","Il modello del mese è una commodity. La domanda vera è cosa fa l'AI alle organizzazioni: un agente per ogni ruolo, un umano se serve.","md",false,{},true,"/un-umano-se-serve",{"title":5,"description":74},"un-umano-se-serve",[71,83,84,85,86],"agenti","organizzazione","ai-native","engineering",null,"ph81sHTs6QKW-MahlXR2G_EEfGawHF7Mapynv5dxFmU",[90,445],{"id":91,"title":92,"body":93,"categories":432,"coverImage":434,"date":435,"description":436,"extension":75,"legacy":76,"meta":437,"navigation":78,"path":438,"seo":439,"stem":440,"sticky":76,"tags":441,"updated":87,"__hash__":444},"articles/velocita-senza-giudizio.md","Velocità senza giudizio",{"type":7,"value":94,"toc":423},[95,101,104,111,114,117,123,130,134,137,144,159,166,172,175,179,185,192,195,206,209,216,224,227,231,234,241,252,255,262,267,270,273,280,284,287,290,293,296,302,305,310,313,317,323,326,333,336,347,351,357,360,371,376,379,382,387,391,394,401,404,415,418],[10,96,97],{},[98,99,100],"em",{},"Il vibe coding non ha inventato il codice scritto male. Ha solo tolto l'attrito.",[10,102,103],{},"Ho visto un backend con l'autenticazione hardcodata nel frontend. Password admin in chiaro, visibile a chiunque aprisse DevTools. Non era vibe coding — era 2018, dev umani, trovati su Upwork.",[10,105,106,107,110],{},"Ve lo dico perché quello che sta succedendo adesso ",[37,108,109],{},"non è una novità",". È la stessa roba, più veloce.",[10,112,113],{},"Ho visto Google Sheets usato come database. Collassava a quattro utenti. I fondatori si sono sorpresi.",[10,115,116],{},"Ho visto funzionalità dichiarate implementate che erano solo API vuote senza niente dietro. L'ho visto fare a dev umani. L'ho visto fare a Claude Opus 4.6, che in questo momento è il modello più capace di Anthropic. Ho visto test scritti per passare, non per verificare.",[118,119,120],"blockquote",{},[10,121,122],{},"Un sistema che si auto-certifica è più pericoloso di uno che fallisce apertamente.",[10,124,125,126,129],{},"Il problema non è l'AI. È che la velocità che offre può farti dimenticare che costruire software è ",[37,127,128],{},"fondamentalmente un atto cognitivo"," — non di scrittura.",[23,131,133],{"id":132},"il-software-non-è-testo","Il software non è testo",[10,135,136],{},"Questa è la cosa che l'entusiasmo attorno al vibe coding dimentica sistematicamente.",[10,138,139,140,143],{},"Il software non è testo. È un ",[37,141,142],{},"modello formale della realtà"," — un sistema di regole che descrive come un dominio si comporta, come gli stati cambiano, come le eccezioni vengono gestite, come il tempo e la concorrenza e il fallimento vengono trattati.",[10,145,146,147,150,151,154,155,158],{},"Scrivere codice non è mai stato il problema difficile. Il problema difficile è capire ",[98,148,149],{},"cosa"," scrivere — e ",[98,152,153],{},"perché",". È identificare i confini del dominio, le invarianti che devono reggere, i casi limite che il business non ti ha detto perché non sapeva di doverlo fare, le implicazioni che una scelta architetturale avrà tra sei mesi quando i requisiti cambieranno — ",[37,156,157],{},"perché cambiano sempre",".",[10,160,161,162,165],{},"Questa comprensione non si ottiene velocemente. Si ottiene attraverso iterazioni, conversazioni, errori, correzioni, notti a chiedersi perché quella cosa non funziona come dovrebbe. È quella che Michael Polanyi chiamava ",[98,163,164],{},"conoscenza tacita"," — sapere che non si riesce a trasferire completamente in parole, che risiede nell'esperienza accumulata, nei pattern riconosciuti, nelle intuizioni costruite su decine di progetti.",[10,167,168,171],{},[37,169,170],{},"L'AI non ha questa conoscenza."," Ha la media statistica di quello che è stato scritto su internet riguardo a problemi simili al tuo.",[10,173,174],{},"Che non è la stessa cosa.",[23,176,178],{"id":177},"la-trappola-della-perfezione-apparente","La trappola della perfezione apparente",[10,180,181,182,158],{},"C'è qualcosa di specifico nell'AI che aggrava tutto questo: ",[37,183,184],{},"il codice che produce sembra sempre scritto bene",[10,186,187,188,191],{},"È ben nominato, ha i commenti nei posti giusti, segue le convenzioni, usa i pattern corretti. Non sembra il codice di qualcuno che non sa quello che fa — sembra il codice di qualcuno che sa ",[98,189,190],{},"esattamente"," quello che fa.",[10,193,194],{},"Questo è il problema.",[10,196,197,198,201,202,205],{},"Il codice sbagliato scritto male ti ferma. Lo vedi, lo senti, ti insospettisce. Attiva il tuo senso critico prima ancora che tu abbia capito cosa fa. Il ",[37,199,200],{},"codice sbagliato scritto bene"," attraversa la code review senza attivare nessun campanello d'allarme, supera i test, va in produzione. E quando si rompe — ",[98,203,204],{},"perché si rompe"," — la forma corretta del codice rende ancora più difficile localizzare il problema concettuale che ci sta sotto.",[10,207,208],{},"Stai cercando un bug in codice che non sembra buggy. Stai cercando un'assunzione sbagliata in codice che sembra ragionevole.",[10,210,211,212,215],{},"Nel 1986 Fred Brooks scriveva che la difficoltà essenziale del software non è accidentale — non riguarda la sintassi, i compilatori, la velocità di scrittura. Riguarda la ",[37,213,214],{},"complessità concettuale intrinseca"," dei sistemi che costruiamo. Quarant'anni dopo, l'AI ha eliminato quasi completamente la difficoltà accidentale. Quella essenziale è rimasta intatta.",[118,217,218],{},[10,219,220,223],{},[98,221,222],{},"\"No silver bullet.\"","\n— Fred Brooks, 1986",[10,225,226],{},"E ora che la difficoltà accidentale è sparita, la difficoltà essenziale è più esposta che mai. Ma è anche più facile da non vedere, perché l'output che la nasconde sembra così convincente.",[23,228,230],{"id":229},"il-modello-della-realtà","Il modello della realtà",[10,232,233],{},"Quando chiedi all'AI di costruire qualcosa, quello che ricevi non è una soluzione.",[10,235,236,237,240],{},"È una ",[37,238,239],{},"interpretazione"," del problema che hai descritto.",[10,242,243,244,247,248,251],{},"L'AI costruisce un modello della realtà basato su quello che gli hai detto — e quello che gli hai detto è inevitabilmente incompleto, perché la conoscenza del dominio che hai in testa non si trasferisce per intero in un prompt. Il gap tra il problema che hai ",[98,245,246],{},"in testa"," e il problema che l'AI ha ",[98,249,250],{},"capito"," è sempre presente. A volte è trascurabile. A volte è la differenza tra un sistema che regge e uno che collassa al primo caso limite reale.",[10,253,254],{},"La velocità non ti dà il tempo di misurare quel gap. Peggio: la velocità e la perfezione apparente dell'output creano attivamente l'illusione che il gap non esista.",[10,256,257,258,261],{},"Questo è il motivo per cui ",[37,259,260],{},"\"funziona\" non è mai abbastanza"," come criterio di accettazione.",[10,263,264],{},[98,265,266],{},"Funziona rispetto a cosa?",[10,268,269],{},"Rispetto ai test che l'AI ha scritto per passare — costruiti attorno agli stessi casi che aveva in testa quando ha scritto il codice, in un loop chiuso che non include nessuna realtà esterna? Rispetto alla demo con dati puliti e percorsi felici? O rispetto alla logica reale del dominio, con tutti i casi limite che solo tu conosci perché ci hai lavorato dentro?",[10,271,272],{},"Salvatore Sanfilippo ha sollevato un problema analogo sulla code review: lo stato mentale di chi scrive non è trasferibile al reviewer. Il reviewer vede il testo, non il ragionamento che ha prodotto quel testo. O puntualizza cose superficiali, oppure non comprende abbastanza da vedere il problema vero.",[10,274,275,276,279],{},"Con l'AI il problema si radicalizza: ",[37,277,278],{},"l'AI non ha stato mentale da trasferire",". Ha prodotto output ottimizzando per la coerenza interna del testo, non per la corrispondenza con la tua realtà. Il reviewer — che sei tu — deve colmare quel gap da solo. Se non ti fermi a farlo, nessuno lo farà.",[23,281,283],{"id":282},"let-it-sink","Let it sink",[10,285,286],{},"C'è una pratica che ogni ingegnere con abbastanza cicatrici ha interiorizzato: dormirci sopra.",[10,288,289],{},"Non per pigrizia. Per necessità cognitiva.",[10,291,292],{},"Il cervello umano non elabora i problemi complessi in modo lineare e sequenziale. Elabora in parallelo, spesso al di sotto della soglia della coscienza. È per questo che le soluzioni migliori arrivano sotto la doccia, in macchina, la mattina appena svegli — non davanti allo schermo quando stai cercando attivamente la risposta. I problemi che non vedi nel momento emergono dopo, quando torni con occhi freschi e il cervello ha avuto il tempo di connettere pattern che la concentrazione attiva non riesce a vedere.",[10,294,295],{},"Non è misticismo. È neuroscienze. La modalità diffusa del cervello è essenziale per l'insight, per la comprensione profonda, per accorgersi delle incongruenze che la modalità focalizzata salta perché è troppo dentro il problema.",[10,297,298,299],{},"Con l'AI quella pratica diventa ancora più importante, e ancora più facile da saltare. Perché in pochi minuti hai davanti qualcosa che sembra completo. L'effort che hai speso è minimo, quindi la sensazione di investimento è bassa, quindi la soglia per dichiararlo fatto si abbassa. ",[37,300,301],{},"Non hai faticato per arrivare lì, quindi non senti il bisogno di proteggerti dall'errore di aver faticato invano.",[10,303,304],{},"Ma \"sembra completo\" e \"è corretto\" sono due cose diverse — e la velocità di produzione dell'AI ha reso quella distinzione più sottile che mai.",[118,306,307],{},[10,308,309],{},"Fermarsi non è perdere il vantaggio della velocità. È il momento in cui verifichi che quella velocità ti abbia portato nella direzione giusta.",[10,311,312],{},"Senza quel momento, stai solo andando veloce verso il posto sbagliato — e ci arrivi prima.",[23,314,316],{"id":315},"la-code-review-non-basta","La code review non basta",[10,318,319,320,158],{},"La risposta istintiva a tutto questo è: ",[98,321,322],{},"\"per questo c'è la code review\"",[10,324,325],{},"Ma la code review, così come è praticata nella maggior parte dei team, non risolve il problema che stiamo descrivendo.",[10,327,328,329,332],{},"La code review tradizionale è ottima per trovare bug sintattici, violazioni di convenzioni, problemi di sicurezza ovvi. È molto meno efficace per valutare se le ",[37,330,331],{},"decisioni architetturali sono corrette",", se il modello del dominio rispecchia la realtà, se le assunzioni implicite nel codice sono valide.",[10,334,335],{},"Con l'AI il problema si amplifica: il codice generato è sintatticamente inattaccabile. Il reviewer scorre, non trova niente che attivi i campanelli d'allarme standard, approva. Il problema concettuale che stava sotto passa indisturbato.",[10,337,338,339,342,343,346],{},"La code review utile in questo contesto non è ",[98,340,341],{},"\"questo codice è scritto bene?\""," — quella risposta è quasi sempre sì. È ",[98,344,345],{},"\"questo codice fa quello che dovrebbe fare nel contesto del dominio reale?\""," — e per rispondere devi avere la conoscenza del dominio che l'AI non ha, devi aver capito i requisiti abbastanza da sapere cosa verificare, devi aver lasciato che la soluzione sedimentasse abbastanza da poterla vedere con distacco critico.",[23,348,350],{"id":349},"il-debito-che-non-vedi","Il debito che non vedi",[10,352,353,354,158],{},"Il debito tecnico generato senza giudizio ha una caratteristica precisa: ",[37,355,356],{},"è silenzioso",[10,358,359],{},"Non si manifesta subito. Si accumula in decisioni prese per default dall'AI che non erano le tue decisioni — ma ora sono nel codice, e il codice è in produzione. In architetture che reggono il caso d'uso che hai descritto ma non quello successivo. In assunzioni implicite che l'AI ha fatto riempiendo i gap del tuo prompt con la media di quello che ha visto in training.",[10,361,362,363,366,367,370],{},"Ward Cunningham, che il termine \"debito tecnico\" lo ha inventato, intendeva qualcosa di specifico: il debito ",[98,364,365],{},"deliberato",", contratto consapevolmente per andare più veloci ora con l'intenzione di ripagarlo dopo. Non il debito ",[98,368,369],{},"accidentale",", quello che accumuli senza saperlo perché non hai capito abbastanza bene il problema.",[10,372,373],{},[37,374,375],{},"Il debito deliberato è uno strumento legittimo. Il debito accidentale è ignoranza capitalizzata.",[10,377,378],{},"Il vibe coding senza giudizio produce quasi esclusivamente debito accidentale. Perché la velocità impedisce la comprensione, e senza comprensione non puoi nemmeno scegliere consapevolmente di indebitarti — ti indebiti e basta, senza saperlo, senza poterlo quantificare, senza un piano per ripagarlo.",[10,380,381],{},"E quando emerge, emerge nel momento peggiore. Quando c'è trazione. Quando ci sono utenti reali. Quando il costo di sistemare è un ordine di grandezza superiore a quello che sarebbe stato all'inizio.",[118,383,384],{},[10,385,386],{},"Il conto arriva sempre. La velocità determina solo quanto in fretta lo accumuli.",[23,388,390],{"id":389},"la-velocità-è-un-mezzo","La velocità è un mezzo",[10,392,393],{},"L'AI nello sviluppo è straordinaria. La uso ogni giorno.",[10,395,396,397,400],{},"Ma la velocità non è il fine — è un mezzo. Il fine è costruire qualcosa che ",[37,398,399],{},"rispecchi la logica che avevi in testa",", che regga i casi limite del dominio reale, che qualcuno possa capire e modificare tra un anno senza maledire chi lo ha scritto.",[10,402,403],{},"Se la velocità ti impedisce di verificare che questo sia vero, non stai andando più veloce. Stai solo sbagliando più in fretta. Con più righe di codice. Con più fiducia. Con meno possibilità di accorgertene prima che diventi costoso.",[10,405,406,407,410,411,414],{},"La differenza tra un ingegnere che usa l'AI bene e uno che la usa male non è tecnica. ",[37,408,409],{},"È cognitiva."," È la capacità di fermarsi, lasciare che le cose sedimentino, tornare con distacco critico e chiedersi: questo rispecchia davvero quello che volevo? O sto guardando qualcosa che ",[98,412,413],{},"sembra"," quello che volevo?",[10,416,417],{},"Sono domande scomode da fare quando hai appena passato un pomeriggio produttivo e lo schermo è pieno di codice nuovo e i test passano.",[10,419,420],{},[98,421,422],{},"Falle lo stesso.",{"title":64,"searchDepth":65,"depth":65,"links":424},[425,426,427,428,429,430,431],{"id":132,"depth":65,"text":133},{"id":177,"depth":65,"text":178},{"id":229,"depth":65,"text":230},{"id":282,"depth":65,"text":283},{"id":315,"depth":65,"text":316},{"id":349,"depth":65,"text":350},{"id":389,"depth":65,"text":390},[433,71],"dev","https://i2.wp.com/enricodeleo.s3.eu-south-1.amazonaws.com/images/velocita-senza-giudizio.png","2026-04-03T10:00:00.000Z","Il vibe coding non ha inventato il codice scritto male. Ha solo tolto l'attrito. E la velocità, senza il tempo di valutare, produce solo errori più rapidi.",{},"/velocita-senza-giudizio",{"title":92,"description":436},"velocita-senza-giudizio",[71,442,86,443],"vibe-coding","build-in-public","e74faFiAYa-yRsNGy5Q3Uqn-nirr0LuwjyhnNHFfGw4",{"id":446,"title":447,"body":448,"categories":951,"coverImage":954,"date":955,"description":956,"extension":75,"legacy":76,"meta":957,"navigation":78,"path":958,"seo":959,"stem":960,"sticky":76,"tags":961,"updated":965,"__hash__":966},"articles/marketing-engineering-il-caos-non-scala.md","Marketing Engineering: mindset da developer per il business",{"type":7,"value":449,"toc":938},[450,455,459,468,471,486,492,498,509,518,523,532,535,539,542,556,563,569,573,579,587,590,593,610,614,620,626,637,646,650,653,658,661,675,678,682,688,691,702,708,712,715,735,738,756,766,770,780,783,794,797,808,813,817,823,826,837,840,851,854,858,870,873,887,896,900,903,912,915,932,935],[10,451,452],{},[98,453,454],{},"Caso reale: budget limitato, geografia \"a lentiggine\" e una domanda semplice solo in apparenza. In questo post racconto come ho trasformato quel caos in un processo decisionale operativo.",[23,456,458],{"id":457},"quando-il-problema-non-è-tecnico-ma-il-metodo-sì","Quando il problema non è tecnico, ma il metodo sì",[10,460,461,462,465],{},"Nel marketing complesso non basta il solo intuito.",[463,464],"br",{},[37,466,467],{},"Serve rigore operativo.",[10,469,470],{},"Per me significa due cose:",[472,473,474,480],"ul",{},[475,476,477],"li",{},[37,478,479],{},"non decidere a sensazione",[475,481,482,485],{},[37,483,484],{},"non delegare ciecamente alla piattaforma",", sperando che la sua AI ottimizzi da sola",[10,487,488,489],{},"La richiesta, in questo caso, era diretta: ",[37,490,491],{},"\"Abbiamo questa situazione, idee?\"",[10,493,494,495,497],{},"Sembra una domanda semplice.",[463,496],{},"\nIn realtà contiene tre problemi diversi:",[472,499,500,503,506],{},[475,501,502],{},"un problema di business (budget limitato)",[475,504,505],{},"un problema operativo (territorio frammentato)",[475,507,508],{},"un problema decisionale (come prioritizzare in modo razionale)",[10,510,511,512,514,515,158],{},"Quindi no: non era \"solo\" un tema di targeting.",[463,513],{},"\nEra un tema di ",[37,516,517],{},"allocazione sotto vincoli",[118,519,520],{},[10,521,522],{},"In una situazione così non serve il bazooka: servono proiettili d'argento.",[10,524,525,526,528,529,158],{},"Un chiarimento sul ruolo: non nasco come marketer operativo.",[463,527],{},"\nVengo coinvolto quando il tema marketing smette di essere solo execution e diventa un problema di ",[37,530,531],{},"allocazione, dati e qualità decisionale",[10,533,534],{},"In questo caso ho applicato criteri, ragionamenti e strategie che uso da anni in ambito tech/software: scomporre il problema, definire vincoli espliciti, progettare un processo replicabile e misurare ogni decisione.",[23,536,538],{"id":537},"_1-la-situazione-di-partenza-cosa-rendeva-il-problema-difficile","1) La situazione di partenza: cosa rendeva il problema difficile",[10,540,541],{},"Il contesto era questo:",[472,543,544,547,550,553],{},[475,545,546],{},"copertura reale limitata a micro-zone non continue",[475,548,549],{},"base clienti potenziale distribuita in modo irregolare",[475,551,552],{},"pressione a partire in fretta",[475,554,555],{},"budget non sufficiente per \"testare tutto\"",[10,557,558,559,562],{},"Io questa configurazione l'ho ribattezzata ",[37,560,561],{},"\"geografia a lentiggine\"",": a macchia di leopardo sarebbe stato già un lusso.",[10,564,565,566,568],{},"In pratica, ogni euro aveva costo opportunità alto.",[463,567],{},"\nSe lo mettevi nel posto sbagliato, non perdevi solo budget: perdevi tempo di apprendimento.",[23,570,572],{"id":571},"_2-perché-il-solo-intuito-non-bastava","2) Perché il solo intuito non bastava",[10,574,575,576,578],{},"L'intuito è utile, soprattutto nelle prime fasi.",[463,577],{},"\nMa qui c'erano due limiti strutturali:",[472,580,581,584],{},[475,582,583],{},"troppa variabilità geografica per ragionare \"a colpo d'occhio\"",[475,585,586],{},"troppi decisori con opinioni plausibili ma non confrontabili",[10,588,589],{},"Quando tutti hanno una buona ipotesi, il rischio è restare paralizzati o scegliere la voce più forte, non la scelta migliore.",[10,591,592],{},"Serviva quindi un criterio:",[472,594,595,600,605],{},[475,596,597],{},[37,598,599],{},"replicabile",[475,601,602],{},[37,603,604],{},"spiegabile al business",[475,606,607],{},[37,608,609],{},"traducibile in execution media",[23,611,613],{"id":612},"_3-perché-non-lasciare-tutto-alla-piattaforma","3) Perché non lasciare tutto alla piattaforma",[10,615,616,617,619],{},"Domanda legittima: \"non può pensarci la piattaforma con la sua AI?\"",[463,618],{},"\nIn parte sì. Ma con un costo.",[10,621,622,623,625],{},"Le piattaforme ottimizzano dopo aver visto abbastanza distribuzione.",[463,624],{},"\nQuella fase richiede volume, quindi budget. E nelle fasi iniziali può significare:",[472,627,628,631,634],{},[475,629,630],{},"dispersione",[475,632,633],{},"targeting troppo ampio",[475,635,636],{},"segnali rumorosi prima di convergere",[10,638,639,640,158,643,645],{},"Quando il budget è stretto, ",[37,641,642],{},"non puoi comprare apprendimento indefinito",[463,644],{},"\nDevi arrivare con una tesi iniziale più robusta.",[23,647,649],{"id":648},"_4-la-domanda-giusta-prima-della-tecnica","4) La domanda giusta prima della tecnica",[10,651,652],{},"Prima di parlare di ML, ho riformulato la domanda così:",[10,654,655],{},[37,656,657],{},"Come trasformiamo una geografia complessa in una lista ordinata di priorità di investimento?",[10,659,660],{},"Da qui derivano i requisiti del metodo:",[472,662,663,666,669,672],{},[475,664,665],{},"partire da dati realmente disponibili",[475,667,668],{},"gestire irregolarità e outlier",[475,670,671],{},"produrre output operativi, non solo analitici",[475,673,674],{},"mantenere la logica trasparente per il team",[10,676,677],{},"Solo a questo punto ha senso discutere di strumenti.",[23,679,681],{"id":680},"_5-dati-minimi-utili-il-vero-punto-di-leva","5) Dati minimi utili: il vero punto di leva",[10,683,684,685,158],{},"Il principio è semplice: ",[37,686,687],{},"dataset minimo utile prima, complessità dopo",[10,689,690],{},"Per questo caso bastavano:",[472,692,693,696,699],{},[475,694,695],{},"coordinate lat/lon dei punti servibili",[475,697,698],{},"eventuale peso commerciale per punto",[475,700,701],{},"vincoli operativi della piattaforma Ads (es. raggio minimo)",[10,703,704,705,707],{},"Non serviva un data lake.",[463,706],{},"\nServiva una base coerente per prendere decisioni migliori delle alternative manuali.",[23,709,711],{"id":710},"_6-dove-entra-ml-e-perché-qui-ha-senso","6) Dove entra ML (e perché qui ha senso)",[10,713,714],{},"Solo dopo il framing decisionale, ML e statistica diventano utili:",[472,716,717,723,729],{},[475,718,719,722],{},[37,720,721],{},"la statistica"," definisce la scala reale del problema (e protegge dagli outlier)",[475,724,725,728],{},[37,726,727],{},"il ML"," identifica pattern geografici non ovvi a vista",[475,730,731,734],{},[37,732,733],{},"il ranking"," trasforma l'analisi in priorità",[10,736,737],{},"Pipeline essenziale:",[739,740,741,744,747,750,753],"ol",{},[475,742,743],{},"stima scala locale con k-NN",[475,745,746],{},"clustering per densità con DBSCAN",[475,748,749],{},"metriche cluster (numerosità, dispersione, centroide, valore)",[475,751,752],{},"ranking delle aree per priorità investimento",[475,754,755],{},"traduzione in azione Ads (centroide + raggio operativo)",[10,757,758,761,763],{},[98,759,760],{},"Il punto non è usare ML \"per innovare\".",[463,762],{},[98,764,765],{},"Il punto è ridurre arbitrarietà nelle decisioni di budget.",[23,767,769],{"id":768},"_7-loutput-che-serve-davvero-al-business","7) L'output che serve davvero al business",[10,771,772,775,777],{},[37,773,774],{},"L'output utile non è una mappa bella da vedere.",[463,776],{},[37,778,779],{},"È una lista prioritaria argomentabile in riunione.",[10,781,782],{},"Per ogni area candidata:",[472,784,785,788,791],{},[475,786,787],{},"livello di priorità",[475,789,790],{},"razionale quantitativo",[475,792,793],{},"vincolo operativo per l'attivazione",[10,795,796],{},"A quel punto la discussione cambia:",[472,798,799,802,805],{},[475,800,801],{},"dove abbiamo maggiore densità utile?",[475,803,804],{},"dove il valore commerciale giustifica maggiore dispersione?",[475,806,807],{},"quanta quota di rumore siamo disposti ad accettare?",[10,809,810],{},[37,811,812],{},"Meno opinioni generiche, più trade-off espliciti.",[23,814,816],{"id":815},"_8-cosa-cambia-nel-modo-di-lavorare","8) Cosa cambia nel modo di lavorare",[10,818,819,820,822],{},"Il cambiamento non è solo tecnico.",[463,821],{},"\nÈ anche organizzativo.",[10,824,825],{},"Prima:",[472,827,828,831,834],{},[475,829,830],{},"ogni campagna riparte quasi da zero",[475,832,833],{},"criteri impliciti",[475,835,836],{},"forte dipendenza da esperienza individuale",[10,838,839],{},"Dopo:",[472,841,842,845,848],{},[475,843,844],{},"criterio esplicito",[475,846,847],{},"processo replicabile",[475,849,850],{},"iterazioni comparabili nel tempo",[10,852,853],{},"In sintesi: meno improvvisazione, più sistema.",[23,855,857],{"id":856},"_9-il-passo-successivo-testare-non-raccontare","9) Il passo successivo: testare, non raccontare",[10,859,860,861,158,864,866,867,158],{},"Questo approccio ",[37,862,863],{},"non promette scorciatoie",[463,865],{},"\nPromette una cosa più utile: ",[37,868,869],{},"ipotesi testabili",[10,871,872],{},"Prima di scalare, definisco sempre:",[472,874,875,878,881,884],{},[475,876,877],{},"metrica primaria",[475,879,880],{},"finestra di osservazione",[475,882,883],{},"criterio di successo/fallimento",[475,885,886],{},"regole di iterazione",[10,888,889,890,892,893,895],{},"Se conferma, si scala.",[463,891],{},"\nSe non conferma, si corregge.",[463,894],{},"\nIn entrambi i casi, si apprende.",[23,897,899],{"id":898},"il-mio-punto-di-vista","Il mio punto di vista",[10,901,902],{},"Quando un problema sembra insormontabile, spesso è solo poco strutturato.",[10,904,905,906,908,909,911],{},"Il caos non scala.",[463,907],{},"\nLe opinioni non scalano.",[463,910],{},"\nLe scorciatoie non scalano.",[10,913,914],{},"Scala un metodo:",[472,916,917,920,923,926,929],{},[475,918,919],{},"domanda giusta",[475,921,922],{},"dati minimi utili",[475,924,925],{},"statistica robusta",[475,927,928],{},"ML pragmatico",[475,930,931],{},"decisioni trasparenti",[10,933,934],{},"Per me, questo è Marketing Engineering: usare dati e metodo per prendere decisioni migliori, prima di spendere.",[10,936,937],{},"È per questo che mi piace il mio lavoro: prima la creatività, per esplorare davvero lo spazio del problema; poi il rigore scientifico, per trasformare intuizioni in decisioni solide e razionali.",{"title":64,"searchDepth":65,"depth":65,"links":939},[940,941,942,943,944,945,946,947,948,949,950],{"id":457,"depth":65,"text":458},{"id":537,"depth":65,"text":538},{"id":571,"depth":65,"text":572},{"id":612,"depth":65,"text":613},{"id":648,"depth":65,"text":649},{"id":680,"depth":65,"text":681},{"id":710,"depth":65,"text":711},{"id":768,"depth":65,"text":769},{"id":815,"depth":65,"text":816},{"id":856,"depth":65,"text":857},{"id":898,"depth":65,"text":899},[71,952,953],"Marketing","Data Science","https://i2.wp.com/enricodeleo.s3.eu-south-1.amazonaws.com/images/data-analaysis-ml-adv.png","2026-02-28T10:00:00.000Z","Quando il problema non è tecnico, ma il metodo sì: dati e AI pragmatica per scelte di marketing mirate, non a pioggia.",{},"/marketing-engineering-il-caos-non-scala",{"title":447,"description":956},"marketing-engineering-il-caos-non-scala",[962,963,964],"marketing","fractional-cto","growth","2026-07-08","m7llQDFtXq4KfCgtCQsJdnGhxbH-pGzSmuV5xCIJ_2k",1783466559986]