Us vs. Them arriva su Hacker News. Le sue etichette Umano vs. AI dipendono dall’identità Git

Us vs. Them è arrivato su Hacker News con 42 punti e un conflitto che gli editor agentici creano sempre più spesso: su quali righe un’AI dovrebbe esitare a intervenire?

L’esperimento open source assegna punteggi umano-versus-agente a intervalli di testo ripercorrendo la cronologia Git di un file. Non richiede etichette all’interno del documento. Questo rende il suo approccio insolitamente compatibile con i repository esistenti, ma la semplicità nasconde una dipendenza critica.

Il sistema non rileva se la prosa suona artificiale. Si fida invece dell’identità associata a ogni revisione e calcola in che modo le modifiche successive alterano l’autorialità precedente. L’avversario principale, quindi, non è l’essere umano contro i modelli. È la cronologia esplicita delle revisioni contro un’identità incerta.

Questa distinzione conta man mano che gli agenti di coding ottengono l’autorizzazione a modificare interi repository. Un modello può ora riscrivere documentazione, configurazione, test e codice di produzione in un’unica sessione. I team hanno bisogno di qualcosa in più di un diff finale per decidere quali modifiche meritino una revisione approfondita.

Us vs. Them propone un segnale di controllo piccolo ma provocatorio. Le regioni scritte da esseri umani diventano “isole” protette, mentre le regioni scritte dalle macchine restano più facili da sostituire per un altro agente. L’idea trasforma la provenienza da etichetta informativa in una politica di modifica.

Il progetto di Hacker News trasforma la cronologia Git in punteggi di autorialità

Us vs. Them considera ogni revisione salvata come una prova, poi porta tale prova in avanti man mano che gli autori successivi modificano lo stesso testo.

Lo sviluppatore, identificato su GitHub come eighttrigrams, descrive il progetto come una provenienza del testo a livello di riga nell’ambito dell’editing agentico. Il suo repository del progetto offre sia una libreria sia un’interfaccia da riga di comando.

L’implementazione parte da una serie ordinata di versioni del documento. Ogni versione deve avere un autore identificabile, classificabile come umano o agente. Lo strumento confronta quindi quelle versioni anziché esaminare soltanto il testo finale.

L’output raggruppa le righe in intervalli e assegna a ogni intervallo un punteggio. Un punteggio di 1.00 rappresenta un intervallo interamente scritto da un umano. Un punteggio di 0.00 rappresenta un intervallo interamente scritto da un agente.

I valori intermedi descrivono una cronologia mista. Il repository indica 0.46 come esempio di un intervallo originato da un umano e poi modificato dagli agenti. Ciò produce uno spettro invece di forzare ogni riga sopravvissuta in una categoria binaria.

Il progetto definisce le regioni umane coerenti “isole” all’interno di un “mare” di testo generato. Questa metafora riflette un’importante scelta progettuale. L’unità protetta non è sempre una singola riga invariata.

Un editor potrebbe dividere un paragrafo, unire due frasi o modificare parte di un blocco scritto da un umano. Una rigida regola dell’ultimo editor dichiarerebbe tutto il materiale toccato come scritto dalla macchina. Us vs. Them cerca di preservare parte del contributo precedente dopo una modifica parziale.

L’interfaccia attuale chiede agli utenti di classificare gli autori tramite identità Git. L’argomento --ours indica gli esseri umani, mentre ogni altra identità conta come agente. L’opzione inversa --theirs indica gli agenti e tratta tutti gli altri come umani.

Gli utenti scelgono il lato con meno identità. Lo strumento rifiuta l’uso simultaneo di entrambe le opzioni. Questo mantiene il comando semplice, pur assegnando all’operatore la responsabilità della classificazione.

Gli esempi motivanti sono concreti. Uno sviluppatore può usare un agente per generare la maggior parte di un’applicazione, quindi riscrivere personalmente un componente sensibile. Un’altra sessione non dovrebbe sostituire con leggerezza quella regione controllata dall’umano.

Lo stesso problema compare nella documentazione. Un agente può redigere un intero README prima che un manutentore ne riscriva con cura l’apertura. Gli agenti futuri dovrebbero mantenere libertà altrove, trattando però l’apertura come una deliberata scelta editoriale.

Non è soltanto una visualizzazione colorata. Il punteggio può diventare contesto per un agente, un’interfaccia di revisione o un controllo del repository. Ogni utilizzatore può applicare una soglia diversa senza modificare il documento sottostante.

