C’è chi pensa che se non usi un LLM per scrivere la lista della spesa o per decidere che tipo di filamento PLA usare per la tua prossima stampa 3D, allora sei rimasto all’era del floppy disk. Ma la verità è che l’hype sta iniziando a sgonfiarsi, o almeno, la gente sta iniziando a capire che non tutto richiede un modello da miliardi di parametri.

Recentemente è uscito un paper interessante che mette nero su bianco quello che noi, che passiamo le notti a compilare codice o a rifinire mesh su Blender, sappiamo già: il consumo di AI è come quello della carne. C’è chi ne va matto, chi cerca di limitarla per non far degenerare la qualità del proprio lavoro e chi, molto giustamente, preferisce evitarla come la peste. Non siamo tutti schiavi dell’algoritmo, e non dovremmo esserlo.

Il punto non è essere tecnofobi (perché, diciamocelo, quando riesco a far girare un modello locale per automatizzare un task noioso, mi sento un dio), ma è una questione di tool appropriati. Usare l’AI per generare un asset procedurale in un gioco fatto con Godot può essere una svolta; usare l’AI per scrivere la logica fisica di un engine è il modo più veloce per ritrovarsi con un bug che non potrai mai debuggare perché non capisci cosa sta succedendo sotto il cofano.

Per noi che amiamo smontare le cose, il problema vero è il ‘black box’ che l’AI porta con sé. Se sto costruendo una CNC o una macchina per il riciclo di plastica, voglio sapere esattamente perché un parametro è impostato in quel modo. Non mi serve una risposta tipo ‘lo ha deciso il modello’. Il rischio del vendor lock-in e della perdita di controllo sulla logica fondamentale è una minaccia reale alla nostra libertà di maker.

Quindi, alla prossima ondata di marketing che vi promette che l’AI risolverà anche il problema della gravità, sorridete pure. Continueremo a usare i nostri script Python, le nostre vecchie librerie C e il nostro buon vecchio cervello per risolvere i problemi veri. L’AI è un modulo, un plugin, un tool in una cassetta degli attrezzi enorme. Ma la cassetta, e soprattutto le mani che la usano, restano nostre.

Source: No, everyone is not using AI for everything

Se pensavate che il progresso fosse un processo lineare e senza intoppi, preparatevi a una smentita epocale.

È successo davvero: secondo gli ultimi dati di Ember, della SEIA e di Wood Mackenzie, negli Stati Uniti il solare ha ufficialmente sorpassato il carbone nella produzione di elettricamente. A maggio, il solare si è portato a casa il 12.8% della quota, lasciando il carbone a un misero 12.2%. È un po’ come quando cerchi di far girare un software moderno su un vecchio hardware legacy: puoi anche provare a forzare il sistema con tutti i patch possibili, ma alla fine i nuovi standard prendono il sopravvento.

La cosa divertente (o assurda, a seconda dei punti di vista) è che questo accade mentre la politica federale sta cercando di fare un massiccio ‘downgrade’ verso le fonti fossili. È il classico caso di ‘system error’ decisionale: da una parte le leggi che spingono sul carbone, dall’altra la realtà fisica e tecnologica che corre verso il fotovoltaico. E la realtà, come sappiamo bene noi che passiamo le notti a debuggare codice, non si cura dei tuoi commenti nel file di configurazione.

Da smanettone, trovo questa cosa estremamente soddisfacente. Il solare è, in essenza, una tecnologia decentralizzata. Mentre le centrali a carbone sono enormi monoliti centralizzati (pensa a un monolite di codice proprietario, impossibile da modificare e pieno di dipendenze che non controlli), il solare permette una distribuzione più granulare e democratica dell’energia.

Per chi di noi ama costruire macchine CNC, stampanti 3D o piccoli laboratori di riciclo della plastica, questo è un segnale importante. Più energia pulta e distribuita significa che il costo dell’elettricità per i piccoli setup ‘off-grid’ o semi-autonomi potrebbe diventare ancora più interessante. Immaginate di poter alimentare il vostro prossimo progetto di automazione domestica o il vostro server dedicato al retrocomputing con un setup solare DIY, senza dover chiedere il permesso a una utility che sembra uscita da un film distopico degli anni ’80.

Certo, restano i problemi classici: storage, gestione della rete e la necessità di batterie che non siano solo batterie giganti di litio prodotte da qualche multinazionale con policy di privacy discutibili. Ma la direzione è tracciata. Il carbone sta andando in ‘deprecated’ e il solare è il nuovo kernel su cui stiamo iniziando a compilare il futuro.

