Trzy dźwignie, o których nikt Ci nie powiedział

Bądźmy szczerzy. Pewnie próbowałeś kodu agenta, patrzyłeś jak pisze jakąś funkcję i pomyślałeś: "No, niezłe". A potem spróbowałeś użyć tego do czegoś prawdziwego — czegoś, co naprawdę ma znaczenie — i wjechałeś w ścianę.

Może zaczął wymyślać API, które nie istnieją. Może naprawił bug w jednym miejscu, a zepsuł trzy inne. Może po prostu siedział i czekał, aż mu wytłumaczysz, co tak naprawdę chciałeś. Coś Cię tu niepokoi?

Oto niewygodna prawda: agent nie jest zepsuty. Po prostu używasz go źle.

Dokładniej mówiąc — prawdopodobnie ciągniesz tylko jedną dźwignię, podczas gdy masz do dyspozycji trzy.

Trzy dźwignie, o których nikt nie mówi

Każdy kod agent — niezależnie czy to Claude Code, Cursor, Copilot czy cokolwiek innego — działa na tej samej fundamentalnej logice. Przyjmuje informacje, coś z nimi robi, a potem dostaje feedback. I tyle. Cała maszyna.

Problem w tym, że większość ludzi optymalizuje jedną lub dwie dźwignie i kompletnie ignoruje trzecią. A w produkcyjnym inżynierstwie właśnie ta brakująca dźwignia staje się Twoim sufitem.

Rozłóżmy to na czynniki pierwsze.

SEE: Co Twój agent właściwie widzi?

Z pudełka Twój agent widzi Twój kod i shell. Tylko tyle. Nie wie nic o standardach kodowania w zespole. Nie wie o tym dziwnym obejściu, którego Twój senior engineer dodał trzy lata temu podczas integracji z legacy systemem. Nie wie, jak wygląda "zrobione" w Twoim konkretnym projekcie.

Kiedy rozmawiam z zespołami, które walczą z AI-assisted development, problem jest niemal zawsze ten sam — kontekst. Agent leci na ślepo. Pisze kod, który technicznie działa, ale nie pasuje do wzorców w repo, ignoruje konwencje nazewnictwa albo wymyśla koło na nowo.

Rozwiązanie? Pakuj kontekst tak, jakbyś przekazywał pracę nowemu juniorowi. Jakie pliki powinien przeczytać w pierwszej kolejności? Co jest ważne? Jak wygląda architektura? Większość narzędzi ma sposoby na wstrzykiwanie tego — system prompts, referencje do dokumentacji, pliki skill. Korzystaj z nich.

ACT: Co Twój agent właściwie może zrobić?

Tu robi się ciekawie. Podstawowy agent może edytować pliki i uruchamiać testy. Skonfigurowany agent może wykonywać zapytania do API, sprawdzać status CI, czytać wątki na Slacku albo komunikować się z infrastrukturą cloud.

Im więcej akcji dostępnych dla agenta, tym mniej musisz ręcznie łączyć luki. Chcesz, żeby agent zweryfikował, że deployment faktycznie się udał, zanim zamknie ticket? Musi mieć dostęp do cloud console. Chcesz, żeby współpracował z zespołem? Potrzebuje kanałów komunikacji.

To nie jest budowanie sci-fi AI overlorda. Chodzi o usunięcie manualnej roboty z przełączania się między narzędziami. Każde alt-tab to handover, gdzie kontekst się gubi. Im więcej agent może zrobić autonomicznie w ramach Twojego workflow, tym ciaśniejsza ta pętla.

CORRECT: Skąd agent wie, że coś zjebał?

To jest dźwignia, którą większość zespołów kompletnie zaniedbuje, a to dlatego ich agenci wydają się niewiarygodni.

Agent potrzebuje feedbacku. Nie tylko "ten kod nie działa", ale subtelnych sygnałów o jakości, stylu i intencji. Lintery łapią błędy składniowe. Testy łapią błędy funkcjonalne. Code review łapią problemy architektoniczne. Ale Twój agent nie może działać na podstawie feedbacku, którego nigdy nie otrzyma.

Pomyśl o tym tak: każda automatyczna korekta, z którą agent się spotyka, to moment nauki. Każdy zignorowany błąd to stracona okazja. Im ciaśniejsze pętle feedbacku, tym szybciej Twój agent się poprawia.

I tu wiele zespołów zawodzi. Uruchamiają testy ręcznie, sprawdzają linty od czasu do czasu, przeglądają kod kiedy sobie przypomną. Ale żeby agent był niezawodny, te sprawdzenia muszą być automatyczne i szybkie. CI pipelines, które działają 45 minut, to śmierć dla produktywności agenta. Natychmiastowy feedback? Tam dzieje się magia.

Zasada najsłabszego ogniwa

Oto mental model, który zmienił moje myślenie o tym temacie:

Wyobraź sobie trzy słupki. Jeden dla See, jeden dla Act, jeden dla Correct. Ogólna zdolność Twojego agenta jest ograniczona przez najkrótszy słupek.

Widziałem zespoły, które wlewały zasoby w to, żeby agenci pisali lepszy kod (Act), ale nigdy nie dali agentowi odpowiedniego kontekstu (See), więc ciągle robił te same błędy. Widziałem zespoły, które budowały rozbudowane systemy feedbacku (Correct), ale agent nie miał dostępu do informacji potrzebnych, żeby ten feedback zastosować (See). W każdym przypadku bottleneckem była dźwignia, której nikt nie pomyślał, żeby pociągnąć.

To nie jest tylko intuicja. To strukturalne ograniczenie każdego systemu, który percepcjonuje środowisko, działa i dostosowuje się. Pomyśl o systemach reinforcement learning — potrzebują obserwacji (SEE), przestrzeni akcji (ACT) i sygnałów nagrody (CORRECT). Usuń którykolwiek z tych elementów, a system degraduje. Twój kod agent działa tak samo.

Co to oznacza dla Twojego zespołu

Jeśli ewaluujesz kod agenty do pracy produkcyjnej, nie testuj ich tylko na prostych problemach. Przepuść je przez scenariusze, które obciążają wszystkie trzy dźwignie:

• Czy agent ma dostęp do kontekstu potrzebnego, żeby zrozumieć Twój codebase?
• Czy agent może wykonywać akcje, które pasują do Twojego rzeczywistego workflow?
• Czy agent otrzymuje feedback wystarczająco szybko, żeby korygować kurs?

Jeśli odpowiedź na którekolwiek z tych pytań brzmi "nie bardzo", tam powinno iść Twoje następne włożenie wysiłku.

Dla tech leadów i architektów: to nie jest o znalezieniu właściwego narzędzia. Chodzi o zbudowanie właściwego systemu. Narzędzie to tylko silnik. Dźwignie to skrzynia biegów, układ paliwowy, system chłodzenia. Ferrari bez koła nie jest supercarem — jest zepsutym autem.

Szerszy obraz

Wciąż jesteśmy we wczesnej fazie ery AI-assisted development. Zespoły uczą się, że wrzucenie kodu agenta na problem nie wystarczy. Zespoły, które wyciągną najwięcej wartości, to nie te z najmądrzejszymi modelami — ale te, które zbudują najciaśniejsze pętle między widzeniem, działaniem i korygowaniem.

Więc zanim obwinisz narzędzie za rozczarowujące wyniki, rzuć uczciwe spojrzenie na swoje dźwignie. Która jest najkrótsza? Tam jest Twoja szansa.