AI nie naprawia rozjazdu w zespole. Ono go maskuje.

Problem dżina

Jest taki obraz, do którego wracam, kiedy myślę o AI. AI jest jak dżin. Robi dokładnie to, co powiesz, a nie to, co miałeś na myśli. I właśnie w tej luce zaskakująco często rozsypuje się dowożenie produktu.

Znasz ten układ. Osoba po stronie produktu żongluje kilkoma tematami naraz i w dwie minuty pisze ticket w Jira. Ten ticket nie jest zły złośliwie. Jest po prostu niedookreślony, pospieszny, niepełny i pełen założeń, których nikt nie wypowiedział wprost.

Zespół inżynierski bierze go na warsztat, buduje coś rozsądnego z tych słów, które faktycznie tam są, a dwa tygodnie później wszyscy siedzą na przeglądzie i mówią jakąś wersję tego samego: nie o to mi chodziło.

Nikt nie kłamał. Nikt się nie obijał. Po prostu intencja nigdy nie została wystarczająco jasno nazwana przed startem pracy. W wersji z AI ten problem jest jeszcze ostrzejszy, bo model nie ma zespołowego kontekstu, który mógłby wypełnić luki. Jeśli ticket niesie prawie zero kontekstu, dżin działa niemal po omacku.

Najsłabszy artefakt

Pomyśl, gdzie tak naprawdę mieszka wiedza o produkcie. Repozytorium zna architekturę, nazewnictwo, zależności i granice implementacji. Pliki projektowe znają język wizualny, wzorce interakcji i decyzje powtarzane tak długo, aż stały się systemem. Wcześniejsze tickety i dokumentacja znają słownik zespołu i sposób, w jaki zwykle opisujecie kompromisy.

Ticket w Jira prawie niczego z tego nie wie. Bardzo często jest najuboższym kontekstowo artefaktem w całym stosie. Kiedy więc zespół wkleja ticket do narzędzia AI i oczekuje wysokiej jakości wyniku, tak naprawdę prosi o świetną odpowiedź na podstawie najmniej informacyjnego wejścia, jakie ma pod ręką.

Dlatego wynik tak często brzmi wiarygodnie, a mimo to słabo pasuje do rzeczywistości. Kryteria akceptacji zakładają niewłaściwego użytkownika. Pomysły projektowe odpływają w stronę stylistyki, której nigdy byście nie wypuścili. Sugestie techniczne ignorują wasz stack, model wdrożenia albo skróty, których zespół świadomie nie stosuje. AI nie tyle “zawodzi”, co robi, co może, z marnie postawionym zadaniem.

Ticket w Jira bywa najuboższym kontekstowo artefaktem w całym stosie produktowym.

Pewny siebie bezsens

Większość narzędzi AI do Jira działa według podobnego schematu. Otwierasz issue. Klikasz przycisk. Dostajesz opis, kryteria akceptacji, może rozbicie na podzadania. Całość sprawia wrażenie produktywnej, bo wynik jest szybki, schludny i uporządkowany.

Najczęściej wygląda to tak:

otwierasz issue;
klikasz przycisk;
dostajesz czysty blok tekstu, kryteria i może podzadania.

Tyle że struktura to nie to samo co zgranie. Jeśli wejście było mgliste i pozbawione kontekstu, to wyjście jest tylko bardziej stanowczą wersją tej samej niejednoznaczności. W praktyce narzędzie może nawet pogorszyć sprawę, bo dopieszczona forma zniechęca ludzi do podważania założeń jeszcze przed startem realizacji.

Na tym polega ciche zagrożenie: śmieci na wejściu, śmieci na wyjściu, tylko że teraz te śmieci mają nagłówki, wypunktowania i ton pełen pewności. Zespół może wejść w implementację jednocześnie z większą pewnością siebie i mniejszą jasnością.

Wynik może wyglądać schludnie i przekonująco, a mimo to rozmijać się z logiką, po prostu dlatego, że model nigdy nie zobaczył prawdziwego kontekstu produktu stojącego za ticketem.

Czego AI naprawdę potrzebuje

Zanim AI wygeneruje coś naprawdę użytecznego dla issue w Jira, musi rozumieć cztery rzeczy o świecie, w którym pracuje:

Wasz produkt: co robi, jakie efekty mają znaczenie i co dana funkcja ma poprawić dla użytkowników oraz dla biznesu.
Wasz język projektowy: wzorce wizualne, bibliotekę interfejsu i nawyki interakcyjne, dzięki którym wynik wygląda jak część waszego produktu, a nie jak generyczne demo.
Waszych odbiorców: kim są, czego potrzebują, czego się spodziewają i czego nie wiedzą. To zmienia sformułowania, interakcje i przypadki brzegowe w niemal każdej funkcji.
Wasz stack: realne frameworki, granice środowiska wykonawczego, integracje, ograniczenia danych i techniczne ramy, które powinny określać, co w ogóle jest sensowną sugestią.

Najciekawsze jest to, że większość zespołów już to wszystko ma. To istnieje w kodzie, dokumentacji, makietach i pamięci zespołu. Tego po prostu nie ma w Jira w formie, którą AI potrafi zobaczyć. Dlatego narzędzia patrzące wyłącznie na Jira są ślepe na najważniejszy kontekst projektu.

Jeśli chcesz praktycznej wersji takiej warstwy kontekstu, w tekście Twoja AI zgaduje, czym jest twój produkt rozpisuję, co warto przechowywać i jak to potem wykorzystywać ponownie.

Wynik może być bardzo ładnie złożony, a mimo to iść w złą stronę, jeśli powstał bez prawdziwego kontekstu produktu.

Twój kod wie więcej

