Przez dłuższy czas zastosowanie generatywnej AI w programowaniu wyglądało dość przewidywalnie. Developer pisał polecenie, model proponował funkcję, człowiek kopiował kod i dokładnie go sprawdzał (przynajmniej w teorii).

Ten układ zaczyna się zmieniać. Agent nie musi już czekać na każde kolejne polecenie. Może sam przejrzeć repozytorium, znaleźć podatność, zmodyfikować kilka plików, uruchomić skaner i przygotować pull request.

 

W ostatnim tygodniu GitHub udostępnił produkcyjnie funkcje pokazujące ten kierunek bardzo wyraźnie. AI Scan ma wykrywać problemy w nowych zmianach, a Agentic Autofix, usuwać istniejące podatności. Brzmi jak zamknięty obieg bezpieczeństwa. Tyle że w praktyce otwiera on kilka nowych pytań.

 

Najważniejsze brzmi: kto sprawdzi agenta?

 

Od podpowiedzi do pełnego zadania developerskiego

 

AI Scan analizuje zmiany w pull requestach i uzupełnia klasyczne skanowanie CodeQL. Szczególnie ciekawa jest obsługa technologii, które dotychczas pozostawały poza jego podstawowym zakresem: PHP, Bash, plików Terraform, Dockerfile, JSP czy Blazora. To dość praktyczny zestaw. W jednym repozytorium możemy mieć przecież kod aplikacji, skrypty administracyjne, definicje infrastruktury i konfigurację kontenerów. Dobre zabezpieczenie jednego języka nie wystarcza, jeśli podatność ukryje się w poleceniu powłoki albo źle skonfigurowanym obrazie.

 

Wyniki AI Scan są na razie doradcze. Nie mogą automatycznie zablokować scalenia. To rozsądne ograniczenie, bo skanowanie oparte na modelu może wygenerować fałszywy alarm lub niewłaściwie zinterpretować logikę aplikacji. Agentic Autofix idzie o krok dalej. Po przydzieleniu mu alertu agent przegląda powiązane pliki, przygotowuje zmianę, ponownie uruchamia CodeQL, a następnie otwiera pull request. Nie jest to już autouzupełnianie kodu. To wykonanie całego, zamkniętego zadania.

 

Zielony wynik nie zawsze oznacza bezpieczny kod

 

Ponowne uruchomienie skanera brzmi jak mocna gwarancja. Jeśli narzędzie znalazło podatność, agent ją poprawił, a CodeQL potwierdził zamknięcie alertu, czego chcieć więcej? Na przykład testu zachowania aplikacji. Skaner sprawdza określoną klasę problemów. Może potwierdzić, że konkretny przepływ danych nie prowadzi już do podatnej funkcji. Nie wie jednak, czy agent nie zmienił logiki biznesowej, nie zepsuł obsługi wyjątków albo nie usunął czegoś, co było potrzebne w nietypowym scenariuszu.

 

Badanie niemal 4900 pull requestów tworzonych przez agentów pokazało, że testy nie stanowią jeszcze wystarczającej siatki bezpieczeństwa. Szczególnie słabo pokrywane są zmienione linie w projektach Pythonowych oraz obsługa błędów. Wynik badania nie dotyczy bezpośrednio nowej funkcji GitHuba, ale dobrze pokazuje szerszy problem: agent potrafi przygotować przekonującą zmianę szybciej, niż człowiek jest w stanie rzetelnie ją zweryfikować. W praktyce code review staje się więc ważniejsze, nie mniej ważne.

 

Agent będzie musiał przestrzegać zasad organizacji

 

Bezpieczeństwo kodu nie kończy się na podatnościach. Liczy się również to, jakie biblioteki i narzędzia trafiają do projektu. GitHub udostępnił właśnie centralną kontrolę licencji open source. Organizacja może zdefiniować dopuszczalne licencje i wymagać pozytywnego wyniku przed scaleniem pull requesta. Co szczególnie istotne, agent programistyczny może użyć API, aby sprawdzić pakiet jeszcze przed dodaniem go do projektu.

 

To zapowiedź szerszej zmiany. Agent nie powinien jedynie „napisać działającego kodu”. Powinien znać zasady organizacji:

  • których pakietów wolno używać,
  • jakie licencje są akceptowane,
  • które testy należy uruchomić,
  • jakie katalogi może modyfikować,
  • jak dokumentować decyzje,
  • kiedy musi poprosić człowieka o zatwierdzenie.

 