Un assistente di coding potrebbe ricevere un avviso prima di modificare un intervallo con punteggio elevato. Una pull request potrebbe evidenziare le modifiche che rimuovono isole scritte da umani. Un revisore potrebbe dare priorità a tali cambiamenti senza leggere con la stessa attenzione ogni riga generata.

Questo è il cambiamento immediato del progetto. La cronologia Git, normalmente consultata dopo un problema, diventa un input per la successiva azione agentica.

L’autorialità umana sta diventando un’autorizzazione di modifica

La domanda importante non è chi meriti il merito per ogni token, ma dove l’editing automatizzato dovrebbe incontrare resistenza.

Il controllo di versione tradizionale registra le modifiche senza attribuire loro un valore morale. Una riga è corrente oppure obsoleta, indipendentemente da chi l’ha scritta. L’editing agentico cambia il significato operativo di questa neutralità.

Un agente può esaminare un’attività, scegliere file, scrivere modifiche, eseguire test e rivedere il proprio lavoro. Una maggiore autonomia aumenta il numero di errori correggibili. Espande anche l’area in cui l’intento umano può scomparire prima della revisione.

Si consideri un file di configurazione prodotto in gran parte da un assistente. Un ingegnere può restringere manualmente un’autorizzazione, aggiungere un avviso e documentare il motivo della restrizione. Un agente successivo vede soltanto testo, a meno che la cronologia non entri nel suo contesto.

Un normale diff mostra ciò che l’agente successivo ha modificato. Non segnala automaticamente che una riga rimossa rappresentava una deliberata eccezione umana. I revisori devono ricostruirne l’importanza da commenti, messaggi di commit o memoria.

Us vs. Them converte la cronologia dell’autorialità in un suggerimento leggibile dalla macchina. Un’elevata provenienza umana non dimostra che una riga sia corretta. Indica che una persona vi ha investito un diretto sforzo editoriale e potrebbe avervi codificato un giudizio da preservare.

Questo segnale mette sotto pressione due gruppi. Gli sviluppatori di agenti hanno bisogno di metodi per rispettare l’intento locale, mentre i team di ingegneria hanno bisogno di politiche che non congelino i repository attorno a ogni pressione di tasto umana.

La risposta imposta è una migliore prioritizzazione delle modifiche. Con l’aumento delle modifiche automatizzate, revisionare ogni cambiamento generato con la stessa intensità diventa difficile. I punteggi di provenienza offrono un modo per indirizzare la limitata attenzione umana.

L’idea si applica anche oltre il codice sorgente. Documenti di policy, note di ricerca, requisiti di prodotto e basi di conoscenza interne spesso combinano bozze generate con passaggi accuratamente rivisti. La loro forma finale nasconde il processo di collaborazione.

Un product manager potrebbe accettare il riepilogo di mercato di un agente, ma riscrivere personalmente la decisione e i suoi vincoli. Un altro agente dovrebbe distinguere la prosa di supporto dalla decisione approvata. Un documento piatto non offre una simile gerarchia.

Le persone creano già meccanismi di protezione informali. Aggiungono commenti come “non modificare”, isolano file, rafforzano i test o ripetono istruzioni nei prompt. Questi metodi comunicano l’importanza, ma richiedono markup manuale o infrastruttura di supporto.

La provenienza basata sui diff promette minore attrito perché Git registra già le versioni. I team non avrebbero bisogno di un formato di documento personalizzato. Markdown esistente, file sorgente e altro testo semplice potrebbero restare invariati.

Questa compatibilità conferisce al progetto di Hacker News il suo più forte vantaggio pratico. Molte proposte sulla provenienza iniziano richiedendo nuovi metadati al momento della creazione. Us vs. Them cerca di recuperare un segnale utile dalla cronologia che i team già mantengono.

Il progetto si inserisce inoltre in un cambiamento più ampio verso il lavoro sulla conoscenza consapevole della provenienza. Una base di conoscenza ingegneristica ricercabile può preservare i documenti, ma il recupero da solo non spiega chi abbia plasmato ciascun passaggio.

I sistemi agentici hanno bisogno sia di contesto sia di confini. Il contesto dice a un agente cosa contiene il repository. I confini gli dicono quali parti riflettono un controllo umano intenzionale e meritano ulteriore cautela.

È probabile che questa pressione persista perché il testo generato è economico da sostituire. L’attenzione umana non lo è. I sistemi che identificano il giudizio umano concentrato possono contribuire a proteggere la risorsa più scarsa.

