Us vs. Them trafił na Hacker News. Jego oznaczenia ludzi i AI zależą od tożsamości Git

Us vs. Them trafił na Hacker News, zdobywając 42 punkty i uwidaczniając konflikt, który coraz częściej wywołują edytory agentowe: które wiersze AI powinno zmieniać z wahaniem?

Eksperyment open source przypisuje fragmentom tekstu wyniki człowiek-kontra-agent, odtwarzając historię Git pliku. Nie potrzebuje etykiet wewnątrz dokumentu. Dzięki temu jego podejście jest wyjątkowo zgodne z istniejącymi repozytoriami, lecz ta prostota skrywa krytyczną zależność.

System nie wykrywa, czy proza brzmi syntetycznie. Zamiast tego ufa tożsamości przypisanej do każdej rewizji i oblicza, jak późniejsze edycje zmieniają wcześniejsze autorstwo. Głównym przeciwnikiem nie są więc ludzie kontra modele. Są nim jawna historia rewizji kontra niepewna tożsamość.

To rozróżnienie ma znaczenie, gdy agenci programistyczni zyskują uprawnienia do modyfikowania całych repozytoriów. Model może teraz w ramach jednej sesji przepisywać dokumentację, konfigurację, testy i kod produkcyjny. Zespoły potrzebują czegoś więcej niż końcowego diffu, aby zdecydować, które zmiany zasługują na szczególnie dokładny przegląd.

Us vs. Them proponuje niewielki, ale prowokacyjny sygnał kontrolny. Fragmenty napisane przez ludzi stają się chronionymi „wyspami”, podczas gdy fragmenty napisane przez maszyny pozostają łatwiejsze do zastąpienia przez innego agenta. Pomysł zmienia pochodzenie tekstu z etykiety ujawniającej w politykę edycji.

Projekt z Hacker News zamienia historię Git w wyniki autorstwa

Us vs. Them traktuje każdą zapisaną rewizję jako dowód, a następnie przenosi ten dowód dalej, gdy późniejsi autorzy modyfikują ten sam tekst.

Deweloper, identyfikowany na GitHub jako eighttrigrams, opisuje projekt jako pochodzenie tekstu na poziomie wierszy w środowisku edycji agentowej. Jego repozytorium projektu udostępnia zarówno bibliotekę, jak i interfejs wiersza poleceń.

Implementacja zaczyna się od uporządkowanej serii wersji dokumentu. Każda wersja musi mieć możliwego do zidentyfikowania autora, którego można sklasyfikować jako człowieka lub agenta. Narzędzie porównuje następnie te wersje, zamiast analizować wyłącznie końcowy tekst.

Wynik grupuje wiersze w zakresy i przypisuje każdemu zakresowi ocenę. Wynik 1.00 oznacza zakres w pełni napisany przez człowieka. Wynik 0.00 oznacza zakres w pełni napisany przez agenta.

Wartości pośrednie opisują mieszaną historię. Repozytorium podaje 0.46 jako przykład zakresu zapoczątkowanego przez człowieka, który agenci później zmodyfikowali. Tworzy to spektrum zamiast wymuszać binarną kategorię dla każdego zachowanego wiersza.

Projekt nazywa spójne ludzkie obszary „wyspami” w „morzu” wygenerowanego tekstu. Ta metafora odzwierciedla ważną decyzję projektową. Chronioną jednostką nie zawsze jest pojedynczy niezmieniony wiersz.

Redaktor może podzielić akapit, połączyć dwa zdania lub dostosować część bloku napisanego przez człowieka. Ścisła reguła ostatniego edytora uznałaby cały dotknięty materiał za napisany przez maszynę. Us vs. Them próbuje zachować część wcześniejszego wkładu po częściowej modyfikacji.

Obecny interfejs prosi użytkowników o klasyfikowanie autorów na podstawie tożsamości Git. Argument --ours wskazuje ludzi, a każda inna tożsamość jest uznawana za agenta. Odwrotna opcja --theirs wskazuje agentów i traktuje wszystkich pozostałych jako ludzi.

Użytkownicy wybierają stronę z mniejszą liczbą tożsamości. Narzędzie odrzuca jednoczesne użycie obu opcji. Dzięki temu polecenie pozostaje niewielkie, choć odpowiedzialność za klasyfikację spoczywa na operatorze.