Jedną z naprawdę mocnych stron współczesnych agentów do kodowania jest to, że potrafią bardzo dobrze czytać repozytorium i zamieniać je w zrozumiały kontekst. Możesz skierować Claude Code, Codex albo innego mocnego agenta na repozytorium i poprosić o podsumowanie w markdownie: po co istnieje produkt, jaki ma stack, gdzie są granice implementacji, jakie są znane luki i jakie sygnały biznesowe już widać. To zajmuje minuty, a nie tydzień pisania dokumentacji.

I to zmienia zasady gry. Zamiast prosić AI o generowanie czegoś z ticketu złożonego z dwóch zdań i niczego więcej, dajesz jej osadzony w rzeczywistości skrót produktu, systemu projektowego, odbiorców i stacku. Nagle model nie improwizuje już po ciemku. Zaczyna rozumować wewnątrz świata, który naprawdę przypomina wasz projekt.

Wasze repozytorium miało te odpowiedzi cały czas. Nazwy komponentów pokazują język projektu. Modele domenowe odsłaniają sposób myślenia produktu. Integracje i biblioteki wyjaśniają techniczne granice. Nie trzeba wymyślać kontekstu od zera. Trzeba go tylko wydobyć do formatu, z którego inne AI będzie potrafiło sensownie skorzystać.

Często problemem nie jest brak wiedzy, tylko to, że to, co już żyje w repozytorium, nie zostało zamienione w kontekst projektu, z którego da się korzystać wielokrotnie.

Ukryte decyzje

Nawet przy świetnym kontekście projektu zostaje jeszcze drugi problem, którego AI nie rozwiąże zgadywaniem: decyzje, których nikt jeszcze nie podjął. Każde issue w Jira niesie ukryte założenia dotyczące uprawnień, zasad wdrożenia, przypadków brzegowych, zgodności wstecznej, szczegółów interakcji i tego, jak w ogóle będzie wyglądał sukces, gdy funkcja trafi do prawdziwych użytkowników.

Te decyzje nie znikają tylko dlatego, że ktoś zacznie pracę. One po prostu wypływają w środku sprintu, czyli dokładnie w najdroższym możliwym momencie. Projektantka pyta, który istniejący ekran jest punktem odniesienia. Inżynier musi wiedzieć, czy dla tego przepływu istnieje już API. Ktoś zauważa, że kryteria akceptacji zakładały użytkowników zalogowanych, podczas gdy połowa doświadczenia jest anonimowa. Nic z tego nie okazuje się zaskoczeniem po fakcie. To wszystko było tam od początku.

Dlatego sam kontekst nie wystarczy. Potrzebne są też pytania: konkretne pytania osadzone jednocześnie w ticketcie i w realnym kontekście produktu. Czy to dotyczy obecnych użytkowników, czy tylko nowych? Co się stanie, jeśli przeglądarka zamknie się w połowie przepływu? Czy funkcja jest tylko dla administratorów? Czy to jednorazowe działanie, czy zachowanie powtarzalne? Krótka seria uczciwych odpowiedzi daje więcej zgrania niż kolejna dopolerowana specyfikacja.

Prosta prośba może ukrywać znacznie więcej decyzji, niż pokazuje to pierwotny ticket.

Jak to działa w Just

Dokładnie taki przepływ zbudowałem w Just: AI Assistant for Jira:

Raz ustawiasz kontekst projektu w czterech uporządkowanych polach: opis produktu, system projektowy, odbiorcy i stack. Just podpowiada nawet komendy, które możesz puścić przez Claude Code albo dowolnego agenta do kodu, żeby wyciągnąć takie podsumowania bezpośrednio z repozytorium. Wklejasz wynik raz i ten kontekst wraca potem przy kolejnych ticketach.
Otwierasz issue w Jira. Bez żonglowania promptami i bez dodatkowej konfiguracji dla każdej pracy. Just czyta issue razem z zapisanym kontekstem i wyciąga wnioski faktycznie dopasowane do waszego projektu. Potem zadaje pytania doprecyzowujące, które nie są ogólnikowe, tylko osadzone w produkcie, technicznej rzeczywistości i języku projektowym zespołu.
Budujesz plan. Just zamienia odpowiedzi w wymagania, kierunek projektowy, przypadki brzegowe, oczekiwane rezultaty i uporządkowaną ścieżkę wykonania, na której zespół może realnie pracować. W razie potrzeby dociąga też świeży kontekst z sieci, a do tego współpracuje z pięcioma dużymi dostawcami AI, żeby na każdym etapie użyć najlepszego modelu do danego zadania. Nie chodzi o to, żeby wyglądało to magicznie. Chodzi o to, żeby pomóc zespołowi wytworzyć właściwą rzecz, a nie tylko coś szybkiego. Cały przepływ zobaczysz na aiapps.me.

Wartość nie polega na tym, żeby szybko zamienić ticket w tekst, tylko na tym, żeby zebrać dość kontekstu i dojść do planu, któremu zespół naprawdę ufa.

Co to zmienia

Dlaczego więc większość narzędzi AI do Jira pogarsza problem zgrania zamiast go zmniejszać? Bo zwykle wchodzą do gry dopiero wtedy, gdy niejednoznaczność już siedzi w ticketcie, a potem tylko nadają jej schludną i skończoną formę.

Prawdziwa dźwignia leży wcześniej. Najpierw trzeba jasno ustalić, czego zespół naprawdę chce, wydobyć ukryte decyzje jeszcze przed startem implementacji i dać AI dość kontekstu, żeby mogła działać wewnątrz realnego kształtu produktu, a nie zgadywać na podstawie ubogiego opisu.

To jest sedno. Jeśli zespół rozumie, czego chce, zanim ruszy praca, AI staje się przydatne. Jeśli nie, wynik nadal może wyglądać imponująco, ale za ten chaos prawie na pewno zapłacicie później poprawkami.