O czym jest ten film
- Oracle udostępnia agent skills, które pozwalają rozszerzać aplikacje Fusion za pomocą zwykłych agentów kodujących — Claude Code czy Codex.
- Problem wyjściowy: gotowe platformy pokrywają ok. 90% potrzeb, a każde odstępstwo wymaga rzadkich i drogich specjalistów oraz tygodni czekania w backlogu IT.
- Przepływ pracy: lokalny agent → skill AI Studio → narzędzie CLI → walidacja w chmurze Fusion → publikacja przez człowieka.
- Reguła pierwsza: najpierw specyfikacja, dopiero potem kod.
- Reguła druga: wszystko jest domyślnie tylko do odczytu, dopóki nie zażądasz inaczej.
- Reguła trzecia: najpierw rozpoznanie istniejących wzorców, dopiero potem budowa.
- Reguła czwarta: struktura zamiast improwizacji — guardrails wpisane w pliki skillów.
- Reguła piąta: brak walidacji oznacza brak ukończenia.
- Demo: budowa dashboardu planowania sukcesji na żywych danych HR, z rekomendacjami następców.
- Wniosek dla twórców oprogramowania: skill przenoszący wiedzę domenową plus CLI do odpytywania platformy to komplet, który wystarczy.
Redakcyjne tłumaczenie
Czym są Oracle Fusion Applications i skąd bierze się problem
Dziś przyglądamy się czemuś naprawdę ciekawemu: temu, jak wielkie firmy — takie jak Oracle — wykorzystują agentów kodujących do budowania i rozszerzania swoich aplikacji. Niezależnie od tego, czy dopiero zaczynasz przygodę z agentowym kodowaniem, czy chcesz podnieść swój poziom, sposób pracy tych organizacji ma sporo do zaoferowania. Wszystko sprowadza się do pięciu ważnych zasad, które można przenieść do własnych projektów — i każdej z nich przyjrzymy się po kolei.
Oracle znasz zapewne przede wszystkim z baz danych, ale firma ma też coś, co nazywa się Oracle Fusion Applications. To one stanowią kręgosłup naprawdę dużych organizacji: HR, finanse, zakupy, łańcuch dostaw, sprzedaż, marketing. I nie jest to skala symboliczna — ponad 14 tysięcy dużych firm na całym świecie prowadzi swoją działalność w oparciu o Oracle Fusion Applications. Może trochę wybiegam naprzód, ale ponad 7 tysięcy z tych klientów korzysta już z funkcji Fusion AI, czyli tego, co pozwala budować nadbudowy nad ich aplikacjami przy użyciu agenta AI.
(Informacja dodatkowa: Fusion Applications to pakiet chmurowego oprogramowania klasy ERP/HCM — odpowiednik SAP-a w portfolio Oracle’a. Odbiorcą są korporacje, nie użytkownicy indywidualni.)
Teraz wyzwanie, które ma wiele organizacji. Jeśli działasz w takiej skali i twoim back office jest Oracle Fusion, siedzi tam mnóstwo surowych danych, które są właściwie bezużyteczne, dopóki czegoś z nimi nie zrobisz.
Weźmy dla przykładu HR — kapitał ludzki. Masz w organizacji sporo osób na kluczowych stanowiskach. Co się dzieje, kiedy taka osoba postanowi odejść albo coś jej się przydarzy? Czy masz plan, żeby wprowadzić kogoś na jej miejsce? Niestety wiele organizacji jest bardzo reaktywnych — czekają, aż coś się wydarzy. To dokładnie ta sytuacja, w której nie chcesz się znaleźć. Fajnie byłoby mieć widok, który podświetla takie ryzyka, żeby dało się je adresować proaktywnie.
I tu pojawia się przeszkoda: dodanie takiego widoku czy komponentu wcale nie jest proste. Mówię to z doświadczenia — sporą część kariery spędziłem, pracując w bardzo podobnym środowisku.
Dlaczego rozszerzenie takiej platformy jest tak kosztowne
Trzeba zrozumieć, że platformy pokroju Oracle Fusion starają się zaadresować bardzo szeroki zestaw wymagań. Ich rozwiązanie HR daje solidny fundament, który zadziała może dla 90% firm. Ale większość firm ma jakieś unikalne wymaganie i musi rozszerzyć aplikację o coś, co jest specyficzne tylko dla niej. Tak jak w naszym przykładzie — być może dostarczone rozwiązanie HR nie zawiera widoku sukcesji, a twoja organizacja potrzebuje dashboardu zarządzania sukcesją zbudowanego na tych danych.
A to wcale nie jest proste. W praktyce oznacza to, że zespół HR musi spisać wymaganie albo specyfikację. To trafia do zespołu IT i ląduje w backlogu. Potem potrzebny jest wyspecjalizowany programista — bo te platformy mają zazwyczaj bardzo specyficzną składnię i strukturę plików, więc potrzebujesz kogoś, kto rozumie Oracle Fusion albo podobne systemy, żeby zbudował dla ciebie rozszerzenie. Tacy specjaliści są rzadcy i drodzy. Efekt: proste wymaganie potrafi zająć tygodnie, jeśli nie miesiące.
Jak Oracle wykorzystuje agentów AI, żeby to skrócić
Oracle wziął te wyspecjalizowane kompetencje i wiedzę, i zamienił je w agent skills — wraz z przykładowymi promptami — których może użyć praktycznie każdy, kto ma konto Codeksa albo Claude Code.
(Informacja dodatkowa: agent skills to katalogi z instrukcjami i plikami referencyjnymi, które agent wczytuje jako wiedzę domenową. To sposób na przekazanie agentowi konwencji konkretnego systemu bez uczenia modelu od nowa.)
Cały przepływ wygląda mniej więcej tak. Twoja przestrzeń robocza jest na lokalnym komputerze i sprowadza się do rozmowy z agentem — może to być Claude Code, Codex, w zasadzie dowolny agent kodujący. Agent korzysta ze skilla AI Studio i z narzędzia CLI. To narzędzie pozwala mu połączyć się z Fusion Studio działającym w chmurze, żeby pobrać istniejące wzorce i tym podobne. Agent produkuje pliki — plik aplikacji, pliki workflow i tak dalej. Kiedy zmiany są gotowe, wysyłamy je do Fusion Cloud. Oracle Agent Studio przegląda te pliki, żeby sprawdzić, czy są poprawne. Jeśli są problemy, pliki wracają do naszego agenta i ten musi wprowadzić poprawki. Jeśli walidacja się powiedzie, Oracle buduje ekrany z zatwierdzonych, istniejących bloków, a użytkownicy końcowi dostają dostęp do nowego widoku.
Jeszcze jedno doprecyzowanie, zanim wejdziemy w demo: budujemy rozszerzenia lokalnie, w Codeksie albo Claude Code, więc pliki są na naszej maszynie — ale dane, które widzimy w podglądzie, pochodzą z rzeczywistej platformy chmurowej. To żywe dane siedzące w Fusion.
Pięć zasad, które warto przenieść do własnej pracy
Zasada pierwsza: specyfikacja jest pierwsza. Nic nie powstaje, dopóki nie ma planu i dopóki wszystko nie zostanie uzgodnione. Jeśli znasz framework RAM, to jest ci to doskonale znane. Rozmawiamy z agentem, żeby ustalić, co właściwie chcemy zbudować, i na końcu mamy szczegółowy plan wdrożenia albo specyfikację.
Zasada druga: wszystko jest tylko do odczytu, dopóki nie powiesz inaczej. Domyślnie, kiedy dodajesz nową funkcję, wszystko działa w trybie odczytu — chyba że wydasz bardzo konkretne polecenie dodania możliwości tworzenia lub modyfikowania danych. Kontrolują to precyzyjne reguły dla agenta zapisane w plikach skillów.
Zasada trzecia: rozpoznanie przed budową. Zanim agent cokolwiek wygeneruje, najpierw robi rozpoznanie w systemie i szuka istniejącego kodu, wzorców albo workflow, na których może się oprzeć. Jeśli poprosisz go o zbudowanie widoku zarządzania sukcesją, najpierw sprawdzi, czy w systemie nie ma już workflow lub wzorców do ponownego wykorzystania, zamiast budować wszystko od zera.
Zasada czwarta: struktura zamiast improwizacji. W tych agent skills są bardzo konkretne reguły, których agent musi przestrzegać przy każdym zadaniu. Te guardrails sprawiają, że agent nie improwizuje i nie odpływa we własnym kierunku. Ma poruszać się w wyznaczonym pasie.
Zasada piąta — moim zdaniem najważniejsza: brak walidacji oznacza brak ukończenia. To, że powstała garść plików i lokalnie wszystko wygląda na działające, nie oznacza, że praca jest skończona. Wszystko musi przejść walidację, zanim system uzna to za zakończone i dopuści do publikacji.
Ten jeden slajd z pięcioma zasadami możesz spokojnie zrzucić jako screenshot — to naprawdę może być krytyczna mapa drogowa, jeśli pracujesz na dużych platformach w dużych organizacjach.
Chcę być z tobą szczery: te platformy zwykle nie są dostępne dla każdego. Jeśli to oglądasz, są spore szanse, że nie masz dostępu do tego środowiska — ale nie o to w tym filmie chodzi. To rozwiązanie bardzo ekskluzywne, zwykle trzeba być partnerem takiej firmy, żeby dostać dostęp. To materiał edukacyjny: pokazuję coś zamkniętego, żebyś mógł się z tego uczyć i myśleć o tym, budując własne aplikacje. A jeśli pracujesz na poziomie enterprise albo z dużymi zespołami deweloperskimi, lekcji do wyniesienia jest tu naprawdę sporo.
Konfiguracja: skille, rozszerzenie VS Code, CLI
Pierwsza lekcja, jaką bym stąd wyciągnął: musisz maksymalnie ułatwić użytkownikom start. Jeśli zrobisz to dobrze, ludzie nie muszą być programistami, żeby rozszerzać twoją aplikację. Oracle wykonał tu naprawdę dobrą robotę — udostępnił wszystko publicznie. To publiczne repozytorium, a agent skills, narzędzie CLI, rozszerzenia do VS Code — wszystko leży w jednym prostym repo.
Wchodzimy do folderu, znajdujemy AI Studio, a w nim wszystkie agent skills spakowane w małym pliku zip. Żeby rozszerzyć dowolną aplikację Oracle Fusion, wystarczy kliknąć „kopiuj” albo pobrać archiwum i sklonować to do pustego folderu projektu.
Pierwsze, co trzeba zrobić, to zainstalować rozszerzenie VS Code, które połączy edytor — i naszego agenta — z kontem Oracle Fusion. Otwieram folder w eksploratorze, wchodzę do folderu release, potem AI Studio, potem bin, i wypakowuję zawartość pliku z rozszerzeniami AI Studio. Wracam do VS Code, wchodzę w zakładkę rozszerzeń, klikam trzy kropki, wybieram „Install from VSIX”, wracam do folderu AI Studio, bin, folder rozszerzeń, zaznaczam rozszerzenie AI Studio i instaluję.
Następnie klikam „configure authentication” i wybieram uwierzytelnianie podstawowe. Jeśli nie zobaczyłeś tego wyskakującego okna, nie martw się — wystarczy nacisnąć Ctrl+Shift+P, wyszukać „Fusion AI Studio”, kliknąć „configure authentication”, a potem „basic authentication”. Teraz trzeba podać adres URL swojej aplikacji Oracle Fusion — jeśli masz konto Fusion, ten adres już znasz. Jeśli chcesz spróbować sam, linkuję stronę w opisie filmu; można tam poprosić o demo albo skontaktować się z działem sprzedaży. Wklejam swój URL, zatwierdzam, podaję nazwę użytkownika i hasło. To tworzy plik env.properties w katalogu głównym projektu.
Połączenie mamy. Teraz kopiujemy agent skills, które nauczą naszego agenta rozszerzać te aplikacje. Znowu w folderze bin wypakowuję zawartość folderu ze skillem AI Studio. W katalogu głównym projektu — w zależności od używanego agenta — możesz potrzebować folderu .claude, jeśli pracujesz na modelach Claude’a, albo, w zasadzie w każdym innym przypadku, folderu .agents. Wewnątrz tworzę podfolder skills, wracam do bin i kopiuję skill AI Studio do folderu ze skillami agenta.
(Informacja dodatkowa: w Claude Code skille umieszcza się w .claude/skills/; katalog .agents/skills/ to konwencja przenośna między różnymi narzędziami agentowymi.)
Otwieram agenta kodującego — Claude’a albo, jak w tym filmie, Codeksa — i wpisuję polecenie wylistowania skillów, po czym pytam: jakie masz skille do dyspozycji? Agent potwierdza, że widzi skill AI Studio.
Wychodzę na chwilę i uruchamiam jedno polecenie. Wygląda strasznie, ale służy tylko sprawdzeniu, czy narzędzie CLI działa. Jeśli widzisz listę wszystkich funkcji i narzędzi — działa.
Skille domenowe: przeniesiona wiedza ekspercka
Teraz instalujemy jeszcze jeden skill. Ten poprzedni nauczył agenta, jak używać CLI do pracy z AI Studio. Ale chcemy też skilla domenowego — na przykład zarządzania sukcesją. Wypakowuję folder, wchodzę w AI Studio, potem w skille aplikacyjne AI Studio, i mamy dostęp do dwóch skillów domenowych: zarządzanie sukcesją oraz braki w operacjach magazynowych.
To jest naprawdę fajne — właśnie w ten sposób można przenieść wiedzę ekspercką do skillów, z których korzystają agenci. Dostajemy bardzo konkretne reguły dotyczące przekazania pracy do AI Studio. Są też reguły dotyczące guardrails — to jedna z zasad, o których mówiliśmy wcześniej: agent nie może po prostu robić, co mu się podoba, musi trzymać się tych reguł. Jeśli chcesz, przeczytaj te pliki — to naprawdę popis tego, jak pisać skille. Można się z nich sporo nauczyć.
Teraz po prostu przenoszę ten skill do naszego folderu ze skillami. I to tyle — tak prosta jest cała konfiguracja.
Wyobraź sobie, że pracujesz w dużym zespole albo budujesz ogromny system i chcesz maksymalnie ułatwić użytkownikom jego rozszerzanie. To dosłownie wszystko, co musisz zrobić: stworzyć agent skills, które przekazują agentom wiedzę domenową i znajomość systemu, oraz narzędzie CLI, którym agent może odpytywać twoją platformę — na przykład wyszukiwać istniejące wzorce, kod czy pliki w rozwiązaniu chmurowym.
Demo: dashboard planowania sukcesji
Środowisko gotowe, więc teraz część zabawna. Otwieram agenta kodującego. Możesz spokojnie użyć Claude Code albo czegokolwiek innego; ja idę w Codeksa — moim zdaniem jest znacznie tańszy niż Claude Code i wyciskam z limitów więcej.
Wysyłam agentowi taki prompt: zaprojektuj i zbuduj aplikację do planowania sukcesji dla menedżerów odpowiedzialnych za sukcesję swoich bezpośrednich podwładnych. Aplikacja ma pozwalać menedżerom proaktywnie identyfikować ryzyka sukcesji, oceniać gotowość następców i wskazywać kluczowych pracowników, którzy nie mają wyznaczonych następców. Ma też rekomendować konkretne kolejne kroki — wskazanie potencjalnych następców, ocenę poziomu gotowości oraz stworzenie lub aktualizację planów sukcesji.
Odpalamy. I proszę: agent mówi, że używa skilla zarządzania sukcesją jako domenowego wzorca. Dokładnie to chcieliśmy zobaczyć. Skill sukcesji wymaga krótkiego ustalenia zakresu, zanim ruszy rozpoznanie w AI Studio albo tworzenie plików. To utrzymuje wstępny przegląd w ryzach i zapobiega wprowadzeniu akcji zmieniających rekordy sukcesji bez wyraźnej zgody.
Dostajemy opis celu biznesowego, a intencja jest taka, żebyśmy wspólnie z agentem ustalili, co właściwie budujemy — z tego wyjdzie szczegółowa specyfikacja i plan. Agent daje też rekomendacje. Jako zalecane MVP proponuje najbezpieczniejszy użyteczny punkt startu: wersję nastawioną na przegląd, z drill-downem do poziomu pojedynczej osoby. Nie będę czytał całości — jeśli chcesz, zatrzymaj film. To i tak zależy od wymagań, które podasz agentowi.
Zostaje nam wybrać ścieżkę. Zalecana to MVP plus drill-down na poziomie osoby: podsumowanie dla menedżera, trzy główne panele i szczegóły pracowników oparte na dowodach, bez zmieniania rekordów sukcesji. Pamiętaj o zasadzie drugiej — wszystko jest domyślnie tylko do odczytu. Musimy jawnie polecić agentowi dodanie akcji destrukcyjnych, takich jak dodawanie czy zmienianie rekordów. Wybieram opcję pierwszą, czyli rekomendowaną.
Gdy agent pracuje, uporządkuję repozytorium. To zresztą kolejna zaleta całego rozwiązania: mamy kontrolę wersji. To zwykłe repo Git, możemy tworzyć commity, czyli punkty kontrolne. Jednej rzeczy nigdy nie chcę wypychać do zdalnego repozytorium — pliku env.properties. Tworzę więc plik .gitignore i dodaję do niego ten plik. Wyszarzy się na liście, co oznacza, że nie trafi do commitów. Robię commit o nazwie „initial” — na tym etapie to po prostu podstawowa struktura z agent skills, niczego jeszcze nie zbudowaliśmy.
Rozpoznanie, specyfikacja i walidacja w praktyce
Mówiliśmy przy zasadach, że agent wykona rozpoznanie — i właśnie to widzimy. Podsumowuje wyniki: wszystkie wymagane workflow dla MVP znalazł lokalnie, więc odpytywanie środowiska nie było potrzebne. Istniejąca przestrzeń robocza gotowości sukcesyjnej oraz osobista przestrzeń gotowości sukcesyjnej również znalazły się lokalnie. Pozostaną chronionymi referencjami — agent ich nie zmieni, ale wykorzysta jako istniejący wzorzec. Wybieram znów opcję rekomendowaną, czyli kontynuację w oparciu o odnalezione workflow.
Jeśli pracowałeś przy dużych projektach, wiesz, jaka to udręka, kiedy agent za każdym razem wymyśla koło na nowo. Ta obudowa — reguły i skille — daje agentowi bardzo konkretne guardrails: najpierw przejrzyj istniejące wzorce, dopiero potem buduj cokolwiek własnego.
Teraz agent przedstawia propozycję, czyli naszą specyfikację. Daje jasne efekty biznesowe, źródła danych, opis pierwszego wczytania, zachowanie zapytań. Możemy to przeczytać i poprosić o zmiany, jeśli coś nam nie pasuje. Dostajemy też kryterium sukcesu: dla rekomendowanej opcji brzmi ono „zatwierdź i utwórz dwie aplikacje MVP”. Wybieram opcję pierwszą.
Ci z was, którzy pracowali kiedyś przy takich aplikacjach, wiedzą, ile to normalnie roboty. To bywają całe warsztaty z mnóstwem interesariuszy w sali: eksperci od baz danych, ludzie od uprawnień, deweloperzy, analitycy biznesowi, konsultanci funkcjonalni, właściciele biznesowi. Cały zespół musiał się zebrać, żeby ustalić, co trzeba zmienić. A teraz jako właściciel biznesowy albo ekspert domenowy po prostu rozmawiasz z agentem, a on wykonuje całą pracę deweloperską.
Agent wciąż pracuje, ale pokażę postęp. Zamykam na chwilę terminal — w projekcie widać, że dodane zostały nowe pliki. W katalogu źródeł są dwie budowane aplikacje, dwa pliki .app. Klikam pierwszy z brzegu: dostajemy podgląd tego, jak aplikacja będzie wyglądać. Muszę trochę oddalić widok, ale tak — widzimy realną aplikację.
Obie nowe aplikacje powstały w starszym układzie projektu i przeszły bezpośrednio walidację AI Studio z zerem błędów. Jak wspominałem — to zasada piąta: wszystkie te pliki są walidowane, zanim AI Studio czy Fusion je przyjmą. MVP daje teraz podsumowanie dla menedżera z przeglądem sukcesji, ryzykiem odejścia i wpływem odejścia. Bezpośrednia walidacja potwierdza, że struktury aplikacji i referencje są spójne. Zautomatyzowane testy uruchomieniowe pozostają odłożone — tak jak zatwierdziliśmy.
Co dalej? Rekomendowana opcja to dodanie top performerów i podsumowania wynagrodzeń. Możemy tak przechodzić kolejne kroki i rozbudowywać aplikację. Widzisz, jakie to proste?
Wdrożenie na żywe dane
Chwila prawdy — testujemy aplikację. Biorę tę aplikację, żeby wdrożyć ją do Fusion Cloud i popracować na prawdziwych danych. Wystarczy kliknąć przycisk odtwarzania na dole. Żeby było jasne: to nie publikuje zmian. Aplikacja jest wdrażana do Fusion Cloud, ale w stanie roboczym. Agent w ogóle nie może jej opublikować — i to jest celowe. To ostateczna bramka przeglądu, której nie da się przejść agentem.
I proszę: pracujemy na żywych danych, wracają prawdziwe nazwiska. To bardzo użyteczne informacje. Tu mamy ryzyko odejścia — szczególnie Sophie Bromley jest oznaczona jako wysokie ryzyko. Po prawej stronie widzimy działania priorytetowe: trzeba przypisać następcę dla Sophie Bromley. I znów — to działa na rzeczywistej infrastrukturze Fusion Cloud, na żywych danych.
Spróbujmy czegoś jeszcze. Wchodzę w „Ask Oracle” i piszę: proszę zarekomenduj następcę dla Sophie. Wysyłam — agent zwraca rekomendację. Lista sugerowanych następczyń dla Sophie: Emily i Olivia.
Podzielę się z wami jeszcze raz tymi pięcioma zasadami — mam nadzieję, że zobaczyliście je wszystkie w akcji. Chcę podziękować Oracle za sponsorowanie tego filmu i za możliwość zajrzenia w to, jak pracują z agentami AI. Jeśli chcesz dowiedzieć się więcej o Oracle Fusion, linkuję stronę w opisie.
(Informacja dodatkowa: materiał jest sponsorowany przez Oracle — autor deklaruje to na końcu nagrania. Warto brać to pod uwagę przy ocenie prezentowanych korzyści.)
10 najważniejszych takeaways — z kontekstem zastosowania
1.Specyfikacja zawsze przed kodem
Na czym polega: Agent nie pisze ani linijki, dopóki nie przejdzie z tobą rozmowy scopingowej i nie wyprodukuje szczegółowego planu wdrożenia, który zatwierdzisz.
Jak stosować: Wpisz w swój skill twardy warunek: „przed jakimkolwiek rozpoznaniem czy tworzeniem plików przedstaw krótką propozycję zakresu i poczekaj na wybór opcji”. Zaproponuj 2–3 warianty z rekomendacją, jak robi to skill sukcesji.
Na co uważać: Faza specyfikacji ma sens tylko wtedy, gdy realnie ją czytasz. Klikanie „opcja rekomendowana” w ciemno zamienia bramkę jakościową w dodatkowy krok proceduralny.
2.Domyślnie tylko do odczytu
Na czym polega: Nowo budowana funkcja nie ma prawa tworzyć ani modyfikować danych, dopóki nie wydasz jawnego polecenia. Reguła siedzi w plikach skilla, nie w promptcie użytkownika.
Jak stosować: W swoich skillach zapisz wprost, że operacje zapisu, usuwania i mutacji rekordów wymagają osobnej, jawnej zgody. Domyślne MVP niech będzie przeglądowe.
Na co uważać: Reguła jest miękka — to instrukcja dla modelu, nie mechanizm systemowy. Przy prawdziwie wrażliwych danych podeprzyj ją uprawnieniami konta technicznego, a nie samym tekstem skilla.
3.Rozpoznanie przed budową
Na czym polega: Agent najpierw przeszukuje system w poszukiwaniu istniejących workflow, wzorców i kodu, na których może się oprzeć, i dopiero potem tworzy cokolwiek nowego.
Jak stosować: Daj agentowi narzędzie, którym może naprawdę odpytać twoją platformę (u Oracle’a to CLI), i wymuś w skillu etap rozpoznania z raportem znalezisk przed przejściem do implementacji.
Na co uważać: Bez narzędzia do przeszukiwania sama instrukcja „szukaj wzorców” jest życzeniem. Agent musi mieć realny dostęp do repozytorium wzorców, inaczej i tak wymyśli koło na nowo.
4.Struktura zamiast improwizacji
Na czym polega: Skille zawierają precyzyjne reguły postępowania dla każdego typu zadania — guardrails, które trzymają agenta w wyznaczonym pasie.
Jak stosować: Nie pisz skilla jako ogólnego opisu domeny. Pisz go jako procedurę: kolejność kroków, co wolno, czego nie wolno, jak wygląda przekazanie pracy dalej.
Na co uważać: Nadmiar reguł potrafi zdusić przydatność agenta w nietypowych przypadkach. Guardrails mają największy sens tam, gdzie koszt błędu jest wysoki, a wariantów rozwiązania mało.
5.Brak walidacji oznacza brak ukończenia
Na czym polega: To, że pliki powstały i lokalnie wszystko wygląda dobrze, nic nie znaczy. Dopiero pomyślna walidacja po stronie platformy przenosi pracę do stanu „gotowe”.
Jak stosować: Zbuduj automatyczną bramkę walidacyjną, która zwraca agentowi błędy do naprawy w pętli. Zdefiniuj „gotowe” jako „przeszło walidację”, nie „napisane”.
Na co uważać: Walidacja strukturalna to nie to samo co testy działania. W demo testy uruchomieniowe zostały świadomie odłożone — zero błędów walidacji nie oznacza, że aplikacja robi to, czego chcesz.
6.Publikacja zostaje po stronie człowieka
Na czym polega: Agent może wdrożyć aplikację do chmury w stanie roboczym, ale nie może jej opublikować. To celowa, ostateczna bramka przeglądu.
Jak stosować: Odetnij agentowi uprawnienia do kroku nieodwracalnego — publikacji, deploya na produkcję, wysyłki do klientów — na poziomie systemu, nie instrukcji.
Na co uważać: Jeśli człowiek przy tej bramce tylko klika „zatwierdź”, zabezpieczenie jest pozorne. Bramka działa, gdy recenzent ma czym ocenić zmianę — podglądem, diffem, danymi testowymi.
7.Skill plus CLI to kompletny wzorzec dla twórcy platformy
Na czym polega: Cała integracja Oracle’a sprowadza się do dwóch elementów: skilla przenoszącego wiedzę domenową i narzędzia CLI, którym agent odpytuje platformę.
Jak stosować: Jeśli budujesz oprogramowanie, które inni rozszerzają, opublikuj skill z konwencjami swojego systemu i CLI do odczytu istniejących zasobów. To tańsze niż budowanie własnego środowiska agentowego.
Na co uważać: CLI musi mieć czytelną listę komend i sensowne komunikaty błędów — agent uczy się twojej platformy z jej wyjścia. Nieczytelne błędy zamieniają się w błędne poprawki.
8.Skille domenowe jako sposób zapisania wiedzy eksperckiej
Na czym polega: Oracle spakował kompetencje rzadkich specjalistów — zarządzanie sukcesją, braki magazynowe — w osobne skille, które ładuje się obok skilla technicznego.
Jak stosować: Rozdziel skill „jak używać narzędzia” od skilli „jak wygląda ta domena biznesowa”. Dzięki temu dokładasz kolejne obszary bez ruszania warstwy technicznej.
Na co uważać: Skill domenowy starzeje się razem z procesem biznesowym. Bez właściciela, który go aktualizuje, po roku będzie utrwalał nieaktualne reguły — z pełnym autorytetem dokumentu.
9.Przesunięcie autorstwa z IT do eksperta domenowego
Na czym polega: To, co wymagało warsztatów z bazodanowcami, analitykami i konsultantami funkcjonalnymi, właściciel biznesowy może przeprowadzić w rozmowie z agentem.
Jak stosować: Przy rozszerzeniach o niskim ryzyku — widoki, dashboardy, raporty — pozwól ekspercie domenowemu prowadzić pracę samodzielnie, zostawiając IT rolę recenzenta.
Na co uważać: Skrócenie ścieżki wycina też ludzi, którzy wychwytywali problemy z wydajnością, uprawnieniami i zgodnością. Utrzymaj przegląd tych aspektów, nawet jeśli reszta procesu znika.
10.Repozytorium Git i higiena sekretów od pierwszej minuty
Na czym polega: Projekt to zwykłe repo Git, a autor od razu tworzy .gitignore dla pliku env.properties, w którym siedzą adres instancji, login i hasło.
Jak stosować: Zanim wypuścisz agenta na projekt, zrób commit początkowy jako punkt kontrolny i wyklucz pliki z poświadczeniami. Commituj po każdym zaakceptowanym etapie — agentowe zmiany łatwiej wtedy cofnąć.
Na co uważać: Uwierzytelnianie podstawowe z hasłem w pliku tekstowym to najsłabszy element tego setupu. W środowisku firmowym użyj konta serwisowego o minimalnych uprawnieniach i nigdy nie wypychaj tego pliku do zdalnego repo.