Ankur Sethi è arrivato su Hacker News. La sua soluzione di riscrittura manuale espone il vero costo del coding con l’AI

Ankur Sethi ha acceso un dibattito su Hacker News con una proposta volutamente scomoda: riscrivere manualmente il codice generato da LLM invece di incollarlo in un progetto. La discussione associata ha raggiunto 105 punti e 83 commenti, secondo l’istantanea catturata della prima pagina. Questa reazione riflette un conflitto più ampio della velocità di digitazione.

Il saggio originale mette in discussione una promessa centrale degli strumenti di AI coding. Questi sistemi fanno risparmiare tempo producendo implementazioni complete, ma la stessa comodità può separare gli sviluppatori dal ragionamento incorporato nel loro software. Il rimedio proposto da Sethi reintroduce attrito proprio nel momento in cui l’automazione cerca di eliminarlo.

Il conflitto principale non è tra codice scritto da esseri umani e codice scritto da macchine. È tra velocità di consegna e comprensione conservata. Anthropic, ricercatori accademici, responsabili engineering e sviluppatori indipendenti stanno ora esaminando diverse versioni di questo compromesso.

La riscrittura manuale è una risposta insolitamente rigorosa. Offre anche un test chiaro di ciò che lo sviluppo assistito dall’AI ha cambiato. Se copiare il codice tramite tastiera migliora la comprensione, allora digitare aveva più valore cognitivo di quanto il settore supponesse.

Se non lo fa, la proposta diventa un costoso teatro. I team passerebbero tempo a riprodurre sintassi generata senza ottenere un modello mentale affidabile. L’argomento su Hacker News conta perché entrambi gli esiti sono plausibili.

Cosa ha effettivamente cambiato il dibattito su Hacker News

La proposta ha trasformato il debito cognitivo da un avvertimento astratto in una decisione concreta sul flusso di lavoro.

Il debito cognitivo descrive la comprensione umana persa o rimandata dopo che il ragionamento è stato delegato a uno strumento. Si differenzia dal normale debito tecnico, che risiede nella struttura del codice, nelle scorciatoie, nelle dipendenze o nei test mancanti. Il debito cognitivo risiede in parte nelle persone responsabili di quel codice.

Il problema rimane spesso invisibile durante la generazione. Uno sviluppatore chiede a un assistente di creare una funzionalità, verifica che i test passino e procede al compito successivo. Il codice può apparire pulito mentre la comprensione dello sviluppatore resta superficiale.

Quel divario diventa visibile più tardi. Un guasto in produzione attraversa diverse astrazioni generate, oppure una modifica apparentemente locale influenza un’assunzione non documentata. Il team deve quindi ricostruire un ragionamento che nessuno aveva formato completamente durante l’implementazione.

La proposta di Sethi impone un pedaggio al codice prima che entri nel repository. Riscrivere ogni riga generata rallenta l’accettazione e costringe lo sviluppatore a confrontarsi con nomi, condizioni, trasformazioni dei dati e flusso di controllo. Il metodo considera la ricostruzione fisica come un punto di controllo dell’attenzione.

È per questo che l’idea ha suscitato discussione. I critici possono ragionevolmente chiedersi se l’attività sulla tastiera equivalga alla comprensione. I sostenitori possono rispondere che la lettura passiva diventa spesso superficiale, soprattutto quando l’output generato appare rifinito e internamente coerente.

La discussione su Hacker News ha reso visibile questo disaccordo. Alcuni sviluppatori hanno considerato la riscrittura un utile freno all’accettazione sconsiderata. Altri l’hanno vista come una rinuncia al principale vantaggio di produttività della generazione di codice.

Entrambe le reazioni individuano lo stesso cambiamento. Gli assistenti AI ora possono produrre implementazioni più rapidamente di quanto molti sviluppatori riescano a ispezionarle. Il collo di bottiglia si è spostato dalla creazione del codice alla costruzione di una fiducia giustificata in esso.

La revisione del codice tradizionale presupponeva che qualcuno avesse già affrontato le difficoltà dell’implementazione. Questa assunzione si indebolisce quando un modello fornisce un’intera modifica. I revisori possono ricevere codice rifinito senza la storia dei tentativi falliti che ne ha plasmato la forma finale.

