Controllare le idee è veramente più importante di guardare il codice?

@kevinthomaj 13 luglio 2026 10

Migliore youtuber italiano su questi argomenti a mani basse! Continua cosi! Sarebbe bello una live di discussione tranquilla tra te e antirez su questi argomenti per capire meglio entrambi i punti di vista

@andrearomano1641 13 luglio 2026 12

Anch’io ho storto un po’ il naso ascoltando il video di Antirez e sono molto d’accordo sul problema di chi pilota l’IA: credo che la visione di Sanfilippo sia inevitabilmente condizionata dalla sua enorme esperienza. È un po’ come un insegnante che, dopo aver spiegato per anni la stessa materia, la percepisce ormai come naturale e tende ad aggiungere sempre più complessità e sfumature, mentre gli studenti stanno ancora cercando di costruire le basi. Per lui il C, il funzionamento dei sistemi e la progettazione dell’architettura sembrano quasi una seconda natura: fondamenta già solide sulle quali può tranquillamente costruire servendosi degli agenti. Il problema è che pochissime persone possiedono la sua expertise. Forse in futuro conterà molto meno conoscere le sfumature di un linguaggio specifico, ma DSA, architetture e trade-off secondo me resteranno fondamentali. Magari avremo meno programmatori, ma più preparati. In ogni caso, sarà un peccato perdere il modo di programmare di persone come Tsoding.

3 risposte

@esadecimale Autore 13 luglio 2026 4

Non penso le perderemo persone come Tsoding, sono già in buona parte tagliate fuori dall'industria ma continuano ad esistere nel contesto del "recreational programming". Un contesto a suo modo da proteggere. Io stesso onestamente continuerò ad insegnare anche a mano il codice perché penso sia ancora molto utile, oltre ad essere divertente :) Ma non sono minimamente contro l'AI in generale, ed anzi sono tool molto utili. Bisogna capire cosa ha senso insegnare e cosa ha meno senso insegnare, ma onestamente questo anche prima dell'AI. E non rifarei tutto in funzione dell'AI perché l'essere umano ha bisogno di tempi di apprendimento non banali.
@andrearomano1641 13 luglio 2026 2

@esadecimale Alla fine penso che chi ha davvero questa passione continuerà comunque a voler vedere cosa c’è sotto il cofano. I vibe coder e i progetti realizzati con un prompt fanno scalpore, ma questi sistemi esistono per l’uomo e con l’uomo: qualcuno dovrà gestire l’infrastruttura, comprenderne i limiti e assumersi la responsabilità dei sistemi critici. Fatico a immaginare che si possa far funzionare qualcosa di importante senza sapere minimamente cosa ci sia dentro. Forse, prima ancora di scegliere cosa insegnare, bisognerebbe aiutare chi inizia a capire in quale direzione vuole andare. All’inizio ci si perde facilmente in domande poco utili, facendosi mille seghe mentali su cose come “qual è il linguaggio migliore?”. E dato che, andando avanti, le diramazioni diventano infinite, avrebbe senso insegnare anche a non perdersi nei rabbit hole. Personalmente apprezzo molto The Odin Project: è testuale, rimanda a molte fonti, evita la tutorial hell e ti costringe a costruire progetti. Piccola sviolinata finale: anche se oggi sto seguendo The Odin Project e università, sono abbonato alla tua piattaforma dal primo giorno. La mentalità che porti è proprio quella che mi ha fatto appassionare all’informatica: curiosa, concreta, hacker e senza gatekeeping. Giusto per dire che stimo davvero molto il tuo lavoro e penso faccia bene alla comunità.
@esadecimale Autore 13 luglio 2026 1

@andrearomano1641 ti ringrazio. Mi hai dato degli ottimi spunti :)

@thezar86 14 luglio 2026