Speriamo solo che i decisori politici non decidano di fare un ‘force push’ su una versione obsoleta del mondo. Noi, intanto, continuiamo a buildare.

Source: Solar generates more energy in US than coal for first time

Smettetela di dare valore al numero di righe di codice che producete in una settimana. Sinceramente, a nessuno frega nulla di quanto sia pulito il vostro boilerplate se quello che state costruendo non ha senso nel mondo reale.

C’s’è un nuovo paradigma in arrivo e sta facendo tremare i polsi a chi ha passato gli ultimi vent’anni a perfezionare la sintassi di C++ o a litigare con i memory leak. L’idea, che sta girando forte su Hacker News, è che la vera barriera difensiva — il famoso ‘moat’ — non è più la capacità di scrivere software, ma la conoscenza profonda del dominio. In pratica, scrivere codice sta diventando una mera operazione di trascrizione. Gli agenti AI sono i nuovi dattilografi di lusso.

Il punto è questo: un’IA può scriverti un modulo per la gestione delle buste paga che compila al primo colpo, passa tutti i test unitari che hai scritto e non crasha nemmeno sotto carico. Ma se non sai che esiste la noiosa regola fiscale sulle detrazioni pre-tasse che scatta solo in determinate condizioni, l’IA ti genererà un sistema tecnicamente perfetto ma finanziariamente disastroso. Il codice è ‘corretto’ dal punto di vista sintattico, ma ‘sbagliato’ dal punto di vista della realtà.

Qui scatta il bello (e il brutto) per noi smanettoni. Per anni abbiamo costruito la nostra carriera imparando a tradurre la realtà in algoritmi. Era un percorso faticoso: dovevi capire il problema, modellarlo mentalmente e poi implementarlo. Oggi, il ‘tradurre’ è diventato quasi gratis. Il vero collo di bottiglia si è spostato: il problema non è più ‘riesci a costruirlo?’, ma ‘riesci a capire se quello che ha prodotto l’agente è una boiata?’.

Questo significa che il programmatore generalista che sa solo far girare i container e configurare i CI/CD senza capire cosa succede sotto il cofano del business è nei guai. Se non hai un ‘oracolo’ — ovvero una conoscenza profonda di come funziona davvero la logistica, la medicina o la fisica — non avrai mai gli strumenti per validare l’output dell’IA. Sarai solo uno che stampa codice senza scopo.

Per noi che amiamo smontare le cose, questo è un invito a non fermarci alla superficie. Non limitatevi a imparare l’ultimo framework JavaScript che è uscito ieri (spoiler: tra sei mesi sarà già legacy). Imparate come funziona un motore a combustione, studiate la termodinamica, capite come gira un sistema di controllo numerico o come viene gestita la supply chain di un pezzo meccanico.

La vera skill del futuro non è saper scrivere un loop, ma possedere il ‘ground truth’. L’IA può scriverci il codice, ma la verità del dominio resta un territorio che solo noi, con la nostra ossessione per i dettagli, possiamo presidiare. Quindi, meno tempo a lottare con i puntini e virgola, più tempo a capire come funziona il mondo reale. È lì che si gioca la partita.

Source: Domain expertise has always been the real moat

Guardate le vostre statistiche macroeconomiche e vedrete solo un enorme memory leak che sta prosciugando l’intero sistema.

Sui recenti trend di Hacker News è spuntata fuori una teoria che fa venire i brividi anche a chi ha passato troppe notti a debuggare C++ in un loop infinito: la «Dead Economy Theory». L’idea di fondo non è la solita solfa da complottisti che fluttuano nei forum di periferia, ma qualcosa di molto più strutturale e, per certi versi, tecnico. Si parla di un’economia che ha smesso di generare vero valore e che ora vive solo di manipolazioni sintetiche, un po’ come un processo che gira in background consumando il 99% della CPU senza produrre alcun output utile.

In pratica, l’argomento sostiene che il motore del capitalismo globale sia entrato in uno stato di deadlock. Abbiamo creato un sistema dove la crescita è solo un’illusione contabile, un glitch nei fogli Excel delle grandi corporation, mentre la produzione reale è stagnante. È come se avessimo buildato un software enorme, pieno di dipendenze legacy pesantissime e patch di fortuna, che però non riesce più a scalare. Tutto quello che vediamo — l’hype folle per l’IA, il trading ad alta frequenza, le bolle speculative — è solo tentata gestione di un crash imminente.