La riscrittura manuale cerca di ricreare una parte di quella storia mancante. Non può ricreare ogni decisione di progettazione, ma interrompe l’accettazione istantanea. Lo sviluppatore deve dedicare attenzione prima che il codice diventi normale materiale di progetto.

La proposta funziona quindi meno come una tecnica di digitazione e più come una policy. Dice che il codice generato non dovrebbe oltrepassare il confine per diventare codice posseduto senza un costo umano deliberato.

Perché il debito cognitivo sta diventando un vincolo ingegneristico

L’AI coding può aumentare l’output visibile riducendo al tempo stesso la comprensione necessaria per validare e mantenere tale output.

Le prove a sostegno di questa preoccupazione sono ancora in evoluzione, ma hanno superato l’aneddotica. Anthropic ha pubblicato nel gennaio 2026 uno studio controllato randomizzato che ha coinvolto 52 ingegneri software, perlopiù junior. I partecipanti hanno imparato una libreria Python con o senza assistenza AI.

Il gruppo assistito dall’AI ha completato il compito circa due minuti più velocemente in media. Tuttavia, questa differenza di velocità non era statisticamente significativa. Il risultato sull’apprendimento era molto più chiaro.

I partecipanti che usavano l’AI hanno ottenuto in media il 50 percento nel quiz successivo. Il gruppo che programmava manualmente ha ottenuto in media il 67 percento. Anthropic ha descritto la differenza di 17 punti come quasi l’equivalente di due voti scolastici.

Il divario maggiore è emerso nelle domande di debugging. Questo dettaglio conta perché il debugging richiede più che riconoscere una sintassi plausibile. Gli sviluppatori devono individuare assunzioni errate, tracciare l’esecuzione e spiegare perché il comportamento osservato differisca da quello previsto.

Lo studio sulle competenze di coding di Anthropic non ha rilevato che ogni forma di utilizzo dell’AI danneggiasse l’apprendimento. I risultati variavano in base al modo in cui i partecipanti usavano l’assistente. La delega intensiva e il debugging guidato dall’AI sono stati associati a punteggi del quiz inferiori al 40 percento.

I partecipanti con punteggi più alti hanno adottato modelli di interazione diversi. Alcuni hanno posto domande concettuali, chiesto spiegazioni o verificato la propria comprensione dopo aver generato codice. Questi gruppi hanno ottenuto in media almeno il 65 percento.

Questa distinzione rafforza la preoccupazione di fondo di Sethi, indebolendo però la versione più radicale del suo rimedio. La ricerca sostiene il coinvolgimento attivo, ma non stabilisce che la riscrittura manuale sia il meccanismo necessario.

Lo studio presenta anche limiti importanti. Il campione era piccolo, i partecipanti erano perlopiù junior e la valutazione si è svolta poco dopo il compito di programmazione. I punteggi immediati del quiz non possono stabilire un declino professionale a lungo termine.

L’esperimento ha utilizzato un esercizio di apprendimento circoscritto che coinvolgeva una libreria non familiare. Non ha misurato un ingegnere esperto che automatizza codice boilerplate noto. Differiva inoltre da un ambiente agentico completo, che modifica più file, esegue comandi e revisiona il proprio output.

Queste limitazioni non cancellano il risultato. Definiscono il campo di applicazione delle prove. L’assistenza AI sembra più rischiosa quando gli sviluppatori stanno acquisendo conoscenze che serviranno in seguito per la supervisione.

Un altro studio del 2026 ha esaminato 621 diari riflessivi di 207 studenti nell’arco di otto settimane. I ricercatori hanno definito il debito di comprensione come il divario tra ciò che un team sa e ciò che deve comprendere per mantenere efficacemente il software.

Il conseguente studio sul debito di comprensione ha identificato quattro modelli di accumulo. Includevano l’accettazione a scatola nera, il disallineamento di contesto, l’atrofia delle competenze indotta dalle dipendenze e la verifica aggirata.

I ricercatori hanno anche riscontrato un modello mitigante. Talvolta gli studenti usavano l’AI come impalcatura per la comprensione, ossia l’assistente li aiutava a costruire comprensione anziché sostituirla. Questo modello punta ancora una volta alla qualità dell’interazione, piuttosto che a un semplice divieto di generazione.

La pressione ricade ora sui team engineering che adottano l’AI attraverso obiettivi di produttività. Se misurano modifiche integrate, ticket completati o righe generate senza misurare la comprensione, premiano la creazione di obblighi nascosti.

