Vibe coding in Pascal

di il
32 risposte

32 Risposte - Pagina 3

  • Re: Vibe coding in Pascal

    01/04/2026 - Delphinium ha scritto:

    Giusto per definire l'affidaibilità di un LLM, questa è una delle risposte fornite:

    La mia conoscenza e i miei dati di addestramento sono aggiornati fino a **luglio 2026**.

    Siamo oltre, siamo già alla preveggenza.

    E questo dovrebbe dirci che......?

    Al netto che, oltre alla fonte, non è chiaro il contesto da cui proviene questa risposta, e che comunque si sta sottolineando l'ovvio ossia che gli LLM possono avere allucinazioni (ma conosco anche persone che sono allucinate), questa cosa che dovrebbe dirci di più?

    Dovrebbe stare a significare che non possiamo usarli? che possiamo usarli "forse"? che li dobbiamo supervisionare necessariamente? che sono totalmente inservibili? che sbagliano più delle persone? che sbagliano di meno?

    Oltre alle battute che ci stanno sempre, iniziamo a fare dei veri e propri "claim", delle asserzioni circostanziate e precise sull'argomento.

    Solo così sarà possibile rivedere questo thread, magari fra un anno al massimo, e capire se è invecchiato bene o male. :)

  • Re: Vibe coding in Pascal

    01/04/2026 - amorosik ha scritto:

    1- Sicuro che NON c'e' certezza al 100%, ma questo come ricordava Alka non vuol dire che sia comunque estremamente utile adottare questa nuovissima tecnologia

    In termini di produttività, nello sviluppo software quotidiano, a mio avviso già oggi l'adozione di un tool come Claude Code, Codex o Copilot (in ordine di preferenza personale) è quasi imprescindibile, o lo diventerà, per chi sviluppa applicazioni o servizi business tradizionali.

    01/04/2026 - amorosik ha scritto:

    2- Pure per una capoccia biologica, la certezza NON c'e' al 100%

    Concordo. Quello che può fare la differenza è la presenza di un processo di validazione molto spinto (ossia i famosi "test", di qualunque tipo) che possa verificare la bontà del software prodotto. Questo era indispensabile già quando il software lo scrivevano al 100% esseri umani, a maggior ragione diventa rilevante quando un LLM si inserisce nel circolo. Oltre al test di validazione, è altrettanto importante la fase iniziale di analisi dei requisiti. Sia nella stesura dei test sia nell'analisi dei requisiti, seppur attualmente guidati da una persona in carne e ossa, i tool LLM possono comunque accelerare notevolmente il processo.

    01/04/2026 - amorosik ha scritto:

    Spesso pensiamo che un llm non riesca a 'comprendere' il significato di una questione (come se 'comprendere' sia definibile in modo semplice)

    E ci dimentichiamo che pure molti umani non riuscirebbero a 'comprendere' il significato della medesima questione

    Oltre a questo, spesso non è di "comprensione" che si ha bisogno: quella magari la ricerchiamo dal partner. :D

    Quello che a volte serve è riconoscere pattern, estrarre un'analisi di un flusso, produrre dati di esempio, riassumere testo da testo, generare una parte di codice boilerplate, in breve accelerare quella che in prevalenza è un'attività "meccanica", e lo sarebbe anche dal punto di vista cerebrale umano.

    01/04/2026 - amorosik ha scritto:

    Solo che Claude da 20 euro/mese ti butta giu' 10K righe di codice in un'ora, che sistema qua e sistema la', alla fine funzionano, mentre per un umano quelle 10K righe di codice te le mette giu' in un mese, e senza documentazione, e senza test

    Non solo quelle righe di codice funzionano ma, soprattutto se hanno una base da cui partire (es. una parte di codice di esempio che hai già scritto e validato), replicano alla perfezione le convenzioni che hai adottato scrivendo codice valido, soprattutto se il prompt è preciso e se il tool comprende dei meccanismi di "safe guard" che rivedono anche il codice scritto per validarlo ulteriormente.

    01/04/2026 - amorosik ha scritto:

    Siamo nella nuova era del vapore, prima si andava a cavallo, adesso abbiamo l'automobile, e' inutile confrontarci con le macchine, come per qualsiasi strumento prendiamo il meglio che possiamo e facciamolo lavorare per produrre di piu' o meglio

    Questa è pure la mia visione.

    Secondo me, a tendere il processo di sviluppo software (ma non solo questo) si trasformerà in una specie di "catena di montaggio".

    Sì, il software è un prodotto di concetto, non è un bene materiale come può essere un automobile, ma le potenzialità degli LLM a oggi consentono di applicare alla scrittura del codice lo stesso criterio di produzione che una catena di montaggio consente per oggetti tangibili.

    Certo, gli LLM hanno difetti e allucinano, e il risultato deve essere validato. Ma questo vale anche per le catene che producono oggetti materiali.

    Io ho fatto software per impianti di imbottigliamento di vino dove il difetto di chiusura di un tappo, o un'etichetta mancante, o una quantità insufficiente di liquido sono eventi del tutto ricorrenti, producendo milioni di bottiglie al giorno, ma questo non è un problema se inserisci sulla linea un tester di pressione del tappo, una videocamera che verifica il livello del liquido, un OCR che rileva l'etichetta e controlla che sia pure stampata con i contenuti attesi, ecc. ecc. Devi validare ciò che la tua linea produce prima di impacchettarlo e mandarlo in distribuzione.

    Nel software con gli LLM succederà la stessa cosa: devi inserire nella catena di sviluppo una serie di tool, che potrebbero essere anch'essi sviluppati con l'ausilio di LLM, che verifichino l'adesione del codice a determinati standard, che eseguano dei test (unit/integration/smoke/ui), che escludano una serie di vulnerabilità rilevabili o più "secche" (es. database CVE) e magari siano posizionati in diverse "stazioni" della tua catena CI/CD. Con i server MCP poi, puoi integrare addon e altri tool a supporto degli LLM per istruirli su quello che non conoscono o deve essere recuperato dal "contesto aziendale" o da altre fonti dati.

    In sintesi, tutto quello che è coerente con i parametri di qualità fissati "passa oltre", ciò che viene rilevato "difettoso" torna indietro e deve essere sistemato. Ma a fronte del problema riscontrato, può essere sistemato anche sempre da un LLM, non necessariamente da una persona. Fino a quando non soddisfa tutti i requisiti impostati, non si va avanti. Un intervento umano può essere richiesto se qualcosa si rompe o se è necessario sbloccare una decisione, così come un tecnico interviene su una linea di produzione fisica se un macchinario presenta dei problemi.

    La bontà del prodotto finale dipenderà sensibilmente dalla qualità della tua catena di produzione.

    E pur riguardando software, questi sono tutti lavori "meccanici", che quindi una macchina fa molto meglio e soprattutto molto più velocemente, a maggior ragione se è stata allenata con tutto lo scibile umano così come hanno fatto (più o meno legalmente, più meno che più) quelli di Open AI, Anthropic e compagnia bella.

    E se LLM sbaglia, dato che le allucinazioni fanno parte del sistema, si fa un altro giro, o se l'errore sfugge si vanno a integrare i criteri di controllo applicati.

    Tutto questo già adesso, ma anche già da ieri, è perfettamente realizzabile e accessibile.

    L'unico problema è che questa trasformazione sta letteralmente galoppando, aziende stanno facendo dei layoff massivi e non nego che, pur meravigliato da queste potenzialità, sono preoccupato del fatto che potrebbero tranquillamente rendermi obsoleto in un futuro non troppo lontano ed estromettermi dal mercato del lavoro di cui faccio parte. Oltre a questo, l'impatto sulla società creerà (e lo sta già facendo) delle distorsioni rilevanti. C'è poi l'incognita di quale sarà il prezzo finale di questa tecnologia che a oggi viene svenduta per guadagnare quote di mercato e investimenti finanziari... prima o poi dovranno recuperarli (e secondo me sarà impossibile recuperare tutto), ma queste sono questioni a parte, un po' come la bolla di Internet che fu: sì, alla fine la bolla è scoppiata, ma Internet non è scomparso.

    E' estremo da dire ma, dal mio punto di vista, a tendere e in un periodo che non sarà nemmeno troppo lungo, se sei una persona che di mestiere lavora su documenti e asset puramente digitali (sviluppatore, traduttore, creator, analista, ecc.), la tua figura è molto a rischio.

  • Re: Vibe coding in Pascal

    @Alka,

    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ì.

    Vedi, partendo dal vino, i sistemi reali applicati (non quelli teorici) sono fallaci e te lo posso dire con certezza matematica visto che faccio i controlli di qualità di invecchiamento sulle produzioni di vino imbottigliato ... il 20 percento di una produzione non supera l'anno o i due anni di vita proprio a seguito delle varie problematiche non controllate o rilevate perfettamente in fase di produzione. Ma perchè accade ciò ? Perchè qualcuno ha fissato i parametri di controllo in base alla convenienza economica, non alla realtà.

    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 ...

    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 ?

    Chi definisce quali sono i parametri che definisccono l'eventuale "round" ?

    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" ...

    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 è.

    Cosa che con la programmazione classica è molto più complesso da raggiungere per un neofita.

    Sarebbe come se io (che non sono un ingegnere strutturale) grazie alla IA progettassi un ponte o un grattacielo ...

    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.

    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. La spinta economica era sicuramente una leva, ma l'atto di "delinquenza" (giusto per dargli un valore) magari richiesta dal committente per abbattere i costi era comunque legata e mitigata dalla coscenza del programmatore (dal team di programmatori).

    Ora non ci sarà più questa figura, ci sarà solo il committente e l'IA (forse un operatore come tramite), con il committente che alla base guarda generalmente il lato economico ... e si sà quanto costa fare i round di revisione del codice alle IA, quanto costa studiare i parametri necessari, etc ...

    Ecco, è questa visione pessimistica che temo.

    Poi c'è l'altro lato che @Alka ha già evidenziato, ossia le ripercussioni sociali che ciò avrà, anzi che stà già avendo ... è notizia di ieri che una grossa azienda multinazionale ha licenziato 10000 dipendenti (si, 10 mila) dall'oggi al domani e altri ne aveva già licenziati e altri sono già in lista prossimamente ... e parliamo di vite umane, non di parametri.

    Ho buttato giù questo di getto, senza tanto pensare (anche se questo post è stato scritto in una mattinata tra una pausa caffè ed un'altra). Non oso neanche rileggere quello che ho scritto .... :)

Devi accedere o registrarti per scrivere nel forum
32 risposte