02/04/2026 - Delphinium ha scritto:
i tuoi discorsi sono belli e idealistici. Stai dipingendo una realtà idilliaca che io spero tanto si attui, ma ho l'impressione che invece non sarà così.
Io invece ho proprio il timore che si attui esattamente in questo modo, per tutti i motivi che ho già espresso, perché la strada mi pare ben tracciata, e sta permeando ovunque, non solo nello sviluppo software.
02/04/2026 - Delphinium ha scritto:
Nel settore automotive qualsiasi "parte prodotta" ha dei controlli che garantiscono che ci sia una difettosità inferiore a 1 parte su dieci milioni, ovviamente secondo parametri definiti, con controllo al 100% di ogni singola parte, viti comprese.
E vai tranquillo che un freno di un veicolo non và "in allucinazione" ... magari ci và chi lo dovrebbe comandare ...
Nella mia metafora, LLM è parte integrante della catena di produzione che produce il freno con quell'affidabilità, mentre il freno rappresenta il software, ossia il prodotto finale.
Proprio come hai detto, "ci sono dei controlli che garantiscono", quindi la perfezione del prodotto in uscita non è dato dall'impeccabilità dei macchinari che producono l'artefatto, tantomeno dalla loro infallibilità, a maggior ragione quando si parla di persone e non di macchinari: ciò che garantisce la qualità di quello che viene prodotto, che sia il freno o che sia un software, è il processo stesso di controllo della qualità, in un caso dato dai test sul freno che verifica si comporti esattamente come dovrebbe, nel caso del software dai test che verificano il corretto funzionamento e l'adesione agli standard.
02/04/2026 - Delphinium ha scritto:
Chi definisce la catena di produzione di un codice prodotto da un AI, chi è in grado di controllare milioni e milioni di righe di codice .. o si pensa che facendo un test (o dieci , cento, mille ... un milione ?) per quanto complessi si riuscirà a trovare il malfunzionamento prodotto da una allucinazione ? E verranno eseguiti poi tutti i test necessari ?
Queste sono le stesse problematiche di una catena di montaggio qualsiasi. Una AI ben addestrata, pur con i suoi difetti, ha bisogno di molto meno tempo e di molte meno iterazioni per individuare una problematica. Se anche fosse e ne servissero dieci, cento, mille o un milione di cicli, è solo una problematica di costi, o di token al momento. Ok, non è indifferente, ma il limite è quello.
Se poi verranno o meno eseguiti i test necessari in futuro, questa è una scelta dell'azienda così come lo è sempre stata. Se devono essere fatti per certificazioni specifiche, così come vale per i beni materiali, allora varrà anche per il software allo stesso modo.
La questione riguarda anche le software house attuali, con o senza l'uso di LLM per lo sviluppo software: molte aziende, pur millantando TDD/BDD/ecc. fanno MOLTI MENO test già oggi di quelli che servirebbero sul prodotto finale, perché rappresenta un costo elevato a maggior ragione quanto si unisce a quello sostenuto per lo sviluppo e la scrittura di codice in sé.
Basta vedere le politiche di rilascio di tantissimi software, oppure anche l'andazzo dell'industria videoludica ormai da anni a questa parte: senza il discorso AI nel mezzo, la politica è sempre quella di andare sul mercato il prima possibile, con versioni BETA, ri-BETA, stra-BETA, poi grazie al fatto che puoi fare aggiornamenti OTA, al massimo si fixa dopo, si ri-fixa, all'infinito. Un rilascio continuo. Ma questo avviene già oggi, e pure con quei software fatti da fior fior di ingegneri: si taglia sul test. E questo non solo nel software, ma anche nell'automotive, visto che l'abbiamo citata.
02/04/2026 - Delphinium ha scritto:
Chi definisce quali sono i parametri che definisccono l'eventuale "round" ?
L'azienda stessa definisce i parametri e li perfeziona, in base alla qualità dell'output che vuole ottenere, oppure in base ai canoni e alle certificazioni che deve/vuole rispettare.
Nei team di sviluppo software in cui ho lavorato c'è sempre stato almeno uno straccio di standard da rispettare, così come c'erano convenzioni relative al percorso di approvazione del software per poter essere rilasciato (code review, acceptance test, smoke test, approvazione rilascio) con svariati tool che se ne occupavano, così come esistono certificazioni ISO e altre procedure per la gestione di anomalie, bug da risolvere e altro ancora.
Queste cose esistono già da tempo, perché in realtà dovrebbero già far parte del processo produttivo del software in generale, solo che in molti casi sono messe in piedi solo per dire di averle, senza renderle di fatto operative, oppure operative formalmente ma non nel pratico (es. la persona che deve approvare un rilascio è designata, ma fa solo clic e non va a controllare nulla di quanto fatto). Adesso diventano d'obbligo con gli LLM.
02/04/2026 - Delphinium ha scritto:
Io non metto in discussione la bontà di tutto ciò, metto in discussione che allo stato odierno (e a maggior ragione in futuro) può attuarlo chiunque, e lascio a voi il proseguio di questa "visione" ...
Al momento non può farlo chiunque. In futuro, è probabile che diventerà così.
02/04/2026 - Delphinium ha scritto:
Uno che non conosce alcunchè di programmazione chiede ad un LLM di fare qualcosa senza porre i corretti parametri senza fare le azioni ricorsive ... facendo due test per validare il "prodotto" ... ecco questo è.
Qui stiamo parlando di "vibe coding" puro, ok. Però non capisco parte di quello che dici.
Ad esempio, "senza porre i corretti parametri": tu non devi porre parametri, a meno che per parametri non si intenda ciò che tu vuoi che faccia la tua applicazione. I parametri ti interessano e li citi perché stai attuando la visione da sviluppatore, che io capisco perfettamente eh. :)
"Senza fare le azioni ricorsive"... questo è un dettaglio implementativo che non interessa a chi vuole sviluppare un'applicazione fornendo dei requisiti. E' un elemento del TUO e del MIO vocabolario da sviluppatori, è un input che possiamo fornire per risparmiare token se ci interessa che una cosa venga fatta in modo ricorsivo o meno, ma non è un input che devi necessariamente fornire poiché sarà il tool di coding a implementare la soluzione in modo ricorsivo o meno a seconda di quello che è l'obiettivo finale.
"Facendo due test per validare il prodotto"... qui si da sempre per scontato che la persona faccia due test e non di più, ma perché? Perché invece non può farne di più? Persone superficiali esistono oggi ed esisteranno anche domani, ma non sono tutte così.
Queste argomentazioni sono una raccolta da manuale di fallacie logiche per me: generalizzazione affrettata o argomento ad hominem (si da per scontato che una persona si possa comportare solo in un modo) e pendio scivoloso (da questo comportamento parte tutta una serie di eventi nefasti).
A mio avviso, quando ci sarà il momento in cui questo scenario esploderà con tutta la sua potenza, senz'altro ci saranno aziende che "faranno le cose per bene", pur usando LLM, e ci saranno quelle che le faranno male, come è sempre accaduto. Ciò non toglie la validità dello strumento.
02/04/2026 - Delphinium ha scritto:
Sarebbe come se io (che non sono un ingegnere strutturale) grazie alla IA progettassi un ponte o un grattacielo ...
No, è una metafora completamente sbagliata.
Se io commetto un errore nella costruzione di un ponte o un grattacielo qualsiasi, questi potrebbero crollare, con tutte le conseguenze che ne derivano facilmente intuibili.
Se io commetto un errore in un software qualsiasi, faccio bug fixing e correggo il bug. Quindi a meno di non entrare in ambiti molto specifici (se è il software del modulo lunare o della centrale nucleare, ok, potrei mettere a rischio delle vite), le due cose sono agli antipodi.
Una anomalia nella progettazione di un ponte ha un grado elevato di rischio. Non puoi sbagliare. Una anomalia nella progettazione di un software ha un rischio mediamente molto più basso.
Ciò non vieta comunque a un ingegnere strutturale di farsi aiutare dall'AI per creare i propri progetti di ponti e grattacieli, ma la supervisione dovrà essere molto alta su ciò che viene prodotto, non perché quanto è generato dall'AI possa contenere degli errori, perché gli errori li fanno anche gli esseri umani spesso e volentieri, ma perché il processo di validazione, verifica, assessment, chiamalocomevuoi dovrà essere molto, molto, molto più forte rispetto alla scrittura di un software, proprio perché ne va della vita delle persone. E qui si torna al punto iniziale: l'importanza assoluta del test e dei criteri di validazione.
02/04/2026 - Delphinium ha scritto:
Tornando a bomba, quello che mi fà più specie (ed è il nocciolo della questione ... anzi di tutte le questioni, anche quelle umane) è l'aspetto economico.
Sono d'accordo. Questo è l'aspetto più devastante e spaventoso. Che io comunque tendo un minimo a separare dalla questione tecnica, giusto per dire che mi meravigliano molto le possibilità odierne, ma del resto sono consapevole che sto alimentando un possibile rimpiazzo di me stesso, anche solo finanziandolo e usandolo in parte. :|
02/04/2026 - Delphinium ha scritto:
Ora parlando esclusivamente di programmazione, la gran parte del lavoro veniva svolto da un team di persone normalmente che professionalmente garantivano la minima funzionalità (ad esempio assenza di leak). Ed era proprio la loro professionalità alla base di tutto. [...]
Diciamo che questa sarebbe stata sempre la situazione ideale, ma a me personalmente è capitato molto di raro trovarla in un team: codice scritto male, convenzioni non rispettate, pressapochismo... per una persona pignola come me, rigida anche su piccole cose minuscole, questo aspetto contribuisce al mio favorire in certi contesti l'adozione di LLM perché, posso proprio dirlo, anche il codice più banale spesso è scritto con maggiore adesione e rispetto delle convenzioni rispetto a quello che leggo in giro, fatta esclusione ovviamente per quegli sviluppatori che seguo e ammiro per questo aspetto.
Parlando di Delphi, visto che siamo in un thread correlato, io faccio spesso consulenze a team di sviluppo e le soluzioni che vedo adottate o le strutture messe in piedi, vecchie e nuove, spesso sono degli accrocchi talmente raffazzonati che la prima AI che fosse impiegata a scrivere lo stesso software, non farebbe di certo gli stessi errori e le medesime brutture. Lo dico proprio onestamente. :)
Per dire, quante volte capita di vedere delle chiamate a Free() mancanti dentro un try...finally per distruggere oggetto, o un uso improprio di classi dichiarate male o con criteri di visibilità travisati... queste sono cose che gli LLM e i tool di coding assistito non fanno, e se le incontrano ti propongono pure di correggerle.
02/04/2026 - Delphinium ha scritto:
Ecco, è questa visione pessimistica che temo.
Sull'aspetto sociale ed economico, concordo. Potrà andare bene o male, certo si abilitano un sacco di potenzialità in più, ma l'impatto che avranno le persone senza più lavoro, prescindendo un momento dal discorso giusto/sbagliato o dal dibattito qualitativo sugli strumenti, diventerà comunque un problema da gestire. Come? Boh... :)