Przykłady motywujące są konkretne. Deweloper może użyć agenta do wygenerowania większości aplikacji, a następnie osobiście przepisać wrażliwy komponent. Kolejna sesja nie powinna beztrosko zastępować tego regionu kontrolowanego przez człowieka.

Ten sam problem pojawia się w dokumentacji. Agent może przygotować cały README, zanim opiekun projektu starannie przepisze jego wstęp. Przyszli agenci powinni zachować swobodę gdzie indziej, traktując wstęp jako przemyślany osąd redakcyjny.

To coś więcej niż barwna wizualizacja. Wynik może stać się kontekstem dla agenta, interfejsu przeglądu lub kontroli repozytorium. Każdy odbiorca może stosować inny próg bez zmieniania bazowego dokumentu.

Asystent programistyczny może otrzymać ostrzeżenie przed edycją zakresu z wysokim wynikiem. Pull request może wyróżniać zmiany usuwające wyspy napisane przez ludzi. Recenzent może nadawać priorytet takim zmianom, nie czytając z jednakową uwagą każdego wygenerowanego wiersza.

To bezpośrednia zmiana proponowana przez projekt. Historia Git, zwykle sprawdzana po wystąpieniu problemu, staje się wejściem do kolejnego działania agentowego.

Ludzkie autorstwo staje się uprawnieniem do edycji

Ważne pytanie nie brzmi, komu należy przypisać zasługi za każdy token, lecz gdzie zautomatyzowana edycja powinna napotykać opór.

Tradycyjna kontrola wersji rejestruje zmiany, nie przypisując im wartości moralnej. Wiersz jest aktualny lub przestarzały, niezależnie od tego, kto go napisał. Edycja agentowa zmienia operacyjne znaczenie tej neutralności.

Agent może przeanalizować zadanie, wybrać pliki, wprowadzić zmiany, uruchomić testy i poprawić swoją pracę. Większa autonomia zwiększa liczbę błędów, które można skorygować. Poszerza też obszar, w którym ludzka intencja może zniknąć przed przeglądem.

Rozważmy plik konfiguracyjny w większości utworzony przez asystenta. Inżynier może ręcznie zaostrzyć jedno uprawnienie, dodać ostrzeżenie i udokumentować, dlaczego ograniczenie istnieje. Późniejszy agent widzi jedynie tekst, chyba że historia zostanie uwzględniona w jego kontekście.

Zwykły diff pokazuje, co zmienił późniejszy agent. Nie sygnalizuje automatycznie, że jeden usunięty wiersz był celowym ludzkim wyjątkiem. Recenzenci muszą odtworzyć jego znaczenie z komentarzy, komunikatów commitów lub pamięci.

Us vs. Them przekształca historię autorstwa w wskazówkę czytelną dla maszyny. Wysokie ludzkie pochodzenie nie dowodzi, że wiersz jest poprawny. Mówi, że dana osoba włożyła w niego bezpośredni wysiłek redakcyjny i mogła zakodować osąd wart zachowania.

Sygnał ten wywiera presję na dwie grupy. Twórcy agentów potrzebują metod respektowania lokalnej intencji, a zespoły inżynieryjne potrzebują polityk, które nie zamrożą repozytoriów wokół każdego ludzkiego naciśnięcia klawisza.

Wymuszoną odpowiedzią jest lepsze ustalanie priorytetów zmian. Wraz ze wzrostem liczby zautomatyzowanych edycji przeglądanie każdej wygenerowanej modyfikacji z jednakową intensywnością staje się trudne. Wyniki pochodzenia oferują jeden ze sposobów kierowania ograniczoną ludzką uwagą.

Ta idea wykracza też poza kod źródłowy. Dokumenty polityk, notatki badawcze, wymagania produktowe i wewnętrzne bazy wiedzy często łączą wygenerowane szkice ze starannie poprawionymi fragmentami. Ich końcowa forma ukrywa proces współpracy.

Menedżer produktu może zaakceptować przygotowane przez agenta podsumowanie rynku, ale osobiście przepisać decyzję i jej ograniczenia. Inny agent powinien odróżniać tekst pomocniczy od zatwierdzonej decyzji. Płaski dokument nie oferuje takiej hierarchii.

Ludzie już tworzą nieformalne mechanizmy ochrony. Dodają komentarze takie jak „nie zmieniać”, wydzielają pliki, wzmacniają testy lub powtarzają instrukcje w promptach. Metody te komunikują znaczenie, ale wymagają ręcznego oznaczania lub wspierającej infrastruktury.