I manager ricevono così un output più rapido oggi e un onere di manutenzione più difficile da osservare domani. Gli sviluppatori senior possono assorbire tale onere attraverso revisioni, risposta agli incidenti e ricostruzione architetturale.

Riscrivere manualmente il codice generato da LLM cambia l’equazione dei costi

La riscrittura è preziosa quando attiva previsione e spiegazione, non quando si limita a riprodurre caratteri.

Si consideri un handler di autenticazione generato. Uno sviluppatore che lo incolla potrebbe scorrere i nomi delle funzioni, eseguire i test e accettare la modifica. Uno sviluppatore che lo riscrive deve almeno passare attraverso ogni condizione e accesso ai dati.

Quel contatto aggiuntivo può mettere in luce dettagli sospetti. Il modello potrebbe validare un token dopo aver letto dati protetti, confondere l’autenticazione con l’autorizzazione oppure restituire errori diversi che rivelano l’esistenza di un account. La riscrittura crea più occasioni per notare queste scelte.

Tuttavia, uno sviluppatore può riprodurre il codice senza comprenderlo. Le persone copiano regolarmente testo pensando ad altro. La sintassi familiare può diventare attività motoria molto prima di trasformarsi in un modello mentale affidabile.

Il meccanismo utile è l’elaborazione attiva. Prima di inserire una condizione generata, lo sviluppatore prevede ciò che dovrebbe fare. Dopo aver inserito una funzione, ne spiega il contratto e ne mette in discussione il comportamento in caso di errore.

La riscrittura può sostenere questo processo perché controlla il ritmo. Impedisce che una patch di grandi dimensioni appaia istantaneamente e impone un’ispezione alla risoluzione della singola riga. Non garantisce il ragionamento collegato a tale ispezione.

Questa distinzione separa l’attrito utile dal rituale. Un rituale chiede se lo sviluppatore abbia digitato ogni carattere. Un controllo della comprensione chiede se lo sviluppatore sappia prevedere il comportamento, identificare le assunzioni e modificare il progetto senza consultare il modello.

La migliore versione della proposta di Sethi necessita quindi di una regola complementare. Il codice generato dovrebbe essere riscritto nella struttura propria dello sviluppatore ogni volta che la struttura originale non sia giustificata in modo indipendente.

Rinominare le variabili non basta. Lo sviluppatore dovrebbe decidere se l’astrazione sia appropriata, se il confine degli errori sia corretto e se la dipendenza generata si adatti al progetto. Queste decisioni stabiliscono la responsabilità.

Questo processo può essere particolarmente prezioso per librerie non familiari, percorsi sensibili alla sicurezza, sistemi concorrenti e operazioni irreversibili sui dati. Queste aree puniscono la comprensione superficiale perché un codice plausibile può nascondere fallimenti al di fuori dell’esecuzione normale.

Riscrivere ogni fixture di test generata offre meno valore. Lo stesso vale per adapter ripetitivi, migrazioni meccaniche o codice derivato da un modello già revisionato. Policy uniformi possono sprecare attenzione su materiale a basso rischio.

Una policy basata sul rischio preserva l’intuizione centrale senza trasformare la digitazione in una tassa universale. I team possono richiedere la ricostruzione per logiche nuove o rilevanti, consentendo al contempo l’automazione per trasformazioni circoscritte.

La decisione dovrebbe seguire la responsabilità, non la paternità. Anche il codice scritto da esseri umani può essere frainteso, soprattutto se ereditato da un altro team. Il codice generato aumenta semplicemente la velocità con cui implementazioni non possedute possono entrare in un sistema.

La ricostruzione manuale crea anche un utile segnale sociale. Comunica ai revisori che lo sviluppatore che invia la modifica ha trascorso del tempo al suo interno. Tuttavia, i team dovrebbero evitare di trattare questo segnale come una prova.

I revisori hanno comunque bisogno di test, analisi delle minacce, contratti delle interfacce e comportamento osservabile. Una vulnerabilità digitata rimane una vulnerabilità. Un progetto ben compreso può comunque essere sbagliato.

Il vero avversario è la velocità senza responsabilità

Il conflitto centrale non riguarda se l’AI scriva codice, ma se un essere umano responsabile possa spiegare e modificare in sicurezza ciò che viene rilasciato.