Il meccanismo evita il rilevamento AI, ma eredita le assunzioni di Git

La cronologia delle versioni offre prove più solide dello stile di scrittura solo quando le identità degli autori e i percorsi di modifica restano affidabili.

La maggior parte dei rilevatori di testo AI analizza un passaggio completato e stima se i suoi schemi linguistici assomiglino all’output di un modello. Questo approccio diventa instabile dopo una revisione umana, una parafrasi o una scrittura specifica di dominio.

Us vs. Them pone una domanda più circoscritta. Non deduce chi abbia scritto il testo finale dallo stile. Ricostruisce quale autore dichiarato abbia introdotto e modificato ciascuna regione.

Questo è più vicino alla contabilità che al rilevamento. Il sistema osserva le transazioni e trasporta le informazioni sulla proprietà attraverso le modifiche successive. Non esamina la prosa per indovinare cosa l’abbia prodotta.

La ricerca descrive la co-autorialità umana e AI come un problema di attribuzione distinto. Un’ampia rassegna sull’autorialità separa l’attribuzione umana, il rilevamento AI, l’attribuzione del modello e l’attribuzione mista umano-macchina in compiti diversi.

Il caso misto è particolarmente difficile per i classificatori che analizzano soltanto l’output. Un paragrafo può iniziare come testo di un modello, ricevere una riscrittura umana, tornare a un agente e subire un’altra correzione umana. Lo stile finale non può rivelare in modo affidabile quella sequenza.

La cronologia delle versioni conserva la sequenza, supponendo che ogni stato rilevante sia stato sottoposto a commit. Fornisce inoltre un percorso spiegabile. Un revisore può ispezionare le revisioni dietro un punteggio anziché fidarsi di una probabilità opaca fornita da un classificatore.

Il modello a intervalli del progetto aggiunge un ulteriore livello. La semplice attribuzione per riga spesso identifica l’ultimo commit che ha toccato ciascuna riga. Us vs. Them cerca invece di tenere conto di regioni coerenti, divisioni, unioni e autorialità diluita.

La stessa documentazione di blame di Git illustra perché ciò diventi complicato. Git offre opzioni separate per rilevare righe spostate all’interno di un file o copiate tra file. Queste operazioni richiedono soglie di somiglianza e non possono stabilire da sole l’origine creativa.

Un diff vede cancellazione e inserimento. Non comprende se un agente abbia preservato un’idea umana riscrivendone la sintassi. Qualsiasi sistema numerico di provenienza deve tradurre la somiglianza testuale in una regola di autorialità.

Supponiamo che una persona scriva un controllo di sicurezza di quattro righe. Un agente rinomina le variabili e ristruttura la condizione senza cambiarne lo scopo. Una politica potrebbe preservare una sostanziale provenienza umana perché l’intento sopravvive.

Un’altra politica potrebbe assegnare la maggior parte dell’autorialità all’agente perché il testo superficiale è cambiato. Nessuna delle due scelte deriva automaticamente da Git. L’algoritmo di punteggio codifica un giudizio sul modo in cui il contributo sopravvive alla trasformazione.

La stessa ambiguità compare quando un agente sposta invariato un paragrafo umano. Un approccio basato sulla posizione potrebbe perderne la cronologia. Un approccio consapevole degli spostamenti può preservarla, ma solo se il matching riconosce il passaggio copiato.

Le righe brevi presentano un’altra sfida. Un’intestazione come “Requisiti di sicurezza” contiene troppo poco testo per un’analisi affidabile della somiglianza. Eppure la sua collocazione e la struttura circostante possono rappresentare una decisione umana significativa.

Il materiale generato può anche assorbire contenuti umani. Un agente potrebbe prendere tre frasi umane ed espanderle in dieci. L’intervallo risultante contiene una direzione umana, formulazioni della macchina e forse nuove affermazioni.

Us vs. Them riconosce questo aspetto attraverso l’idea della diluizione. I punteggi intermedi esprimono una storia mista anziché certezza. È sensato, ma gli utenti devono comunque sapere come ogni trasformazione modifica il numero.

Un punteggio come 0,46 sembra preciso. Il suo significato pratico dipende dall’algoritmo, dalle soglie e dai commit disponibili. I team dovrebbero trattarlo come un segnale di policy, non come una misurazione forense della titolarità creativa.