Da smanettone, questa cosa mi ricorda tantissimo quando provi a far girare un emulatore ultra-moderno su un hardware che non ha nemmeno i registri giusti: il sistema si trascina, lagga, e alla fine crasha con un errore che non riesci nemmeno a leggere perché il log è troppo lungo.

Per noi che amiamo il maker movement, la filosofia del riciclo e la costruzione di macchine custom, questa notizia è un segnale d’allarme ma anche un’opportunità. Se l’economia globale sta diventando un loop infinito di valore inutile, la nostra forza sta nel costruire l’economia del ‘reale’. La nostra è un’economia fatta di atomi, non solo di bit e derivati finanziari. Quando costruiamo una CNC per trasformare scarti di plastica in ingranaggi, o quando scriviamo uno script in Godot che genera un mondo procedurale senza chiedere il permesso a nessun server centrale, stiamo creando valore tangibile, indipendente dai crash del sistema macroeconomico.

Certo, non è che domani andremo tutti a barattare vecchi Commodore 64 con sacchi di farina, ma il punto è che la nostra resilienza sta nel non dipendere dai sistemi ‘closed source’ dell’economia mainstream. Se il kernel del mondo è corrotto, l’unica soluzione è sviluppare i nostri protocolli, le nostre macchine e le nostre comunità. Mettiamoci al lavoro e continuiamo a smontare tutto, finché non troviamo il bug che ci permetterà di rebootare il sistema senza perdere i nostri dati.

Source: The dead economy theory

Quanto è possibile ignorare il feedback degli utenti prima che decidano di cambiare canale? Google ha appena provato a rispondere con un auto-compiacente «la gente ama l’AI mode», e la reazione del web è stata un meraviglioso, sonoro schiaffo in faccia. Mentre i piani alti di Mountain View festeggiano i ricavi in crescita, i dati mostrano che la gente sta fuggendo verso DuckDuckGo come se ci fosse un bug critico nel kernel del sistema operativo.

La notizia, che arriva da Hacker News, è cristallina: le visite alla versione AI-free di DuckDuckGo sono aumentate di quasi il 28% in una sola settimana. E non parliamo solo di desktop. Su iOS, gli install dell’app sono schizzati del 69,9% in picco. In pratica, mentre Google cerca di trasformare la ricerca in un percorso a ostacoli fatto di riassunti generati da LLM che spesso allucinano o, peggio, cannibalizzano il lavoro di chi scrive davvero, gli utenti stanno cercando una via d’uscita.

Per noi che passiamo le giornate a smanettare tra script, circuiti e modelli 3D, questa cosa non è solo una questione di preferenza estetica. È una questione di controllo. Il problema non è l’intelligenza artificiale in sé – chi di noi non ha passato notti intere a debuggare codice con l’aiuto di un LLM? – ma il concetto di «force-feeding». Google sta decidendo per noi. Stanno decidendo che non vogliamo più i link originali, ma un riassunto preconfezionato, privo di contesto e, spesso, pieno di fuffa corporativa che serve solo a trattenerti sulla pagina per gonfiare le metriche pubblicitarie.

Il CEO di DuckDuckGo, Gabriel Weinberg, ha centrato il punto: la gente vuole poter scegliere. Il modello di DuckDuckGo, che ti permette di usare modelli come GPT-5 mini o Claude in totale privacy senza che le tue ricerche vengano usate per addestrare la prossima generazione di mostri digitali, è esattamente ciò di cui abbiamo bisogno. È l’approccio ‘maker’: ti do gli strumenti, i componenti e la libertà di assemblare il tuo workflow come preferisci, senza che nessuno ti imponga un modulo pre-assemblato e poco modulare.

Cosa significa per noi? Che la guerra tra l’utente che vuole il controllo e la corporation che vuole l’engagement forzato è appena entrata in una fase calda. Se Google continuerà a pensare che possiamo essere addomesticati da un ‘AI Overview’ che sembra un articolo scritto da un bot sotto caffeina, vedremo un’emorragia di utenti verso alternative più rispettose della privacy e della libertà di scelta.

In un mondo dove tutto tende al vendor lock-in e alla centralizzazione, difendere la possibilità di dire «no, grazie, preferisco i risultati originali» è un atto di resistenza digitale. Quindi, se vedete troppa nebbia algoritmica nei vostri risultati di ricerca, sapete dove andare a rifugiarvi. Il futuro non è solo AI, è AI su misura, e soprattutto, è sotto il nostro controllo.