I fornitori di coding con AI sottolineano spesso la velocità di completamento, l’automazione e una copertura più ampia delle attività. Sono vantaggi reali per molte attività ripetitive o familiari. Il problema nasce quando la velocità diventa la principale prova del successo.

Una funzionalità completata non è soltanto un artefatto. È anche un insieme di presupposti su utenti, dipendenze, errori, autorizzazioni e modifiche future. Qualcuno deve farsi carico di tali presupposti dopo la conclusione della conversazione che l’ha generata.

La programmazione tradizionale spesso costruiva comprensione attraverso l’attrito. Gli sviluppatori interpretavano male la documentazione, incontravano errori del compilatore, verificavano ipotesi e rivedevano i progetti. Quei passaggi frustranti formavano una mappa del sistema.

L’AI può eliminare molti fallimenti intermedi. Questo migliora le prestazioni immediate, ma può anche cancellare le esperienze che insegnano agli sviluppatori dove un sistema si piega o si rompe. Il codice finale arriva senza lo stesso percorso cognitivo.

Questo non è un argomento a favore della conservazione di difficoltà inutili. Anche compilatori, framework e linguaggi ad alto livello moderni eliminano lavoro. Di solito sostituiscono lo sforzo a basso livello con astrazioni stabili su cui gli sviluppatori possono ragionare.

I sistemi generativi operano diversamente. Possono produrre un’implementazione su misura che appare autorevole senza offrire un’astrazione durevole né una garanzia comportamentale coerente. Lo sviluppatore deve valutare ogni volta un nuovo artefatto.

Questo rende la titolarità della responsabilità la risorsa scarsa. Un team possiede il codice quando sa spiegare il progetto, prevedere i comportamenti importanti, diagnosticare i guasti e modificare il sistema senza una dipendenza cieca dal generatore.

La titolarità può esistere senza digitazione manuale. Uno sviluppatore potrebbe generare una patch, scomporla, riscrivere le sezioni critiche, aggiungere test avversariali e spiegare l’intera modifica durante la revisione. Questo flusso di lavoro richiede più comprensione che riscrivere ciecamente ogni riga.

Vale anche il contrario. Uno sviluppatore potrebbe inserire manualmente codice generato preservando ogni decisione opaca. L’atto fisico soddisferebbe la regola visibile di Sethi senza saldare l’obbligo cognitivo.

L’obiezione più forte alla riscrittura obbligatoria è quindi economica. Consuma tempo in proporzione alla lunghezza del codice, mentre il rischio di comprensione non cresce ordinatamente con il numero di righe.

Dieci righe che modificano l’autorizzazione possono comportare più rischi di centinaia di definizioni di serializzazione generate. Una politica basata soltanto sulle battute di tastiera dedica attenzione nelle unità sbagliate.

Un’unità migliore è la decisione non verificata. I team dovrebbero individuare i punti in cui il modello ha scelto architettura, confini di fiducia, dipendenze, comportamento di persistenza o recupero dagli errori. Queste scelte meritano una ricostruzione attiva.

Questo approccio evita anche di presentare l’AI come un avversario. L’avversario utile è la velocità priva di titolarità, indipendentemente dallo strumento che ha prodotto il codice.

Gli sviluppatori possono usare gli assistenti per indagine concettuale, progetti alternativi, generazione di test o scoperta della documentazione. Questi utilizzi possono rafforzare la comprensione quando l’essere umano rimane responsabile del ragionamento finale.

I team hanno bisogno anche di registrazioni durevoli oltre alle trascrizioni delle chat. Decisioni architetturali, alternative scartate e presupposti operativi dovrebbero entrare in documentazione ricercabile. Una base di conoscenza tecnica può conservare il contesto che altrimenti scomparirebbe con una sessione AI.

Quella documentazione non può sostituire la comprensione del codice. Può ridurre il costo di ricostruire il contesto quando cambiano i manutentori o si verificano incidenti mesi dopo.

Cosa Non Dimostra l’Argomento della Riscrittura

Le prove disponibili sostengono un coinvolgimento deliberato, ma non dimostrano che la riscrittura manuale prevenga il debito cognitivo.

