Good enough definiujesz ty, nie agent - SDLC z AI

To widzę na przykład, nie negowanie tego jest świetne, tylko trzeba bardzo jasno przekazać jedną rzecz, hej sorry, nasz system wygląda trochę już inaczej pod spodem, ale inspiracja procesu jest zajebista i bierzemy ją od ciebie. To już masz zrobić coś, wykorzystanie artefaktów cloudowych do takich rzeczy. Fajnie działają propozycje. Tak, to jest akurat, zgadzam się tylko, że nie w każdym orgu będziesz to miał. Weźmy na przykład tych, których mamy gdzieś tam, klientów korzystają z clouda, ale przez Bedrocka, Vertexa, Inny case, tak. Dobra, idziemy teraz. Projekt, czy mamy tam architektura i granice, dokumentacja na zadania, dekompozycja na zadania i przygotowanie środowiska pracy, wszystkie harnessy, toolingi i tak dalej. Jaką masz za tym myśl główną i przewodnią? Dla mnie to jest kilka rzeczy. Po pierwsze, moja taka jedna myśl przewodnia, jaka mi przyjechała, to było to, że bardzo narzekamy na to, że agenci nie są w stanie na przykład przygotować, przewidzieć, co będzie się działo w przyszłości.

Agenci to ograniają świetnie. Dobra, czyli tak. Przygotowanie środowiska pracy. Harness, toolingi, dane testowe, dostępy. I bądźmy szczerzy. Znowu przypominam Gista, którego wrzucałem też parę odcinków temu, może nawet z tego zrobię repo, to chyba będzie lepsze, bo patrząc się ile Borys przekombinowuje, to warto to update'ować częściej. To w tym miejscu, sorry, wrzucam zbuduj mi Harness z takimi wymaganiami. Tak, ale tam jest co więcej. I teraz tak, ja teraz, bardzo ważne, przez Harness, teraz Szymon, co dopracuję, to nie są pliki MD. Ja przez to rozumiem twarde huki, skrypty bashowe na zasadzie, skończył ci subagent działać, nie pozwól mu przestać działać, tylko wyrzuć mu na przykład, że teraz mają się odpalić.

Jeszcze raz automatyczne lintery, testy, skan Sonar Cube, metryki czy nie są przekroczone, czyli Harness dla mnie to jest twardy. Bardzo twarda rzecz. Wrzucimy też tutaj komentarz, który dostałem od kolegi odnośnie tego, jak mu agent tłumaczy, że no faktycznie było to, że mam tego nie robić, ale usunąłem bazę. A mam ten screen na Discordzie, wrzucimy. Potwierdza się, że trzeba być przezornym, trzeba być zapobiegliwym, trzeba się Zapraszamy przy okazji na Discorda. Dobra, to od tej strony. Dane testowe, patrząc się jeszcze w połączeniu do libek innych rzeczy. No Szymon, kurde, to jest genialne. Akurat to jest pierwszy czas, kiedy wygenerowanie datasetów testowych razem z dodatkowym poolingiem Łukasz, ja bym jeszcze do jednej rzeczy wrócił, co powiedziałeś.

Popowiedziałeś gadanie harnesów i tak dalej. To będzie, bo dostajemy czasami krytykę od niektórych naszych słuchaczy, dziękujemy pięknie, odnośnie tego, że no tak, ale to nie, to jest za dużo i tak dalej i tak dalej. Tak, tylko że rozdzielmy dwie rzeczy. Rozdzielmy ludzi, którzy będą realnie budowali harnesy i przeciętnego dewelopera, który robi kod biznesowy. To są dwie zupełnie inne role. Znaczy, wiesz co, czy budowane harnesy, ja bym tego nawet nie tak, powiedziałbym jardziele inaczej. Są osoby... Oskar, znowu pozdrowienia za dzisiejszą rozmowę, bo z Oskarem ostatnio dużo dyskutujemy sobie. Trzeba rozdzielić osoby, które bardzo mocno agentic workflow'y wykorzystują, potrafią wykorzystać i mają dopasowane pod Swój proces myślowy, swoje działacze w tym i fajnie też Oskar u nas na Discordzie powiedział, że np. są okresy, że przez to, przez jego tryb pracy by dużo nie dowoził, a dzięki agentom np. i sposobie pracy jest w stanie coś puścić i zrobić o wiele więcej niż byłby w stanie.

Ale ma swój workflow. I teraz wasza krytyka, jeżeli dopracowaliście swój workflow, jest on wydajny, faktycznie przyspieszyliście, odwożyliście więcej, chwała wam za to, ale jeżeli popatrzymy na średnią rynkową, tak nie wygląda. I wszystkie te standaryzacje harnessów, podejścia są właśnie po to, żeby zespół zwiększyć średnią zespoły. Tak, dokładnie. Więc jak mówimy, że agenci się nie dają, agenci są świetni, mówmy o tym samym obszarze, na którym pracują. Bo często to są ludzie, którzy mają inne zastosowania, inne przypadki życia, inny kontekst, ale finalnie oceniają całość. Tak. Dobra. Dekompozycja na zadania. I teraz tak, bo dlaczego idę od tyłu, bo zaczynam od rzeczy łatwych, które można delegować, więc przygotowanie środowiska pracy 100%.

Tak. Jedna rzecz odnośnie jak gdybyśmy całego, na przykład, code review Tak, on to robi dobrze, ale znowu chodzi o odpowiedź człowieka. Dokładne kryteria, żeby nie stawić tego na zasadzie, żeby zrób, żeby było dobrze. Bo takie czyny nie działają. Raczej inaczej. Pierwsza warstwa code review jest genialna przed człowiekiem. Pierwszą powinna być linter. Linter powinien się odpalić automatycznie. O tym właśnie mówimy, tak. A potem patrzy na to, tylko z wytycznymi, jak chcemy, żeby było dobrze i jak jest nasze good enough. Dobra i teraz jak tam popatrzysz i tak jak popatrzymy sobie testy, gdzieś tam właśnie CI i inne rzeczy, to są harnessy powinny być automatem, sorry. Jak mówimy o implementacji i teraz mam tu raczej, dobra to jest tak, to jest poziom znowu, potem sobie o tym pogadamy, o odpowiedzialności.

Dobra, skończmy na poważnie, żarty, ale na poważnie. To jest tak, robota DevOpsowa, tak, reviewujesz. To jest review. Frontend, tak jak Tomek powiedział... Poklikasz. Poklikę, tak jak Tomek powiedział, nawet bez... Jak testy przechodzi i sprawdzisz testy frontendowe, jest okej. To jest ok, bo po prostu skasujesz, wygenerujesz na nowo. Można teraz byłoby powiedzieć jedną rzecz, która gdzieś tam się dzieje. Przykładowo masz test, że nie wygenerował samodzielnie komponentów, tylko np. jak masz biblioteki do komponentów i innych rzeczy, że skorzystał tylko z gotowych. Ale znowu, wracamy do harnessów i pilnowania. Jeszcze ten obszar, w którym ja się zgodzę. Mianowicie to, żeby on trzymał spójność, żeby za każdym razem ten UI nie wyglądał inaczej, żeby w lewo, w prawo.