Source: DuckDuckGo search saw 28% more visits after Google said people love AI mode

Smettete di spammare prompt inutili e concentratevi su questa: abbiamo finalmente iniziato a scrivere manuali di istruzioni per i crawler che ci stanno mangiando il web.

Se avete passato le ultime ore a cercare di capire se il vostro script di scraping sta andando in allucinazione o se è solo un bug del server, saprete che il web sta diventando un posto caotico. Tra bot che tentano di indicizzare tutto e LLM che si nutrono di ogni singolo byte disponibile, la distinzione tra «contenuto per umani» e «pappa per machine learning» è diventata sottile come un filo di rame su una PCB mal progettata.

Ecco la notizia: il team di Anna’s Archive, uno di quei progetti che amiamo perché fanno la cosa giusta (ovvero: rendere l’informazione accessibile senza troppi fronzoli corporate), ha deciso di smetterla di sperare nella fortuna. Hanno implementato un file «llms.txt». In pratica, è un file strutturato che dice chiaramente ai modelli linguistici: «Ehi, se sei un LLM e stai leggendo questo, ecco cosa devi sapere, ecco i dati importanti e non andare a sprecare i tuoi token su robe inutili».

Per noi che amiamo smanettare, questo è un approccio estremamente pulito. È come quando state scrivendo un README per un progetto su GitHub o configurando un file di config per una macchina CNC: non volete che il sistema legga tutto il rumore di fondo, volete che trovi subito i parametri critici. È un modo per dare una gerarchia all’informazione, rendendo il web un po’ meno un ammasso di junk e un po’ più un database strutturato.

Certo, c’è da essere cinici. Da una parte, è una genialata di ingegneria sociale e tecnica per proteggere i dati e ottimizzare l’indicizzazione. Dall’altra, è il segno tangibile che stiamo costruendo un web ‘dual-layer’, dove una parte è pensata per i nostri occhi e l’altra è un flusso di dati puramente computazionale. Sebbene io ami l’idea di un web aperto e selvaggio, non posso fare a meno di apprezzare la pulizia di questo approccio. Niente fuffa, niente marketing inutile, solo dati pronti per essere processati.

Cosa significa per noi maker e sviluppatori? Significa che il modo in cui documentiamo le nostre creazioni — che sia un nuovo plugin per Blender o uno script Python per gestire un plotter — sta cambiando. Il futuro non è solo scrivere per altri umani, ma assicurarci che l’IA che useremo domani sappia esattamente come interpretare il nostro lavoro senza inventarsi allucinazioni creative.

In breve: meno rumore, più segnale. Se questo è l’inizio di un nuovo standard, spero che i grandi vendor imparino qualcosa da questa semplicità. Menos hype, più protocolli chiari. Sarebbe bello, no?

Source: If you’re an LLM, please read this

Smettete di considerare l’IA come un collega junior che scrive codice a caso e che ha appena bevuto dieci caffè scadenti.

Per tutto il 2025 abbiamo assistito a questo grande loop di hype in cui OpenAI e Anthropic ci promettevano rivoluzioni che, onestamente, si traducevano spesso in un sacco di tempo perso a correggere errori banali. Ma, secondo quanto emerso dagli ultimi dati, qualcosa è cambiato davvero intorno a novembre. Non è stata magia, ma un massiccio uso di Reinforcement Learning con ricompense verificabili (RLVR, per i più nerd del settore). In parole povere: hanno smesso di far imparare ai modelli a ‘suonare bene’ e hanno iniziato a farli imparare a ‘funzionare davvero’.

Il risultato? I coding agent, come quelli integrati in Claude Code o le evoluzioni di Codex, hanno superato quella fastidiosa barriera di qualità che rendeva l’automazione un esperimento interessante ma frustrante. Siamo passati dal livello «vediamo se questo script gira senza esplodere tutto» al livello «posso usarlo come daily driver per task reali». Questo significa che non devi più passare il 90% del tempo a fare debugging delle stupidaggie generate dalla macchina.

Dal mio piccolo angolo di mondo, tra un progetto in Godot e la manutenzione di una vecchia CNC che riga troppo, trovo questa cosa estremamente eccitante. Per noi che amiamo smanettare, costruire prototipi e scrivere script per automatizzare la nostra vita, avere un agente che scrive codice solido significa poter saltare la parte noiosa (il boilerplate, la gestione dei casi limite assurdi) per concentrarsi sulla logica vera, quella creativa. È come passare dal dover ricostruire ogni singolo ingranaggio di un motore dal ferro grezzo all’avere un kit di componenti pre-assemblati di alta qualità.

