{"id":166425,"date":"2026-03-26T17:13:13","date_gmt":"2026-03-26T15:13:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/intervyu-s-gregom-kroa-hartmanom-ob-otchyotah-ob-oshibkah-sgenerirovannyh-ai"},"modified":"2026-03-26T17:13:13","modified_gmt":"2026-03-26T15:13:13","slug":"intervyu-s-gregom-kroa-hartmanom-ob-otchyotah-ob-oshibkah-sgenerirovannyh-ai","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/intervyu-s-gregom-kroa-hartmanom-ob-otchyotah-ob-oshibkah-sgenerirovannyh-ai","title":{"rendered":"Intervista con Greg Kroua-Hartman sui report di errori generati dall'AI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Durante la conferenza KubeCon Europe, The Register ha intervistato Greg Kroah-Hartman, responsabile del supporto ai rami stabile e 'staging' del kernel Linux e mainteiner in 16 sottosistemi del kernel. Nell'intervista si discute dell'approccio di Greg nei confronti dei rapporti sugli errori trovati dall'AI. L'AI \u00e8 gi\u00e0 utilizzata nel kernel per revisionare le modifiche nel sottosistema di rete, eBPF e DRM, e recentemente \u00e8 stato integrato lo strumento Sashiko di Google per verificare le modifiche inviate. <\/p>\n
Alcune delle affermazioni di Greg: <\/p>\n
\n
\u00abQualche mese fa ricevevamo quello che chiamavamo spazzatura AI \u2014 rapporti di sicurezza generati dall'AI, chiaramente errati o di bassa qualit\u00e0. Era persino divertente. Non ci preoccupavamo molto... Un mese fa \u00e8 successo qualcosa e la situazione \u00e8 cambiata radicalmente. Ora riceviamo rapporti reali.\u00bb\n
\u00abUna situazione simile si osserva non solo in Linux \u2014 tutti i progetti open source ricevono rapporti reali redatti con l'ausilio dell'AI, e ora sono di qualit\u00e0 e validi. I team responsabili della sicurezza nei maggiori progetti open source riscontrano la stessa tendenza in conversazioni informali tra loro.\u00bb\n
Alla domanda su cosa abbia causato questo, Greg ha risposto: \u00abNon lo sappiamo. Sembra che nessuno lo sappia. O molti strumenti sono diventati molto migliori, oppure le persone hanno iniziato a dire: 'Ehi, affrontiamo questo problema'. Sembra riguardare molti gruppi e aziende diversi. Per quanto riguarda il kernel, noi lo gestiremo. Il nostro team \u00e8 diventato molto pi\u00f9 grande, \u00e8 molto disperso in tutto il mondo, e la nostra crescita \u00e8 una realt\u00e0 che non sta rallentando. Sono piccole cose, niente di serio, ma potrebbe esserci bisogno di aiuto in questo per tutti i progetti open source. Nei piccoli progetti ci sono molte meno possibilit\u00e0 di gestire un'improvvisa ondata di rapporti di errori e vulnerabilit\u00e0 generati dall'AI, in cui si menzionano veri errori e non spazzatura.\u00bb\n
Greg ha raccontato che quando ha chiesto all'AI di trovare errori nel set di modifiche proposto, ne ha trovati 60 e ha fornito patch per correggerli. Solo un terzo degli errori trovati erano effettivamente tali, e solo 2\/3 delle patch si sono rivelate soluzioni corrette, senza necessit\u00e0 di ulteriori modifiche, ma tutto ci\u00f2 non \u00e8 stato affatto inutile. Secondo Greg, i maintainer non possono ignorarlo, soprattutto perch\u00e9 i risultati del lavoro dell'AI stanno migliorando sempre di pi\u00f9. \u00c8 stato aggiunto un tag 'Co-developed:' per contrassegnare le patch create utilizzando l'AI. Tuttavia, nonostante i singoli tentativi di utilizzare l'AI per creare nuove funzionalit\u00e0, attualmente l'AI nel core viene principalmente utilizzata durante la revisione delle modifiche.\n
Uno dei vantaggi pi\u00f9 evidenti dell'AI \u00e8 la riduzione del tempo di gestione delle patch. Quando l'assistente AI identifica problemi evidenti, gli autori delle patch ricevono feedback molto prima che il vero maintainer possa leggere la patch: 'Se vedo che il sistema sta rispondendo a qualcosa, fornisce un feedback all'autore pi\u00f9 velocemente di quanto potrebbe fare un maintainer, ed \u00e8 fantastico. Abbiamo gi\u00e0 diversi bot che controllano le patch. Se noto che segnalano un errore, capisco immediatamente che come maintainer non devo nemmeno guardarlo. E lo sviluppatore pensa 'Oh, posso fare un'altra versione domani', il che aiuta un po' a migliorare il feedback.' <\/ul>\n