Good enough definiujesz ty, nie agent - SDLC z AI

Wiem o co ci chodzi. Żeby dało go się bardziej mechanicznie do niego podejść. To teraz ja rzucę taki temat, czy może nie wróci Enterprise Architect, który na podstawie Enterprise Architect będziemy generowali kopy. Stary, szalony pomysł. Nie, to nie jest szalony. Powiem ci tak. Zaczynam mieć ręce i nogi. Pamiętasz Tomka, z którym pracowaliśmy i Marcina. Pamiętasz, mieliśmy dwóch kolegów na pewnym etapie. Przepraszam. Od nich specyfikacje, które wychodziły w Enterprise Architekcie, prawdopodobnie w tym momencie, gdyby jeszcze zajmowali się pisaniem specyfikacji, bo pewnie już tego nie robią, Sorry, znam analityków, od których moim zadaniem, gdybym miał pracować jako deweloper byłoby wzięcie ich Enterprise Architecta i DIF-ów zmian, żeby mieć tylko część zmian, które robili i po prostu robienie za sprawdzanie, czy agent poprawnie tylko zrobił lukier biznesową.

I żeby było jasne, my nie mówimy konkretnie o narzędziu Enterprise Architect, ale o formach jamlowych, czy formach przepływowych, hermaidów, tak inne rzeczy. Tak, tylko raczej w sensie formalizacji przygotowania analizy i wymagań. No tak, bo sposób, w którym oni pracowali... Bardziej centralizacji i weryfikacji w porównaniu z innymi rzeczami. Tak, tylko że oni mieli to spójne. Zobacz, że sposób w tym narzędziu... Oni korzystali z Enterprise Architecta nie do rysowania diagramów, tylko faktycznie do modelowania i zbierania wymagań. W tym systemie i w ekosystemie, gdzie ten system będzie istniał tak naprawdę, bo to jest problematyczne z agentami, nie wiedząc, co się dzieje dalej. Dobrze, czyli mamy, mamy, mamy, mamy ogarnięte. Ale dobra, to tak, czyli zanim powstania zadanie, podsumowując, bardzo dobrze wspomaga, Ale wspomaga.

A ja się z tym zgodzę w ogóle. Nie, ale ja z drugiej strony, bo słuchajcie, kurde, mieliśmy wyznawców, przepraszam, Architektura heksagonalna, clean code, solid, dry i tak dalej. Tak, inaczej, czy wiesz, czy całość, czy weźmy książkę, którą, kurde, polecamy te, czasami główno, czasami przepiękne, jest przepiękne, czyli na przykład Enterprise Integration Patterns. W tych modelach to wszystko jest. To, co niektórzy tak czczą i Szymon, i wiesz o tym, że to na koniec dnia Doświadczenie cię uczy dobierania. Właśnie o to chodzi. Przeciętym developer, jakiego mamy w zespole, będzie to aplikował

Mhm. To jest taka rzecz, z którą się nie zgodzę, nie może... To jest rzecz... Opisanie tego to jest inna sprawa, ale to ty musisz core zbudować, core założenia. To moja obserwacja jest taka, i to jest jedna z tych takich bardzo ważnych odpowiedzi człowieka, który tu istnieje. Definicja wystarczająco dobra, good enough, bo dostaniemy dwie skrajności, albo Enterprise aplikacje do subskrypcji na maile, no nie, albo drugi koniec, wciśnięte nogą rozwiązanie, które powinno być skomplikowane w to, co już istnieje. Tak, Szymon, wiesz, że jestem leniwy i staram się inaczej. Moja podstawowa zasada, co będzie, jeżeli ktoś do mnie zadzwoni, bo jest problem. I to jest moim zdaniem taki właśnie rule of thumb. Zastanów się, co będzie, jak ci każą to utrzymywać.

I też przypomnę te badanie o open source, że wyszło na to, że maintainerzy bibliotek i innych rzeczy Ich wydajność agent vs oni była względem błędu statystycznego w wielu miejscach. Tak, ale moja teoria jest też taka, no nie? Czemu to? Bo w tych jednoosobowych albo paroosobowych projektach masę jest wiedzy stadnej w głowach tych ludzi. Więc agent po prostu, ten agent, który jest w trybie, a rób aplikację Enterprise, bo takiego kodu jest najwięcej w sieci, on się takiego nauczył, nie odnajduje się w tym wąskim kontekście, gdzie po prostu trzeba to zoptymalizować. Dlatego też. Ale też z drugiej strony potrafi wykryć, weźmy na przykład... Tak, to jest fajne, on wykryje, on napisze testy i tak dalej. Dużo tej roboty, której nie chcemy robić.