Ciao. Innanzitutto tanti complimenti per il canale e per il modo in cui ti esprimi. Mi sembra che il discorso di Antirez fili e non vedo contraddizioni tra il "controllo delle idee" e lo sviluppo completamente automatico. Lo sviluppo automatico è un discorso di scrittura, aggiornamento e gestione delle linee di codice (così come già avviene con il versionamento, la fase CI/CD, e altro). Semplicemente questa automazione si è estesa anche alla scrittura del codice stesso, grazie agli LLM. Questa potenza libera energie all'uomo/creatore di progetti, che però deve necessariamente riaddattare il proprio ruolo. Non so se è questo che intende Antirez, ma io sono convinto che questo "shift upwards", questo salto verso la programmazione ancora più ad alto livello sia da un lato una liberazione di energie per lo sviluppatore e dall'altro, soprattutto, avvicini lo sviluppatore a quello che è il nucleo irriducibile del suo lavoro: l'ideazione e la progettazione pura.

@linusgates555 14 luglio 2026 2

salvatore per me sbaglia alla grandissima qui 🤔, l'ai bisogna usarla solo come supporto ad idee, stratagemmi o come le si vuol chiamare, per arricchire ulteriormente la qualità del software. Questa è una questione da discutere a tavolino!

@massimocolombo1973 13 luglio 2026

Non ho le competenze per poter giudicare in modo critico i due punti di vista. Forse la visione di Salvatore è più uno sguardo verso il futuro prossimo ? A questo ritmo i modelli arriveranno in pochissimo tempo a creare codice inarrivabile per qualsiasi sviluppatore, quindi non è forse più utile concentrarsi su idee di valore invece di perdere tempo a scoprire tra le mila e mila righe quella riga che fa storcere il naso ? questo non significa far uscire codice pattume, significa solo usare gli strumenti a disposizione anche per i test e le validazioni in modo sensato.

@DonataRella 13 luglio 2026 2

A me sembra sempre la stessa questione di base Un conto è antirez o tu o programmatori con competenza Un conto è in mano a me Ma il punto sono i junior developer o i futuri programmatori Gente come te e antirez avete esperienza di programmazione e sapete come istruire llm Se uno non ha anni o decenni di esperienza non sa come gestire "le idee" e l'architettura del software Io credo per ora magari in futuro cambierò idea alla luce di nuove nozioni che ora mi mancano Cmq credo che se uno non programma per anni o decenni in modo professionale non sarà in grado di gestire o istruire gli llm Come karate kid metti la cera togli la cera😂

@caseuniche 13 luglio 2026 2

Ciao 😊 io ho mandato il link di questo video ad Antirez, perché secondo me avete detto cose complementari. Grazie per quello che condividi 😊

1 risposta

@esadecimale Autore 13 luglio 2026

Ti ringrazio per il pensiero!

@mattmezza 14 luglio 2026

La questione è se leggere TUTTO il codice o no. È ovvio che voglio capire cosa sta facendo il modello. Ovvio che voglio rendermi conto della direzione che ha preso. È altrettanto ovvio che non voglio fare la review di parti su cui tanto so che il modello non sgarra. Se lo faccio a manella è perdita di tempo e opportunità/costo. Se lo faccio fare al maggiordomo è perdita di energia/token.

2 risposte

@esadecimale Autore 14 luglio 2026 1

Sono d'accordo con utilizzare delle valutazioni di rischio e criticità per capire cosa e quanto analizzare, sempre in funzione del prodotto che si sta sviluppando.
@mattmezza 14 luglio 2026

@esadecimaleesattamente Cioè, io alla 10ma volta che leggevo PR fatte da Fable o GPT 5.6 mi sono letteralmente accorto di quanto fosse subottimale focalizzarsi sui dettagli rispetto a spendere più tempo nel dare direzioni migliori e più sensate al modello prima di implementare.

@loenard27c 20 luglio 2026

Non mi trovo troppo d’accordo con Salvatore in questo caso. Il primo motivo è che mi sembra che la sua posizione sia troppo influenzata dalle sue conoscenze e capacità sopra la media. Il secondo motivo è che le idee sono si la chiave della riuscita di un buon software, soprattutto nell’era dell’IA, ma molte volte le idee si schiariscono e migliorano proprio programmando e toccando con mano. Dunque trovo difficile uno abbia già le idee corrette fin da subito, in più delegare tutta la scrittura e la revisione del codice all’IA non provoca quella “revisione “ continua che tende a migliorare il progetto.

@antoniogalvano9957 13 luglio 2026 2