La proposta di Sethi è attraente perché semplice, visibile e immediatamente attuabile. Questi punti di forza possono farla diffondere più rapidamente delle prove che la sostengono. I team di ingegneria dovrebbero separare la diagnosi di fondo dalla cura prescritta.

La diagnosi gode di un sostegno crescente. Gli sviluppatori possono produrre codice funzionante senza trattenere conoscenze sufficienti per eseguirne il debug o estenderlo. I ricercatori hanno osservato schemi correlati in esperimenti controllati e progetti educativi.

La cura resta incerta. Nessuno studio citato confronta direttamente codice LLM incollato con codice LLM riscritto manualmente in attività professionali realistiche. Senza tale confronto, le affermazioni causali sulla riscrittura andrebbero oltre le prove.

L’esperimento di Anthropic offre un indizio importante. I partecipanti con i punteggi più alti usavano spesso l’AI per migliorare la comprensione, ma solo due partecipanti hanno seguito il modello generazione-poi-comprensione. Quel sottogruppo è troppo piccolo per stabilire una regola generale.

L’indagine concettuale ha dato buoni risultati nello studio. I partecipanti chiedevano all’assistente informazioni sulle idee e poi scrivevano il codice in autonomia. Questo comportamento assomiglia più a un apprendimento guidato che a una trascrizione.

Questa scoperta suggerisce un intervento concorrente. I team potrebbero limitare l’AI a domande, critiche di progetto, scoperta della documentazione o suggerimenti per i test quando gli sviluppatori stanno imparando materiale non familiare. Potrebbero consentire una generazione più ampia per attività ben comprese.

Tale politica preserverebbe lo sforzo cognitivo senza richiedere di reinserire ogni carattere. Allineerebbe inoltre la restrizione al rischio di apprendimento invece che al volume di codice.

Un’altra incertezza riguarda l’adattamento a lungo termine. Gli sviluppatori potrebbero inizialmente trattenere meno informazioni usando un nuovo assistente, per poi sviluppare migliori abitudini di verifica. In alternativa, la delega costante potrebbe amplificare il divario nel tempo.

Gli studi brevi non possono distinguere queste traiettorie. La ricerca longitudinale deve misurare se gli ingegneri riescono a diagnosticare incidenti, modificare vecchio codice generato e trasferire conoscenze a problemi non familiari mesi dopo.

Gli effetti sul team introducono un’ulteriore complicazione. Uno sviluppatore può comprendere a fondo una modifica generata, mentre i revisori restano dipendenti da quella persona. Il debito cognitivo può accumularsi collettivamente anche quando esiste una titolarità individuale.

Al contrario, walkthrough strutturati possono distribuire la conoscenza senza richiedere a ogni revisore di digitare il codice. Programmazione in coppia, revisioni di progetto, esercitazioni sugli incidenti e approvazioni basate sulla spiegazione possono rendere condivisa la comprensione.

La proposta rischia inoltre di svantaggiare gli sviluppatori che usano la generazione come strumento di accessibilità. La digitazione manuale può imporre costi fisici non necessari. Qualsiasi politica dovrebbe valutare direttamente la comprensione invece di usare le battute di tastiera come indicatore universale.

La sicurezza costituisce il test più severo. Riscrivere una chiamata a una dipendenza non rivela un pacchetto vulnerabile, un’impostazione predefinita non sicura o una lacuna nella conoscenza del modello. Analisi statica, revisione delle dipendenze e test avversariali restano necessari.

Le affermazioni sulla produttività meritano uguale scetticismo. Una generazione più rapida non produce automaticamente una consegna più rapida, ma una digitazione più lenta non produce automaticamente una manutenzione migliore. I team hanno bisogno di prove dai propri repository.

Un utile esperimento interno confronterebbe tassi di fallimento delle modifiche, revisioni richieste durante la code review, tempi di recupero dagli incidenti e velocità delle modifiche successive tra diversi tipi di flusso di lavoro. L’obiettivo non è contare i suggerimenti accettati.

La misura critica è se il team riesce a operare il codice in sicurezza dopo che il modello ha lasciato la conversazione.

Cosa Dovrebbero Osservare Ora i Lettori di Hacker News

La prossima fase sarà decisa da risultati di manutenzione misurati, progettazione dei prodotti e politiche di ingegneria, non dall’ideologia della digitazione.

