Grazie, sono tornato indietro di cinquant’anni, quando leggevo i primi libri sui codici binari, poi sono approdato al Fortran e usato Ansys ma ho preso un’altra strada…
Uno sguardo alla nostra storia davvero importante. La mancanza di precisione nella lingua parlata é un punto chiave che spesso viene trascurato quando si pensa alle potenzialità di AI. Un software engineer che lavora a stretto contatto con un product manager risponde a migliaia di domande e pone migliaia di quesiti nel corso della costruzione di una macro funzionalità. Non si può pensare che AI, per quanto potente, con un prompt di 5 righe sia in grado di compensare il gap informativo. Se l'agent utilizzato assume di sapere le risposte a quelle migliaia di domande, tipicamente il risultato atteso sarà molto diverso da quello che il vibe coder si immaginava. Se pone quelle migliaia di domande, il vibe coder deve rispondere e quel punto non stiamo parlando di un agente autonomo, ma di un processo iterativo e interattivo.
Potremo considerare questo nuovo approccio, quando sarà maturo, un ulteriore abbassamento della barriera tecnica richiesta per contribuire allo sviluppo, possiamo anche considerarlo un acceleratore del processo di coding, ma le headline che leggiamo in questi giorni dove pare in grado di tirare fuori informazioni perfette dove mancano sono molto lontani dalla realtà.
Il suo post mi ha anche fatto riflettere sulla recente notizia eclatante secondo cui GenAI ha sviluppato un compilatore C con un investimento di soli 20000$ in token.
Ho letto questa analisi che evidenzia come il compilatore generato da AI, anche tralasciando le lacune funzionali per cui non compila certi progetti complessi come il Kernel linux, produce eseguibili molto meno efficienti:
Quanto meno? Nel caso più eclatante, ben 158000 volte più lento. Andare poi a trovare quel problema e risolverlo richiede capacità molto avanzate di debugging, conoscenza di C e Assembly. Vuol dire che GenAI non é utile? Affatto, le potenzialità sono immense, ma ancora non é in grado di fare il lavoro di un software engineer.
Mi ha fatto ripercorrere la mia esperienza di sviluppatore di modelli matematici (il mio campo è stata la termodinamica, la cinetica chimica e la modellazione reattoristica). Credo di aver usato l’assembler sul Vic 20; le schede perforate invece le ho usate per l’esame dí programmazione di calcolatori elettronici nel 1979 (un programmino in Fortran per trovare l’uscita più corta da un labirinto) e per la tesi; poi nei 40 anni successivi Fortran, BASIC, ho persino comprato un libro sul Prolog, era l’epoca in cui erano di moda i Sistemi Esperti. Un po’ di C++ e Java. Ci fu poi l’Aspen Custom Modeler, software commerciale per generare modelli di processi chimici: con un’opportuna sintassi si scrivevano le equazioni e si dichiaravano le variabili senza preoccuparsi della loro risoluzione. Verso la fine della mia attività lavorativa, Matlab e Python per cinetiche e modellazione dei dati sperimentali.
Mi dispiace un po’ di essere andato in pensione prima dell’avvento degli LLM.
Grazie, sono tornato indietro di cinquant’anni, quando leggevo i primi libri sui codici binari, poi sono approdato al Fortran e usato Ansys ma ho preso un’altra strada…
Uno sguardo alla nostra storia davvero importante. La mancanza di precisione nella lingua parlata é un punto chiave che spesso viene trascurato quando si pensa alle potenzialità di AI. Un software engineer che lavora a stretto contatto con un product manager risponde a migliaia di domande e pone migliaia di quesiti nel corso della costruzione di una macro funzionalità. Non si può pensare che AI, per quanto potente, con un prompt di 5 righe sia in grado di compensare il gap informativo. Se l'agent utilizzato assume di sapere le risposte a quelle migliaia di domande, tipicamente il risultato atteso sarà molto diverso da quello che il vibe coder si immaginava. Se pone quelle migliaia di domande, il vibe coder deve rispondere e quel punto non stiamo parlando di un agente autonomo, ma di un processo iterativo e interattivo.
Potremo considerare questo nuovo approccio, quando sarà maturo, un ulteriore abbassamento della barriera tecnica richiesta per contribuire allo sviluppo, possiamo anche considerarlo un acceleratore del processo di coding, ma le headline che leggiamo in questi giorni dove pare in grado di tirare fuori informazioni perfette dove mancano sono molto lontani dalla realtà.
Il suo post mi ha anche fatto riflettere sulla recente notizia eclatante secondo cui GenAI ha sviluppato un compilatore C con un investimento di soli 20000$ in token.
Ho letto questa analisi che evidenzia come il compilatore generato da AI, anche tralasciando le lacune funzionali per cui non compila certi progetti complessi come il Kernel linux, produce eseguibili molto meno efficienti:
https://harshanu.space/en/tech/ccc-vs-gcc/
Quanto meno? Nel caso più eclatante, ben 158000 volte più lento. Andare poi a trovare quel problema e risolverlo richiede capacità molto avanzate di debugging, conoscenza di C e Assembly. Vuol dire che GenAI non é utile? Affatto, le potenzialità sono immense, ma ancora non é in grado di fare il lavoro di un software engineer.
Mi ha fatto ripercorrere la mia esperienza di sviluppatore di modelli matematici (il mio campo è stata la termodinamica, la cinetica chimica e la modellazione reattoristica). Credo di aver usato l’assembler sul Vic 20; le schede perforate invece le ho usate per l’esame dí programmazione di calcolatori elettronici nel 1979 (un programmino in Fortran per trovare l’uscita più corta da un labirinto) e per la tesi; poi nei 40 anni successivi Fortran, BASIC, ho persino comprato un libro sul Prolog, era l’epoca in cui erano di moda i Sistemi Esperti. Un po’ di C++ e Java. Ci fu poi l’Aspen Custom Modeler, software commerciale per generare modelli di processi chimici: con un’opportuna sintassi si scrivevano le equazioni e si dichiaravano le variabili senza preoccuparsi della loro risoluzione. Verso la fine della mia attività lavorativa, Matlab e Python per cinetiche e modellazione dei dati sperimentali.
Mi dispiace un po’ di essere andato in pensione prima dell’avvento degli LLM.