Pochodzenie oparte na diffach obiecuje mniejsze tarcie, ponieważ Git już rejestruje wersje. Zespoły nie potrzebowałyby niestandardowego formatu dokumentu. Istniejący Markdown, pliki źródłowe i inne zwykłe teksty mogłyby pozostać niezmienione.

Ta zgodność zapewnia projektowi z Hacker News jego najsilniejszy praktyczny argument. Wiele propozycji dotyczących pochodzenia zaczyna się od wymagania nowych metadanych w chwili tworzenia. Us vs. Them próbuje odzyskać użyteczny sygnał z historii, którą zespoły już utrzymują.

Projekt wpisuje się również w szerszą zmianę w kierunku pracy z wiedzą uwzględniającej pochodzenie. Przeszukiwalna inżynieryjna baza wiedzy może zachowywać dokumenty, lecz samo wyszukiwanie nie wyjaśnia, kto ukształtował każdy fragment.

Systemy agentowe potrzebują zarówno kontekstu, jak i granic. Kontekst mówi agentowi, co zawiera repozytorium. Granice wskazują, które części odzwierciedlają celową ludzką kontrolę i zasługują na dodatkową ostrożność.

Presja prawdopodobnie się utrzyma, ponieważ wygenerowany tekst jest tani do zastąpienia. Ludzka uwaga nie. Systemy identyfikujące skoncentrowany ludzki osąd mogą pomóc chronić rzadszy zasób.

Mechanizm unika wykrywania AI, lecz dziedziczy założenia Git

Historia wersji stanowi mocniejszy dowód niż styl pisania tylko wtedy, gdy tożsamości autorów i ścieżki edycji pozostają wiarygodne.

Większość detektorów tekstu AI analizuje ukończony fragment i szacuje, czy jego wzorce językowe przypominają dane wyjściowe modelu. Podejście to staje się niestabilne po ludzkiej rewizji, parafrazie lub pisaniu specyficznym dla danej dziedziny.

Us vs. Them zadaje węższe pytanie. Nie wnioskuje, kto napisał końcowy tekst na podstawie stylu. Odtwarza, który zadeklarowany autor wprowadził i zmodyfikował każdy region.

Jest to bliższe księgowości niż wykrywaniu. System obserwuje transakcje i przenosi informacje o własności przez późniejsze zmiany. Nie analizuje prozy i nie zgaduje, co ją wytworzyło.

Badania opisują współautorstwo ludzi i AI jako odrębny problem atrybucji. Szeroki przegląd autorstwa rozdziela atrybucję ludzką, wykrywanie AI, atrybucję modelu i mieszaną atrybucję człowiek-maszyna na różne zadania.

Przypadek mieszany jest szczególnie trudny dla klasyfikatorów opartych wyłącznie na wyniku końcowym. Akapit może zacząć się jako tekst modelu, zostać przepisany przez człowieka, wrócić do agenta, a następnie przejść kolejną ludzką korektę. Końcowy styl nie może wiarygodnie ujawnić tej sekwencji.

Historia wersji zachowuje sekwencję, zakładając, że każdy istotny stan został zatwierdzony commitem. Zapewnia również możliwą do wyjaśnienia ścieżkę. Recenzent może sprawdzić rewizje stojące za wynikiem, zamiast ufać nieprzejrzystemu prawdopodobieństwu klasyfikatora.

Model zakresów projektu dodaje kolejną warstwę. Prosta atrybucja wierszy często identyfikuje ostatni commit, który dotknął każdego wiersza. Us vs. Them próbuje natomiast uwzględniać spójne regiony, podziały, połączenia i rozmyte autorstwo.

Własna dokumentacja blame Git ilustruje, dlaczego staje się to skomplikowane. Git oferuje osobne opcje wykrywania wierszy przeniesionych w obrębie pliku lub skopiowanych między plikami. Operacje te wymagają progów podobieństwa i same w sobie nie mogą ustalić twórczego pochodzenia.

Diff widzi usunięcie i wstawienie. Nie rozumie, czy agent zachował ludzką ideę, przepisując jej składnię. Każdy numeryczny system pochodzenia musi przełożyć podobieństwo tekstu na regułę autorstwa.

