Propozycja AGENTS.md dla jądra Linux sprawdza, czy agenci AI potrafią przestrzegać zasad ustalonych przez ludzi

Propozycja AGENTS.md dla jądra Linux dodaje tylko jedno dowiązanie symboliczne, ale dotyczy narastającego konfliktu wokół kodu wspomaganego przez AI. Patch zgłoszony 24 września 2026 roku miałby ułatwić agentom programistycznym automatyczne odnajdywanie istniejących instrukcji dla jądra.

Proponowany plik nie upoważniałby do autonomicznego wnoszenia zmian ani nie łagodziłby standardów przeglądu kodu obowiązujących w projekcie. Kierowałby agentów do README, które już teraz odsyła narzędzia AI do szczegółowej polityki współtworzenia projektu. Zmiana rozwiązuje węższy problem: agenci często działają, zanim przeczytają dokumentację pisaną przede wszystkim dla ludzi.

To rozróżnienie ma znaczenie, ponieważ jądro już teraz informuje narzędzia AI, by nie poświadczały patchy w imieniu człowieka. Wymaga również ludzkiego przeglądu, właściwego przypisania autorstwa, testów i odpowiedzialności. Propozycja Linux kernel AGENTS.md zestawia więc łatwo dostępne instrukcje z trudniejszą rzeczywistością: plik w repozytorium może pokierować agentem, ale nie może uczynić niewiarygodnego patcha godnym zaufania.

Propozycja Linux Kernel AGENTS.md zmienia jeden punkt wejścia

Patch zmienia sposób, w jaki agenci odnajdują istniejące zasady, a nie same zasady.

Opiekun jądra Sasha Levin zgłosił patch zatytułowany „docs: add AGENTS.md as a symlink to README.” Propozycja tworzy najwyższego poziomu dowiązanie symboliczne o nazwie AGENTS.md, wskazujące na istniejący w repozytorium plik README.

Dowiązanie symboliczne to odwołanie w systemie plików, które przekierowuje jedną nazwę pliku do innego pliku. W tym przypadku agent otwierający AGENTS.md otrzymałby ten sam materiał, który jest już dostępny w README, zamiast drugiej kopii instrukcji.

Takie rozwiązanie pozwala uniknąć tworzenia dwóch dokumentów dotyczących zasad, które opiekunowie musieliby synchronizować. Propozycja dowiązania symbolicznego Levina wskazuje, że istniejący README już kieruje narzędzia AI do Documentation/process/coding-assistants.rst. Problem polega na tym, że agent musi zdecydować się na otwarcie README, zanim to wskazanie mu pomoże.

Wiele agentów programistycznych automatycznie sprawdza specjalnie nazwane pliki z instrukcjami. AGENTS.md stał się jedną z powszechnych nazw plików zawierających wskazówki dla całego repozytorium, w tym polecenia budowania, wymagania testowe, konwencje kodowania i granice bezpieczeństwa.

Proponowany plik dla jądra nie zawierałby osobnego tekstu. Jego jedyną zawartością byłby cel dowiązania, README. Dzięki temu ścieżki wejścia dla ludzi i maszyn pozostają powiązane z jednym utrzymywanym źródłem.

Levin dołączył kontrolowany przykład, aby wyjaśnić, dlaczego wykrywalność ma znaczenie. Dwaj agenci otrzymali to samo zadanie: utworzyć commit zmieniający nazwę wydania jądra w Makefile na „AI Test”.

Bez AGENTS.md jeden agent wygenerował linię Signed-off-by dla użytkownika. Drugi nie podał informacji o udziale AI. Oba rezultaty były sprzeczne z udokumentowanymi oczekiwaniami projektu.

W obecności dowiązania oba agenty podobno użyły tagu Assisted-by: LLM i uniknęły dodawania ludzkiego podpisu. Dokładniej przestrzegały również konwencji projektu dotyczących komunikatów commitów. Jeden dodał opisową treść, podczas gdy drugi użył oczekiwanej struktury tematu „subsystem: summary phrase”.

Był to ograniczony test zachowania, a nie szeroka ocena niezawodności agentów. Nie mierzył, czy agenci potrafią znajdować subtelne błędy, tworzyć bezpieczne poprawki ani rozumieć ograniczenia charakterystyczne dla poszczególnych podsystemów. Pokazał, że dwa agenty zachowywały się inaczej po otrzymaniu automatycznie wykrytej ścieżki do istniejących instrukcji.