Podobną rolę pełnią nowe lockfiles dla GitHub Actions. Zapisują dokładne commity zewnętrznych akcji, dzięki czemu przesunięcie tagu nie podmieni po cichu kodu wykonywanego przez pipeline. To nie jest efektowna funkcja AI. Jest jednak bardzo potrzebna, gdy agenci zaczynają samodzielnie modyfikować proces budowania i wdrażania aplikacji.

 

Developer coraz częściej staje się recenzentem i projektantem procesu

 

16 października Anthropic opublikowało analizę własnej organizacji pracy. To szczególny przypadek, bo firma tworząca zaawansowane modele wykorzystuje je znacznie intensywniej niż przeciętne przedsiębiorstwo. Mimo tego jej doświadczenia mogą być sygnałem kierunku zmian.

 

Agenci mają tam wykonywać więcej godzin pracy niż ludzie, a pracownicy coraz częściej zajmują się tworzeniem instrukcji, monitorowaniem agentowych pipeline’ów i porządkowaniem wyników. W rekrutacji rośnie znaczenie samodzielności i osądu, natomiast spada udział juniorskich stanowisk technicznych.

 

Można się zastanawiać, czy nie powstaje tu paradoks. Im więcej kodu tworzą agenci, tym bardziej potrzebujemy osób, które potrafią rozpoznać, czy ten kod rzeczywiście ma sens. Tyle że dotychczas taką umiejętność budowało się właśnie przez wykonywanie prostszych zadań.

 

Dlatego podstawy programowania nie tracą znaczenia. Zmienia się powód, dla którego są potrzebne. Nie wystarczy wiedzieć, jak napisać pętlę czy zapytanie SQL. Trzeba rozumieć ich działanie na tyle dobrze, aby dostrzec błąd w rezultacie przygotowanym przez model.

 

Polski kontekst: od pilotażu do działającej usługi

 

Podobny zwrot widać w Polsce, chociaż nie ogranicza się on do tworzenia kodu. Podczas konferencji Państwo 2.0 eksperci omawiali przechodzenie od pilotaży AI do odpornych usług publicznych. Jeden z pokazanych chatbotów działa już na 357 stronach urzędów pracy i w okresie od 1 września do 12 października obsłużył ponad 151 tysięcy zapytań.

 

W takim wdrożeniu nie wystarczy stwierdzić, że model odpowiada poprawnie na kilku wybranych dokumentach. Trzeba sprawdzić jakość odpowiedzi przy rzeczywistych danych, wydajność pod obciążeniem, koszt zapytań oraz respektowanie uprawnień użytkowników.

 

Właściwie jest to ten sam problem co przy agentowym poprawianiu kodu. Demonstracja możliwości jest łatwa. Trudniej zaprojektować proces, który zadziała niezawodnie, będzie mierzalny i nie ominie zabezpieczeń.

 

Jak przygotować się do programowania z agentami?

 

Pierwsza odpowiedź może brzmieć mało efektownie: nauczyć się dobrze testować. Przydatne będą testy jednostkowe i integracyjne, analiza statyczna, code review, praca z Gitem oraz rozumienie CI/CD. Do tego dochodzi bezpieczeństwo zależności, zarządzanie sekretami i kontrola uprawnień agenta.

 

Drugi obszar to architektura. Agent może bardzo szybko zmieniać kod, ale potrzebuje jasno opisanych granic modułów, interfejsów i kryteriów akceptacji. Nieuporządkowanego systemu nie naprawi samo dodanie mocniejszego modelu.

 

I wreszcie: obserwowalność. Zespół musi wiedzieć, co agent zmienił, jakie narzędzia uruchomił, które testy wykonał oraz na jakiej podstawie uznał zadanie za zakończone.

 

Wydaje się, że nadchodzące miesiące nie przyniosą końca pracy programistów. Przyniosą natomiast znacznie więcej kodu, który trzeba będzie świadomie oceniać. AI może znaleźć podatność i przygotować poprawkę. Odpowiedzialność za decyzję o wdrożeniu nadal pozostaje po drugiej stronie ekranu.

 

Źródła:

 

Programowanie z agentami wymaga dziś czegoś więcej niż znajomości promptów. Bezpieczny workflow opiera się na testach, GitHubie, analizie kodu, DevSecOps i rozumieniu architektury, czyli na kompetencjach, które pozwalają nie tylko przyspieszać pracę z AI, ale również zachować nad nią kontrolę.