Czym jest harness: infra, dzięki której AI naprawdę dowozi

W pierwszym tekście z serii opowiedziałem o niepokoju, który kazał mi zacząć przebudowę tech w Prolog. Na końcu obiecałem otworzyć każdą część. Zaczynam od tej, którą najdłużej rozumiałem: harness.

Uprzedzam od razu, nie ma tu magicznej formuły. To, co przeczytałem, co widziałem u innych firm i co próbujemy robić, z trafieniami i z błędami.

Miesiącami szukałem nazwy dla czegoś, co czułem, a nie umiałem nazwać.

Słowo, którego brakowało

Widziałem trzyosobowe firmy dowożące to, co wcześniej wymagało trzydziestu. I widziałem, że zysk nie tkwił w modelu, bo model wszyscy używają podobny. Był gdzie indziej, a ja nie miałem na to słowa.

W lutym 2026 OpenAI opublikowało tekst zatytułowany Harness Engineering i dało mi to słowo.

Ich definicja otwiera się dwiema krótkimi linijkami: „Ludzie kierują. Agenci wykonują.” A to, co następuje potem, zmienia sposób myślenia: główna praca zespołu inżynierii przestaje być pisaniem kodu, a staje się projektowaniem środowisk, specyfikowaniem intencji i budowaniem pętli feedbacku, które pozwalają agentom wykonywać wiarygodną pracę.

Każdy kawałek tam to prawdziwa praca. Zaprojektować środowisko, w którym działa agent. Jasno określić, co jest do zrobienia, intencję, zamiast krok po kroku. I zbudować pętle, które mówią AI, czy trafiła, żeby sama się poprawiła.

Zwróć uwagę, co zniknęło ze zdania: pisanie kodu. To nie OpenAI mówi, że kod się nie liczy. To OpenAI mówi, że gdy AI pisze większość, praca człowieka wchodzi o warstwę wyżej. A gdy coś się psuje, pytanie zmienia się razem z nią. Przestaje brzmieć „spróbuj jeszcze raz, przyłóż się bardziej”, a staje się „jakiej zdolności zabrakło w środowisku, żeby AI trafiła”. Bug przestaje być winą AI („jest głupia”), a staje się pytaniem o to, czego zabrakło wokół niej.

Harness to zatem organizowanie kodu, procesu i pracy tak, żeby AI widziała, rozumiała i wykonywała. To nie narzędzie, które kupujesz. To nowy sposób myślenia o tym, co dowozi zespół.

Model to jedno, harness to drugie

Najbardziej oszczędne zdanie, jakie znalazłem, żeby to utrwalić, pochodzi od Viveka Trivedy’ego, inżyniera z LangChain: „jeśli to nie model, to harness”.

Model to surowy LLM. Opus, GPT, cokolwiek. Wchodzi tekst, wychodzi tekst, koniec. A model ma praktycznie każdy. To towar masowy. Różnica między tym, kto zyskuje 10%, a tym, kto zyskuje 5x, nie tkwi w modelu.

Tkwi w harnessie. Harness to cała reszta: kod, narzędzia, które AI może wywołać, kontekst, który widzi, hooki, orkiestracja, sandbox, w którym działa, pamięć, reguły biznesowe. Wszystko, co otacza model w przepływie, zanim praca dotrze do ciebie gotowa.

Harness nie ma dobrego polskiego tłumaczenia. Uprząż, oprzyrządowanie, gubią sens. Nazywam to „infrastrukturą agenta” i tyle.

Może słyszałeś już o „context engineering”. To część tego, część o organizowaniu tego, co AI widzi. Harness jest większy: obejmuje kontekst, ale też narzędzia, hooki, sandbox, trwałość, orkiestrację. Kontekst to kawałek, harness to całość.

Harness to uczynić wszystko czytelnym dla AI

Gdybym miał streścić harness w jednej zasadzie, brzmiałaby tak: uczynić wszystko czytelnym dla AI.

W poprzednim tekście opowiedziałem o diagnozie, która mnie dopadła. Kontekst Prologa był porozrzucany. Kawałek w Notion, inny na Drive, inny w Jira, w Figmie. Nie było jednego źródła. Każda nowa rozmowa z AI zaczynała się od zera, bo informacja, której potrzebowała, była w pięciu miejscach i wykurowana w żadnym.

Kiedy czytasz to przez soczewkę harnessu, problem staje się oczywisty. AI nie widziała. A czego nie widzi, tego nie używa.

Peter Pang, CTO CREAO, opowiedział o decyzji, która wydaje się radykalna i ma pełny sens: połączył cały kod w jeden monorepo. Powodem nie była organizacja. Chodziło o to, żeby AI mogła zobaczyć wszystko naraz.

To właśnie jest ta praca. Nie sprytny prompt, nie sztuczka. To wziąć to, co porozrzucane, niejawne, żywe tylko w głowach ludzi, i uczynić czytelnym w jednym miejscu, spisanym, dostępnym dla agenta. Czasem nudne. Ale to dokładnie to oddziela zysk 10% od zysku 5x.

