Foreman przekształca agentów opartych na dużych modelach językowych (LLM) w natywne zasoby Kubernetes, umożliwiając zespołom uruchamianie kodu wygenerowanego przez AI na produkcji przy jednoczesnym zachowaniu ścisłej kontroli nad kosztami i bezpieczeństwem.

Jak ta idea wpisuje się w dzisiejszy proces deweloperski

Przedsiębiorstwa eksperymentują z modelami LLM potrafiącymi pisać kod, ale większość implementacji traktuje model jako zaufaną „czarną skrzynkę”. Pojedynczy sygnał „gotowe” wysłany przez model może spowodować wprowadzenie nieprzetestowanych zmian bezpośrednio do repozytorium, co budzi obawy o bezpieczeństwo i niezawodność. Jednocześnie uruchamianie usług AI w chmurze może szybko stać się kosztowne, zwłaszcza gdy ten sam model jest wielokrotnie wywoływany z potoków CI.

Odpowiedzią Foremana jest osadzenie całego cyklu kodowania wewnątrz klastra Kubernetes. Foreman działa jako zasoby Kubernetes.

Cztery kluczowe obiekty, które to umożliwiają

  • Agent – definiuje pracownika. Określa nazwę wywoływanego modelu LLM, wymienia narzędzia, które model może wykorzystać (np. file-write lub git-push) i ustawia budżet ograniczający liczbę wywołań modelu. Tutaj przypisuje się role; agent typu „coder” pisze kod, a agent typu „verifier” go sprawdza.
  • Workload – jednostka pracy zdefiniowana przez użytkownika. Zawiera ogólny cel (np. „dodaj testy jednostkowe dla modułu X”), odniesienie do docelowego repozytorium oraz listę agentów, którzy powinni wykonać zadanie.
  • AgenticTask – konkretne zadanie generowane przez Workload. W miarę postępu prac każdy AgenticTask rejestruje aktualizacje statusu, co pozwala operatorom monitorować potok w czasie rzeczywistym.
  • FleetNode – węzeł Kubernetes, który faktycznie wykonuje zadania. Wbudowany scheduler dopasowuje oczekujące AgenticTask do węzłów FleetNode, które posiadają odpowiednią rolę i zasoby.

Weryfikacja zamiast ślepego zaufania

Foreman nie zakłada, że wynik działania modelu jest poprawny. Gdy agent typu „coder” kończy pracę, wysyła żądanie zamiast końcowego wyniku. Weryfikator — zazwyczaj deterministyczny skrypt, a nie kolejny model LLM — przepuszcza kod przez lintery, testy jednostkowe lub pełne procesy budowania. Dopiero gdy te sprawdzenia zakończą się sukcesem, Foreman zapisuje nową gałąź w repozytorium.

Jeśli weryfikator zawiedzie, zadanie zostaje oznaczone jako odrzucone, a zmiany nigdy nie trafiają do repozytorium. To rozdzielenie pozwala modelowi na kreatywne generowanie rozwiązań, podczas gdy siatka bezpieczeństwa pozostaje w pełni pod kontrolą człowieka.

Instalacja stosu na klastrze

  1. Wdróż podstawowy chart LLMKube za pomocą Helm.
  2. Wdróż chart Foreman, również za pomocą Helm.
  3. Przełącz tryb agenta na „native”, aby aktywować rzeczywistą pętlę żądanie-odpowiedź.
  4. Przypisz role (coder, verifier) do węzłów FleetNode, które będą obsługiwać pracę.

Wymagane są dwa zestawy poświadczeń: dane uwierzytelniające Git do odczytywania zgłoszeń (issues) i wypychania gałęzi (pushing branches) oraz dane uwierzytelniające modelu do wywoływania hostowanego API lub własnej usługi wnioskowania (inference service).

Suwaki kosztów i bezpieczeństwa, którymi można realnie sterować

Foreman pozwala operatorom ograniczać uprawnienia modelu poprzez usuwanie narzędzi z definicji agenta. Usunięcie „bash” lub „write_file” uniemożliwia modelowi wykonywanie dowolnych poleceń powłoki lub zapisywanie plików poza wyznaczonym obszarem roboczym.

Limit wywołań (turn limit) ogranicza liczbę zapytań do modelu na jedno zadanie, co bezpośrednio kontroluje wydatki. Dostosowanie okna kontekstowego — czyli tego, jak dużą część promptu widzi model — dodatkowo redukuje zużycie tokenów. Gdy model działa lokalnie na sprzęcie on-prem, żadne dane nie opuszczają organizacji, co pozwala spełnić surowe polityki prywatności danych.

Gdzie platforma błyszczy, a gdzie wciąż napotyka trudności

Foreman doskonale radzi sobie z mechanicznymi, dobrze określonymi zadaniami:

  • Naprawianie udokumentowanych błędów.
  • Dodawanie brakujących przypadków testowych.
  • Aktualizowanie dokumentacji w celu poprawy przejrzystości lub stylu.

Zadania te mają jasne kryteria sukcesu, które weryfikator może sprawdzić automatycznie. System wciąż ma jednak trudności z wysokopoziomowym przeprojektowywaniem architektury lub niejednoznacznymi pracami nad funkcjonalnościami, gdzie „poprawność” zależy od ludzkiego osądu.

Podsumowanie

Traktując programistów napędzanych przez LLM jako zasoby Kubernetes klasy pierwszej i wymuszając deterministyczny krok weryfikacji, Foreman oferuje pragmatyczną ścieżkę do generowania kodu AI na produkcji, która zapewnia przejrzystość wydatków i kontrolę nad bezpieczeństwem. Nie jest to uniwersalne rozwiązanie dla wszystkich prac deweloperskich, ale w przypadku powtarzalnych, testowalnych zadań zapewnia audytowalny proces pracy, który naturalnie wpisuje się w istniejące operacje cloud-native.