Questa distinzione protegge il contributo utile del progetto. La provenienza basata sui diff non deve risolvere la paternità legale per migliorare il comportamento degli agenti. Deve soltanto identificare le aree in cui è giustificata cautela.

L’identità dei commit è l’anello più debole nella provenienza umana vs. AI

Lo strumento può tracciare la paternità dichiarata, ma non può verificare autonomamente se un umano dichiarato abbia effettivamente scritto una revisione.

I commit Git contengono campi relativi ad autore e committer. Questi campi aiutano a ricostruire la cronologia, ma un normale repository non garantisce che l’identità indicata corrisponda alla persona alla tastiera o al modello dietro la modifica.

Un agente può operare tramite l’account locale di uno sviluppatore. Il suo commit può riportare nome ed email dello sviluppatore perché tali valori provengono dalla configurazione Git. Us vs. Them classificherebbe quella revisione in base all’identità configurata.

Può verificarsi anche il contrario quando una persona modifica tramite un account di automazione. Una correzione creata da un umano può apparire sotto l’identità di un bot. Il punteggio risultante sottostimerebbe il coinvolgimento umano.

Le sessioni condivise rendono il confine ancora meno chiaro. Una persona può chiedere a un agente una patch, modificare diverse righe e committare una sola volta il risultato combinato. L’identità del commit registra un unico autore per un processo misto.

Git supporta i trailer di co-autore, ma si tratta di dichiarazioni a livello di commit. Non associano i singoli contributori a righe specifiche. Dipendono inoltre dalla registrazione accurata della collaborazione da parte dei partecipanti.

I commit firmati migliorano la garanzia che una determinata chiave abbia approvato un oggetto Git. GitHub documenta come i commit firmati ricevano una verifica basata su firme crittografiche e identità associate.

Una firma valida non dimostra comunque la composizione manuale. Uno sviluppatore può firmare una patch prodotta da un agente dopo averla revisionata. La firma stabilisce approvazione e integrità, non l’origine fisica di ogni riga.

Questa limitazione definisce chiaramente l’avversario principale. La cronologia esplicita è migliore delle congetture stilistiche quando la cronologia è affidabile. Un’identità incerta indebolisce l’intera catena prima ancora che inizi l’algoritmo di punteggio.

La cronologia mancante crea una seconda debolezza. Alcuni team comprimono molte revisioni in un unico commit. Altri incollano l’output di un modello, lo modificano localmente e salvano solo lo stato finale.

In entrambi i casi, la collaborazione intermedia scompare. Lo strumento può analizzare solo le versioni che sopravvivono. Una cronologia lineare e pulita può quindi offrire meno provenienza di una sequenza disordinata di piccoli commit.

Il rebase può riscrivere la struttura dei commit, mentre il cherry-pick può duplicare le modifiche con nuovi metadati. Le importazioni di repository possono comprimere lo sviluppo precedente in un’unica istantanea iniziale. La generazione di file può anche sovrascrivere contenuti senza preservare stati intermedi utili.

Non sono casi limite oscuri. I team comprimono regolarmente le pull request per mantenere una cronologia leggibile. I flussi di lavoro agentici spesso creano modifiche temporanee che non ricevono mai commit individuali.

Le opzioni di classificazione del progetto introducono una terza debolezza. Ogni identità non collocata nel lato nominato riceve la classificazione opposta. Un appaltatore sconosciuto, un’integrazione o un account configurato in modo errato possono ricevere silenziosamente l’etichetta sbagliata.

Questa configurazione binaria è comoda per un prototipo. L’uso in produzione trarrebbe vantaggio da uno stato sconosciuto. Gli autori non classificati non dovrebbero diventare automaticamente umani o agenti quando le prove sono incomplete.

Una policy matura potrebbe richiedere almeno quattro categorie: umano verificato, agente dichiarato, sessione mista e sconosciuto. L’approvazione potrebbe rimanere separata dalla paternità. Ciò impedirebbe a una modifica di un agente revisionata di spacciarsi per testo scritto manualmente.

Esiste anche il rischio di proteggere eccessivamente lavoro umano debole. Un punteggio di provenienza misura la cronologia del contributo, non la correttezza. Il codice scritto da esseri umani può contenere difetti, presupposti obsoleti e schemi non sicuri.

Un agente dovrebbe esitare davanti a un intervallo con punteggio alto, ma non dovrebbe trattarlo come sacro. La risposta appropriata potrebbe essere richiedere una revisione, fornire prove più solide o proporre una modifica con una spiegazione chiara.