Dowód: 3 inżynierów, milion linii

Z natury nie ufam hype’owi. Więc to, co przekonało mnie, że to nie chwilowa moda, to przypadek z liczbą.

Zespół OpenAI, który zbudował Codex CLI, ich narzędzie wiersza poleceń, liczył trzech inżynierów. W ciągu kilku tygodni dowieźli około miliona linii kodu: aplikacja, infra, tooling, dokumentacja. I zero linii napisanych ręcznie. Filozofia zespołu, ich słowami, brzmiała „żadnego kodu pisanego ręcznie”. Było około tysiąca pięciuset pull requestów, wszystkie zmergowane, żaden wpisany przez człowieka. Trójka kierowała, AI budowała.

Żeby nie było zamieszania: OpenAI ma Codex, czyli model wytrenowany do kodu, i Codex CLI, czyli narzędzie. Trójka użyła modelu, przez narzędzie, żeby zbudować to samo narzędzie. Rzecz budująca się sama sobą.

I na tym się nie kończy. W całym OpenAI Codex robi review 100% pull requestów firmy.

To, co mnie przekonało, to nie sama liczba z OpenAI. To, że Peter Pang w CREAO doszedł do tego samego wniosku osobną drogą, bez umawiania się z nikim. Dwa różne miejsca opisujące to samo. Kiedy tak się dzieje, zwykle nie jest to moda. To wzorzec.

AI-assisted to nie to samo co AI-first

Tu muszę być szczery co do tego, gdzie jest Prolog.

Jest różnica, której prawie nikt nie zauważa, między używaniem AI, żeby wspierała pracę, a postawieniem AI w jej centrum.

AI-assisted to człowiek w centrum i AI podpięta na końcach. Ten sam sprint, ten sam board, to samo spotkanie, ten sam przepływ. AI pomaga wewnątrz procesu, który już istniał. Zysk jest realny i niewielki: 10, 20%. Tam jest większość firm. Tam jest dziś Prolog, i nie będę udawał inaczej.

AI-first to AI w centrum i człowiek kierujący. Zakładasz, że agent jest podstawowym budowniczym, i przerabiasz proces, architekturę, a nawet organizację wokół tego. Człowiek krytykuje, waliduje, ocenia. Zysk jest innego rzędu: 5x, 10x. To robi Codex, CREAO i Anthropic.

Różnica, jak podsumowuje Peter Pang, jest multiplikatywna, nie przyrostowa. I właśnie dlatego harness tak bardzo się liczy. Do AI-first nie dojdziesz, podpinając AI do tego, co już istnieje. Dochodzisz, przebudowując tak, żeby AI widziała, rozumiała i wykonywała. Czyli robiąc harness.

I to nie tylko problem inżynierii

Zdanie OpenAI, „główna praca to już nie pisanie kodu”, powstało z myślą o inżynierii. Ale gdy przeczytałem je jeszcze raz, zmieniając podmiot, pasowało do każdego stanowiska w tech.

Produkt nie pisze już tylko dokumentu, umożliwia agentowi zaproponowanie rozwiązania. Design nie projektuje już tylko ekranu, umożliwia agentowi wygenerowanie interfejsu wewnątrz systemu. QA nie odpala już tylko testu ręcznie, umożliwia agentowi walidację. Dane nie odpalają już tylko zapytania, umożliwiają agentowi odpowiedź na pytanie biznesowe.

We wszystkich z nich pytanie staje się to samo: jakiej zdolności brakuje agentowi, żeby to zrobił, i jak uczynię to dla niego widocznym i sterowalnym.

Co z tego wynoszę

Harness to nie narzędzie, które się kupuje, ani lepszy model, który się subskrybuje. To praca. Praca polegająca na wzięciu tego, co jest w głowach ludzi i porozrzucane po dziesięciu systemach, i uczynieniu tego czytelnym, w jednym miejscu, żeby maszyna mogła z tego skorzystać.

Nudna część jest taka, że nie ma skrótu. Dobra część jest taka, że skoro to praca, da się ją wykonać. Jesteśmy w jej środku: daleko od AI-first, bliżej niż dwa miesiące temu. Będę dalej opowiadał, jak idzie.

Źródła

• OpenAI, Harness Engineering: leveraging Codex in an agent-first world (luty 2026). Stąd pochodzą zdanie „ludzie kierują, agenci wykonują” i przypadek zespołu Codex CLI.
• Vivek Trivedy, LangChain, The Anatomy of an Agent Harness. Definicja „jeśli to nie model, to harness”.
• Peter Pang, CREAO, o stawianiu AI w centrum. Monorepo, żeby AI widziała wszystko, i różnica multiplikatywna.
• How OpenAI’s Codex Team Works and Leverages AI, Eng Leadership Newsletter. Liczby zespołu Codex.