Załóżmy, że osoba pisze czterowierszową kontrolę bezpieczeństwa. Agent zmienia nazwy zmiennych i restrukturyzuje warunek, nie zmieniając jego celu. Jedna polityka może zachować znaczące ludzkie pochodzenie, ponieważ intencja przetrwała.

Inna polityka może przypisać większość autorstwa agentowi, ponieważ zmienił się tekst powierzchniowy. Żaden z tych wyborów nie wynika automatycznie z Git. Algorytm punktacji koduje osąd dotyczący tego, jak wkład przetrwa transformację.

Ta sama niejednoznaczność pojawia się, gdy agent przenosi ludzki akapit bez zmian. Podejście oparte na lokalizacji może utracić jego historię. Podejście uwzględniające przeniesienia może ją zachować, lecz tylko jeśli dopasowanie rozpozna skopiowany fragment.

Krótkie wiersze stanowią kolejne wyzwanie. Nagłówek taki jak „Wymagania bezpieczeństwa” zawiera zbyt mało tekstu, by rzetelnie analizować podobieństwo. Jednak jego umiejscowienie i otaczająca struktura mogą odzwierciedlać istotną ludzką decyzję.

Wygenerowany materiał może również absorbować ludzką treść. Agent może wziąć trzy ludzkie zdania i rozwinąć je do dziesięciu. Powstały zakres zawiera ludzkie wskazówki, maszynowe sformułowania i być może nowe twierdzenia.

Us vs. Them uwzględnia to poprzez koncepcję rozcieńczenia. Wyniki pośrednie wyrażają mieszaną historię, a nie pewność. To ma sens, ale użytkownicy nadal muszą wiedzieć, jak każda transformacja zmienia wynik.

Wynik taki jak 0,46 wygląda precyzyjnie. Jego praktyczne znaczenie zależy od algorytmu, progów i dostępnych commitów. Zespoły powinny traktować go jako sygnał dla polityki, a nie kryminalistyczny pomiar twórczego autorstwa.

To rozróżnienie chroni użyteczny wkład projektu. Pochodzenie oparte na diffach nie musi rozstrzygać autorstwa prawnego, by poprawiać zachowanie agentów. Wystarczy, że identyfikuje obszary, w których uzasadniona jest ostrożność.

Tożsamość commita jest najsłabszym ogniwem pochodzenia człowiek kontra AI

Narzędzie może śledzić zadeklarowane autorstwo, ale nie potrafi niezależnie zweryfikować, czy zadeklarowany człowiek rzeczywiście napisał daną rewizję.

Commity Git zawierają pola autora i commitera. Pola te pomagają odtworzyć historię, lecz zwykłe repozytorium nie gwarantuje, że wskazana tożsamość odpowiada osobie przy klawiaturze lub modelowi stojącemu za zmianą.

Agent może działać przez lokalne konto dewelopera. Jego commit może zawierać nazwę i e-mail dewelopera, ponieważ wartości te pochodzą z konfiguracji Git. Us vs. Them sklasyfikuje taką rewizję zgodnie ze skonfigurowaną tożsamością.

Odwrotna sytuacja może wystąpić, gdy człowiek edytuje przez konto automatyzacji. Poprawka stworzona przez człowieka może pojawić się pod tożsamością bota. Wynik zaniży wtedy udział człowieka.

Wspólne sesje jeszcze bardziej zacierają granicę. Osoba może poprosić agenta o patch, zmodyfikować kilka linii i jednorazowo zacommitować połączony rezultat. Tożsamość commita rejestruje jednego autora dla mieszanego procesu.

Git obsługuje trailery współautorów, ale są one deklaracjami na poziomie commita. Nie przypisują odrębnych współtwórców do konkretnych linii. Zależą też od tego, czy uczestnicy poprawnie odnotują współpracę.

Podpisane commity zwiększają pewność, że określony klucz zatwierdził obiekt Git. GitHub dokumentuje, w jaki sposób signed commits otrzymują weryfikację na podstawie podpisów kryptograficznych i powiązanych tożsamości.

Prawidłowy podpis nadal nie dowodzi ręcznego stworzenia treści. Deweloper może podpisać patch wygenerowany przez agenta po jego przejrzeniu. Taki podpis potwierdza zatwierdzenie i integralność, a nie fizyczne pochodzenie każdej linii.

To ograniczenie jasno definiuje głównego przeciwnika. Jawna historia jest lepsza od zgadywania na podstawie stylu, gdy historia jest wiarygodna. Niepewna tożsamość osłabia cały łańcuch, zanim algorytm punktacji zacznie działać.

