Twój zespół wypuszcza kod przy pomocy czterech różnych narzędzi AI do kodowania. Może pięciu. Backend-owiec przysięga na Claude Code, front-endowcy żyją w Cursorze, stażysta odkrył GitHub Copilota na studiach i nigdy go nie porzucił, a ktoś z platform engineeringu po cichu zainstalował JetBrains AI. Wszyscy są produktywni. Kod się kompiluje. CI przechodzi. Nikt nie kwestionuje tego układu.

Ale jest pewien problem: twój codebase czyta się teraz jak powieść napisaną przez czterech ghostwriterów, którzy nigdy się nie spotkali. Każde zdanie jest gramatycznie poprawne. Książka jako całość nie ma sensu.

Podział jest już oficjalny

10 kwietnia 2026 roku JetBrains opublikował badanie AI Pulse — ponad 10 000 profesjonalnych developerów, osiem języków programowania, wyniki ważone statystycznie. Liczba, która tu ma znaczenie: Copilot na 29%, Claude Code i Cursor remisują na 18%, JetBrains AI na 11%. Dziewięćdziesiąt procent developerów używa w pracy przynajmniej jednego narzędzia AI.

To nie jest wygrana jednego narzędzia. To wygrana każdego narzędzia wewnątrz tej samej organizacji.