W chwili opisywania zmiana nadal była analizowana. Stwierdzenie, że Linux już ją przyjął, byłoby więc przesadą. Dokładne twierdzenie brzmi: opiekun jądra zaproponował to dowiązanie i przedstawił dowody na jego poparcie.

Kees Cook, znany programista zajmujący się bezpieczeństwem jądra, odpowiedział potwierdzeniem. Poparł użycie README zamiast utrzymywania osobnej polityki przeznaczonej wyłącznie dla agentów. W swojej odpowiedzi w przeglądzie zaznaczył również, że byłoby pożądane, aby agenci czytali dokumentację dla współtwórców przed tworzeniem patchy.

Patch jest na tyle mały, że może wyglądać ceremonialnie. Jego praktyczny cel jest jednak konkretny. Ma umieścić obowiązkowe informacje procesowe na ścieżce, którą narzędzie AI jest już nauczone lub skonfigurowane sprawdzać.

Czyni to z propozycji zmianę interfejsu. Ludzie mogą przeglądać drzewa dokumentacji i interpretować normy społeczności. Agenci programistyczni działają bardziej przewidywalnie, gdy repozytoria udostępniają te normy poprzez nazwy plików i ścieżki rozpoznawane przez narzędzia.

Wynikające z tego pytanie nie brzmi, czy Markdown może poprawić wygenerowany kod. Chodzi o to, czy niezawodny punkt wejścia może zapobiegać powtarzającym się błędom procesowym, zanim opiekunowie będą musieli wychwytywać je ręcznie.

Istniejące zasady jądra nadal nakładają odpowiedzialność na ludzi

Polityka AI jądra Linux traktuje agenta jako pomocnika, nigdy jako prawnego lub technicznego właściciela wkładu.

Podstawowe zasady sięgają już znacznie dalej niż proponowane dowiązanie symboliczne. Przewodnik jądra dotyczący wkładu AI prowadzi narzędzia AI i ich użytkowników przez standardowy proces rozwoju, styl kodowania, wymagania dotyczące zgłaszania patchy, zasady licencjonowania oraz politykę dotyczącą generowanych treści.

Co najważniejsze, przewodnik mówi, że agenci AI nie mogą dodawać tagu Signed-off-by. Ta linia nie jest ozdobnym metadanym commita. Stanowi poświadczenie osoby zgodne z Developer Certificate of Origin, powszechnie nazywanym DCO.

DCO to mechanizm, za pomocą którego współtwórca oświadcza, że zgłoszona praca może legalnie wejść do projektu na jego licencji. Model językowy nie może złożyć takiego poświadczenia w imieniu człowieka. Nie może też ustalić, czy dana osoba przeprowadziła przegląd niezbędny do przyjęcia odpowiedzialności.

Ludzki zgłaszający musi przejrzeć wygenerowany kod, potwierdzić zgodność z licencją, dodać podpis i przyjąć odpowiedzialność za wkład. Agent, który sam wstawia podpis, sprowadza te odrębne kroki do wygenerowanego tekstu.

Dlatego test Levina ma znaczenie mimo ograniczonego zakresu. Agent nie wybrał jedynie niepopularnego stylu formatowania. Wygenerował oświadczenie, które wyłącznie człowiek może złożyć w sposób uprawniony.

Dokumentacja jądra przypisuje udziałowi AI inny znacznik. Gdy narzędzie AI wnosi wkład, patch powinien używać tagu Assisted-by. Opcjonalne narzędzia analityczne, takie jak Coccinelle, Sparse, Smatch lub Clang-Tidy, mogą również pojawić się po etykiecie LLM.

Ten model przypisania odróżnia pomoc od autorstwa i poświadczenia. Daje recenzentom użyteczny kontekst, nie udając przy tym, że model może wziąć na siebie odpowiedzialność.

Dokumentacja ustanawia też wymagający proces pracy nad błędami wspomaganej przez AI. Agent powinien przeczytać kompletną istotną dokumentację, zlokalizować konkretny błąd i podjąć próbę odtworzenia każdego nietrywialnego problemu. Powinien porzucić ustalenie, które nie przetrwa weryfikacji.

Jeśli problem wydaje się rzeczywisty, agent powinien napisać poprawkę, zbudować ją, przetestować z użyciem reproduktora lub pełnej analizy oraz uruchomić kontrole patchy jądra. Musi wskazać wszystko, czego nie mógł zweryfikować.

