O czym jest ten film
- Budowanie z AI przestaje być kwestią wyboru „najlepszego” modelu, a staje się kwestią orkiestracji wielu agentów w jeden system.
- Prezentacja narzędzia Orca — otwartoźródłowego i darmowego menedżera agentów kodujących.
- Kluczowa przewaga: Orca działa na Twojej subskrypcji (Claude Max, Codex, Grok, Gemini, Cursor CLI), a nie na kluczach API.
- Struktura pracy: projekty → drzewa robocze Gita (work trees), w których działają osobni agenci.
- Bezpośrednia integracja z trackerami zadań (GitHub, Jira, Linear) eliminuje przełączanie kontekstu.
- Równoległa praca nad wieloma drzewami roboczymi i wieloma projektami naraz, bez kolizji na plikach.
- Warstwa orkiestracji: agenci różnych dostawców recenzują nawzajem swój kod i przekazują sobie zadania.
- Zakładka automatyzacji — cykliczne przebiegi (np. codzienny „bug sweep” o 9:00) z testami i tworzeniem PR-ów.
- Dodatki: wbudowane emulatory (iOS), obsługa komputera, komendy głosowe oraz aplikacja mobilna.
- Zastrzeżenie autora: narzędzie nie zastąpi solidnego procesu budowania — potrzebujesz własnego „systemu-fabryki”.
Redakcyjne tłumaczenie
Nie chodzi już o model, chodzi o orkiestrację
Budowanie z pomocą AI nie polega już właściwie na tym, który model jest odrobinę lepszy od pozostałych. Nie chodzi też tak naprawdę o to, jakich wtyczek czy umiejętności (skills) użyjesz do budowania. Coraz bardziej sprowadza się to do tego, jak dobrze potrafisz orkiestrować i zarządzać wieloma agentami, składając je w jeden system do budowania produktu.
To bywa jednak przytłaczające — trudno takie środowisko skutecznie okiełznać. Dotyczy to zarówno budowania oprogramowania, prowadzenia agencji, jak i ogólnego tworzenia rzeczy dla własnego biznesu i automatyzowania pracy. W tym materiale przyglądam się narzędziu o nazwie Orca i wykorzystuję je do orkiestracji nowych funkcji i buildów w mojej aplikacji. To narzędzie rozwiązuje wiele problemów, które zwykle spowalniają pracę i utrudniają panowanie nad tym, co dzieje się w procesach budowania.
Struktura: projekty i drzewa robocze
Pierwsze, co rzuca się w oczy, to hierarchia. Zasadniczo masz projekty, a wewnątrz projektów — drzewa robocze (work trees).
(Informacja dodatkowa: „work tree” to mechanizm Gita pozwalający mieć w tym samym repozytorium kilka niezależnych katalogów roboczych, każdy na innej gałęzi — dzięki temu wielu agentów może pracować równolegle bez wchodzenia sobie w drogę).
Jest to podobne do narzędzi takich jak IDE Anti-Gravity czy Cursor, które mają wbudowane możliwości agentowe i mają pomagać w ich orkiestracji. Bo właśnie orkiestracja wielu agentów — nawet trzech, czterech, pięciu robiących coś jednocześnie — bywa trudna i to ona jest tak naprawdę wąskim gardłem.
Największa zaleta: działa na Twojej subskrypcji
Powodem, dla którego szczególnie lubię to narzędzie, jest to, że korzysta z Twojej faktycznej subskrypcji. To duża różnica względem wielu innych narzędzi, które działają wyłącznie z kluczami API. Orca zadziała na przykład z subskrypcją Claude Max, z subskrypcją Codeksa — w zasadzie z każdym terminalowym agentem kodującym, jakiego używasz: Claude Code, Codex, Grok, Gemini, Cursor CLI. Wszystkie te subskrypcje działają z tym narzędziem, a tak wiele tego typu „agentowych IDE” po prostu nie funkcjonuje. To jedna z ogromnych zalet akurat tego rozwiązania.
Projekt demonstracyjny i integracja z trackerem zadań
Patrzymy teraz na projekt, nad którym pracuję od miesiąca czy dwóch — to aplikacja do śledzenia odżywiania w podejściu „agent-first”. Potrafi uczyć się o użytkowniku i o tym, jak loguje określone pokarmy.
W trakcie budowania nieuchronnie pojawiają się błędy, potrzeby usprawnienia UI oraz różne kierunki, w których moglibyśmy poprowadzić poszczególne funkcje. Zwykle logujemy takie rzeczy w GitHubie. I to jest kolejna cecha, którą naprawdę cenię w Orce: ma bezpośrednią integrację z większością trackerów zadań. Nie ma przełączania kontekstu — nie musisz skakać do GitHuba, Jiry czy Linear (albo grzebać w pliku Markdown w projekcie), żeby czytać zgłoszenia, tworzyć pull requesty i diagnozować problemy. To zwykle wybija z rytmu. Teraz mam to wszystko zintegrowane w projekcie i widzę u góry, w zakładce zadań.
W tym przypadku mam cztery zgłoszenia oznaczone jako usprawnienia UI — sytuacje, gdy podczas testów zauważyliśmy, że interfejs powinien być w pewnych miejscach czytelniejszy dla użytkownika.
Uruchamianie drzew roboczych z agentami
Będąc w projekcie, mogę utworzyć nowe drzewo robocze Gita. Wybieram odgałęzienie od gałęzi main, a jeśli mam podłączonych różnych agentów, wybieram, którego z nich chcę użyć do tej pracy, i każę mu utworzyć drzewo robocze. Zostaję natychmiast wrzucony do środka.
Mogę teraz powiedzieć: „Pobierz wszystkie zgłoszenia z etykietą »usprawnienie UI« i uszereguj je pod kątem tego, co da się wdrożyć równolegle — czyli które obszary nie dotykają tych samych plików, żebyśmy mogli pracować nad wszystkimi naraz różnymi podagentami bez kolizji”.
Podczas gdy to się dzieje, mogę uruchomić kolejne drzewo robocze — znów bardzo prosto, wybieram gałąź źródłową (origin main), tworzę drzewo i wydaję analogiczne polecenie, na przykład: „Pobierz wszystkie zgłoszenia z etykietą »bug« dodane w ciągu ostatnich 3 dni i zbadaj przyczynę źródłową”. Teraz oba te zadania działają w jednym projekcie, wykonując swoją robotę.
Wiele projektów jednocześnie
To, co bardzo lubię, to fakt, że zwykle prowadzimy kilka projektów naraz — niezależnie od tego, czy jest to efektywne i czy faktycznie wchodzimy w głęboką pracę, taka jest rzeczywistość. Mogę więc zwinąć bieżący projekt i dodać nowy do przestrzeni roboczej. Przeglądam folder na dysku, wchodzę do dokumentów i wczytuję na przykład moje umiejętności do produkcji treści — mam skills, które potrafią wyjść i badać tematy.
Podczas gdy tamte zadania działają w tle (widać, że oba wciąż pracują), mogę tu uruchomić moje systemy produkcji treści. W kontekście biznesowym to coś, co i tak robisz: pracujesz nad projektem, ale w tle zajmujesz się też materiałami marketingowymi, elementami operacji i tak dalej. Wszystkim naraz — a o zakończeniu głównych wątków pracy zostaniemy powiadomieni.
Mogę na przykład powiedzieć: „Uruchom pipeline »topic scout«”. Ten pipeline wychodzi do miejsc takich jak Twitter, Reddit czy Hacker News, próbuje zrozumieć, jakie tematy są teraz na fali, i raportuje mi to z powrotem. Rozumiesz ideę: możemy jednocześnie zajmować się bardziej operacyjnymi obszarami biznesu (marketing, pisanie copy) oraz poprawkami błędów, usprawnieniami i budowaniem nowych funkcji.
Warstwa orkiestracji: agenci recenzują się nawzajem
Jedną z rzeczy, które naprawdę lubię, jest opcja warstwy orkiestracji. Często słyszy się, jak ktoś opowiada, że ma agentów od różnych dostawców modeli, którzy recenzują nawzajem swój kod i przekazują sobie zadania. Robienie tego było dotąd albo procesem ręcznym, albo czymś, co trzeba było samodzielnie oskryptować. Z narzędziem takim jak Orca możemy to wszystko uruchomić dość prosto.
Wchodzimy w ustawienia, potem w orkiestrację — narzędzie dostarcza umiejętność (skill), która to umożliwia. Najpierw instalujemy skill Orki odpowiadający za orkiestrację.
To odblokowuje kilka naprawdę fajnych rzeczy. Po pierwsze, zadanie, nad którym aktywnie pracujesz, możesz przekazać zupełnie innemu agentowi — także od innego dostawcy modeli. Możesz przekazywać pracę do innego drzewa roboczego. W przykładzie, w którym utworzyliśmy różne drzewa robocze, możemy teraz przekazywać zadania i obciążenie między agentami na różnych drzewach. Możemy też łączyć agentów w łańcuch w stylu fazowym, gdzie jedno zadanie przechodzi w kolejne.
Kiedy uruchomię polecenie orkiestracji (zainstalowane właśnie jako skill), mogę powiedzieć: „Chcę, żeby trzej podagenci Codeksa zrecenzowali te ustalenia i odesłali analizę”. Widać, że faktycznie ruszyło i uruchomiło trzech różnych podagentów Codeksa, pracujących z boku, przekazując im cały potrzebny kontekst.
To już samo w sobie jest potężnym paradygmatem. Jeśli nie jesteś przyzwyczajony do takiej pracy, Orca robi z tego niezwykle prosty proces — tradycyjnie trzeba było być trochę bardziej zaawansowanym, żeby samodzielnie zbudować taki system przekazywania danych sesji między różnymi dostawcami modeli. W tym przypadku poddajemy kontroli jakości (QA) ustalenia o przyczynach źródłowych błędów, które dostaliśmy od Claude Code.
Ręczne sesje w wybranych modelach
Jeśli chcesz ręcznie odpalić osobne zadania lub sesje względem któregoś z drzew roboczych, po prostu klikasz w drzewo, otwierasz nową kartę terminala i jesteś gotowy — możesz wybrać dowolnego dostawcę modelu dla tej sesji. Jeśli chcę sesję Codeksa, klikam w niego i otwiera mi się nowa sesja terminala.
Pętla „błędy → poprawki → PR” i automatyzacje
Bardzo potężny bywa proces, który właśnie przeszliśmy: pobraliśmy wszystkie błędy z backlogu zadań, a teraz chcemy przez nie przejść, wprowadzić poprawki i otworzyć PR. To naprawdę mocna pętla.
Jeśli faktycznie używasz swojego produktu albo testuje go partner biznesowy, a ty robisz build, możesz skorzystać z zakładki automatyzacji. Orca wychwytuje pewne automatyzacje, które już mam skonfigurowane na maszynie z agenta Hermes używanego jakiś czas temu, ale możemy skonfigurować je pod konkretny projekt.
Dodaję nową automatyzację, nadaję jej nazwę — na przykład „daily bug sweep” (codzienne zamiatanie błędów) — i podaję prompt. Fajne jest to, że wspierane są dowolne wbudowane komendy Twojego narzędzia. Możemy użyć na przykład komendy goal i powiedzieć: „Celem jest naprawa wszystkich błędów zgłoszonych w ciągu ostatnich 24 godzin przez etykietę »bug« w naszych zgłoszeniach na GitHubie. Zidentyfikuj przyczynę źródłową, utwórz propozycję open spec, napisz testy regresyjne, żeby błąd nie wrócił w przyszłości, wdróż poprawkę przez podagentów, przetestuj ją, sterując symulatorem iOS przez ten serwer MCP do symulatora iOS (to aplikacja mobilna), a następnie utwórz pull requesta”.
Całość uruchamiałaby się wtedy co rano o 9:00. Idealnie, jeśli używamy komendy goal, chcielibyśmy mieć bardzo jasne kryteria akceptacji na końcu — na przykład uruchomienie zestawu testów i sprawdzenie wyników — ale to daje ogólny obraz podejścia.
Następnie precyzuję szczegóły uruchomienia. W tym przypadku chcę, żeby każdy taki przebieg był nowym uruchomieniem w nowym drzewie roboczym odgałęzionym od origin main. Wybieram agenta, który ma to uruchomić. Korzystając z pokazanego procesu, mogę powiedzieć: „Musisz uruchomić agenta orkiestracji, żeby na przykład Codex zrobił review przed utworzeniem PR-a”. Wszystko to można ze sobą łączyć w łańcuch. Na koniec harmonogramuję to na 9:00 i tworzę — teraz będzie się uruchamiać każdego ranka.
Codex znajduje błędy w ustaleniach Opusa
Gdy wracamy, widać, że agenci-recenzenci Codeksa właśnie skończyli i możemy zobaczyć ich ustalenia. W tym przypadku recenzja Codeksa okazała się naprawdę wartościowa, bo faktycznie znalazł wady w tym, co ustalił Opus.
(Informacja dodatkowa: Opus to jeden z modeli Claude’a od Anthropic — tu chodzi o wynik pracy agenta Claude Code, który następnie recenzuje Codex od OpenAI).
Mając te wglądy, możemy uruchomić podagentów, żeby rozwiązali te problemy. Powiem więc: „Uruchom podagentów, żeby wdrożyli każdą z tych poprawek, a następnie utwórz PR, gdy wszystkie będą gotowe. Każde ukończone zadanie powinno przejść adwersaryjne review od Codeksa przez skill orkiestracji”. Trzymamy się tej samej konwencji i podwajamy zakład, żeby przetestować wszystkie te rzeczy.
Dodatki: emulatory, obsługa komputera, głos i aplikacja mobilna
W tym narzędziu można zrobić naprawdę wiele — to dopiero wierzchołek góry lodowej. Sporo da się skonfigurować, na przykład emulatory do testowania. Jeśli chcemy testować aplikacje iOS, Orca ma zintegrowane emulatory. Potrafi też obsługiwać komputer w Twoim imieniu — są umiejętności „computer use”, które można zainstalować. Są komendy głosowe (lepsze niż to, co domyślnie daje Claude Code).
Ostatnia rzecz, którą chcę pokazać, to aplikacja mobilna. Wszystko, o czym mówiliśmy — uruchamianie wielu agentów, orkiestracja między nimi — możesz robić z telefonu. Zaczynasz przez App Store (iOS) albo pobierając APK (Android). Na Androidzie potrzebujesz niestandardowej instalacji — nie da się tego łatwo pobrać wprost ze sklepu. I znów: całe zarządzanie zadaniami, tworzenie nowych przestrzeni roboczych, orkiestrację między różnymi agentami możesz robić w drodze.
Podsumowanie: narzędzie nie zastąpi procesu
Wypróbowałem wiele podobnych narzędzi i uważam, że Orca jest jednym z najlepszych. Do tego jest w całości otwartoźródłowa i darmowa. To dla mnie idealny sposób pracy.
Jedyne, czego brakuje, to fakt, że musisz mieć naprawdę dobry proces, przez który to przepuścisz. Potrzebujesz swego rodzaju „fabryki” — solidnego systemu do budowania rzeczy. Narzędzia takie jak to nie sprawią magicznie, że staniesz się zdolny budować świetne produkty. Do tego potrzebny jest system.
(Informacja dodatkowa: w tym miejscu autor reklamuje własną płatną społeczność dla przedsiębiorców — z cotygodniowymi warsztatami i wsparciem od MVP do wejścia na rynek. To fragment promocyjny, nie część merytoryczna materiału).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przewaga to orkiestracja, nie wybór modelu
Na czym polega: Realną wartość daje dziś umiejętność zarządzania wieloma agentami działającymi jednocześnie, a nie dobór „najlepszego” pojedynczego modelu.
Jak stosować: Zamiast szukać idealnego modelu, projektuj przepływy: kto co robi, kto co recenzuje, jak zadania przechodzą między agentami. Zacznij od 2–3 agentów pracujących na niezależnych zadaniach.
Na co uważać: Orkiestracja sama w sobie jest wąskim gardłem — więcej agentów to więcej pilnowania. Nie mnóż ich bez potrzeby, bo stracisz kontrolę nad tym, co się dzieje.
2.Orca działa na subskrypcji, nie na kluczach API
Na czym polega: W przeciwieństwie do wielu „agentowych IDE” Orca korzysta z Twoich subskrypcji (Claude Max, Codex, Grok, Gemini, Cursor CLI), a nie z płatnych per-token kluczy API.
Jak stosować: Jeśli masz już opłacone subskrypcje agentów terminalowych, sprawdź Orkę, żeby uniknąć podwójnych kosztów za API. To realna oszczędność przy intensywnej pracy.
Na co uważać: Korzystanie z subskrypcji do zautomatyzowanych, masowych przebiegów może naruszać limity lub warunki użytkowania danego dostawcy — zweryfikuj regulamin przed odpaleniem cyklicznych automatyzacji.
3.Drzewa robocze Gita jako izolacja równoległej pracy
Na czym polega: Praca dzieli się na projekty i drzewa robocze (work trees) Gita — każdy agent działa we własnym katalogu roboczym na własnej gałęzi.
Jak stosować: Uruchamiaj osobne drzewa robocze dla zadań dotykających różnych plików, żeby agenci mogli pracować równolegle bez konfliktów. Najpierw poproś agenta o wskazanie, które zadania da się bezpiecznie zrównoleglić.
Na co uważać: Równoległość działa tylko wtedy, gdy zadania faktycznie nie dotykają tych samych plików — inaczej dostaniesz konflikty przy scalaniu. Priorytetyzacja pod kątem kolizji jest kluczowa.
4.Integracja z trackerem zadań zamiast przełączania kontekstu
Na czym polega: Orca łączy się bezpośrednio z GitHubem, Jirą czy Linear, więc zgłoszenia i PR-y widzisz bez wychodzenia z narzędzia.
Jak stosować: Wykorzystuj etykiety (np. „bug”, „usprawnienie UI”) jako filtr dla agentów: „pobierz wszystkie zgłoszenia z etykietą X z ostatnich 3 dni i zbadaj przyczynę”. Utrzymuj dyscyplinę tagowania w trackerze.
Na co uważać: Jakość automatyzacji zależy od jakości Twojego backlogu — źle otagowane lub niejasno opisane zgłoszenia dadzą słabe wyniki działania agentów.
5.Warstwa orkiestracji: krzyżowa recenzja między dostawcami
Na czym polega: Wbudowany skill pozwala, by agenci różnych dostawców (np. Codex) recenzowali ustalenia innych (np. Claude/Opus) i przekazywali sobie zadania — bez własnego skryptowania.
Jak stosować: Najpierw zainstaluj skill orkiestracji w ustawieniach. Potem wprost każ np. „trzem podagentom Codeksa zrecenzować te ustalenia i odesłać analizę”. Użyj różnych modeli jako niezależnych recenzentów.
Na co uważać: Krzyżowa recenzja ma sens realny — w filmie Codex znalazł błędy w ustaleniach Opusa — ale trzykrotne QA zużywa proporcjonalnie więcej zasobów subskrypcji i czasu. Stosuj tam, gdzie koszt błędu jest wysoki.
6.Adwersaryjne review jako standard jakości
Na czym polega: Autor każe każde ukończone zadanie przepuszczać przez „adwersaryjne review od Codeksa” — recenzenta nastawionego na wyszukiwanie wad.
Jak stosować: Wbuduj w swój przepływ regułę: żaden PR nie powstaje, zanim niezależny agent (najlepiej innego dostawcy) nie spróbuje obalić poprawności rozwiązania. Traktuj to jak drugą parę oczu.
Na co uważać: Recenzent też się myli — może zgłaszać fałszywe alarmy albo przeoczyć realne wady. Nie traktuj jego werdyktu jako ostatecznego bez własnej weryfikacji przy krytycznych zmianach.
7.Automatyzacje cykliczne (np. codzienny „bug sweep”)
Na czym polega: Zakładka automatyzacji pozwala harmonogramować powtarzalne przebiegi — np. codziennie o 9:00 znajdź błędy z ostatnich 24 h, napisz testy regresyjne, wdróż poprawkę i otwórz PR.
Jak stosować: Zdefiniuj automatyzację z jasnym celem (goal), nowym drzewem roboczym od main, wybranym agentem i etapem review przed PR-em. Zacznij od jednego prostego, dobrze zdefiniowanego zadania.
Na co uważać: Bez twardych kryteriów akceptacji (uruchomienie testów, sprawdzenie wyników) automatyzacja może otwierać PR-y niskiej jakości co rano. Autor sam podkreśla, że jego przykładowy cel był niepełny.
8.Testy regresyjne i sterowanie emulatorem jako część pętli
Na czym polega: Przepływ naprawy błędu obejmuje pisanie testów regresyjnych oraz weryfikację poprawki przez sterowanie symulatorem iOS (przez serwer MCP), zanim powstanie PR.
Jak stosować: Wpleć w prompt automatyzacji wymóg napisania testu regresyjnego dla każdego błędu i realnego przetestowania na emulatorze — tak, by błąd nie wrócił. To domyka pętlę „znajdź → napraw → zweryfikuj”.
Na co uważać: Sterowanie emulatorem i MCP wymaga wcześniejszej konfiguracji środowiska; bez działającego serwera MCP i emulatora ten etap zawiedzie cicho lub da fałszywe „zielone” wyniki.
9.Aplikacja mobilna do zarządzania w drodze
Na czym polega: Orca ma aplikację mobilną (iOS przez App Store, Android przez APK), z której można uruchamiać agentów, zarządzać zadaniami i orkiestrować przepływy.
Jak stosować: Wykorzystuj mobilkę do monitorowania długich przebiegów i odpalania automatyzacji, gdy nie jesteś przy komputerze. Traktuj to jako pilot, nie główne stanowisko pracy.
Na co uważać: Na Androidzie instalacja z APK wymaga niestandardowego procesu i wiąże się z ryzykiem bezpieczeństwa — instaluj tylko z zaufanego, oficjalnego źródła projektu.
10.Narzędzie nie zastąpi procesu budowania
Na czym polega: Autor wprost zastrzega, że nawet najlepsza orkiestracja nie uczyni z Ciebie budowniczego świetnych produktów — potrzebujesz własnego, solidnego systemu („fabryki”).
Jak stosować: Zanim skalujesz liczbę agentów, dopracuj swój proces: jasne kryteria akceptacji, dobre tagowanie zadań, powtarzalne przepływy. Narzędzie ma wzmacniać dobry system, nie go zastępować.
Na co uważać: Łatwo dać się uwieść efektowności demonstracji. Pamiętaj, że materiał jest częściowo promocyjny (reklama płatnej społeczności autora) — oceniaj Orkę na własnym, realnym projekcie, zanim oprzesz na niej pracę.