I tu zaczyna się ciekawie: każde narzędzie przyniosło ze sobą własny plik instrukcji — dokument konfiguracyjny, który mówi AI, jak pisać kod w twoim konkretnym projekcie. Claude Code czyta CLAUDE.md. Copilot czyta copilot-instructions.md. Cursor czyta .cursor/rules/*.mdc. OpenAI Codex CLI czyta AGENTS.md (teraz pod opieką Linux Foundation, zaadoptowany przez ponad 60 000 projektów open-source). Windsurf czyta .windsurf/rules/*.md. Gemini CLI czyta GEMINI.md.

Sześć narzędzi. Sześć formatów konfiguracji. Każdy z nich po cichu ignoruje pozostałe. Jak zauważył TokenCentric w porównaniu z marca 2026: "Developer pracujący nad pięcioma projektami z trzema narzędziami AI może utrzymywać piętnaście plików konfiguracyjnych."

Jak cztery AI piszą cztery różne codebase'y

Każda AI ma osobowość. Claude Code preferuje jawną obsługę błędów i kompozycję funkcyjną — małe funkcje, jasne typy, rozwlekłe, ale przewidywalne. Copilot odzwierciedla statystyczną średnią GitHuba — pisze kod tak, jak wygląda większość open-source'owego kodu, czyli jest średni w każdym tego słowa znaczeniu. Cursor automatycznie przełącza się między modelami (Claude, GPT, własne fine-tune'y), mieszając style w ramach jednego pull requesta w zależności od tego, który model obsłużył który plik.

Nic z tego nie jest złe. I to jest właśnie problem. Linter — narzędzie sprawdzające kod pod kątem naruszeń stylu — łapie literówki i formatowanie. Nie łapie tego, że twój serwis uwierzytelniania obsługuje błędy blokami try-catch, serwis płatności używa typów Result, a serwis powiadomień zwraca null. Trzy podejścia, wszystkie poprawne, wszystkie przechodzą CI (Continuous Integration — automatyczne testy uruchamiane przed mergem kodu), wszystkie tworzą codebase, po którym nikt nie jest w stanie nawigować bez mapy.

Najnowsze duże badanie jakości kodu AI — raport CodeRabbit z grudnia 2025, wciąż najlepsze dostępne dane cztery miesiące później — zmierzyło skalę problemu na 470 pull requestach z GitHuba: kod napisany przez AI miał 1,7× więcej problemów ogółem, 3× więcej problemów z czytelnością i 2,66× więcej niespójności w formatowaniu niż kod ludzki. I to mierzyło wynik jednego narzędzia. Codebase'y z wieloma narzędziami nakładają te niespójności jedną na drugą.

Moment olśnienia, którego nikt nie chciał

Rezultatem nie są bugi. Bugi da się znaleźć. Rezultatem jest niespójność architektoniczna — termin, wokół którego 7 kwietnia 2026 roku krążył Martin Fowler w swoim eseju o "harness engineering", gdzie zdefiniował równanie: Agent = Model + Harness. Harness to wszystko, co otacza model AI — pliki konfiguracyjne, guardrails, instrukcje. Fowler przyznał: "Wciąż mamy wiele do zrobienia, żeby wymyślić dobre harnessy dla zachowań funkcjonalnych."

Tłumaczenie: nikt tego jeszcze nie rozwiązał.

Greg Foster, CTO Graphite, ujął to inaczej w poście na Stack Overflow z 26 marca: ludzcy inżynierowie "w sposób niejawny absorbują kontekst codebase'u" podczas kodowania. Zauważają, że reszta serwisu używa typów Result, więc też ich używają. Agenci AI niczego nie absorbują — podążają za tym, co mówi ich plik konfiguracyjny, albo gorzej — za tym, co sugerują ich dane treningowe.

Rachunek

Żadne istniejące narzędzie tego nie łapie. ESLint sprawdza składnię. Prettier sprawdza formatowanie. Code review łapie bugi. Żadne z nich nie flaguje "ten plik ewidentnie napisała inna AI niż plik obok".

I nie licz na to, że vendorzy sami zbudują mosty. Gdyby Cursor uczynił swoje reguły kompatybilnymi z configiem Claude Code, ułatwiłoby to przejście na konkurencję. Fragmentacja to fosa, nawet jeśli przypadkowa.

Projekty społecznościowe próbują to kompensować. rule-porter, który pojawił się na GitHubie w lutym 2026, konwertuje między formatami konfiguracji; rulesync, który pojawił się mniej więcej w tym samym czasie, próbuje je zunifikować. Oba raportują mniej więcej 75% czystej konwersji. W pozostałych 25% żyje intencja architektoniczna, i ta ginie w tłumaczeniu.

Addy Osmani z Google ostrzegał w lutym 2026: "Im czystsza twoja architektura, tym mniej AI halucynuje dziwnymi abstrakcjami." Odwrotność jest równie prawdziwa: im bardziej bałaganiarski twój multi-AI codebase, tym dziwniejszy staje się każdy kolejny wkład AI. Entropia się kumuluje.

Co z tym zrobić

Jeśli twój zespół używa wielu narzędzi AI — a statystycznie tak jest — potrzebujesz jednej rzeczy: jednego, narzędziowo-agnostycznego dokumentu stylu, który każda AI czyta. Nie sześciu plików konfiguracyjnych. Jednego kanonicznego źródła prawdy o tym, jak twój codebase obsługuje błędy, strukturyzuje API, nazywa rzeczy i organizuje zależności. Potem pre-commit hook — automatyczne sprawdzenie uruchamiane przed zapisaniem kodu — który wymusza te wzorce niezależnie od tego, która AI napisała kod.

Standard AGENTS.md, teraz pod Linux Foundation, jest najbliżej formatu uniwersalnego. Nie jest idealny, ale to jedyny z międzyvendorowym wsparciem.

Nowa normalność

Twój codebase ma teraz więcej autorów-AI niż ludzkich. Andrej Karpathy powiedział to wprost 26 stycznia 2026: "Nie piszesz kodu bezpośrednio przez 99% czasu… orkiestrujesz agenty." Okej. Ale orkiestry potrzebują dyrygenta i partytury. Na razie większość zespołów ma czterech muzyków grających z czterech różnych nut w czterech różnych tonacjach — a publiczność słyszy "kompiluje się" i zakłada, że to muzyka.

Ktoś musi napisać politykę redakcyjną, zanim repo napisze ją za ciebie. Nie będzie ładna.