Ha senso far revisionare all'IA il codice consegnato prima del collaudo?

C'è un rischio legale pesantissimo da non sottovalutare. Cosa prevedono le clausole di riservatezza o proprietà intellettuale nel contratto che avete firmato con l'agenzia? Caricare il codice sorgente proprietario dell'azienda su una piattaforma IA in cloud potrebbe costarvi una violazione contrattuale senza che ve ne rendiate conto. Se quei dati vengono usati per il training su server di terze parti, passate dalla parte del torto in un attimo.

Dal punto di vista prettamente tecnico il limite più grande è la context window. Un gestionale di magazzino da 26.000 EUR sarà composto con ogni probabilità da decine di microservizi, schemi di database e integrazioni esterne. I modelli analizzano i file in modo isolato. Non vedendo la validazione dei dati eseguita da una funzione posizionata tre file più in là, potrebbero gridare alla vulnerabilità creando falsi allarmi del tutto inutili.

Nel quadro del diritto contrattuale tedesco, i vizi devono essere documentati in modo tangibile prima della firma del verbale di accettazione. L'output testuale di un'IA non costituisce una notifica formale di difetto valida. È indispensabile che il difetto sia riproducibile sull'ambiente funzionante e che si dimostri il mancato rispetto dei requisiti del capitolato tecnico.

L'anno scorso abbiamo fatto esattamente la stessa prova per un portale B2B da 18.000 EUR. Il modello ci ha tirato fuori un elenco di 47 punti. Prima di girarlo all'agenzia abbiamo pagato 400 EUR a un freelancer senior per una perizia: di quei 47 punti solo 4 erano veri difetti, il resto fuffa totale. Va detto però che uno di quei 4 bug avrebbe fatto saltare il sistema in produzione. Utile come filtro preliminare, del tutto inadeguato come giudice ultimo.

invece di incollare tutto il codice chiedendo trovami i bug se vai modulo per modulo con prompt mirati tipo elenca dipendenze e falle di sicurezza ottieni roba molto più pulita. cmq nn mandare mai il report grezzo dell'ia all'agenzia, nn ti prendono sul serio.

Non vi complicate la vita. Gestite l'accettazione basandovi esclusivamente su esperienza utente e funzionalità effettive. Preparate scenari di test: 1) Cosa succede se si inserisce un codice a barre errato? 2) Se salta la connessione e torna, la giacenza resta sincronizzata? 3) Durante l'emissione fattura il sistema si blocca? Il vostro compito non è giudicare lo stile del codice, ma verificare che faccia il lavoro per cui state pagando.

Nel contratto avevate inserito parametri specifici sui test automatici o percentuali di code coverage? E nel repository consegnato sono inclusi gli unit test scritti dall'agenzia? Se i file di test ci sono, far girare quelli fornisce una metrica di accettazione infinitamente più chiara e inattaccabile rispetto a far leggere il codice a una IA.

Un nostro cliente ha fatto una cosa simile. Si è presentato in riunione sventolandoci in faccia otto pagine tirate fuori da un prompt dicendo che il nostro software era spazzatura. Uno dei punti sosteneva che la password del database fosse hardcoded, mentre in realtà era solo un template di configurazione di esempio e quella vera veniva pescata dalle variabili d'ambiente. Si è creato un clima tesissimo e la consegna è slittata di due mesi senza motivo.

Quanto scritto rispecchia esattamente ciò che abbiamo vissuto. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Spero che le sia utile.

Ho lavorato a lungo su questo. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Spero che le sia utile.

Se scendiamo nei dettagli: Chiunque abbia fretta su istruzioni revisione codice si blocca nello stesso punto.

Nel nostro caso è andata così. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

Correggetemi se sbaglio.

Questo consiglio non va bene per tutti, secondo me. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Naturalmente cambia se la vostra situazione è diversa.

C'è una parte che non ho capito. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione. Sono curioso di sapere se qualcuno lo fa in modo diverso.

Scrivo questo per evitare che facciate lo stesso errore. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Se scrivete qui il risultato, sarà utile anche ad altri.

Come avete risolto questo? Ogni "ci pensiamo dopo" in riunione significa lavoro non preventivato.

È tutto, scusate se mi sono dilungato.

Sono emerse tre opinioni diverse, si completano a vicenda. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

ha ragione ma comunque da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

naturalmente cambia se la vstra situazione è diversa.