O czym jest ten film
- Omnigent to nowe, darmowe narzędzie open source — meta-harness, czyli warstwa, która orkiestruje wielu asystentów kodujących w ramach dłuższych przepływów pracy, z jednej sesji.
- Główna teza autora: otoczka agenta (harness) znaczy dziś co najmniej tyle, co sam model — zwłaszcza że dostęp do czołowych LLM-ów bywa niepewny (przykład: zablokowanie modelu Fable 5).
- Najlepsi inżynierowie nie trzymają się już jednego modelu ani jednego narzędzia: łączą mocne strony agentów i rozdzielają sesje, żeby oszczędzać kontekst i tokeny.
- Projekt pochodzi z Databricks, prowadzi go osobiście CTO firmy, a wewnątrz organizacji korzysta się z niego codziennie w zwykłej pracy inżynierskiej.
- Instalacja jest trywialna: link do repozytorium na GitHubie wystarczy wkleić własnemu agentowi; Omnigent działa lokalnie i korzysta z poświadczeń CLI, w których już jesteśmy zalogowani.
- W zestawie dostajemy dwa przykładowe orkiestratory: Polly (implementacja w Claude Code, review w Codexie) i Debbie (debata dwóch modeli z syntezą wniosku).
- Każdy orkiestrator składa się z trzech elementów: konfiguracji (executor, prompt systemowy, piaskownica, zabezpieczenia), umiejętności i listy agentów, do których można delegować pracę.
- Polityki i zabezpieczenia to zwykły Python obok konfiguracji — przykład z filmu: pełna autonomia agenta poza wymuszonym pushem do gita, który wymaga zatwierdzenia człowieka.
- Kluczowa praktyka: review kodu powinno odbywać się w osobnej sesji niż implementacja, bo model nabiera zbyt dużej stronniczości wobec własnego kodu.
- Sesje można prowadzić równocześnie na wielu urządzeniach (telefon i komputer) oraz współdzielić je z innymi osobami po udostępnieniu instancji w sieci.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Otoczka agenta znaczy co najmniej tyle, co model
Na czym polega: Wniosek autora z bieżącego roku: niezawodność AI codingu zależy od harnessu — promptu systemowego, narzędzi, umiejętności, przepływów i reguł — w stopniu porównywalnym z jakością modelu, a po ograniczeniach dostępu do czołowych LLM-ów coraz częściej od niego większym.
Jak stosować: Zanim zmienisz model na nowszy, zainwestuj czas w dopracowanie otoczki: powtarzalnych przepływów (skills), reguł i narzędzi. To tańsza i stabilniejsza dźwignia jakości.
Na co uważać: To opinia praktyka, nie udowodniona reguła — warto mierzyć efekty (np. liczbę uwag z review), a nie przyjmować ją na wiarę.
2.Review kodu zawsze w osobnej sesji niż implementacja
Na czym polega: Gdy ten sam model pisze i ocenia kod, nagromadza zbyt dużą stronniczość wobec własnej pracy. W społeczności pokutuje przekonanie, że Codex najlepiej radzi sobie z przeglądem, a Claude z pisaniem — według autora nie jest to absolutna prawda, ale praktyka jest powszechna.
Jak stosować: Po zakończeniu implementacji otwórz nową sesję, najlepiej z innym agentem, i tam rób review. W Omnigent gotowy schemat realizuje Polly — wystarczy jedno polecenie.
Na co uważać: Podział ról Claude/Codex to subiektywna ocena — przetestuj na własnym kodzie, który model lepiej sprawdza się u Ciebie w roli recenzenta.
3.Jedna sesja zamiast skakania po terminalach
Na czym polega: Ręczna orkiestracja kilku agentów oznacza przełączanie się między terminalami i ręczne tworzenie dokumentów przekazujących zadanie dalej — to droga przez mękę i łatwe miejsce na błędy.
Jak stosować: Wszystkie dłuższe przepływy prowadź z jednego miejsca, które zna kontekst projektu i potrafi delegować etapy do wybranych asystentów.
Na co uważać: Przy krótkich, jednorazowych zadaniach orkiestracja bywa przesadą — zacznij od jednego przepływu (implementacja plus review) i rozbudowuj, gdy zacznie zwracać czas.
4.Instalację zleć swojemu agentowi i wykorzystaj lokalne poświadczenia
Na czym polega: Setup Omnigent sprowadza się do wklejenia linku do repozytorium własnemu asystentowi (lub pojedynczej komendzie). Narzędzie działa lokalnie, więc Claude Code, Codex czy Pi używają poświadczeń z CLI, w których już jesteśmy zalogowani — bez ponownej autoryzacji. Autor przeszedł cały proces w niecałe dziesięć minut.
Jak stosować: Podaj agentowi link do repo i poproś o konfigurację, łącznie z wdrożeniem na serwer czy dostępem z telefonu (instrukcje są w readme projektu).
Na co uważać: Lokalne działanie oznacza, że poświadczenia i repozytoria zostają na Twojej maszynie — przed dłuższą pracą sprawdź konfigurację piaskownicy.
5.Dziel długi proces na sesje, żeby oszczędzać kontekst i tokeny
Na czym polega: Rozdzielenie etapów (implementacja, review, przygotowanie PR) na osobne sesje i agentów pozwala nie „zaśmiecać” kontekstu każdym etapem i płacić mniej za tokeny — zdaniem autora ważniejsze niż kiedykolwiek.
Jak stosować: Długie zadania projektuj jako sekwencję krótkich sesji z jasnym przekazaniem wyniku między nimi; orkiestrator dba o ciągłość.
Na co uważać: Przekazanie między sesjami musi nieść pełny kontekst (np. zgłoszenie z GitHuba, opis zadania) — zbyt skrótowe streszczenie niweczy korzyści.
6.Orkiestrator składa się z trzech klocków
Na czym polega: Konfiguracja (executor, czyli asystent pracujący, gdy nikt nie jest delegowany; prompt systemowy; tryb piaskownicy; zabezpieczenia), umiejętności — czyli zapisane, powtarzalne przepływy — oraz lista agentów, do których można delegować (Claude Code, Codex, Pi, modele lokalne przez Ollamę, Kimi, MiniMax). Każdy pojedynczy agent ma taką samą strukturę konfiguracji.
Jak stosować: Nowego orkiestratora nie pisz od zera — poleć swojemu asystentowi przejrzeć konfigurację Polly’ego i Debbie i zbudować analogiczną (tak zrobił autor).
Na co uważać: Osobna konfiguracja każdego agenta daje elastyczność, ale zwiększa liczbę miejsc do utrzymania — trzymaj spójne konwencje nazw i struktury.
7.Polityki to zwykły Python obok konfiguracji — i działają dla każdego agenta
Na czym polega: Przykład z filmu: agent działa w pełni samodzielnie, ale każda komenda pushu z flagą wymuszenia (—force) wymaga zatwierdzenia człowieka, bo może nadpisać zmiany w repozytorium. Polityka to plik Pythona leżący obok konfiguracji agenta — autor w ogóle nie pisał go ręcznie, wygenerował go jego asystent.
Jak stosować: Wypisz operacje destrukcyjne (wymuszone pushowanie, kasowanie, wdrożenia) i dodaj dla nich wymóg zatwierdzenia; przetestuj, prosząc agenta o taką komendę — powinien poprosić o zgodę.
Na co uważać: Zabezpieczenie działa w obrębie platformy orkiestrującej — komendy uruchamiane poza nią nie są objęte. W Claude Code podobny efekt dają hooki, ale tam reguła dotyczy tylko tego jednego agenta.
8.Piaskownice i zatwierdzenia człowieka — przygotowanie pod produkcję
Na czym polega: Omnigent pozwala uruchamiać agentów bez izolacji, w Dockerze albo na platformach typu E2B, a mechanika „człowieka w pętli” wstrzymuje przepływ do momentu naszej zgody przy wrażliwych akcjach.
Jak stosować: Do codziennej pracy wystarczy tryb lokalny; gdy agent wykonuje operacje na żywych systemach, przenieś wykonanie do piaskownicy, a krytyczne kroki zostaw do ręcznego zatwierdzenia.
Na co uważać: Piaskownica to dodatkowa warstwa złożoności — upewnij się, że katalog roboczy i dostęp do sieci w izolowanym środowisku są skonfigurowane zgodnie z projektem.
9.Poza kodem: niech dwa modele się pokłócą
Na czym polega: Przykładowy orkiestrator Debbie stawia naprzeciw siebie dwóch agentów (Claude i GPT), każe im argumentować za przeciwnymi stanowiskami przez ustaloną liczbę rund, a na końcu syntetyzuje wspólne stanowisko. Można podejrzeć rozumowanie i zużycie tokenów każdego z osobna.
Jak stosować: Przy decyzjach projektowych czy architektonicznych zorganizuj kontrastową debatę dwóch modeli i oceń syntezę — wtedy łatwiej dostrzec słabe punkty własnego pomysłu.
Na co uważać: Wynik zależy od promptów, liczby rund i doboru modeli — traktuj go jako wsparcie decyzji, nie ostateczny werdykt.
10.Sesje działają na wielu urządzeniach i można je współdzielić
Na czym polega: Tę samą rozmowę można prowadzić równolegle na telefonie i komputerze — najprościej, gdy urządzenia są w jednej sieci Wi-Fi; po wdrożeniu na serwer działa to przez internet, także z innymi osobami. Autor całą konfigurację zlecił swojemu agentowi.
Jak stosować: Wdróż instancję na serwerze (instrukcje w readme — można je po prostu przekazać agentowi), a potem wracaj do sesji z dowolnego urządzenia i zapraszaj do niej zespół.
Na co uważać: Udostępnienie instancji w internecie wystawia sesje poza lokalną sieć — zadbaj o dostęp i uwierzytelnienie.
Redakcyjne tłumaczenie
Narzędzie z minionego weekendu
W miniony weekend opublikowano nowe narzędzie open source — Omnigent. Warto je dziś rozłożyć na części, bo to bardzo potężny i darmowy meta-harness. Wyjaśnijmy od razu pojęcia, bo będą wracać przez cały materiał. Harness to cała otoczka, którą budujemy wokół modelu, żeby agent piszący kod pracował niezawodnie: prompt systemowy, narzędzia, umiejętności, przepływy pracy, reguły. Meta-harness to piętro wyżej — narzędzie, które pozwala łączyć różnych asystentów programistycznych w dłuższe przepływy i sterować nimi z jednego miejsca.
Najbardziej klasyczny przykład, który teraz zachwyca ludzi: implementacja w Claude Code, a potem przegląd tego kodu w Codexie. Dziś czołowi inżynierzy nie opierają się na pojedynczym modelu, a nawet na pojedynczym narzędziu. Chodzi o wykorzystanie mocnych stron poszczególnych asystentów, a także o rozdzielanie sesji — dla oszczędzania kontekstu i tokenów, co jest ważniejsze niż kiedykolwiek. Omnigent jest właśnie warstwą nad asystentami, dzięki której taka orkiestracja staje się prosta: dostajemy jedną sesję do zarządzania wszystkimi agentami i możliwość budowania własnych. Gdy podobnego narzędzia brakuje, trzeba skakać między terminalami i ręcznie tworzyć dokumenty przekazujące zadanie dalej — to droga przez mękę. Meta-harness to w tej dziedzinie najwyższa forma inżynierii.
Plan materiału jest prosty: najpierw wyjaśnię, dlaczego meta-harnessy są teraz takie ważne, a potem pokażę, jak łatwo prowadzić w Omnigent dłuższe przepływy i zbudować własny, niestandardowy setup.
Dlaczego meta-harnessy mają teraz tak duże znaczenie
Jeśli z tegorocznej pracy z agentami kodującymi można wynieść jedną lekcję, to właśnie tę: otoczka agenta znaczy co najmniej tyle, co model — a może i więcej. Robi się to jeszcze wyraźniej widoczne po niedawnym zablokowaniu modelu Fable 5 (Informacja dodatkowa: chodzi o ograniczenie dostępności czołowego LLM-a — autor nie podaje szczegółów; przykład ma pokazać, że dostęp do najlepszych modeli bywa niepewny). Nie możemy już zakładać, że zawsze będziemy mieć do dyspozycji najlepsze modele — albo że zaraz przyjdą jeszcze lepsze. Skoro nie ulepszymy samego LLM-a, trzeba wzmocnić to, co go otacza. Cały pakiet — prompt systemowy, narzędzia, umiejętności, przepływy, reguły — to właśnie harness, od którego zależy niezawodność pojedynczego asystenta.
Meta-harness to natomiast kierunek, w którym środowisko coraz chętniej idzie — kolejna wielka rzecz w kodowaniu wspomaganym AI. Zamiast doszlifowywać jednego agenta, budujemy warstwę, która każe wielu asystentom wspólnie pracować nad większym zadaniem. Dokładnie to znaczy pojęcie meta-harness. Sam rozwijam coś wokół tej idei w projekcie Archon i kilka rozwiązań z Omnigent na pewno przeniosę do własnego narzędzia. To bardzo mocny trend.
Do tego Omnigent działa niemal od razu po instalacji. Jak zaraz zobaczycie, wszystko stawia się w kilka minut. Można pracować z tego samego środowiska na różnych urządzeniach, podpiąć najpopularniejszych asystentów — Claude Code, Codex czy Pi — korzystając z rozmaitych modeli, a także współdzielić sesje z innymi osobami, czego typowe agenty do dziś nie oferują. Jest i cała warstwa polityk, zabezpieczeń oraz piaskownic, więc platforma jest przygotowana pod warunki produkcyjne. Jestem pod ogromnym wrażeniem tego, co powstało, i szczerze się cieszę, że wszystko udostępniono jako open source.
Skąd się wzięło narzędzie i jak jest zbudowane
Ciekawy kontekst: Omnigent to projekt open source firmy Databricks — dużej organizacji — prowadzony osobiście przez ich dyrektora technicznego. Wewnątrz firmy korzystają z niego bardzo intensywnie, codziennie, w zwykłej pracy inżynierskiej, i odnoszą spore sukcesy. Mówiąc obrazowo: sami są swoim pierwszym użytkownikiem.
Architekturę da się opisać w kilku zdaniach. Wybierasz dowolnego agenta albo tworzysz własnego i uruchamiasz go w piaskownicy — dzięki temu praca jest niezawodna i bezpieczna. Nad wszystkim stoi główny orkiestrator, który trzyma historię, polityki i zabezpieczenia, serwery MCP oraz umiejętności. Dostosowana przez Ciebie warstwa AI żyje więc po stronie serwera i dotyczy każdego asystenta, którego uruchomisz. Nie trzeba utrzymywać osobnej konfiguracji dla Pi i osobnej dla Claude Code — wszystko działa na najwyższym poziomie. Korzystać można na wiele sposobów: przez natywną aplikację, REST API do zadań programistycznych, terminal — dla tych, którzy czują się w nim jak w Claude Code — oraz interfejs webowy.
Start w kilka minut i interfejs webowy
Żeby zacząć, dosłownie wystarczy wkleić link do repozytorium na GitHubie swojemu asystentowi i poprosić o skonfigurowanie wszystkiego (link zostawiam w opisie filmu). A jeśli wolisz zrobić to sam, to pojedyncza komenda. Serio — spróbuj od razu. Nie trzeba nawet logować się ponownie: Claude, Codex czy Pi korzystają z poświadczeń z CLI, w którym już jesteś zalogowany, bo Omnigent działa lokalnie na Twoim komputerze. W zestawie dostajemy Polly’ego i Debbie, dwa przykładowe agenty orkiestrujące współpracę między Claude i Codexem. Zaraz pokażę, jak działają, a przy okazji — jak tworzyć własnych agentów i orkiestratorów.
Po uruchomieniu zobaczysz webowy interfejs — prosty i elegancki, kojarzy mi się z aplikacją Codexa. Całość jest zbudowana wokół rozmowy z agentem: masz okno czatu i mówisz, co chcesz zbudować. Przełącza się między agentami kodującymi, przykładowymi orkiestratorami oraz parą własnych, które za chwilę omówię. Przy własnych dodatkowo wybieramy harness — gdybym chciał użyć Pi z Ollamą do pracy lokalnej (Informacja dodatkowa: Ollama to popularne narzędzie do uruchamiania modeli lokalnie, na własnym komputerze), nie ma najmniejszego problemu. Elastyczność jest pełna.
Wybieram katalog roboczy, na przykład moją aplikację AI Tutor. Mogę też sięgnąć po drzewa robocze (worktrees), czyli odseparowane kopie repozytorium, w których kilka wątków pracy biegnie równolegle — to bardzo istotna praktyka. I wysyłam zlecenie. Nie będziemy oczywiście siedzieć i patrzeć, jak agent pracuje na żywo, dlatego przechodzę od razu do rozmowy już zakończonej.
Polly w akcji: implementacja w Claude Code, review w Codexie
Orkiestratorem był Polly. Ma umiejętności opisujące, jak prowadzić większe przepływy między agentami, oraz dostęp do poszczególnych harnessów. Można mu przekazać zgłoszenie z GitHuba albo zwykły, swobodny opis zadania — tak jak ja w tym przypadku. Wprost zaznaczyłem, że implementacja ma pójść do Claude Code, a przegląd kodu do Codexa.
Najpierw Polly ładuje kontekst projektu, a potem własną umiejętność, dzięki której zna powtarzalny przebieg tego przepływu. Następnie uruchamia Claude Code — jako proces potomny, który w zależności od ustawień może działać w piaskownicy albo bez niej (wszystko się konfiguruje, jeszcze do tego wrócimy). Polly nadzoruje implementację, a po jej zakończeniu przekazuje kod do review w Codexie. Autoryzacji nie konfigurowałem od nowa — narzędzie po prostu użyło moich istniejących poświadczeń Claude Code i Codexa. Całość, łącznie z instalacją, postawiłem w niecałe dziesięć minut i bez trudu przeprowadziłem przepływ łączący Claude z Codexem.
To prosty przykład, ale fundamentalny: przegląd kodu powinien odbywać się w sesji odseparowanej od implementacji, najlepiej w innym agencie. W przeciwnym razie model nagromadzi zbyt dużo stronniczości wobec tego, co sam napisał. I choć to żadna absolutna prawda, wielu ludzi uważa, że Codex najlepiej radzi sobie z przeglądem, a Claude z pisaniem kodu. Jeśli jeszcze nie pracujesz w takim schemacie, zachęcam do próby — zwłaszcza że dzięki Omnigent nie jest to już żadna przeszkoda.
Praca kończy się implementacją zapisaną lokalnie w drzewie roboczym. Dalej wszystko wygląda jak w zwykłym asystencie: można dopisać na przykład „zrób z tego pull request” i doprowadzić zmiany do momentu review i wypuszczenia. Omnigent ma pełnię możliwości każdego agenta kodującego, a do tego potrafi przywoływać poszczególnych asystentów.
Jak zbudowany jest orkiestrator
Nie będziemy siedzieć długo w konfiguracji, ale warto zobaczyć, jak to wygląda w zarysie. Twórcy przygotowali proste prymitywy do budowania własnych agentów i orkiestratorów — a co ważne, platforma jest tak pomyślana, żeby nasz asystent AI pomagał nam w tej budowie. Każdy orkiestrator składa się z trzech części: konfiguracji, umiejętności (jak ta do wzajemnego review, którą widzieliśmy w interfejsie) oraz agentów, do których może się odwoływać, prowadząc większy przepływ.
Agentami mogą być Claude Code i Codex — jak już widzieliśmy — ale też na przykład subskrypcja Kimi, MiniMax czy modele lokalne przez Ollamę (Informacja dodatkowa: Kimi i MiniMax to azjatyccy dostawcy dużych modeli językowych, popularni m.in. dzięki subskrypcyjnym planom). Domyślny Polly potrafi dodatkowo uruchamiać Pi.
W konfiguracji znajdziemy między innymi executor, czyli asystenta, który pracuje wówczas, gdy orkiestrator właśnie nikogo nie deleguje — tu na najwyższym poziomie jest to Claude. Dalej prompt systemowy (długi, ale dziś rzadko bywa inaczej), ustawienia piaskownicy — można działać bez izolacji, w Dockerze albo na platformach produkcyjnych typu E2B (Informacja dodatkowa: E2B to usługa uruchamiania kodu generowanego przez AI w izolowanych, bezpiecznych środowiskach) — a także cała sekcja poświęcona zabezpieczeniom. Jest tu mechanika człowieka w pętli (human in the loop): przepływ zatrzymuje się i czeka na naszą zgodę, na przykład przy wymuszonym pushu do gita. W narzędziach z kolei wskazujemy, do których agentów orkiestrator może delegować pracę. Umiejętności to klasyka znana z Claude Code, Codexa i pozostałych asystentów: zapisany przepływ, po którym agent przeprowadza się sam. Każdy pojedynczy agent ma dokładnie taką samą strukturę konfiguracji — prompt systemowy, executor (ten używa Claude, tamten Codexa, kolejny Pi), narzędzia i zabezpieczenia — więc każdy element orkiestry da się dopasować osobno.
Własny agent i polityka pilnująca pushy
Teraz przykład łączący dwie rzeczy: budowanie własnego agenta oraz polityki i zabezpieczenia. Stworzyłem agenta bardzo prostego: skromny prompt systemowy, Claude Code, bez piaskownicy. Dodałem za to własne zabezpieczenie — agent może samodzielnie uruchamiać dowolne komendy z jednym wyjątkiem: push do gita z flagą wymuszenia. To jedna z tych operacji, przy których naprawdę trzeba uważać, bo potrafi nadpisać zmiany w repozytorium.
Polityka leży po prostu obok konfiguracji agenta i jest zwykłym kodem w Pythonie. W dodatku nie napisałem jej sam — całość stworzył mój asystent, gdy tylko poleciłem mu spojrzeć, jak skonfigurowane są Polly i Debbie, i zbudować coś analogicznego według mojego opisu.
Zobaczmy to w praktyce. Wracam do Omnigent, przełączam się na mojego agenta z zabezpieczeniem i wklejam zlecenie: wykonaj komendę git push z wymuszeniem do gałęzi feature. Przy okazji coś, czego jeszcze nie pokazałem, bo nie było żywego przebiegu: po załadowaniu repozytorium widzimy wszystkie pliki w przestrzeni roboczej, a przy orkiestracji wielu agentów — również ich samych. Interfejs jest naprawdę dopracowany. I proszę: agent pyta o moją zgodę. Kontrola jest więc bardzo precyzyjna — sami decydujemy, co agent wykonuje samodzielnie, a co wymaga naszego zatwierdzenia. Owszem, podobny efekt dałoby się osiągnąć hookami w Claude Code, ale przewaga Omnigent polega na tym, że zabezpieczenie działa niezależnie od tego, jakiego agenta właśnie uruchamiamy czy orkiestrujemy.
Debbie: niech dwa modele się pokłócą
Omnigent sprawdzi się też poza samym pisaniem kodu, a najlepszym przykładem jest Debbie — drugi z dołączonych orkiestratorów. Debbie stawia dwóch agentów naprzeciwko i każe im spierać się o pytanie albo temat, a potem wspólnie dojść do wniosku, nadzorując całość. Zadaję pytanie, Claude rozumuje i obejmuje jedno stanowisko, a GPT kontrargumentuje z drugiej strony. Można wejść w widok każdego z nich i osobno przejrzeć rozumowanie oraz zużyte tokeny, po czym wrócić do Debbie i zobaczyć, jak wygląda cała orkiestracja.
W moim przebiegu były dwie rundy — tyle zaznaczyłem w prompcie. Uwagi GPT trafiały do Claude’a i odwrotnie, a na koniec Debbie zamknęła debatę, syntetyzując to, co powiedziały obie strony, i podając ostateczną odpowiedź. Podobnie jak test z Polly’m, to raczej prosty przykład — pokazuję go tylko po to, żeby zasygnalizować kształt takich przepływów. Gdy łączenie agentów staje się tak banalnie proste, wyobraźnia naprawdę może rozwinąć skrzydła; tym bardziej że własnych orkiestratorów również nie trzeba tworzyć ręcznie, jak pokazałem wcześniej.
Ta sama sesja na telefonie i komputerze
Została nam ostatnia funkcja, której jeszcze nie pokazałem: współpraca. Chodzi o pracę w tej samej sesji jednocześnie na telefonie i komputerze. Da się to zrobić przez internet — więc także z ludźmi z drugiego końca świata — ale najprostszy wariant to urządzenia w jednej sieci Wi-Fi. W readme projektu znajdują się instrukcje: wdrożenie na serwer, korzystanie z telefonu. Ja osobiście niczego nie konfigurowałem sam — po prostu zleciłem to swojemu agentowi. To zresztą motyw przewodni każdej instalacji dzisiaj.
Wracam do rozmowy z mechaniką człowieka w pętli, którą pokazywałem wcześniej. Biorę telefon, piszę „cześć”, wysyłam — i proszę: wiadomość natychmiast pojawia się na komputerze. Przechodząc z pokoju do pokoju, mogę spokojnie prowadzić rozmowę dalej. A gdy udostępnisz własną instancję w internecie, to samo działa w zespole.
Na koniec
To wszystko, czego potrzebujesz, żeby zacząć pracę z Omnigent. Meta-harnessy są dziś po prostu koniecznością: przyklejanie się do jednego modelu czy jednego dostawcy na cały przepływ kodowania nie jest już najlepszą strategią. Gorąco zachęcam do wypróbowania — wystawienie tego zajmuje dosłownie chwilę. Jeśli doceniasz ten materiał i czekasz na więcej o inżynierii otoczek i kodowaniu z AI, polub film i zasubskrybuj kanał. Do zobaczenia w następnym.