--- title: "Od zgłoszenia w Jira do zmian w AWS: jak AI porządkuje wymagania infrastrukturalne" description: Zastosowanie AI w analizie wymagań infrastrukturalnych w AWS eliminuje błędy i przyspiesza proces wdrożeń, poprawiając komunikację między zespołami. image: https://tech.univio.com/hubfs/Gemini_Generated_Image_jjdcy0jjdcy0jjdc.jpeg --- [Przejdź do treści](https://tech.univio.com/pl/od-zgłoszenia-w-jira-do-zmian-w-aws-jak-ai-porządkuje-wymagania-infrastrukturalne#main-content) [![tech\_univio\_blog\_COLOR+BLACK](https://tech.univio.com/hs-fs/hubfs/tech_univio_blog_COLOR+BLACK.png?width=850&height=300&name=tech_univio_blog_COLOR+BLACK.png)](https://tech.univio.com/pl) - [GitHub](https://github.com/Univio-Tech) - [EN \>](https://tech.univio.com/from-jira-tickets-to-aws-how-ai-automates-infrastructure-requirements) ![](https://tech.univio.com/hubfs/raw_assets/public/univio-tech-blog/images/icons/search.svg) Szukaj na blogu - Brak sugerowanych wyników, ponieważ pole wyszukiwania jest puste. # Od zgłoszenia w Jira do zmian w AWS: jak AI porządkuje wymagania infrastrukturalne Z tego artykułu dowiesz się: 1. Proces jako problem: ręczne poprawki, luki w komunikacji i niepełne uprawnienia IAM 2. Jak przenieśliśmy analizę wymagań AWS przed implementację 1. Jak działa skill? Kluczowe założenia 2. Bezpieczeństwo dostępu do AWS 3. Ustrukturyzowany raport 3. Wewnętrzny test jakości raportów 4. Kiedy uruchamiać analizę: lokalnie czy w CI/CD? 5. Podsumowanie Zmiana w kodzie aplikacji może wyglądać na niewielką: dodatkowy zapis do DynamoDB, nowa kolejka, zmienna środowiskowa czy parametr istniejącej usługi. Dopiero podczas wdrożenia okazuje się, że aplikacja nie ma wymaganych uprawnień IAM, zasób ma niewłaściwą konfigurację albo nowa funkcja wpływa na inne elementy środowiska.  Dodanie nowej funkcji do aplikacji często pociąga za sobą zmianę w infrastrukturze: nową politykę IAM, zasób AWS, zmienną środowiskową albo zmianę konfiguracji istniejącej usługi. To, kto odpowiada za takie zmiany, zależy od modelu pracy przyjętego w organizacji. Najczęściej spotykamy 2 podejścia: > Model nr 1 > Backend developer sam przygotowuje i utrzymuje zasoby chmurowe potrzebne jego aplikacji. Najczęściej w dojrzałych projektach korzysta przy tym z narzędzi Infrastructure as Code, takich jak Terraform czy Pulumi.  > > Model nr 2 > Większa część odpowiedzialności za infrastrukturę trafia do zespołu DevOps. To on odpowiada za bezpieczeństwo i konfigurację kont AWS, a także za wdrażanie usług aplikacyjnych, z których korzystają developerzy. Ten artykuł dotyczy drugiego podejścia. Opisuję, skąd brały się nieporozumienia i dodatkowe iteracje między backend developerami a zespołem DevOps oraz jak rozwiązaliśmy ten problem za pomocą skilla AI analizującego wymagania infrastrukturalne zanim zmiana trafi do środowiska.   ## Proces jako problem: ręczne poprawki, luki w komunikacji i niepełne uprawnienia IAM Wyobraźmy sobie, że backend developer dodaje w aplikacji obsługę zapisu danych do kilku tabel DynamoDB w jednej transakcji. Implementuje logikę, kończy testy lokalne i tworzy zgłoszenie w Jirze dla zespołu DevOps: > *„potrzebne uprawnienia do DynamoDB”* Na podstawie takiego opisu zespół DevOps aktualizuje infrastrukturę i polityki IAM. Gdy aplikacja trafia na środowisko, okazuje się jednak, że standardowe uprawnienia do zapisu nie wystarczają. Nowa logika korzysta z operacji TransactWriteItems, która wymaga osobnego uwzględnienia w polityce IAM.    Lambda kończy działanie błędem AccessDeniedException, zgłoszenie wraca do doprecyzowania, zespół DevOps wprowadza kolejną zmianę, a backend developer ponownie testuje rozwiązanie. W skrócie: problemem nie był sam dostęp do DynamoDB, lecz mało dokładnie określone wymaganie.   Wcześniej proces wyglądał następująco:    1. Backend developer implementował logikę biznesową. 2. Następnie zgłaszał potrzebę utworzenia lub zmiany zasobów AWS, opisaną w nieprecyzyjny sposób (np. z uwagi na presję czasu). 3. Zespół DevOps przygotowywał infrastrukturę zgodnie z zasadą *"Principle of least privilege"* na podstawie opisu w Jirze. 4. Backend developer testował aplikację na środowisku. 5. Po testach wychodziło na jaw, że brakuje uprawnień, zasobu albo konfiguracji. Problem nie wynikał z pojedynczego błędu po stronie aplikacji czy infrastruktury. Informacja o wymaganiach infrastrukturalnych pojawiała się za późno, była przekazywana ręcznie i często nie zawierała istotnych szczegółów: konkretnych akcji IAM, parametrów kolejki czy wymaganych zmiennych środowiskowych. Wynikało to bezpośrednio z kilku czynników: - nieprecyzyjnych opisów zadań, - braku szerszej znajomości infrastruktury, - presji w projekcie, która wymuszała realizację zadań „na szybko” kosztem lakonicznych zgłoszeń. W efekcie braki ujawniały się więc podczas testów na środowisku - wtedy, gdy ich usunięcie wymagało już kolejnej iteracji między zespołami. Dotyczyło to zarówno nowych modułów, jak i pozornie niewielkich zmian w kodzie, takich jak dodanie uprawnień zapisu do danego zasobu. Potrzebowaliśmy sposobu, który pozwoli wykrywać takie zależności wcześniej: zanim zmiana trafi do środowiska, a najlepiej jeszcze przed rozpoczęciem implementacji. [![Komunikat AccessDeniedException](https://tech.univio.com/hs-fs/hubfs/art2%20obraz%201.png?width=936&height=300&name=art2%20obraz%201.png)](https://tech.univio.com/hubfs/art2%20obraz%201.png?hsLang=pl) Przykład zrzutu ekranu pokazujący komunikat AccessDeniedException, który wystąpiłby w przypadku braku odpowiednich uprawnień IAM. ## Jak przenieśliśmy analizę wymagań AWS przed implementację Aby ograniczyć opisane problemy, przygotowaliśmy skill pre-implement-aws-resources. Backend developer uruchamia go przed przekazaniem zmiany do zespołu DevOps, najlepiej jeszcze przed implementacją lub na etapie jej planowania. Wcześniej backend developerzy samodzielnie tworzyli prompty i prosili modele językowe o analizę potrzeb infrastrukturalnych. Rezultaty zależały więc od sposobu sformułowania zapytania i nie zawsze uwzględniały standardy przyjęte w projekcie (ale można je podnieść skillem o którym piszemy).  Obecnie backend developer uruchamia skill przed implementacją lub na etapie przygotowywania zmiany. W odpowiedzi otrzymuje raport wskazujący m.in. zasoby AWS, konfigurację oraz uprawnienia IAM, które zespół DevOps powinien zweryfikować lub przygotować. Dzięki temu zgłoszenie przekazywane do DevOps zawiera pełniejszy i bardziej jednolity opis wymagań. ### Jak działa skill? Kluczowe założenia Pełny kod skilla oraz jego pliki konfiguracyjne znajdziesz w naszym [repozytorium GitHub](https://github.com/Univio-Tech). Poniżej przedstawiamy najważniejsze elementy, które warto dostosować do standardów i specyfiki własnego projektu. - Analiza różnic w kodzie (git diff) lub dedykowanych specyfikacji (.ai/specs/). - Porównanie zidentyfikowanych wymagań z konfiguracją Terraform. - Interaktywne dopytanie o źródło, kontekst środowiskowy i ewentualny live cross-check. Wynik: Gotowy, ustrukturyzowany raport zgodności. ### Bezpieczeństwo dostępu do AWS Udostępnienie agentowi AI dostępu do shella lub AWS CLI wymaga szczególnej ostrożności. Agent może analizować treści pochodzące z kodu, specyfikacji czy konfiguracji, a w najgorszym przypadku z dowolnego pliku znajdującego się na komputerze. Dlatego należy zakładać ryzyko nieoczekiwanych lub niepożądanych instrukcji w analizowanych danych, w tym prób prompt injection. Z tego powodu dostęp do środowiska AWS powinien być ograniczony zgodnie z zasadą najmniejszych uprawnień: - Uruchomienie agenta w izolowanym środowisku (np. docker sandbox) jako najważniejszy, fundamentalny krok ograniczający potencjalne ryzyko. - Zasada najmniejszych uprawnień w AWS: - Używaj osobnej, dedykowanej roli wyłącznie do odczytu. - Nie udostępniaj agentowi poświadczeń z uprawnieniami do tworzenia, modyfikowania ani usuwania zasobów. - Ogranicz dostęp roli do niezbędnych kont, regionów i usług. - Jawne potwierdzenie operacji – wymagaj każdorazowego, jawnego potwierdzenia przed uruchomieniem przez agenta dowolnego polecenia (nie tylko AWS CLI). ### Ustrukturyzowany raport Wynikiem działania jest raport w czytelnej formie zawierający sekcje: - Add / Diff: precyzyjne zestawienie dodawanych lub zmienianych zasobów, z rozbiciem na parametry, uprawnienia IAM oraz zmienne środowiskowe. - Status weryfikacji AWS: jasne oznaczenie przy każdej pozycji (aws-verified, aws-mismatch lub aws-unverified). - Unknown Service: ostrzeżenie, gdy w kodzie pojawi się usługa nieskategoryzowana w pliku zasobów będącym referencją skilla. Backend developer weryfikuje raport przed dołączeniem go do pull requesta. Sprawia to, że sekcja Infrastructure w opisie PR jest spójna i zrozumiała dla całego zespołu. [![Przykładowy raport](https://tech.univio.com/hs-fs/hubfs/art%202%20obraz%202.png?width=936&height=771&name=art%202%20obraz%202.png)](https://tech.univio.com/hubfs/art%202%20obraz%202.png?hsLang=pl) Przykładowy raport Raport nie zastępuje review infrastruktury, ale ma sprawić, że komunikacja między zespołami zacznie się od konkretów: operacji, zasobów, konfiguracji i otwartych decyzji. ## Wewnętrzny test jakości raportów Ważnym elementem tworzenia dobrych skilli jest ich testowanie. Nie tylko na przykładowym kodzie i poprzez ręczną ocenę pojedynczych wyników, ale też na różnych modelach i zestawie zróżnicowanych przypadków testowych. Takie podejście pozwala sprawdzić, gdzie skill działa dobrze, gdzie odpowiedzi odbiegają od oczekiwań i co warto doprecyzować w jego instrukcjach. Na podstawie wyników można stopniowo uszczelniać skilla, eliminować niejednoznaczności i poprawiać jakość generowanych raportów. Skill opisany w tym dokumencie wywołany został trzema modelami w dwóch próbach: Haiku 5.5, GPT-6-LUNA i Sonnet 5.5 na dzień 20.10.2026. Poniżej umieszczam tabele z benchmarkiem. Ze specyfikacji wyodrębniono 14 punktów opisujących zasoby AWS do utworzenia lub zmiany (kolejki, Lambda, IAM, tabele, zmienne środowiskowe). Punktom powodującym niepowodzenie kroku deploy lub lukę bezpieczeństwa, nadano wagę 3, pozostałym 1. Odpowiedź oceniono ręcznie dla każdego punktu: pełny (1), częściowy (0,5) lub brak (0). Wynik to suma ważona podzielona przez maksimum. [![Wynik testu](https://tech.univio.com/hs-fs/hubfs/art%202%20obraz%203.png?width=900&height=514&name=art%202%20obraz%203.png)](https://tech.univio.com/hubfs/art%202%20obraz%203.png?hsLang=pl) Wynik naszych testów wewnętrznych. - Sonnet 5.5 najdokładniej oddał różnice między specyfikacją a AWS. Jako jedyny wychwycił konflikt między 60-sekundowym visibility timeout kolejki wejściowej a czasem pracy Lambdy oraz zwrócił uwagę na batchSize=1, a przy tym poprawnie opisał wszystkie uprawnienia IAM. - Haiku 5.5 był drugi. Dobrze rozpisał zmienne środowiskowe i wskazał błędne wartości w .env.example, ale uznał istniejącą kolejkę wejściową za zgodną ze specyfikacją i pominął konflikt timeoutów. - GPT-6-LUNA był najsłabszy. Pominął wyłączenie deduplikacji contentowej i zmianę nazw zmiennych, a konflikt timeoutów odnotował tylko jako niemożliwy do sprawdzenia. Różnice między modelami były jednak mniejsze niż sugerowałby sam ranking, a raport Luny był w większości użyteczny. ## Kiedy uruchamiać analizę: lokalnie czy w CI/CD? Skill można włączyć do zasad SDLC, tak aby każdy developer używał go przed scaleniem zmian i dołączał wygenerowany raport do opisu Pull Requesta.  Jeśli zespół korzysta z automatycznych reviewerów, na przykład GitHub Reviewera, część procesu można zautomatyzować, dodając instrukcję skilla do konfiguracji agenta. Backend developer uruchamia analizę ręcznie na swoim branchu, weryfikuje wynik, a następnie – jeśli raport jest poprawny – umieszcza jego podsumowanie w opisie PR-a. Powoduje to, że raport jest traktowany jako materiał pomocniczy do rozmowy z zespołem DevOps, a nie jako automatyczna decyzja o zmianie infrastruktury. ## Podsumowanie Największa wartość skilla nie polega na automatycznym projektowaniu infrastruktury. Polega na tym, że wymagania AWS stają się widoczne wcześniej — na etapie planowania zmiany lub przed utworzeniem PR-a, a nie dopiero po nieudanym teście na środowisku. Włączenie skilla do codziennej pracy backend developerów pozwoliło ograniczyć większość problemów opisanych na początku artykułu. W naszym przypadku mamy twarde dane, które to potwierdzają. Liczba odrzuceń i dodatkowych iteracji spadła średnio z 6 do 1 na 10 zgłoszeń modyfikujących infrastrukturę. Drastycznie poprawił się też czas obsługi i płynność procesu: - Czas cyklu: Wcześniej, ze względu na przerwy w komunikacji z zespołem DevOps, cykl poprawek potrafił trwać dłużej niż jeden dzień. Obecnie cała sprawa zawsze zamyka się maksymalnie w ciągu 2 godzin. - Czas realizacji: Jeśli praca nad zgłoszeniem zostanie rozpoczęta od razu po jego utworzeniu, czas ten nie przekracza nawet godziny. Rzadziej dochodzi też do sytuacji, w których nieprzemyślana zmiana negatywnie wpływa na działające środowisko, zespół z wyprzedzeniem widzi jej potencjalny wpływ na inne usługi. Dodatkową korzyścią jest większa świadomość infrastrukturalna po stronie backend developerów. Lepiej rozumieją oni usługi AWS wykorzystywane przez aplikację i potrafią wcześniej wskazać ich konsekwencje dla infrastruktury. Rozwijają również katalog wspieranych usług, dzięki czemu standardy projektu pozostają aktualne. Skill sygnalizuje w trakcie analizy użycie usługi spoza ustalonego katalogu, co daje zespołowi możliwość omówienia takiej decyzji przed wdrożeniem. Nie chodziło o przeniesienie odpowiedzialności za infrastrukturę na AI ani na backend developerów. Celem było wyeliminowanie zgadywania i niepełnych wymagań na etapie testów. Odpowiednio zaprojektowany proces pozwolił wcześniej wykrywać luki, sprawniej łączyć perspektywę backend developerów i zespołu DevOps oraz ograniczać niespodzianki podczas deploymentów. Tagi: - [Devops](https://tech.univio.com/pl/tag/devops) - [LLM](https://tech.univio.com/pl/tag/llm) - [Backend & Data](https://tech.univio.com/pl/tag/backend-data) - [Jakość Oprogramowania](https://tech.univio.com/pl/tag/jakość-oprogramowania) Spodobał Ci się ten artykuł? Podziel się nim - - - ## Autor ![Michał Pawlik](https://tech.univio.com/hs-fs/hubfs/IMG_4909-1.jpeg?width=125&height=125&name=IMG_4909-1.jpeg) [Michał Pawlik](https://tech.univio.com/pl/author/micha%C5%82-pawlik) Inżynier oprogramowania i architekt rozwiązań chmurowych, specjalizujący się w językach C# i JavaScript oraz kładący duży nacisk na wykorzystanie narzędzi AI w celu zwiększenia produktywności. Posiada również dogłębną wiedzę na temat dużych modeli językowych (LLM) oraz związanej z nimi infrastruktury systemowej. ## Sprawdź pozostałe artykuły ![](https://tech.univio.com/hubfs/raw_assets/public/univio-tech-blog/images/icons/arrow-left.svg) - ![](https://tech.univio.com/hs-fs/hubfs/wadki_AI_v1-1.png?width=1320&height=770&name=wadki_AI_v1-1.png) ### [Sztuka wyboru odpowiedniego modelu. Dlaczego stworzyliśmy Commerce & Enterprise Benchmark (CEB)](https://tech.univio.com/pl/sztuka-wyboru-odpowiedniego-modelu.-dlaczego-stworzyli%C5%9Bmy-commerce-enterprise-benchmark-ceb?hsLang=pl) Łukasz Biegaj 9 paź 2026 - ![](https://tech.univio.com/hs-fs/hubfs/KV%20Cache%20cover-1.png?width=1320&height=770&name=KV%20Cache%20cover-1.png) ### [KV Cache - jak wykorzystać kluczowy mechanizm LLM w pracy programisty](https://tech.univio.com/pl/kv-cache-jak-wykorzysta%C4%87-kluczowy-mechanizm-llm-w-pracy-programist?hsLang=pl) Michał Pawlik 9 paź 2026 - ![](https://tech.univio.com/hs-fs/hubfs/unity_220606_unity_team_of_teams_v1-kopia-2%20(1)-1.png?width=1320&height=770&name=unity_220606_unity_team_of_teams_v1-kopia-2%20(1)-1.png) ### [Aplikacje SaaS i wykonywanie zadań w tle z AWS Batch i AWS Step Functions](https://tech.univio.com/pl/aplikacje-saas-i-wykonywanie-zadan-w-tle-z-aws-batch-i-aws-step-functions?hsLang=pl) Tomasz Dudek & Dawid Branicki 6 paź 2020 - ![](https://tech.univio.com/hs-fs/hubfs/unity_230509_unity_omnichannel_illustration_v3@2x%20(1)-1-1.png?width=1320&height=770&name=unity_230509_unity_omnichannel_illustration_v3@2x%20(1)-1-1.png) ### [Proces testowy a zapewnienie jakości – Quality Assurance i Quality Control](https://tech.univio.com/pl/proces-testowy-a-zapewnienie-jakosci-quality-assurance-i-quality-control?hsLang=pl) Tomasz Jański 14 lut 2019 ![](https://tech.univio.com/hubfs/raw_assets/public/univio-tech-blog/images/icons/arrow-right.svg) [Follow us on Facebook](https://www.facebook.com/UnivioIT) [Follow us on LinkedIn](https://www.linkedin.com/company/univio-it-company/) [Follow us on Instagram](https://www.instagram.com/univio_it) [Check YT Channel](https://www.youtube.com/@univioITcompany) © 2026 Univio