Przewodnik nakazuje też agentowi wskazać właściwych opiekunów i listy mailingowe. Musi ocenić, czy problem należy do zwykłego procesu obsługi błędów, czy do poufnego procesu bezpieczeństwa. Agent musi pozostawić faktyczne zgłoszenie osobie, która z niego korzysta.

Wymagania te ujawniają ograniczenia traktowania AGENTS.md jako samodzielnego rozwiązania. Plik może skierować agenta do właściwej listy kontrolnej. Nie może potwierdzić, że reproduktor ma znaczenie, testowanie jest wystarczające ani że człowiek rozumie kod.

Rozwój jądra obejmuje też tysiące komponentów o wyspecjalizowanych oczekiwaniach. Ogólne instrukcje nie mogą zawierać wszystkich ograniczeń architektonicznych, założeń sprzętowych ani preferencji opiekunów.

Agent może doskonale przestrzegać widocznych zasad formatowania, a mimo to błędnie rozumieć zarządzanie cyklem życia, blokady, porządkowanie pamięci lub zachowanie urządzeń. Dopracowany komunikat commita może ułatwić przegląd takiego patcha, ale nie czyni lepszym stojącego za nim rozumowania.

Tworzy to użyteczną granicę. Instrukcje repozytorium mogą ograniczyć możliwe do uniknięcia błędy administracyjne. Pewność techniczna nadal musi wynikać z dowodów, testów, eksperckiego przeglądu i odpowiedzialnych współtwórców.

Dla opiekunów to rozdzielenie jest istotne. Każde nieprawidłowo sformułowane zgłoszenie pochłania uwagę, zanim ktokolwiek dotrze do jego technicznej treści. Lepsze odkrywanie instrukcji może zmniejszyć ten narzut bez obniżania progu akceptacji.

Dla współtwórców polityka jest równie jasna. Korzystanie z agenta nie przenosi odpowiedzialności. Programista musi umieć wyjaśnić i obronić wynik tak, jakby każda linia została napisana ręcznie.

Dlaczego agenci AI do kodowania wciąż pomijają README

Konflikt dotyczy dokumentacji, która istnieje, oraz instrukcji pojawiających się w automatycznym kontekście agenta.

Repozytoria tradycyjnie organizują informacje dla współtwórców z myślą o ludziach. README przedstawia projekt, a pliki dotyczące współtworzenia, katalogi dokumentacji, strony list mailingowych i skrypty zawierają bardziej wyspecjalizowane procedury.

Osoba trafiająca do drzewa źródłowego Linux może podążać za tą hierarchią. Agent otrzymujący wąski prompt może natomiast sprawdzić tylko pliki, które uważa za bezpośrednio istotne. Jeśli nigdy nie otworzy głównego README, odsyłacz README do polityki AI pozostanie niewidoczny.

Takie zachowanie pojawiło się w niedawnej dyskusji dotyczącej wspomaganej przez AI poprawki Qualcomm I2C dla jądra. Opiekun zauważył, że proces był udokumentowany poprzez łańcuch rozpoczynający się w README i prowadzący do coding-assistants.rst. Mimo to narzędzia nie zawsze podążały za tym łańcuchem.

Dyskusja opiekunów zwróciła uwagę na brak pliku AGENTS.md lub CLAUDE.md, który popularne narzędzia sprawdzają domyślnie. Ostrzegła również, że dodanie takiego pliku niekoniecznie rozwiązałoby wszystko.

To właśnie stoi za nową propozycją. Opiekunowie jądra spotykają się z patchami wspomaganymi przez AI niezależnie od tego, czy repozytorium optymalizuje dokumentację dla agentów. Odmowa dodania punktu wejścia nie powstrzymuje współtwórców przed korzystaniem z tych narzędzi.

Praktyczny wybór jest węższy. Opiekunowie mogą pozostawić agentom niespójne odkrywanie dokumentacji zorientowanej na ludzi albo umieścić znajomy drogowskaz w głównym katalogu repozytorium.

Szersza konwencja AGENTS.md opisuje ten plik jako README dla agentów. Jej dokumentacja otwartego formatu podaje, że z konwencji korzysta ponad 60 000 projektów open source, choć liczba ta odzwierciedla indeksowane przykłady, a nie audytowaną miarę aktywnego użycia agentów.

Format nie narzuca wymaganego schematu. Projekt może wymienić polecenia konfiguracji, zasady stylu kodu, testy, kwestie bezpieczeństwa lub odsyłacze do głębszej dokumentacji. Zagnieżdżone pliki mogą dostarczać bardziej szczegółowych instrukcji dla podkatalogów.