Al contrario, un testo con punteggio basso non è sacrificabile. Una migrazione, un test o una dichiarazione di conformità generati da un agente possono diventare operativamente importanti dopo il deployment. La dipendenza in esecuzione e l’approvazione del revisore possono pesare più della paternità iniziale.

I team hanno quindi bisogno di più segnali. La provenienza può affiancarsi a regole di ownership, copertura dei test, sensibilità alla sicurezza, incidenti recenti e approvazioni esplicite. Nessun singolo punteggio dovrebbe determinare se una modifica procede.

L’impostazione più efficace del progetto è consultiva. Può evidenziare la concentrazione umana e attivare comportamenti di revisione diversi. Presentare il suo output come prova dell’origine andrebbe oltre ciò che la cronologia del repository stabilisce.

La vera competizione è tra controllo basato sulla cronologia e metadati incorporati

Us vs. Them vince sul fronte dell’attrito di adozione, mentre i sistemi di provenienza più ricchi vincono su identità, contesto e portabilità.

La provenienza basata sulla cronologia non richiede markup speciale nel file tracciato. Questo preserva il testo semplice e mantiene i documenti compatibili con editor, renderer e repository esistenti.

L’approccio funziona anche retrospettivamente. Un team può analizzare un progetto consolidato se la relativa cronologia e le identità restano disponibili. Non è necessario che ogni contributore installi prima un’applicazione di authoring specializzata.

I metadati incorporati seguono la direzione opposta. Un editor o un agente può registrare chi ha generato, accettato, rivisto o approvato ciascun blocco nel momento dell’azione. Questo acquisisce dettagli che un diff successivo non può ricostruire.

Il costo è l’integrazione. I metadati richiedono uno schema, una posizione di archiviazione, un modello di identità e regole per copiare contenuti tra sistemi. Gli strumenti devono preservarli quando gli utenti esportano, uniscono o incollano testo.

Il markup inline può inoltre affollare i file sorgente. Un documento Markdown perde parte della sua semplicità se ogni blocco contiene tag di paternità. I file sidecar evitano il rumore visivo, ma possono disallinearsi dal contenuto che descrivono.

Us vs. Them sceglie la compatibilità rispetto alla completezza. Il suo vincolo di “nessun markup” rende possibili esperimenti immediati. Significa anche che il sistema deve inferire la continuità ogni volta che il testo cambia.

La provenienza basata sugli eventi può registrare più dell’identità dell’autore. Può acquisire il modello, il contesto del prompt, l’azione di approvazione, il materiale sorgente, la chiamata allo strumento e il revisore. Questi dettagli aiutano a spiegare perché un agente ha prodotto una modifica.

Tuttavia, più metadati non garantiscono maggiore fiducia. Un agente può etichettare erroneamente la propria attività, un’integrazione può omettere eventi e gli utenti possono aggirare l’editor strumentato. La provenienza resta affidabile solo quanto il suo percorso di acquisizione.

Un modello combinato offre la direzione più credibile. La cronologia Git può fornire un record strutturale indipendente, mentre gli eventi firmati degli agenti forniscono dati di creazione più ricchi. Le differenze tra i due record possono attivare una revisione.

Per esempio, una piattaforma di agenti potrebbe creare commit con un’identità dedicata e firmata. Potrebbe allegare una dichiarazione leggibile dalle macchine che descriva i file generati e gli intervalli approvati da esseri umani. Il repository conserverebbe sia il testo finale sia il processo dichiarato.

Le modifiche umane effettuate al di fuori di quella piattaforma apparirebbero comunque tramite la normale cronologia. Il livello basato sui diff potrebbe trasferire in avanti la loro provenienza. Gli eventi sconosciuti o in conflitto riceverebbero una confidenza inferiore anziché un’etichetta imposta.

Questa architettura trasforma il punteggio da un singolo numero di paternità in più dimensioni. Un intervallo potrebbe avere un elevato contributo umano, una modifica dell’agente confermata e un’esplicita approvazione umana.

Queste dimensioni rispondono a domande diverse. Il contributo chiede chi ha plasmato il testo. L’approvazione chiede chi ha accettato la responsabilità. L’integrità chiede se il record sia cambiato dopo la firma.

Per i team di ingegneria, l’approvazione conta spesso più della composizione. Un modello può generare codice corretto che un manutentore qualificato revisiona attentamente. Un umano può anche scrivere codice non sicuro senza una revisione significativa.

