---
title: "Narzędzia czy ludzie - o czym tak naprawdę jest transformacja AI"
description: "Gdy agenci AI generują dziesiątki zmian na godzinę, wąskim gardłem przestaje być pisanie kodu. Zobacz, dlaczego klasyczne Two Pizza Teams, Git i ręczne Code Review pękają pod nową skalą."
publishDate: "2026-10-23T10:00:00.000Z"
image: "~/assets/images/blog/thumbnails/praca-jutra.png"
canonical: "https://opanuj.ai/blog/narzedzia-czy-ludzie-transformacja-ai/"
draft: false
excerpt: "Konflikty na mergu, spuchnięty backlog i kolejki do Code Review przy pracy z agentami rzadko wynikają z braku kolejnej wtyczki. Częściej próbujemy wcisnąć wielokrotną dźwignię AI w strukturę zespołu zaprojektowaną pod ręczne pisanie kodu."
category: "Felieton"
tags: ["ai","agenci","produktywność","claude-code","architektura","bigtech"]
author: "Przemek Smyrdek"
readingTime: 6
type: "post"
language: "pl"
---

Na ostatnim live'ie 10xDevs pojawiło się pytanie, które świetnie oddaje napięcie w dzisiejszych zespołach produktowych:

> Często w zespołach mamy kilku deweloperów od tej samej działki, np. frontendowców. Zakładając, że lista tasków „to do” jest długa, nie zawsze tworzący taski ma ogląd na inne taski. Dlatego też zdarza się, że kilka tasków dotyczy zmian w granicach jednego komponentu, co spowoduje konflikty przy mergu. Jeśli pracuję w projekcie sam, to jestem w stanie zapanować nad taskami tak, aby agenci w swoich zmianach nie wchodzili sobie w kod. Czy wasz 10x workflow daje możliwość kontroli, używając agentów, kto nad czym pracuje i czy inne taski nie zahaczają o ten sam obszar?

Na pierwszy rzut oka diagnoza wydaje się oczywista: szwankuje zarządzanie backlogiem i pojawia się za dużo konfliktów przy mergu. Pierwszy odruch podpowiada więc lepszy workflow w Gicie, nowy zestaw skilli dla AI, dodatkowy plugin do IDE albo przesiadkę z Jiry na Lineara.

Tyle że to łatanie objawów. Autor pytania, prawdopodobnie zupełnie nieświadomie, sam ukrył w nim gotowe rozwiązanie. Zamiast dokładać kolejne narzędzie do koordynacji, warto przyjrzeć się prawdziwemu źródłu problemu. I nie chodzi tu o pozbywanie się programistów, tylko o konstrukcję zespołów i procesów, w które próbujemy wcisnąć agentów.

## Pizzeria jako źródło problemu: od Two Pizza do Two Slice Teams

Git i długi backlog nie są źródłem problemu z przytoczonego pytania. Źródłem jest zasada wymyślona wokół dwóch pizz.

Przez lata standardem w branży IT był spopularyzowany przez Jeffa Bezosa w Amazonie model **Two Pizza Teams**. Adresował on bardzo konkretny problem rosnących firm: zatory komunikacyjne. Im więcej osób i punktów styku w codziennej pracy, tym więcej czekania na inne działy, zależności między silosami i rozmytej odpowiedzialności.

Bezos chciał zbudować autonomiczne, sprawcze grupy, które potrafią dowieźć temat od początku do końca. Zamiast sztywnego limitu etatów przyjęło się mówić, że zespół powinno dać się wykarmić dwiema dużymi pizzami — w praktyce oznaczało to od 6 do 10 osób o różnych specjalizacjach. Większość zespołów produktowych pracuje w takim układzie do dziś.

Kiedy jednak do zespołu dołączają agenci AI, ten bilans przestaje się spinać.

Wróćmy do drugiego zdania z pytania naszego uczestnika:

> Jeśli pracuję w projekcie sam, to jestem w stanie zapanować nad taskami tak, aby agenci w swoich zmianach nie wchodzili sobie w kod.

Właśnie tutaj leży sedno. Problem z konfliktami nie wynika z braku magicznego skilla do Gita czy wtyczki do Claude Code'a. Wynika z tego, że próbujemy wcisnąć narzędzia dające kilkukrotną dźwignię w strukturę zespołu zaprojektowaną pod ręczne pisanie kodu.