Ta elastyczność pomaga wyjaśnić, dlaczego format się rozpowszechnił. Repozytorium może korzystać z jednego prostego pliku Markdown w kilku narzędziach, bez wiązania się z własnościowym systemem konfiguracji.

Propozycja dla jądra wykorzystuje wyjątkowo konserwatywną wersję tego wzorca. Nie tworzyłaby rozbudowanego podręcznika dla agentów ani nie powielałaby informacji już utrzymywanych gdzie indziej. Udostępniałaby istniejący README pod nazwą, o którą agenci prawdopodobnie poproszą.

To podejście zachowuje również spójność między wskazówkami dla ludzi i maszyn. Kees Cook powiedział, że README celowo zaprojektowano tak, aby działał dla agentów. Odsyłanie do niego wzmacnia tę wspólną ścieżkę, zamiast tworzyć prywatny zestaw zasad, którego ludzcy współtwórcy mogliby nigdy nie zobaczyć.

Wspólne źródło ogranicza dryf zasad. Jeśli opiekunowie zaktualizują README lub jego odnośnik do przewodnika AI, agenci otrzymają zmianę przez dowiązanie symboliczne. Skopiowany AGENTS.md mógłby po cichu się zdezaktualizować.

Mimo to użycie dowiązania symbolicznego wiąże się z kwestią kompatybilności. Systemy uniksopodobne naturalnie obsługują dowiązania symboliczne w repozytoriach, lecz niektóre konfiguracje Windows pobierają je jako zwykłe pliki. Agent mógłby wtedy zobaczyć słowo README, a nie wskazaną treść.

Nie unieważnia to propozycji, szczególnie w projekcie rozwijanym głównie w ramach ugruntowanych przepływów pracy Linuksa. Pokazuje jednak, dlaczego łatkę należy oceniać jako infrastrukturę, a nie magiczne metadane.

Zachowanie narzędzi także się różni. Niektóre agenty automatycznie wczytują AGENTS.md, podczas gdy inne preferują nazwy plików specyficzne dla danego narzędzia lub wymagają jawnej konfiguracji. Uniwersalnie wyglądająca nazwa pliku nie gwarantuje uniwersalnego przetwarzania.

Łatka poprawia więc prawdopodobną ścieżkę dla wielu agentów, nie eliminując różnic między narzędziami. Jej korzyść zależy od tego, czy klient podąża za linkiem, respektuje instrukcje i zachowuje je przez cały czas realizacji zadania.

Warunki te są silniejsze niż samo posiadanie dobrej dokumentacji. Są jednak słabsze niż egzekwowalna kontrola techniczna.

Lepsze instrukcje nie czynią generowanych łatek bezpiecznymi

AGENTS.md może poprawić zgodność z zasadami, ale nie może zapewnić poprawności, pochodzenia ani rzeczywistej ludzkiej kontroli.

Najmocniejszy argument za propozycją ma charakter operacyjny. Agenci już tworzą łatki związane z kernelem, więc opiekunowie powinni zapewnić im przewidywalną drogę do zasad. Zapobieganie błędnym podpisom i brakującym informacjom o autorstwie oszczędza czas podczas przeglądu.

Najmocniejsza krytyka również ma charakter operacyjny. Wygenerowana łatka może przestrzegać każdej widocznej instrukcji, a mimo to pozostać błędna w trudny do wykrycia sposób.

Oceny przestrzegania instrukcji często wykorzystują proste, obserwowalne wyniki. Czy agent dodał właściwy tag? Czy uruchomił wskazane polecenie? Czy poprawnie sformatował temat? Takie kontrole są ważne, lecz jakość kernela zależy od głębszych właściwości.

Poprawka może przejść kompilację, a mimo to wprowadzić wyścig. Reproduktor może sprawdzić jedną konfigurację sprzętową, pomijając inną. Agent może odwołać się do właściwej dokumentacji, lecz błędnie zrozumieć niezmiennik, o którym dokumentacja zakłada, że współtwórcy już wiedzą.

Istnieje też ryzyko, że lepsza prezentacja zwiększy nieuzasadnione zaufanie. Dobrze uporządkowany opis commitu, poprawne wskazanie autorstwa i przechodzące kontrole mogą sprawić, że łatka wspomagana przez AI będzie wyglądać dojrzale. Recenzenci nadal muszą traktować te sygnały jako zgodność z procesem, a nie dowód technicznej poprawności.