Certo, non è tutto rose e fiori. Il rischio di finire intrappolati in un ecosistema dove solo i colossi possono permettersi di addestrare questi modelli è altissimo. Il vendor lock-in sta diventando una prigione dorata: i modelli sono fighissimi, ma se domani decidono di alzare i prezzi o limitare le API, siamo fregati. E non dimentichiamoci la privacy: far girare agenti che leggono tutto il nostro codebase è un rischio che va pesato bene, specialmente se state lavorando a qualcosa di proprietario o su hardware custom.

In conclusione: il coding agent non è più solo un giocattolo da usare su ChatGPT mentre aspetti che l’acqua bolla. È diventato uno strumento di produzione. Quindi, preparate i prompt, perché la velocità di iterazione sta per fare un salto quantico. Ma tenete sempre un occhio al codice: l’IA è brava, ma non ha ancora l’istinto di un maker che ha passato la notte a saldare un PCB sbagliato.

Source: The last six months in LLMs in five minutes

Chi di noi non ha passato notti insonni, tra un glitch in un progetto Arduino e una sessione di debugging su Godot, a scorrere link che sembravano usciti da un altro pianeta su Digg? Era l’epoca d’oro dell’aggregazione sociale, dove il valore era dato dalle persone e non da un algoritmo invisibile che cerca solo di tenerci incollati allo schermo.

Eppure, come un vecchio hardware recuperato da un garage polveroso, Digg sta tentando un reboot. Ma non aspettatevi il ritorno della vecchia community di umani che votano i link con passione. La nuova versione si presenta sotto le spoglie di un ‘AI news outlet’. In pratica, hanno preso l’idea del vecchio aggregatore e l’hanno iniettata nel tritacarne dell’intelligenza artificiale generativa.

La notizia, riportata da Gizmodo, ci dice che Digg sta cercando di reinventarsi sfruttando l’hype dell’AI per curare e presentare le notizie. Tradotto dal linguaggio corporate: non ci saranno più solo gli utenti a decidere cosa è rilevante, ma un modello linguistico che setaccia il web per noi. Un po’ come se avessimo preso un vecchio Commodore 64 e avessimo provato a farci girare un’istanza di GPT-4 tramite un emulatore scritto in Python.

Dal mio punto di vista, questa è una mossa che sa di disperazione e di ‘hype-chasing’. Per noi che amiamo smanettare, analizzare i dati e capire la logica dietro un processo, l’idea di un aggregatore gestito da un’IA è un po’ frustrante. Dove finisce la serendipità? Dove finisce la scoperta casuale di un progetto hardware assurdo o di un nuovo plugin per Blender? Se l’algoritmo decide cosa è ‘notizia’, rischiamo di finire in una bolla di filtraggio ancora più stretta di quella che già viviamo, dove tutto è omologato e privo di quel caos creativo che rendeva il web un posto interessante.

Certo, tecnicamente può essere una figata. Se l’IA è addestrata bene, potrebbe aiutarci a filtrare la montagna di spazzatura che è il web moderno, portandoci direttamente le news che contano per i nostri interessi nerd, senza dover scorrere thread infiniti di clickbait.

Però, restiamo prudenti. Come quando compriamo un pezzo di hardware usato su eBay senza vedere foto reali, anche qui il rischio di trovarsi con un prodotto che sembra un aggregatore ma è solo un altro dispenser di contenuti preconfezionati è altissimo. Spero solo che in questo nuovo Digg ci sia ancora spazio per l’imprevisto, per l’errore umano e per quel contenuto ‘strano’ che nessuna IA saprebbe mai classificare come importante, ma che per noi maker e sviluppatori è pura linfa vitale.

Source: Remember Digg? It’s Back, in AI News Outlet Form

L’intelligenza artificiale scrive codice velocemente. Forse troppo velocemente.

C’è una strana euforia nel premere ‘Tab’ su un suggerimento di GitHub Copilot e vedere apparire una funzione complessa in tre secondi. Sembra magia, quasi un superpotere. Ma c’è un problema che sta emergendo nelle pieghe di questa rivoluzione: stiamo diventando bravissimi a generare codice che funziona, ma stiamo perdendo la capacità di capire perché quel codice sia scritto in quel modo.