Brakująca historia tworzy drugą słabość. Niektóre zespoły squashują wiele rewizji do jednego commita. Inne wklejają wynik modelu, lokalnie go edytują i zapisują wyłącznie stan końcowy.

W obu przypadkach pośrednia współpraca znika. Narzędzie może analizować tylko wersje, które przetrwały. Czysta liniowa historia może zatem zapewniać mniej danych o pochodzeniu niż chaotyczna sekwencja małych commitów.

Rebase może przepisać strukturę commitów, a cherry-pick może zduplikować zmiany pod nowymi metadanymi. Importy repozytoriów mogą skompresować wcześniejszy rozwój do jednego początkowego zrzutu. Generowanie plików może również nadpisywać treść bez zachowania użytecznych stanów pośrednich.

Nie są to rzadkie przypadki brzegowe. Zespoły rutynowo squashują pull requesty, aby zachować czytelną historię. Przepływy pracy z agentami często tworzą tymczasowe zmiany, które nigdy nie otrzymują osobnych commitów.

Opcje klasyfikacji projektu wprowadzają trzecią słabość. Każda tożsamość, której nie umieszczono po nazwanej stronie, otrzymuje klasyfikację przeciwną. Nieznany wykonawca, integracja lub błędnie skonfigurowane konto mogą po cichu otrzymać niewłaściwą etykietę.

Taki binarny układ jest wygodny dla prototypu. Zastosowanie produkcyjne skorzystałoby na stanie „nieznany”. Niesklasyfikowani autorzy nie powinni automatycznie stawać się ludźmi ani agentami, gdy dowody są niepełne.

Dojrzała polityka może potrzebować co najmniej czterech kategorii: zweryfikowany człowiek, zadeklarowany agent, mieszana sesja i nieznany. Zatwierdzenie mogłoby pozostać oddzielone od autorstwa. Zapobiegłoby to sytuacji, w której przejrzana zmiana agenta udaje tekst napisany ręcznie.

Istnieje również ryzyko nadmiernej ochrony słabej pracy człowieka. Wynik pochodzenia mierzy historię wkładu, a nie poprawność. Kod napisany przez człowieka może zawierać błędy, nieaktualne założenia i niebezpieczne wzorce.

Agent powinien zachować ostrożność wobec zakresu o wysokim wyniku, ale nie powinien traktować go jak świętości. Właściwą reakcją może być poproszenie o przegląd, przedstawienie mocniejszych dowodów lub zaproponowanie zmiany z jasnym wyjaśnieniem.

Z kolei tekst o niskim wyniku nie jest jednorazowy. Migracja, test lub deklaracja zgodności wygenerowane przez agenta mogą stać się operacyjnie istotne po wdrożeniu. Zależność środowiska uruchomieniowego i zatwierdzenie recenzenta mogą przeważyć nad pierwotnym autorstwem.

Zespoły potrzebują zatem kilku sygnałów. Pochodzenie może funkcjonować obok zasad własności, pokrycia testami, wrażliwości bezpieczeństwa, niedawnych incydentów i jawnych zatwierdzeń. Żaden pojedynczy wynik nie powinien decydować o tym, czy edycja zostanie wykonana.

Najmocniejsze ujęcie projektu ma charakter doradczy. Może ujawniać koncentrację ludzkiego wkładu i wywoływać inne zachowania podczas przeglądu. Przedstawianie jego wyników jako dowodu pochodzenia wykraczałoby poza to, co ustala historia repozytorium.

Prawdziwa konkurencja to kontrola oparta na historii kontra osadzone metadane

Us vs. Them wygrywa pod względem barier wdrożenia, podczas gdy bogatsze systemy pochodzenia wygrywają w kwestiach tożsamości, kontekstu i przenośności.

Pochodzenie oparte na historii nie wymaga specjalnych znaczników w śledzonym pliku. Zachowuje to zwykły tekst i utrzymuje zgodność dokumentów z istniejącymi edytorami, rendererami i repozytoriami.

Podejście działa również retrospektywnie. Zespół może przeanalizować istniejący projekt, jeśli jego historia i tożsamości pozostają dostępne. Nie wymaga ono wcześniejszego zainstalowania przez każdego współtwórcę wyspecjalizowanej aplikacji do tworzenia treści.