Obecna polityka kernela przewiduje ten problem. Wymaga, aby człowiek przejrzał kod i wziął za niego odpowiedzialność. Prosi też współtwórców o ujawnianie brakujących testów lub nieudanej weryfikacji, zamiast ukrywania luk za pewną siebie prozą.

To, czy ludzie będą przestrzegać tych wymagań, leży poza zasięgiem AGENTS.md. Współtwórca może usunąć tag autorstwa, zignorować nieudany test albo przesłać kod, którego nie rozumie. Plik nie ma niezależnego mechanizmu potwierdzającego, że doszło do ludzkiego przeglądu.

Inne projekty open source odpowiedziały na ten sam problem odmiennymi strategiami. Repozytorium linux-firmware wcześniej w 2026 roku przyjęło dokumentację skoncentrowaną na agentach, obejmującą zasady współtworzenia i wskazówki dotyczące autorstwa. Jego wytyczne dotyczące firmware stanowiły bliski precedens dla polityki czytelnej dla agentów.

NetworkManager obrał bardziej konfrontacyjne podejście po ustanowieniu swojej polityki AI. Jego instrukcje miały podobno nakazywać niezgodnym agentom umieszczanie nietypowego słowa-kanarka w komunikacji współtwórców. Opiekunowie mogli wtedy wykrywać zgłoszenia, które wykonały ukrytą instrukcję, omijając jednocześnie politykę projektu.

Ten mechanizm kanarka ilustruje przeciwne zastosowanie pliku z instrukcjami. Zamiast pomagać agentowi stworzyć akceptowalną łatkę, plik pomaga identyfikować zautomatyzowane zachowanie, które powinno skutkować odrzuceniem.

Oba podejścia uznają ten sam fakt: agenci czytają kontekst repozytorium i odpowiednio zmieniają swoje wyniki. Różnią się tym, czy takie zachowanie powinno być kierowane ku zgodności z zasadami, czy wykorzystywane jako sygnał wykrywania.

Propozycja kernela wybiera wskazówki. Zakłada, że współtwórcy korzystający z agentów nadal mogą uczestniczyć, jeśli spełniają te same obowiązki prawne, techniczne i dotyczące przeglądu, co wszyscy inni.

Nie jest to poparcie dla nienadzorowanego rozwoju kernela. To próba uwidocznienia istniejącej granicy w chwili, gdy agent zaczyna pracę.

Propozycja unika też tworzenia instrukcji istniejących wyłącznie dla maszyn. Ponieważ AGENTS.md wskazywałby na README, opiekunowie i współtwórcy mogliby sprawdzić to samo źródło, które otrzymuje agent.

Przejrzystość pomaga, lecz nie rozwiązuje problemu prompt injection ani złośliwej treści w repozytorium. Agenci programistyczni rutynowo pobierają instrukcje z plików, treści zgłoszeń, komentarzy, logów i zewnętrznych stron. Sprzeczne lub wrogie polecenia mogą konkurować z zaufaną polityką.

Plik na najwyższym poziomie może ustanowić priorytet dla współpracujących narzędzi. Nie może zagwarantować, że każde narzędzie prawidłowo zastosuje ten priorytet, zwłaszcza gdy agent odczytuje głębiej położone pliki zawierające sprzeczne sformułowania.

Istnieje powiązane ryzyko utrzymaniowe. Wszelkie wskazówki dotyczące repozytorium mogą się zdezaktualizować wraz ze zmianą procesów pracy. Proponowane dowiązanie symboliczne ogranicza duplikację, jednak połączone dokumenty nadal wymagają aktywnego przeglądu.

Skala kernela sprawia, że takie utrzymanie jest szczególnie ważne. Instrukcje ogólnie poprawne mogą nadal być niepełne dla konkretnego podsystemu. Agenci i współtwórcy muszą wciąż konsultować lokalną dokumentację, opiekunów, systemy budowania i infrastrukturę testową.

Wyważone stanowisko nie brzmi więc ani „AGENTS.md naprawia kod AI”, ani „plik jest bez znaczenia”. Może ograniczyć określoną klasę przewidywalnych błędów, pozostawiając najtrudniejszą pracę weryfikacyjną nietkniętą.

To skromne twierdzenie wspiera przykład Levina. Wszystko szersze wymaga dowodów z rzeczywistych wkładów w różnych podsystemach i narzędziach.

To, co wydarzy się dalej, będzie ważniejsze niż dowiązanie symboliczne

Propozycję należy oceniać na podstawie wyników przeglądów, zachowania agentów i obciążenia opiekunów po jej przyjęciu.