Il primo segnale è una migliore ricerca longitudinale. I quiz brevi mostrano differenze immediate nella comprensione, ma l’ingegneria di produzione si svolge nell’arco di mesi e anni. I ricercatori devono seguire il modo in cui gli sviluppatori assistiti dall’AI affrontano modifiche e guasti successivi.

Prove di diagnosi degli incidenti più lente o di maggiore rilavorazione rafforzerebbero l’argomento del debito cognitivo. Prove che gli sviluppatori recuperino la comprensione attraverso l’uso successivo indebolirebbero le affermazioni di danno duraturo.

Il secondo segnale è come gli strumenti di coding cambiano le proprie interfacce. Oggi molti prodotti ottimizzano l’accettazione di patch di grandi dimensioni, l’esecuzione di piani e il completamento delle attività con interventi minimi. Questi progetti privilegiano naturalmente l’output.

Modalità di apprendimento, prompt di spiegazione, diff graduali e checkpoint di previsione offrono una direzione diversa. Uno strumento potrebbe chiedere agli sviluppatori di dichiarare il comportamento atteso prima di mostrare il codice generato. Potrebbe richiedere spiegazioni per le decisioni ad alto rischio.

Anthropic indica già nelle sue ricerche modalità di interazione orientate all’apprendimento. La domanda importante è se queste funzionalità rimarranno percorsi secondari opzionali o diventeranno parte dei normali flussi di lavoro professionali.

Il terzo segnale è se le organizzazioni di ingegneria ridefiniranno la produttività. Le righe generate e i ticket completati sono facili da contare. La fiducia dei manutentori, la profondità delle revisioni e la conoscenza del sistema trattenuta sono più difficili da misurare.

Le politiche riveleranno ciò che le aziende valorizzano davvero. Alcuni team potrebbero richiedere note di progetto, walkthrough dal vivo o test scritti da esseri umani per le modifiche generate. Altri potrebbero affidarsi a revisori AI aggiuntivi e a valutazioni automatizzate.

Nessuna delle due strade garantisce il successo. La revisione umana può diventare cerimoniale, mentre i controlli automatizzati rilevano solo le condizioni per cui sono stati progettati. I team maturi combineranno controlli a livello di codice con una titolarità esplicita.

Osservate come la responsabilità emerge nelle pull request. Lo sviluppatore che invia la modifica spiega il progetto generato e le alternative scartate? Un altro ingegnere può modificare il cambiamento senza riaprire la conversazione originaria con il modello?

Osservate anche la risposta agli incidenti. Se i team chiedono ripetutamente a un assistente di correggere guasti causati da codice generato in precedenza, potrebbero creare una dipendenza ricorsiva. Ogni riparazione può aggiungere comportamenti che sempre meno persone comprendono.

Il dibattito di hacker news dell’agosto 2026 non dovrebbe concludersi con un verdetto sulla digitazione. Il suo valore duraturo è la domanda che impone alla pratica ingegneristica: quali prove dimostrano che uno sviluppatore possiede il codice generato?

I team possono iniziare con uno standard ristretto. Richiedete agli sviluppatori di prevedere il comportamento, spiegare le decisioni importanti e modificare autonomamente i percorsi critici. Usate la riscrittura manuale quando sostiene questi obiettivi, specialmente durante l’apprendimento.

Mantenete l’automazione dove l’attività è vincolata, familiare e ben testata. Intensificate la revisione quando il modello prende decisioni architetturali o sensibili alla sicurezza. Registrate il ragionamento dove i futuri manutentori potranno recuperarlo.

Il flusso di lavoro corretto varierà in base al sistema e al rischio. Il principio dovrebbe rimanere stabile: consegnare codice trasferisce la responsabilità agli esseri umani, anche quando gli esseri umani non ne hanno generato la prima bozza.

Prima di accettare la prossima grande patch AI, ponete una domanda pratica. L’ingegnere responsabile potrebbe eseguirne il debug durante un’interruzione senza chiedere allo stesso modello di spiegarsi? Se la risposta non è chiara, il team deve già acquisire maggiore comprensione.

La riscrittura può aiutare a recuperare quel debito, ma è solo un metodo di recupero. Il vero obiettivo è il giudizio trattenuto, non l’attività sulla tastiera. Questa è la lezione più incisiva dietro l’argomento di hacker news, e quella che i team di ingegneria dovrebbero verificare nel proprio lavoro.