Osadzone metadane wybierają przeciwną drogę. Edytor lub agent może w chwili działania zapisywać, kto wygenerował, zaakceptował, zmienił lub zatwierdził każdy blok. Pozwala to uchwycić szczegóły, których późniejszy diff nie potrafi odtworzyć.

Kosztem jest integracja. Metadane potrzebują schematu, miejsca przechowywania, modelu tożsamości i zasad kopiowania treści między systemami. Narzędzia muszą je zachowywać, gdy użytkownicy eksportują, scalają lub wklejają tekst.

Znaczniki inline mogą również zaśmiecać pliki źródłowe. Dokument Markdown traci część swojej prostoty, jeśli każdy blok zawiera tagi autorstwa. Pliki towarzyszące pozwalają uniknąć wizualnego szumu, ale mogą utracić synchronizację z opisywaną treścią.

Us vs. Them wybiera kompatybilność zamiast kompletności. Jego ograniczenie „bez znaczników” umożliwia natychmiastowe eksperymenty. Oznacza też, że system musi wnioskować o ciągłości zawsze, gdy tekst się zmienia.

Pochodzenie oparte na zdarzeniach może rejestrować więcej niż tożsamość autora. Może uchwycić model, kontekst promptu, działanie zatwierdzające, materiał źródłowy, wywołanie narzędzia i recenzenta. Te szczegóły pomagają wyjaśnić, dlaczego agent stworzył zmianę.

Większa ilość metadanych nie gwarantuje jednak większego zaufania. Agent może błędnie oznaczyć własną aktywność, integracja może pominąć zdarzenia, a użytkownicy mogą ominąć zinstrumentowany edytor. Pochodzenie pozostaje wiarygodne tylko tak, jak wiarygodna jest ścieżka jego rejestracji.

Najbardziej wiarygodny kierunek oferuje model łączony. Historia Git może dostarczać niezależnego zapisu strukturalnego, a podpisane zdarzenia agentów — bogatszych danych o powstaniu treści. Różnice między tymi dwoma zapisami mogą wyzwalać przegląd.

Na przykład platforma agentowa mogłaby tworzyć commity pod dedykowaną, podpisaną tożsamością. Mogłaby dołączać maszynowo czytelne oświadczenie opisujące wygenerowane pliki i zakresy zatwierdzone przez człowieka. Repozytorium zachowałoby zarówno końcowy tekst, jak i zadeklarowany proces jego powstania.

Edycje ludzkie dokonane poza tą platformą nadal pojawiałyby się w zwykłej historii. Warstwa oparta na diffach mogłaby przenosić ich pochodzenie dalej. Nieznane lub sprzeczne zdarzenia otrzymywałyby niższą pewność zamiast wymuszonej etykiety.

Taka architektura zmienia wynik z jednej liczby opisującej autorstwo w kilka wymiarów. Zakres mógłby mieć wysoki udział człowieka, potwierdzoną modyfikację agenta i jawne zatwierdzenie człowieka.

Te wymiary odpowiadają na różne pytania. Wkład pyta, kto ukształtował tekst. Zatwierdzenie pyta, kto przyjął odpowiedzialność. Integralność pyta, czy zapis zmienił się po podpisaniu.

Dla zespołów inżynieryjnych zatwierdzenie często ma większe znaczenie niż samo stworzenie treści. Model może wygenerować poprawny kod, który wykwalifikowany opiekun dokładnie przejrzy. Człowiek również może napisać niebezpieczny kod bez znaczącego przeglądu.

Dla autorów i badaczy wkład może być ważniejszy. Mogą potrzebować ujawnić, które fragmenty powstały z udziałem modelu, nawet po ludzkiej edycji. System świadomy wersji może pokazać tę współpracę dokładniej niż jedna końcowa etykieta.

Dla organizacji kluczowe stają się retencja i przenośność. Dane o pochodzeniu przechowywane wyłącznie w jednej platformie agentowej znikają, gdy organizacja zmienia narzędzia. Zapisy wyprowadzone z Git pozostają użyteczne wszędzie tam, gdzie trafia repozytorium.

To sprawia, że Us vs. Them jest mniej kompletną platformą pochodzenia, a bardziej użyteczną bazą odniesienia. Pokazuje, jak wiele zasad można wyprowadzić ze zwykłej historii wersji. Ujawnia też informacje, których historia wersji nigdy nie uchwyciła.