Per scrittori e ricercatori, il contributo può contare di più. Potrebbero dover dichiarare quali passaggi hanno avuto origine con un modello, anche dopo l’editing umano. Un sistema consapevole delle versioni può rivelare quella collaborazione più accuratamente di un’unica etichetta finale.

Per le organizzazioni, la conservazione e la portabilità diventano centrali. La provenienza archiviata soltanto all’interno di una piattaforma di agenti scompare quando l’organizzazione cambia strumenti. I record derivati da Git rimangono utilizzabili ovunque viaggi il repository.

Questo rende Us vs. Them meno una piattaforma completa di provenienza che una baseline utile. Dimostra quanta policy possa emergere dalla normale cronologia delle versioni. Espone anche le informazioni che la cronologia delle versioni non ha mai acquisito.

Cosa dovrebbero osservare i lettori di Hacker News

Il valore del progetto dipenderà da tre segnali: test di punteggio, integrazione degli agenti e una gestione dell’identità più solida.

Il primo segnale è se il repository amplia i propri test comportamentali attorno ai modelli di editing reali. Il progetto indica già ai lettori i test come spiegazione più chiara del suo algoritmo.

I prossimi casi utili includono riscritture di paragrafi, blocchi riordinati, sezioni copiate, merge squash, file generati e modifiche alternate tra umani e agenti. La pubblicazione dei punteggi attesi renderebbe il sistema più facile da valutare.

Questo segnale rafforzerebbe il progetto se utenti indipendenti potessero prevedere e riprodurne l’output. Grandi variazioni del punteggio dovute a formattazione minore indebolirebbero l’affermazione che una paternità coerente sopravvive al normale editing.

Il secondo segnale è l’integrazione con un agente di coding reale o un flusso di revisione. Un report da riga di comando dimostra che i punteggi possono essere calcolati. Non dimostra che le informazioni cambino il comportamento degli agenti.

Un esperimento pratico potrebbe richiedere a un agente di chiedere conferma prima di modificare intervalli al di sopra di una soglia. Un altro potrebbe dare priorità alla revisione delle pull request quando una modifica rimuove un’isola ad alta provenienza.

Il successo dovrebbe essere misurato attraverso gli esiti, non gli screenshot. Misure utili includono modifiche annullate, correzioni dei revisori, difetti mancati e richieste di approvazione non necessarie.

Troppi avvisi creerebbero affaticamento da provenienza. Troppo pochi renderebbero il sistema decorativo. La soglia migliore dipenderà probabilmente dal repository e dalla sensibilità di ciascun file.

Il terzo segnale è un modello di identità che vada oltre un’allowlist. Identità dedicate agli agenti, commit firmati, etichette per sessioni miste e uno stato sconosciuto esplicito affronterebbero la limitazione più importante del progetto.

Questa modifica rafforzerebbe la provenienza basata sulla cronologia perché migliora le prove che entrano nell’algoritmo. Senza di essa, agenti sempre più capaci potrebbero continuare a effettuare commit tramite account umani, cancellando la distinzione.

Sarebbe importante anche un formato pubblico per esportare gli intervalli. Altri agenti e strumenti di revisione hanno bisogno di un modo stabile per utilizzare il risultato. Un sidecar portabile potrebbe preservare il testo semplice evitando al tempo stesso la dipendenza da un singolo comando.

La lezione più ampia è già visibile. La provenienza AI diventa più utile quando guida una decisione anziché limitarsi a decorare un documento con un’etichetta.

Per gli sviluppatori, questa decisione riguarda se un agente possa modificare automaticamente una riga. Per i revisori, riguarda dove concentrare l’attenzione. Per le organizzazioni, riguarda quali modifiche richiedano un’approvazione umana responsabile.

Us vs. Them non risolve queste questioni di governance. Fornisce loro un input concreto derivato da un’infrastruttura che molti team già utilizzano.

L’approccio resta vulnerabile a commit incompleti, identità condivise e riscritture ambigue. Questi limiti dovrebbero orientarne l’adozione fin dall’inizio. Un punteggio dovrebbe avviare un esame approfondito, non concluderlo.

Se gestisci un repository modificato da agenti, esamina la cronologia di un file e individua dove risiede davvero il giudizio umano. Poi chiediti se il tuo prossimo agente può vedere quel confine.

Questo esercizio è più rivelatore che discutere se il testo finale “sembri scritto dall’IA”. La discussione su Hacker News suggerisce una domanda migliore: il tuo sistema di editing conserva prove sufficienti per rispettare l’intento umano?