Secondo me non siete in contraddizione. Hai solo approfondito alcuni aspetti che secondo me lui dava per sottointesi per brevità.

@paolo.achdjian 14 luglio 2026 1

Se non possiamo "fidarci" del codice generato dall'AI perchè dobbiamo fidarci del codice generato dai compilatori ? Sono 2 tool simili uno compila da linguaggio umano ad un altro codice e l'altro dal C al codice macchina (che è ad un livello ancora più basso dell'assembler). Anche scrivere in C equivale a scrivere una idea che poi viene tradotta in linguaggio macchina. Per non parlare poi scrivere in javascript o in un linguaggio ad un più alto livello. Eppure nessuno parla (più) di dovere imparare come scrivere in linguaggio macchina per essere un bravo programmatore. A mio parere il concetto di Antirez è proprio lo stesso passaggio da scrivere in assembler in C, JS. Più che educare a scrivere nel formalismo logico le nostre idee dovremmo educare i giovani programmatori ad esprimere correttamente i concetti in modo che poi LLM possa trasformali correttamente senza ambiguità. Forse il problema è che fa sentire inutile tutti gli anni passati a formarci. Non ci fa sentire più superiore alla gente "normale" che non è in grado di trasformare in formalismo le proprie idee. Forse anche ci viene tolta qualche scusa sui nostri errori o mancanza di idee

14 risposte

@matteo679 14 luglio 2026 4

> Se non possiamo "fidarci" del codice generato dall'AI perchè dobbiamo fidarci del codice generato dai compilatori ? Semplice perché, mentre gli LLM rimangono comunque, di fondo, algoritmi stocastici, i compilatori sono algoritmi deterministici. LLM e compilatori non possono essere paragonati.
@paolo.achdjian 14 luglio 2026

@matteo679 Sembra che per te i compilatori non hanno bug. Purtroppo li hanno (busta leggere le release note del gcc per capire quanti bug hanno). Però ti fidi. E non ti interessa neanche capire cosa generano. Perchè invece non ti fidi dei coding agent e anzi vuoi capire cosa generano ? Forse perchè quello che genera un compilatore non lo capisci mentre quello che genera l'LLM lo capisci ? Quindi forse non è un problema di avere fiducia o non in quello che genera ma che tu lo capisca o no. Entrambi (LLM e compilatore) possono generare codice sbagliato ma si è deciso che solamente il compilatore merita fiducia mentre LLM no. E questo sulla base di cosa io sia in grado di controllare oppure no.
@esadecimale Autore 14 luglio 2026

1. Sentirsi superiori o migliori è una cosa sbagliata a prescindere e non c'entra con la discussione tecnica 2. LLM e compilatori sono tecnologie diverse con caratteristiche diverse. La prima è stocastica, la seconda è deterministica. 3. Per essere bravi programmatori devi internalizzare dei concetti in modo formale e strutturato. Questo necessita arrivare a qualche livello di formalità, che può essere il C, l'assembly, o un linguaggio formale custom. Il linguaggio naturale è troppo ambiguo per fornire la struttura necessaria per imparare seriamente l'informatica
@samuelepadoan4993 14 luglio 2026 1

@paolo.achdjian A parte il fatto che gli LLM non sono deterministici, e lo hanno già scritto... I compilatori convertono un linguaggio, per esempio il C, in un altro linguaggio EQUIVALENTE. La logica della computazione non viene toccata dal processo di compilazione. Se il compilatore ha dei bug ed altera in modo errato la computazione il bug è comunque fixxabile e ricompilando il tutto viene risolto, l'LLM non è determinisito e per ogni input uguale può produrre codice diverso e soprattutto che produce una computazione diversa. Sono 2 cose completamente diverse anche perché come ha scritto @esadecimale il compilatore converte un linguaggio formale in un altro, mentre l'LLM deve convertire un linguaggio naturale che per definizione è ambiguo ...
@paolo.achdjian 14 luglio 2026

@samuelepadoan4993 forse non ha capito il senso del mio discorso: nel momento che tu compili non sai a priori se il risultato sarà corretto o ci sarà un bug. Certo con lo stesso codice ci sarà sempre lo stesso bug, ma questo non cambia il fatto che ci sia un bug e quindi in quel momento non puoi essere sicuro che il risultato sia corretto. Dove corretto non vuol dire riproducibile ma che faccia quello che tu voglia che faccia. Il punto è che quando programmi hai specifiche e quello che vuoi è che il programma (classe, funzione, modulo, libreria, etc) faccia quello che voglia, indipendentemente da come lo scrivi. Da cui la necessità dei test. Da questo punto di vista, LLM o compilatore sono la stessa cosa: nessuno ti da la sicurezza che LLM e il compilatore rispettino le specifiche. Però di uno ti fidi dell'altro no. Di uno vuoi vedere cosa fa dell'altro no.
@paolo.achdjian 14 luglio 2026 1

@esadecimale Per essere dei bravi programmatori devi fare un programma che risponda alle specifiche. Lo scopo è fare un programma che funzioni (compressa tutta la parte di manutenzione, etc) Tutto il resto sono tecniche necessarie perchè fino ad oggi eri obbligato a "internalizzare dei concetti in modo formale e strutturato" Se ci pensi, non è sufficiente sapere scrivere bene il codice, lo sapere scrivere il codice che risponda alle specifiche. Infatti i concetti che usi per un linguaggio ad alto livello, sono ben diversi da quelli che usi per l'assembler. Da una parte hai per esempio classi, dall'altra registri. Però puoi fare programmi in entrambi i modi. E non pensare che per programmare bene con l'LLM non serva disciplina. Devi sapere esprimere bene le specifiche. Capire i buchi e riempirli prima che li riempa LLM come vuole lui.
@tiziofalzonii 14 luglio 2026

citando torvalds mentre scrivi in C puoi immaginare subito come verrá il codice macchina dopo la compilazione, questo non puoi farlo con gli llm, oltre a questo un compilatore non si mette a chiamare tool, eseguire comandi o a toccare file lasciandoti all'oscuro di tutto, non sono scenari comparabili, tu ti faresti impiantare un peacemaker sapendo che il firmware é stato interamente vibecodato e il codice non é stato neanche revisionato?
@paolo.achdjian 14 luglio 2026

@tiziofalzonii non sono così sicuro che anche torvalds sia in grado di immaginare il livello di ottimizzazione che viene applicato ad un programma in C (non banale ovviamente). E suprattutto in codice macchina (non assebler dove i mnemonici autano ). Solo numeri esadecimali. Comunque. Anche se fosse ? Tutti gli altri che non sono in grado in ogni caso non sanno cosa fa il compilatore nè cosa genera. Nè le libreria che va ad usare. Nè dove va a mettere i dati costanti, il codice, la singola variabile. Come ci accede. Se la cache fa hit oppure no. Tutte cose invisibili al normale programmatore che si preoccupa però che llm vada a toccare dei file. "firmware é stato interamente vibecodato e il codice non é stato neanche revisionato?" E tu ti fideresti di un firmware fatto da dei neulaureati in medicina che hanno imparato a programmare nel tempo libero ? Non è questione chi/cosa fa il programma, ma l'esperienza di chi l'ha fatto. Se tu pensi che basta dire al coding agent "fammi un firmware da mettere nel pacemaker" forse non hai mai provato a fare seriamente del software con un coding agent.
@tiziofalzonii 14 luglio 2026

@paolo.achdjian a parte che non hai risposto alla domanda, ma poi da quando i laureati in medicina scrivono il firmware dei pacemaker lol? piuttosto mi fiderei di informatici/ingegneri perché almeno in teoria quella é gente che sa dove sta mettendo mano, ha studiato le cose che hai detto e che se servisse potrebbe intervenire anche manualmente per affrontare casi particolari o correggere il codice generato dall'ia, un vibecoder specialmente se neanche controlla il codice non é piú un programmatore ma é un cliente che senza ia sarebbe totalmente perso e incapace di intervenire se qualcosa dovesse andare storto poi vabbé la frase che hai detto "Non è questione chi/cosa fa il programma, ma l'esperienza di chi l'ha fatto" é una cazzata astronomica, un programma buggato scritto da uno con esperienza é meglio di uno che funziona ma scritto da qualcuno senza esperiernza? bro é letteralmente il contrario, se il programma funziona bene allora funziona bene a prescindere da chi lo ha fatto, giá solo da questa frase si capisce quanto vale la tua preparazione
@paolo.achdjian 14 luglio 2026

@tiziofalzonii Pensavo fosse una domanda retorica. Pensavo che sapessi che il firmware per apparecchi medicali deve sottostare a test intensivi. Se passano i test, poco importa come è stato fatto. Non è chi (programmatore o LLM) scrive il firmware che importa ma come è stato scritto, se ha seguito certe norme e se ha passato i test. Il software deve funzionare secondo le specifiche. Non è importante come è stato scritto. Questi informatici di cui parli, cosa vuoi che ne sappiano di come deve funzionare un pacemaker ? : come fanno gli informatici a sapere che il firmware del pacemaker funziona correttamente se non hanno mai fatto un corso di medicina ? Quindi, domanda, tu useresti un pacemaker il cui firmware è scritto da uno che non sa cosa deve fare un pacemaker ?
@tiziofalzonii 14 luglio 2026

@paolo.achdjian ancora una volta non hai risposto alla domanda iniziale la mia risposta invece é: si, per un discorso molto semplice ovvero confido che chi sa cosa deve fare un peacemaker lo abbia spiegato a chi sa cosa di conseguenza deve far fare il codice e alla fine del processo puó garantire che il codice faccia quello che deve fare e che determinate norme siano state rispettate, un llm da solo invece non puó garantire proprio un bel niente e a sua volta non puó farlo neanche il programmatore per quanto sia bravo se non controlla l'output e non si assicura che tutto sia stato fatto a modo, in quel caso si spezza la chain of trust
@zxano91 14 luglio 2026

@paolo.achdjian in realtà se si parla dei bug relativi al solo compilatore, ormai sono rarissimi (in più di 10 anni di C ne ho trovato solo 1 con una vecchia versione di gcc che ero costretto ad usare in cui un minchia di puntatore veniva castato male facendo l'operazione++ finiva per sporcare la variabile successiva), e quelli che si trovano vengono segnalati velocemente, e corretti. Non so quanta esperienza tu abbia, ma è noto che sono rari, e sotto controllo. Invece un llm essendo probabilistico lo stesso prompt potrebbe o meno dare un bug, con diversi ordini di grandezza superiori a quelli introdotti da un compilatore, è proprio un paragone che non regge. Inoltre un llm in mano ad una persona poco esperta può (e dico può perché non si sa a prescindere l'esito essendo probabilistico) produrre molti più bug rispetto ad una persona esperta. Mentre un compilatore, produrrà matematicamente gli stessi bug, indipendentemente da chi li usa. È il classico paragonare mele con pere, non funziona come confronto.
@paolo.achdjian 14 luglio 2026

@zxano91 perchè pensi che llm possa produrre più bug in mano ad una persona poco esperta ? la quantità di bug è la stessa, la LLM non sa chi sta scrivendo il prompt. Forse non scriverà un prompt aderente alle specifiche di progretto, ma il codice generato dall'llm avrà la stessao conformità al prompt sia che lo scriva un neolaureato che un senior con 20 anni di esperienza. Se invece intendevi che il prompt scritto da uno con poca esperienza non contenga tutte le indicazioni necessarie per fare generare un codice conforme alle specifiche di progetto su questo siamo d'accordo.
@paolo.achdjian 14 luglio 2026

@zxano91 Il compilatore era solo un esempio sul fatto che usiamo sempre molti tool che hanno bug ma non ci facciamo troppo caso. Se per te il compilatore è troppo sicuro rispetto all'LLM, cosa ne pensi delle librerie o del codice che tu stesso scrivi ? Se sicuro che l'LLM possa produrre più bug rispetto a queste due categorie ? La tesi di Sanfilippo (uno che ha un po' di esperienza nello scrivere codice) è che il codice dell'LLM sia sufficientemente corretto e quindi non serve controllarlo come si fa con il compilatore o le librerie.

@giovannisardisco4541 13 luglio 2026 1

Cosa dicevamo prima del codice di merda? Che era codice di merda, buggato e scritto coi piedi! E lavorare su progetti con quel tipo di codice è molto più difficile, perché convincere l'AI a scrivere codice pulito è molto più difficile, perché è influenzato dalla merda.

1 risposta

@giovannisardisco4541 13 luglio 2026 2

Quindi, cor ca che non riguardo cosa ha scritto l'AI su quei progetti. Su quelli scritti da me da zero, su linguaggi che non conosco, ho provato a non guardare codice (anche perché non riuscirei a fare una consapevole review), ma quei progetti diventano una black box di cui conosco solo le specifiche di input e output.

@Roy-k6z7x 14 luglio 2026

5:19 senza A.I. ormai è un concetto che non può più esistere.

@loris5499 13 luglio 2026

Ciao Esa, ho visto tutto il video, oltre a ciò sono un assiduo ascoltatore dei pensieri di sanfilippo. Dal mio punto di vista, Salvatore e te, avete le stesse idee, ma magari non vi siete capiti. Lui dice che la scrittura del codice DS4 è stata automatizzata, ma subito dopo lancia una sfida, con "prova a farlo tu". Quindi non si toglie dall'equazione anzi. Vede piuttosto la scrittura delle singole funzioni come un qualcosa di automatizzabile, ma non il pensiero che sta dietro a quelle singole funzioni, algoritmi e architettura del software. Nel video di sanfilippo, ma anche nell'articolo, dice come la revisione riga per riga sia fatta attraverso un QA con il modello. Quello che aggiungerei io, è che gli LLM, al netto della scrittura del codice effettiva, ti fanno sprecare meno tempo alla ricerca di informazioni nelle documentazioni alla ricerca di un metodo di una libreria etc... Mi spiego meglio: spiegare l'architettura del sw, l'algoritmo a livello teorico, o in generale il tuo pensiero (sapendo la teoria quell'argomento) ad un LLM e lasciare che sia quello ad occuparsi della scrittura, non toglie nulla al sw, perchè è comunque una rappresentazione del tuo pensiero. Ovvio è che per progetti di grandi dimensioni bisogna stare attenti, fare molti test. ps: scusami e scusatemi per l'eventuale poca chiarezza, sono un po di corsa, ma ci tenevo a dire la mia umile opinione.

1 risposta

@esadecimale Autore 13 luglio 2026 1

Per il modo in cui io mi rapporto al termine "automatico" per me significa che non richiede nessun input umano. Questo significa un processo privo di creatività, giudizio, intuizione. Se richiede input umano anche in minima parte non è automatico, al massimo semiautomatico. Questa distinzione semantica per me è importante. Anche i compilatori generano del codice a partire da una descrizione formale di un altro linguaggio. Eppure non utilizziamo automated programming in quel senso. Non per dire che LLM == compilatore ovviamente, ci sono delle differenze, ma mentre è vero che aumenta il livello di astrazione, è anche vero che c'è bisogno di formare gente competente, a prescindere dalla tecnologia in gioco. A me sembra invece che continuiamo a parlare solo della tecnologia, come se questa avesse una vita propria e prendesse delle scelte proprie. Il codice di merda lo puoi generare sia con LLM sia a mano.

@ICLVoluseno 14 luglio 2026

Sono d'accordo con Salvatore che non ha più senso mettersi a leggere il codice però sono allo stesso tempo d'accordo con Leonardo di Esadecimale che per l'apprendimento ed una comprensione profonda dei sistemi si debba entrare dentro. La mia proposta è quella di usare il linguaggio naturale per il design architetturale e ad alto livello del sistema mentre usare, al posto dei linguaggi di programmazione, la matematica per implementare la soluzione progettuale. Sarà poi l'LLM, avendo in input linguaggio naturale che descrive ad alto livello il sistema e formalizzazione matematica che lo descrive a basso livello, a tradurre tutto in codice.

@RaffaeleVitolo 14 luglio 2026

Completamente automatico é riferito al code writing, non al controllo di idee. L'AI é un tool, come lo é il martello per un fabbro. Il fabbro sa come usare il martello. Le idee non sono nel martello, ma nella testa del fabbro. Un ragazzo alle prime armi può farsi male con il martello? Direi di si. Come gli si insegna ad usarlo, ad "essere un bravo fabbro"? Gli mostri come usare lo strumento, che sia manual developmemt o automatic developmemt. Non amo le battaglie ideologiche e non amo neanche questa storia pro/contro ai. Penso che le future generazioni debbano passare per le forche caudine del codice, ma credo che debbano approcciarsi in maniera agnostica anche ai nuovi strumenti... Pure perché negli ultimi secoli non mi é mai capitato di vedere "il nuovo" sostituito "dal vecchio". Sei estremamente bravo come divulgatore ed il lavoro gratis che fai ha un valore immenso tanto per le nuove generazioni che per le vecchie, ma non ti nascondo che l'assegnazione "ai=mexda" che traspare nei tuoi discorsi é piu che cristallina. E quest'ultima cosa mi sta incominciando a fare più paura dello strumento stesso. Non acquistiamo un manufatto in ferro se il fabbro ha usato quel diavolo di martello?? Ti assicuro che il martello è non deterministico, esattamente come altre diavolerie. Ci interessa più la qualità del manufatto che non la tecnologia impiegata per realizzarlo. Usiamo i feedback per pesare la reputazione del fabbro, testiamo con mano altri suoi manufatti, o proof-of-concept se stiamo parlando del "dio della sega e del martello". Ma certo non ci chiediamo cosa abbia usato in officina per generare con cotanta arguzia questa o quella bellezza. Un appunto che può essere fatto ad Antirez (mi ha morso una tarantola poco fa, perciò sono cosi indisponente in questa ultima frase. Chiedo venia preventivamente e dirò 1024 padre nostro di penitenza...) é: "mostra il modo corretto di inserire l 'AI nel flusso reale di creazione di un tuo prodotto" (ammesso che esista un solo modo). Lo direi anche a te, ma sarebbe come mettere assieme il diavolo e l'acqua santa. Un video o una serie di video del genere sarebbero "il mastro fabbro che insegna al ragazzo di bottega, come non farsi male col martello e portare a casa una future core skill". Esattamente come lo sono stati i suoi video sul C e come lo sono stati - e spero lo saranno ancora per lungo tempo - i tuoi.

2 risposte

@esadecimale Autore 14 luglio 2026

Mai detto che l'AI sia merda, si vede che non hai ascoltato bene le mie parole. Il mio punto è che l'AI non è salvifica, è uno strumento, e sarà usata male esattamente come le altre tecnologie del passato saranno usate male.
@RaffaeleVitolo 14 luglio 2026

@esadecimalenon ti ho mai messo quelle parole in bocca. Ho scritto "traspare...". Cioè attraverso le tue parole io percepisco quella equazione. Se non é cosi, ti chiedo scusa: devo aver frainteso. I compilatori sono stati usati male? Gli editor wysiwyg sono stati usati male? Il kernel linux? C? Se é successo, non si può cambiare il passato. Eppure - a mio avviso - questi stesssi errori sono solo un motivo in più per dire 'i nuovi strumenti vanno usati così' e mostrare le right ways.

@fabiocibecchini 13 luglio 2026

11:05 ma lo dice una riga dopo che anche se è automatizzato le idee e la progettazione ce la devi mettere tu

2 risposte

@esadecimale Autore 13 luglio 2026

E allora non è automatizzato. Un processo è automatizzato quando non richiede creatività o intuito umano. Infatti io contesto proprio quella parola, perché non descrive bene ciò che sta succedendo. Lo accetto se si descrive come semi-automazione del processo di scrittura del software.
@JoyBoyRevolution 14 luglio 2026 3

@esadecimaleallora il problema è semantico, dipende cosa intendete per automatizzato. Tu pare tutto, lui solo la parte di codice. Per i livelli attuali di IA non è ancora possibile automatizzare tutto e comunque non sempre i risultati sono accettabili al 100% anche con una buona progettazione. Quindi anche secondo me dite più o meno la stessa cosa, probabilmente tra 2 anni sarete d'accordo al 100%

Descrizione

Commenti 43