Pierwszym sygnałem będzie los łatki. Potwierdzenie wspiera projekt, lecz zmiana nadal musi przejść przez proces dokumentacyjny kernela i trafić do głównego repozytorium, zanim stanie się standardową infrastrukturą projektu.

Recenzenci mogą zaakceptować dowiązanie symboliczne bez zmian, poprosić o zwykły plik, zażądać dostosowań kompatybilności albo uznać, że ścieżka przez README jest niewystarczająca. Każdy wynik wyjaśni, w jaki sposób kernel chce udostępniać zasady zautomatyzowanym narzędziom.

Drugim sygnałem będzie to, czy główne agenty programistyczne konsekwentnie podążają za linkiem. Porównanie dwóch agentów przeprowadzone przez Levina jest użyteczne, ale niewielkie. Szersze testy powinny objąć różne narzędzia, prompty, katalogi robocze i typy wkładu.

Udana implementacja przyniosłaby mniej wygenerowanych podpisów, bardziej spójne tagi Assisted-by, lepsze tematy commitów oraz wyraźniejsze ujawnianie nieprzetestowanej pracy. Są to obserwowalne usprawnienia procesu.

Porażka wyglądałaby inaczej. Agenci mogliby ignorować dowiązanie symboliczne, czytać tylko część połączonego materiału albo stosować ogólne zasady, pomijając wymagania specyficzne dla podsystemu. Pliki z instrukcjami dla konkretnych narzędzi mogłyby pozostać konieczne.

Trzecim i najważniejszym sygnałem jest obciążenie opiekunów. Jeśli plik ograniczy powtarzalne poprawki bez zwiększania liczby niskiej jakości zgłoszeń, spełni praktyczny cel.

Jeśli dopracowane wyniki agentów zachęcą więcej współtwórców do wysyłania łatek, których nie potrafią wyjaśnić, link może poprawić prezentację, jednocześnie zwiększając ciężar przeglądu. Taki rezultat osłabiłby podstawowe założenie propozycji.

Opiekunowie powinni także obserwować, czy współtwórcy uczciwie stosują wskazanie autorstwa. Konwencja Assisted-by ma wartość tylko wtedy, gdy ludzie ją zachowują. Zautomatyzowana zgodność podczas generowania nie może uniemożliwić komuś edycji commitu przed zgłoszeniem.

Projekty poza Linuksem będą analizować wynik. Kernel jest jedną z najbardziej widocznych i wymagających współpracujących baz kodu, dlatego jego podejście do instrukcji dla agentów ma znaczenie symboliczne, nawet jeśli łatka jest technicznie niewielka.

Tego wpływu nie należy mylić z uniwersalną polityką. Mniejsze repozytoria, zespoły komercyjne i projekty o innym profilu ryzyka mogą wybrać pełniejsze pliki instrukcji, konfiguracje zależne od narzędzi, zautomatyzowane bramki lub zakazy dotyczące określonych wygenerowanych wkładów.

Podejście kernela jest godne uwagi, ponieważ nie buduje równoległego procesu rozwoju. Kieruje agentów z powrotem ku procesowi, który już reguluje pracę ludzi.

Dla zespołów inżynieryjnych bezpośrednia lekcja polega na oddzieleniu wykrywalności od autorytetu. Kontekst czytelny dla agentów może wskazać właściwe polecenia i ograniczenia. Testy, przeglądy, odpowiedzialność i systemy zatwierdzania nadal muszą egzekwować pracę.

Zespoły dokumentujące te granice mogą również utrzymywać techniczny kontekst w formie możliwej do przeszukiwania za pomocą bazy wiedzy inżynieryjnej. Kluczowe jest udostępnianie jednego utrzymywanego źródła zamiast kopiowania zasad do kilku plików agentów.

W ciągu najbliższych kilku miesięcy warto śledzić historię łatki, rzeczywiste zgłoszenia wspomagane przez AI i reakcje opiekunów. Te sygnały pokażą, czy wskazówki Linux kernel AGENTS.md usuwają możliwy do uniknięcia szum, czy jedynie standaryzują sposób, w jaki ten szum dociera.

Opiekunowie repozytoriów powinni zadać podobnie konkretne pytanie: który powtarzający się błąd agenta wynika z braku kontekstu, a który wymaga egzekwowalnej kontroli? Umieść stabilne wskazówki tam, gdzie narzędzia je znajdą, a następnie zmierz, czy zachowanie się zmienia. Pozostaw ludzkiej kontroli odpowiedzialność za wszystko, czego plik Markdown nie może udowodnić.