Przed erą agentów pojedynczy programista miał fizyczny limit kodu, który był w stanie napisać w ciągu dnia. Jeden frontendowiec pracował nad zadaniem przez dwa dni, więc trzech kolejnych mogło bezpiecznie działać obok niego w tym samym module. Przy czterech deweloperach w jednym obszarze mieliśmy 6 par potencjalnych kolizji.

Dziś ten sam deweloper uruchamia równolegle trzech agentów i w godzinę przemiela dziesiątki plików w obrębie modułu. Jeśli w tym samym miejscu posadzimy czterech takich programistów z klasycznego Two Pizza Teamu, a każdy wypuści własne stado agentów, robi się z tego 12 równoległych strumieni zmian, czyli aż 66 par potencjalnych kolizji na mergu. Liczba konfliktów nie rośnie liniowo, tylko eksploduje.

Stąd zwrot w stronę modelu **Two Slice Teams**: mniejszych, 1–2 osobowych zespołów, które wspólnie z agentami biorą odpowiedzialność za znacznie większy wycinek codebase'u. Zamiast 6 czy 8 osób wchodzących sobie w paradę we wspólnym backlogu, pełny ownership nad modułem trafia w ręce jednej lub dwóch osób wspieranych przez agentów.

Jest to możliwe, bo agenci zasypują dawne silosy specjalizacji i minimalizują wewnętrzne handoffy między bazą danych, API a frontendem. Kiedyś potrzebowaliśmy osobnych specjalistów od każdej warstwy, bo praca na niskim poziomie abstrakcji w całym stacku była dla jednej osoby zbyt obciążająca. Dziś mały zespół z agentami potrafi przekrojowo rozwijać obszary, które wcześniej wymagały zaangażowania kilku ról.