Na co czytelnicy Hacker News powinni zwrócić uwagę w następnej kolejności

Wartość projektu będzie zależeć od trzech sygnałów: testów punktacji, integracji z agentami oraz lepszego zarządzania tożsamością.

Pierwszym sygnałem jest to, czy repozytorium rozszerzy testy zachowania o rzeczywiste wzorce edycji. Projekt już kieruje czytelników do testów jako najjaśniejszego wyjaśnienia swojego algorytmu.

Kolejne użyteczne przypadki obejmują przepisywanie akapitów, zmianę kolejności bloków, kopiowane sekcje, merge'e squash, generowane pliki i naprzemienne edycje człowieka oraz agenta. Opublikowane oczekiwane wyniki ułatwiłyby ocenę systemu.

Sygnał ten wzmocniłby projekt, gdyby niezależni użytkownicy mogli przewidzieć i odtworzyć jego wyniki. Duże zmiany wyników spowodowane drobnym formatowaniem osłabiłyby twierdzenie, że spójne autorstwo przetrwa zwykłą edycję.

Drugim sygnałem jest integracja z rzeczywistym agentem programistycznym lub przepływem pracy przeglądu. Raport z wiersza poleceń dowodzi, że wyniki można obliczać. Nie pokazuje, czy informacja zmienia zachowanie agenta.

Praktyczny eksperyment mógłby wymagać od agenta potwierdzenia przed modyfikacją zakresów powyżej progu. Inny mógłby nadawać priorytet przeglądowi pull requestu, gdy zmiana usuwa wyspę o wysokim pochodzeniu.

Sukces należy mierzyć rezultatami, a nie zrzutami ekranu. Przydatne miary obejmują cofnięte edycje, poprawki recenzentów, przeoczone defekty i niepotrzebne prośby o zatwierdzenie.

Zbyt wiele ostrzeżeń stworzyłoby zmęczenie pochodzeniem. Zbyt mało uczyniłoby system dekoracyjnym. Najlepszy próg prawdopodobnie będzie zależeć od repozytorium i wrażliwości każdego pliku.

Trzecim sygnałem jest model tożsamości wykraczający poza allowlistę. Dedykowane tożsamości agentów, podpisane commity, etykiety mieszanych sesji i jawny stan „nieznany” rozwiązałyby najważniejsze ograniczenie projektu.

Taka zmiana wzmocniłaby pochodzenie oparte na historii, ponieważ poprawia jakość dowodów trafiających do algorytmu. Bez niej coraz bardziej zaawansowani agenci mogą nadal commitować przez konta ludzi i zacierać to rozróżnienie.

Znaczenie miałby również publiczny format eksportowania zakresów. Inne agenty i narzędzia do przeglądu potrzebują stabilnego sposobu konsumpcji wyniku. Przenośny plik towarzyszący mógłby zachować zwykły tekst, jednocześnie unikając zależności od jednego polecenia.

Szersza lekcja jest już widoczna. Pochodzenie AI staje się bardziej użyteczne, gdy kieruje decyzją, zamiast jedynie ozdabiać dokument etykietą.

Dla deweloperów tą decyzją jest to, czy agent może automatycznie zmodyfikować linię. Dla recenzentów — gdzie poświęcić uwagę. Dla organizacji — które zmiany wymagają odpowiedzialnego zatwierdzenia przez człowieka.

Us vs. Them nie rozwiązuje tych kwestii zarządzania. Dostarcza im konkretną daną wejściową wyprowadzoną z infrastruktury, której używa już wiele zespołów.

Podejście pozostaje podatne na niepełne commity, współdzielone tożsamości i niejednoznaczne przepisywania. Te ograniczenia powinny od początku kształtować sposób jego wdrażania. Wynik powinien inicjować analizę, a nie ją kończyć.

Jeśli zarządzasz repozytorium edytowanym przez agenta, przejrzyj historię jednego pliku i ustal, gdzie faktycznie znajduje się ludzka ocena. Następnie zapytaj, czy Twój kolejny agent potrafi dostrzec tę granicę.

To ćwiczenie jest bardziej odkrywcze niż dyskusja o tym, czy końcowy tekst „wygląda na napisany przez AI”. Dyskusja na Hacker News prowadzi do lepszego pytania: czy Twój system edycji zachowuje wystarczająco dużo dowodów, aby respektować ludzkie intencje?