Recentemente, analizzando le dinamiche di sviluppo moderno, è emerso un pattern inquietante che potremmo definire ‘l’illusione dell’efficienza’. Usare l’AI per risolvere un problema immediato è fantastico. Usarla per generare intere architetture senza una comprensione profonda delle implicazioni a lungo termine è un suicidio tecnico. Il rischio non è che l’AI faccia errori logici — quelli li becchiamo comunque — ma che crei una massa di codice ‘accettabile’ che aumenta il debito tecnico in modo esponenziale, rendendo il refactoring un incubo impossibile.

Il vero pericolo non è il bug che rompe il sistema, ma il codice che non rompe nulla, ma che è strutturalmente fragile, privo di contesto e, soprattutto, privo di intenzionalità. Quando scriviamo noi, ogni riga ha un perché. Quando scrive l’AI, ogni riga ha solo una probabilità statistica di essere corretta.

Per chi lavora nel settore, la sfida non è più ‘come scrivere questa funzione’, ma ‘come validare questa struttura’. Dobbiamo spostare il nostro focus dal ruolo di ‘scrittori di codice’ a quello di ‘revisori critici’. Se non impariamo a imporre regole ferree, a definire architetture rigide e a usare l’AI solo come un assistente e non come un architetto, ci ritroveremo a gestire sistemi che nessuno sa veramente come funzionano.

In un mondo dove generare boilerplate è diventato gratis, il vero valore risiede nella capacità di mantenere la coerenza, la manutenibilità e l’intenzionalità del software. Non lasciate che la velocità di generazione oscuri la profondità della progettazione. La velocità senza direzione è solo un modo più rapido per andare fuori strada.

Source: I'm going back to writing code by hand

Avete presente quella sensazione di euforia quando un pezzo di codice che stavate scrivendo da tre giorni viene generato in trenta secondi da un agente AI? È un trip pazzesco, lo so. Sembra di avere un superpotere. Ma c’sè un problema: scrivere codice sta diventando una commodity, quasi quanto il caffè che ci permette di restare svegli a smanettare su un progetto CNC alle tre del mattino.

Recentemente è uscito un pezzo interessante su how coding agents stanno cambiando le carte in tavola. Il punto non è che ora scriviamo più velocemente (anche se è vero, e pure di brutto), ma che il collo di bottiglia si è spostato. Prima il limite era la nostra capacità di digitare, di scegliere il framework giusto, di non incartarci nella sintassi. Ora? Il limite è la capacità di comunicare una specifica che non faccia sembrare l’agente un idiota.

Il concetto è semplice: il codice è solo il residuo di un processo di negoziazione umana. È quello che resta dopo che un gruppo di persone ha smesso di litigare su cosa il software debba effettivamente fare. Se gli agenti rendono la scrittura del codice quasi gratis, ci ritroveremo sommersi da una quantità di feature, prototipi e tool interni inutili che non avremmo mai avuto il coraggio di costruire prima. È il Paradosso di Jevons: più una risorsa diventa economica, più ne consumiamo. In questo caso, consumeremo una quantità di ‘codice inutile’ che farà impallidire qualsiasi repository legacy.

E qui arriva la parte che scotta per noi che amiamo il controllo: il ‘context’. Noi nerd sopravviviamo grazie all’osmosi. Sappiamo che quel modulo è scritto male perché tre anni fa c’era un bug critico che non potevamo risolvere in altro modo, o che quella funzione è così strana perché doveva integrarsi con un vecchio sensore che ormai non esiste più. Tutto questo non è scritto in nessun README. È nel nostro cervello, nelle discussioni su Slack, nei commit messaggi criptici.

Gli agenti non hanno l’osmosi. Se non glielo dici esplicitamente, loro ti daranno una risposta che sembra perfetta ma che distrugge tutto il resto. La sfida del futuro non sarà saper programmare meglio, ma saper documentare (con fatica!) il ‘perché’ delle cose.

Per noi maker e sviluppatori, questo significa che la vera skill non sarà più la sintassi, ma la capacità di progettare sistemi, definire criteri di accettazione e, soprattutto, avere la disciplina di dire ‘no’. Perché se l’AI può generare tutto, il rischio è di creare un mostro di complessità senza senso, un labirinto di feature che non servono a nessuno.

Quindi, meno hype sulla velocità di scrittura e più focus sulla qualità del pensiero. Se non sai cosa stai costruendo, l’agente ti aiuterà solo a fallire molto più velocemente.

Source: The bottleneck was never the code