O takim modelu na początku 2026 roku pisał [Dan Shipper, CEO firmy Every, w eseju „The Two-slice Team”](https://every.to/chain-of-thought/the-two-slice-team). Na polskim rynku bardzo podobne podejście wdraża edrone — ich CTO, Maciej Mendrela, szczegółowo omówił przejście na małe zespoły Product Builderów podczas [wystąpienia na żywo w ramach AI Product Heroes](https://www.youtube.com/watch?v=FIvZab-uxBw).

W tym miejscu naturalnie pojawia się obiekcja: w teorii brzmi to świetnie, ale w większości firm obowiązują przecież ustalone procesy, sprinty, kwartalne roadmapy i sztywne zasady Code Review. I tu dochodzimy do niewygodnej prawdy.

## Wszystko, co uznajesz za standard, wymaga rewizji

Większość praktyk, które w naszej branży traktujemy jak nienaruszalne „best practices” — od rozmiaru zespołów, przez planowanie sprintów i kształt backlogu, aż po sposób prowadzenia Code Review — powstała w świecie, który właśnie znika. W epoce AI każdy z tych standardów wymaga ponownego przemyślenia.

Kopiowanie starych playbooków 1:1 przestaje działać. Rozsądniejsza zasada na dziś brzmi: słuchaj tego, co robią inni, rób notatki, po czym wyrzuć gotowe szablony do kosza i przełóż wnioski na realia własnego zespołu.

Trafnie ujął to Josh Woodward (VP Google Labs, odpowiedzialny m.in. za aplikację Gemini, AI Studio i NotebookLM) w [rozmowie w podcaście Lenny'ego Rachitsky'ego](https://www.youtube.com/watch?v=3I6QYkccd3o). Jego główna teza jest bezlitosna: dziś każda firma i każdy zespół produktowy musi zacząć myśleć i działać jak laboratorium R&D (badawczo-rozwojowe).

Powód jest prosty. Możliwości modeli pod spodem zmieniają się co kilka miesięcy. W takich warunkach sztywna, roczna roadmapa i napompowany backlog to przepis na budowanie funkcji, które w dniu premiery są już przestarzałe.

Z podejścia Woodwarda warto wyciągnąć trzy zasady, które pokazują, jak bardzo trzeba dziś zrewidować utarte nawyki:

1. **Innowacji nie da się „odgrzać w mikrofali”.** Najlepsze rozwiązania nie powstają na zaplanowanych w kalendarzu, dwudniowych warsztatach dla piętnastu osób. Rodzą się w małych, 1–2 osobowych zespołach zafiksowanych na problemie, które szybko prototypują poza głównym procesem. Dokładnie tak — z wieczornego prototypu pokazanego na korytarzu, poza jakimkolwiek Excelem i kwartalnym OKR-em (Objectives and Key Results) — narodziło się głośne Audio Overviews w NotebookLM.
2. **Krótkie horyzonty czasowe i bezwzględne ubijanie prototypów.** Większość wewnętrznych inicjatyw przegrywa przez efekt utopionych kosztów: firmy boją się zamykać projekty, w które włożyły już czas, mimo braku mierzalnych efektów. Praca w rytmie laboratorium oznacza szybkie eksperymenty w krótkich oknach czasowych (np. do 90 dni) i gotowość do wyrzucenia 90% prób do kosza, żeby podwoić stawkę tam, gdzie faktycznie pojawia się wartość.
3. **Backlog rzeczy „Almost Possible”.** Zamiast planować wyłącznie w granicach dzisiejszej technologii, zespoły w Google Labs prowadzą żywą listę rzeczy, które dziś jeszcze nie działają, ale znajdują się tuż za granicą możliwości obecnych modeli. Kiedy wychodzi nowy model, nie zaczynają od burzy mózgów pod tytułem „co by tu zbudować”, tylko sprawdzają, które pozycje z listy zostały właśnie odblokowane.

Jak takie podejście wygląda w praktyce, kiedy przeniesiemy je na sam proces wytwarzania oprogramowania? Najlepiej widać to w miejscach, gdzie pod naporem agentów pękają najbardziej zakorzenione rytuały deweloperskie: kontrola wersji oraz Code Review.

## Co pęka pierwsze na froncie AI: Git w Anthropicu

Anthropic opublikował w październiku 2026 roku raport [„How Employment is Changing at Anthropic”](https://www.anthropic.com/research/employment-at-anthropic), w którym przeanalizował wpływ AI na własną organizację. Jako laboratorium budujące modele wiodące są o jakieś 12–18 miesięcy przed resztą rynku pod względem intensywności użycia agentów, więc ich wewnętrzne wąskie gardła są dobrą zapowiedzią tego, z czym za chwilę zmierzą się inne firmy technologiczne.

Kilka liczb z tego raportu pokazuje skalę zmiany:

- W sierpniu 2026 roku na każdą godzinę pracy człowieka przypadało w Anthropicu **6 godzin pracy agentów** (jeszcze w marcu 2026 proporcja wynosiła nieco ponad 1:1).
- Przeciętny inżynier Anthropica commituje dziś **5 razy więcej kodu** niż pół roku wcześniej.
- Udział sesji współpracy z AI poświęconych budowie infrastruktury dla samych agentów, pipeline'ów weryfikacyjnych i ewaluacji wzrósł od jesieni 2025 roku z 10% do 22%.
- Jednocześnie udział juniorów wśród nowo zatrudnianych osób na stanowiska techniczne spadł z 27% do 9%. Głównym wąskim gardłem stała się ludzka uwaga i osąd architektoniczny, a nie samo tempo pisania kodu.

Przy takiej skali jako pierwszy przestał wyrabiać fundament każdego zespołu inżynierskiego: **Git**.

Jak opisują inżynierowie firmy w tekście [„Redesigning source control at Anthropic”](https://www.anthropic.com/engineering/redesigning-source-control), między majem a wrześniem 2026 roku liczba mergowanych zmian w ich monorepo wystrzeliła z 2 500 do ponad **30 000 dziennie**, przy **25 milionach operacji checkoutu** w CI/CD (Continuous Integration / Continuous Delivery) każdego dnia. Klasyczny Git — zaprojektowany w 2005 roku pod człowieka pracującego lokalnie i pobierającego pełną historię repozytorium — przestał wytrzymywać takie obciążenie.

Zamiast łatać skrypty wokół Gita, siedmiu inżynierów Anthropica wspieranych przez Claude'a w 5 miesięcy napisało od zera nowy system kontroli wersji o nazwie **Scion** (wraz z dedykowanym narzędziem do przeglądu kodu **Antique**) i zmigrowało na niego całą firmę:

- Commity, merge'e i rebase'y wykonuje centralnie serwer, więc klienci nie muszą niczego pushować.
- Agenci i zadania CI pobierają tylko te pliki, których faktycznie potrzebują, zamiast klonować całe repozytorium.
- Infrastruktura utrzymująca repozytorium skurczyła się 200-krotnie względem poprzedniego klastra gitowego, a checkout trwa sekundy zamiast minut.

Większość firm nie potrzebuje własnego następcy Gita. Ten sam problem nienadążającej ludzkiej uwagi uderza jednak u niemal każdego zespołu w innym punkcie: na etapie przeglądu kodu.

## Gdy wąskim gardłem staje się człowiek: `small-change` w Imprint

W firmie Imprint po wdrożeniu narzędzi takich jak Claude Code przeciętny inżynier merguje dziś **4 razy więcej Pull Requestów** niż dwa lata temu (a w niektórych zespołach nawet 10 razy więcej). Co ważne, większa przepustowość nie oznaczała spadku jakości: w okresie intensywnej adopcji AI całkowita liczba incydentów produkcyjnych spadła o **42%** półrocze do półrocza, a liczba incydentów krytycznych aż o **78%**.

Skok produktywności wywołał jednak nowy zator. Mediana czasu oczekiwania na Code Review wzrosła z **33 do ponad 77 minut**. Ręczny przegląd kodu przez drugiego programistę stał się głównym hamulcowym.

Zamiast traktować tradycyjne Code Review jak świętą krowę, zespół inżynieryjny — o czym pisze na swoim blogu [Will Larson, CTO Imprint, w artykule o procesie `small-change`](https://lethain.com/small-changes/) — zadał sobie pytanie rodem z laboratorium: skoro nasza automatyzacja i testy tak skutecznie chronią produkcję, to czy naprawdę każda zmiana w kodzie wymaga blokowania czasu i uwagi drugiego człowieka?

W Imprint wprowadzono ścieżkę o nazwie `small-change`. Pull Request otrzymuje w niej automatyczną akceptację (bez udziału człowieka), jeśli spełnia twarde kryteria bezpieczeństwa:

1. **Ograniczony rozmiar i zakres:** zmiana ma mniej niż 1 000 linii, nie dotyczy współdzielonych bibliotek i nie dotyka wrażliwych ścieżek wykluczonych przez repozytorium (np. logiki finansowej czy bezpieczeństwa).
2. **Weryfikacja przez AI:** wewnętrzny bot AI do Code Review przeskanował kod i nie znalazł żadnych poważnych problemów (klasy P1 ani P2). Co istotne, bot w tym trybie nigdy nie zostawia komentarzy — albo akceptuje zmianę, albo przekazuje ją do standardowego przeglądu.
3. **Testy i próg zaufania:** przeszły wszystkie testy automatyczne, a autor zmiany ma już na koncie co najmniej 10 wcześniej zmergowanych zmian w danej usłudze.

Efekt? Około **10% wszystkich Pull Requestów** zaczęło przechodzić przez szybką ścieżkę bez angażowania innych deweloperów. Czas i uwaga ludzi zostały uwolnione na te zmiany, które faktycznie wymagają ludzkiego osądu architektonicznego, a gdy przez sito przejdzie błąd, zespół traktuje go jako sygnał do uszczelnienia automatycznych reguł, a nie powód do szukania winnego.

## Co z tym zrobić w swoim zespole

Wracając do pytania z naszego live'a: jeśli agenci wchodzą sobie w paradę w kodzie, a zespół tonie w konfliktach na mergu i kolejkach do Code Review, kolejna wtyczka do Jiry ani nowy skill do Gita nie rozwiążą problemu.

Zamiast optymalizować stare rytuały, zadajcie sobie w zespole trzy trudne pytania:

- **Czy struktura zespołu pasuje do nowej dźwigni?** Sprawdźcie, gdzie kilku programistów z agentami orze ten sam moduł, i przetestujcie podejście Two Slice Teams: dajcie 1–2 osobom pełny ownership nad wyodrębnionym obszarem od bazy po frontend.
- **Czy planujecie jak laboratorium, czy jak fabryka?** Zamiast zabetonowanych roadmap spróbujcie krótkich eksperymentów i zacznijcie spisywać własny backlog rzeczy „Almost Possible”, które odblokuje kolejna generacja modeli.
- **Które procesy chronią dziś jakość, a które są tylko przyzwyczajeniem?** Przeanalizujcie, ile czasu zjada wam ręczne Code Review powtarzalnych zmian i jakie warunki (testy, limity rozmiaru, automatyczne skany) musiałyby zostać spełnione, żeby część z nich mogła przechodzić bez blokowania drugiego człowieka.

Kwestionowanie praktyk, które jeszcze wczoraj były branżowym standardem, bywa niekomfortowe. Transformacja AI nie polega jednak na dopinaniu szybszych narzędzi do starych procesów, tylko na odwadze, żeby te procesy zaprojektować na nowo.