Peknęła ósma trzydzieści, więc może ja wjadę z formułką, żebyśmy później czasu nie tracili. To jest City Morning Coffee, czyli nasze co dwutygodniowe spotkania, gdzie rozmawiamy sobie o tematach istotnych dla senior technical leaders. Jeżeli ktoś jest po raz pierwszy, konwencja spotkań jest bardzo prosta. Spotkania trwają godzinę, każde spotkanie ma konkretny temat. Dzisiejsze spotkanie będzie poświęcone trzydziestej odsłonie radara, tak zwanego Technology Radar firmy ThoughtWorks. W ramach naszych spotkań każdy może zabrać głos. Mamy tutaj trzech moderatorów, wynapędzamy dyskusję. Natomiast każdy może użyć zbudowanej funkcjonalności aplikacji Twitter Spaces, aka xSpaces, po to, żeby zasygnalizować, że chce coś skomentować, chce zadać pytanie. My postaramy się takiej osoby nie przeoczyć. Jeżeli przeoczymy, prosimy, żeby się nie zniechęcać, tylko dać nam szansę, abyśmy mogli nas nie przeoczyć. W ramach naszej dyskusji trzymamy się pewnych podstawowych zasad, czyli przede wszystkim, jeżeli krytykujemy, to staramy się nie krytykować konkretnych firm, konkretnych nazw, konkretnych osób, tylko krytykujemy na przykład zachowania. Z bardzo ważnych rzeczy na cityomorning.coffee jest ponownie wrócił nasz landing page, gdzie można się zapisać na powiadomienia, chyba już też, czy jeszcze nie? Ale na pewno są tam linki do archiwum, są tam linki do archiwum naszych odcinków. Nie ma jeszcze linków, holy shit. Sytuacja jest dynamiczna, sytuacja jest rozwojowa. Dobra, ja tylko wyjaśnię krótko, nastąpiła pewna stopa techniczna, nasz poprzedni landing wyparował, mamy nowy cityomorning.coffee, można tam się napisać, kontent powróci. I tego się właśnie trzymamy. Dobra, super, fajnie. Chyba powiedzieliśmy o wszystkim, co jest najistotniejsze i możemy przejść do clue naszego tematu. Cityomorning.coffee zajmuje się dzisiaj ThoughtWorks Technology Radarem. To co panowie, przyznać się, czy już macie wychód na blachę cały? Wojtek, czy ty już się nauczyłeś? No ja go przeczytałem faktycznie, zmusiliśmy się do przedstawienia go od deski do deski, słuchajcie, więc... Natomiast ja chciałem dodać, że absolutnie zapraszamy wszystkich do dyskusji, jest tu kilka rzeczy, które na pewno, mam nadzieję, wywołają rozmowę, więc zobaczymy. No i mamy cztery kategorie, Technics, Platforms, Tools, Languages and Frameworks. Więc mamy o czym rozmawiać, jest tutaj prawie sto pozycji. Natomiast można je pogrupować, więc myślę, że do tego też się odniesiemy. Słuchajcie, to co bierzemy na początek? No właśnie, może uporządkujmy dyskusję i po prostu pojedźmy tymi czterema kategoriami po kolei, w ramach tych kategorii niech każdy mówi, tylko też może nie jakieś tam 15-minutowa wypowiedź, tylko właśnie rzucajcie swoje wtedy punkty, żeby była jakaś tam dynamika tej całej naszej dyskusji, a na samym końcu jeszcze może sobie zrobimy coś takiego, takie ogólne podsumowanie, czy widzimy w tym wszystkim jakieś większe trendy przebijające się, albo ogólnie, co nas zaskoczyło całościowo w tej Technology Radarze. Ja z chęcenia do dyskusji zrobię cheap marketing trick. Kto się pierwszy odezwie, dostanie markę osobistą w branży IT z podpisem autora. Holy shit, czy to Umberto Eggo? Nie. No dobrze, to słuchajcie, wobec tego wjeżdżamy. Zaczynamy od technik, w sekcji technik. Myślę, że tutaj akurat będziemy mieli spore pory do popisu. Czy jest coś, co was zainteresowało, zaskoczyło, z czym byście się bardzo zgodzili, albo bardzo nie zgodzili? To ja zacznę, bo tutaj coś mam do powiedzenia, innych mogę nie mieć. Bardzo mi się spodobała sekcja hold, powiem szczerze. Jest tłusta. Tak, znaczy, ale bo ona jest poprzed tego wszystkiego, co się ogólnie mówi, tak, albo gdzie firmy idą, nie, no bo zaraz przejdziemy do innych. Ogólnie zauważmy, że w sekcji technik jest LLM, LLM, LLM, LLM, LLM, AI, LLM, LLM, AI. A to chcę, cześć. Ale hold mi się spodobało, bo tam mamy Over Enthusiastic LLM Use, Rush to Find Tune LLMs, czyli generalnie to, co przynajmniej ja widzę, że wszyscy chcą testować swoje modele i tak dalej i tak dalej, no to tutaj ThoughtWorks mówi Polior Horses, może to nie jest najlepszy sposób na robienie tego. Ja bym powiedział, że jeżeli chodzi o sekcję technik, no to na pewno coś, co jest, oni dobrze zidentyfikowali, myślę, że będzie jak najbardziej na, powiedzmy, na roadmapach wielu firm, to jest ten Retrieval Augmented Generation, tak? Czyli mamy techniki, które potrafią naszą bazę wiedzy mocno scrawlować, zrozumieć, a następnie móc odpowiadać w postaci, prawda, czatu z LLM-em. Więc myślę, że to będzie jak najbardziej coś, co się będzie teraz bardzo mocno rozwijać, szczególnie, że o niej później będziemy to mówić, ale mają też konkretne już tool'e do tego, proponują. I jeszcze jedna technika, która z tym się łączy, która według mnie jak najbardziej spowoduje, że myślę, że osoby biznesowe będą dużo łatwiej korzystały z wiedzy i z danych, które zgromadziliśmy, czyli tekstu SQL, tak? Czyli jak zrozumie narzędzia, które pozwalają tekst naturalny zamienić na zapytania SQL-owe. Oni proponują tam narzędzie, które się nazywa Vanna i przyznam szczerze, że ja sobie na to popatrzyłem, martwię się, powiecie, te zapytania, na przykład jak wiem, z własnego podwórka, niektóre, żeby zrozumieć bardzo dobrze użytkowników, są ogromne. To są SQL-ki na dwa, trzy ekrany, bardzo skomplikowane. Więc ja nie jestem przekonany, czy na przykład w takich sytuacjach te narzędzia sobie będą dawały radę, ale myślę, że część takich prostych zapytań dla wielu osób wokół produktów na przykład mogą bardzo fajnie wspomóc. Ja jeszcze dodam jedną rzecz, coś, co się podpisuje, natomiast jestem zdziwiony, że musimy o tym rozmawiać, to jest Automatically Generate Backstage Entity Descriptors. Czyli backstage to jest narzędzie, to jest narzędzie Service Discovery od Spotify. Ono jest bardzo rozszerzalne, tak? Więc jesteśmy w stanie ten Service Discovery, informacje o serwisach bardzo wzbogacić bardzo różnymi dodatkowymi informacjami na temat zespołów, na temat może SLO, SLA, sposobów eskalacji, więc jest to bardzo dobre narzędzie, żeby je mieć. Natomiast się zdziwiłem, że musimy rozmawiać w 2024 roku, że w trialu powinniśmy automatycznie i powiedzmy w taki sposób ciągły budować opisy do naszych serwisów, więc tak stwierdziłem, wow. Wojtek, wychodzisz, że jesteś w swoim bąbelku, to tak ci tylko powiem. Jasne, znaczy ja rozumiem, że wiesz o co mi chodzi, rozumiem, że backstage nie jest jeszcze przez wszystkich zaadaptowany, ja do tego wrócę, bo tutaj w tym radarze to jest jeden z moich największych zarzutów do tego radaru, natomiast, znaczy powiedzmy dotykamy jednego z największych zarzutów do tego radaru, natomiast jeżeli już go mamy, to aż się zdziwiłem, że wiecie tak, taki nitpick z tego backstage'a, ze wszystkich rzeczy, które się powinno robić z backstage'em, to w trialu mamy w technikach w 2034 roku Entity Descriptors, czyli te opisy serwisów automatycznie generowane. Może oczywiście jest to mój bąbel. Sebastian, co u ciebie? Tak do skończenia tego backstage'a, chcę tak myślę wykorzystać temat na osobny odcinek, bo ja na przykład mam bardzo radykalne zdanie na temat backstage'a, w ogóle też go postrzegam trochę szerzej, jako ogólnie development portal, a nie tylko i wyłącznie serwis Discovery, natomiast to jest narzędzie, które bardzo dużo obiecywało, a okazało się bardzo trudne do implementacji, tam każda implementacja to jest tak jak taki poziom customizacji, że tak naprawdę filmu, który robimy, jest bardzo niewiele, ale dobra, zostawmy backstage, bo to ostatnia kwestia. W ogóle, jeżeli chodzi o techniki, to mamy tu chyba ze 13 wypisanych takich swoich ładnych, to jest moja druga największa kategoria, ale może zacznę od tych, z którymi się zgadzam, więc tak, zgadzam się oczywiście z RAG-iem, chociaż akurat trafili w ciekawy moment, dlatego że była dyskusja dosłownie ze 2 czy 3 tygodni temu, że jaki jest sens zlewania RAG-a w sytuacji, kiedy wchodzą modele z tak gigantycznym kontekstem. Natomiast ja tak z praktyki, z tego co robię, bo akurat trochę się tym zajmuję zawodowo, aktualnie, to jednak całkowicie się zgadzam z tym adoptem dla RAG-a, z czym się jeszcze mocno zgadzam. Jest tam taki fajny punkt, LLM, Powered Autonomous Agents, ja jestem w ogóle fanatykiem tych architektur agentowych, nawet powiedziałbym, że nie tylko Autonomous Agents, ogólnie architektury agentowe, wspieranie LLM w architekturach agentowymi, to jest coś, pod czym ja się podpisuję nie tylko rękami i nogami, ale jeszcze innymi częściami działa. Z innych rzeczy, z którymi się absolutnie zgadzam, które są, tak, Over Enthusiastic LLM News, tu chyba nie ma co mówić, wiadomo, tam jest też ciekawy ten punkt związany z Rush to Fine-Tune LLM, tak, to prawda, wszyscy odkryli, że fine-tuning jest iteracyjny, natomiast myślę, że w tym punkcie też przebija się to, że to nie tylko i wyłącznie są koszty, nakłady i tak dalej, ale przede wszystkim kontrola jakości, że my nie za bardzo umiemy to robić i że w tej sytuacji, kiedy robimy fine-tuning, to jest po prostu zbyt ryzykowne tak naprawdę i wiele firm, które próbują ten fine-tuning robić, kończy tak naprawdę z tym fine-tunowanym modelem znacznie gorszym niż ten punkt startowy, od którego zaczynały. Natomiast ja sobie myślę, takie jedno małe ćwiczenie, to też może, żeby pomyśleć dyskusję, dlatego że ja przystąpiłem nie tylko i wyłącznie temu edycje radaru, ale jeszcze chyba cztery albo pięć wstecz. Dlaczego? Żeby zobaczyć, co znikło. Żeby zobaczyć, co znikło i też czy się zgadzam z tym, czy znikło, czy nie znikło. Na przykład w tej sekcji, czyli konkretnie Technics, to, co mnie na przykład zaskoczyło, znaczy mnie zaskoczyło, no ale z taką smutną obserwacją, to jest to, że na dobre znikły wszystkie tematy związane z decentralizacją nieblockchainową, bo tu się pojawiały i DIPs, tu się pojawiały overriding credentials, tego już w ogóle nie ma. To jest troszeczkę smutne. To taka tylko mała obserwacja. Co jeszcze znikło? Znikły, to jest w ogóle też część chyba większego wzorca, pewne techniki związane z danymi, zwłaszcza z dużymi danymi, czyli znikł Lake House. Na szczęście znikły też pewne bzdury, które na siłę próbowało fotoworks lansować, czyli data mesh. Nie wiem, czy będziecie chcieli o tym rozmawiać. Nie, nie, nie, nie znikło. Zaczekajcie, to teraz będzie. Będzie później. Będę robił co początkowego, ale jako początkowy też dam komentarz. Pamiętajcie to, co, bo ja tam podlinkowałem, jak robiłem ogłoszenie, to mówiliśmy o fotoworks technologii radar, że prawdopodobnie to jest takie okienko w to, co oni robią, nie? Więc jak Sebastian mówił już, te rzeczy znikły, to znaczy, że po prostu klienci weszli swego i wszyscy się wychylili na LLM-y. Albo nie ma w tym biznesu, albo nie ma w tym biznesu. To jest też smutne. To jest prawda, jeden do drugiego. Na przykład tylko ja powiem, że my zaczynamy właśnie jakiś projekt na Verify Abroad Credentials, więc jakiś tam biznes jest. Szymon. Tak, szukałem telefonu. Szymon musi głośniej mówić, albo coś poprawić. Teraz lepiej. Będę głośniej mówił trochę. To jeszcze trochę głośniej, ale coś się słychać będziesz. Więc tak, rzeczywiście też zgadzam się z tym spostrzeżeniem, że kontekst to troszkę blokowało, jak się spojrzało na tą dokumentację, na tę publikację i ja krótko chciałem wspomnieć a propos tego RAGA, bo tutaj też akurat trafiłem niedawno też na ciekawą taką krótką prezentację Andrew Ng., który mówi o tym ogólnie, że tendencja jest właśnie do tego, aby bardzo w prosty sposób korzystać z LLM-ów, czyli one-shot question i się oczekuje, że od razu będzie rozwiązane wszystko. Tymczasem jest wiele różnych takich nielkorag, które powodują, że już dzisiaj jakby na przykład GPT-3.5 potrafi dać znacznie lepszą jakość niż GPT-4, jeśli skorzysta się z jakichś dodatkowych technik, na przykład kilku zapytań, kilku kwestionowaniach, RAGA i różnych innych rzeczy. Także w skrócie, to jest temat potężny oczywiście, który się bardzo dynamicznie rozwija, więc dużo tu się dzieje i tak samo, sam fine-tuning z jednej strony jest obiecujący, a z drugiej strony właśnie są może takie mniej sexy technologie, które potrafią również bardzo dużo dać. No ja tylko tutaj powiem taki komentarz trochę nietechniczny, że wiesz, lepiej brzmi jak CEO powie, wytrenujemy swój model, niż jak może spróbujmy tych technik, nie? I inicjatywa trenowania modelu jednak dobrze robi na morale. Tomek, dołączyłeś do nas z jakimś komentarzem, musisz się... Wiecie co, właśnie bo ja dołączyłem tutaj, żeby w sumie dodać w temacie tego, problemu LLM, że właśnie ciekawym rozwiązaniem jest to, co Cloudflare teraz eksperymentuje z... Jestem, jestem, tylko po prostu ukliknąłem, to się wyciszyłem, żeby uszu tutaj nie liczyć wszystkim. To chodziło mi o to, że tak jak w sumie stawiłem w komentarzu, no to ciekawe jest to, jak Cloudflare właśnie eksperymentuje z tym serwerem, a z dostępem do GPU. No i ogólnie, Cloudflare w sumie, jak chce robić konkurencję, no nie tyle Wercelowi, tylko właśnie Cloudflare chce robić konkurencję AWS-owi, w szczególności w serwerleśniu. No i tak szczerze mówiąc, to oni akurat mają infrastrukturę, żeby to robić, bo no przez to, co Cloudflare robiło wcześniej, no to oni są na całym świecie, tak? W różnych miejscach, więc oni akurat mogą robić EDE czy właśnie serwer leśny dosyć skutecznie. Ciekawi mnie, gdzie pójdą w końcu, bo na razie z tego, co eksperymentuję z platformą, to no nie jest zupełnie kompletna platforma. Powiedziałbym, że części funkcjonalności brakuje w porównaniu do AWS-a, ale no dosyć już, sporo bym powiedział, się rozwinęli. No i to, co może niektórych odstraszać, to pricing jest trochę inny, bo czy jakby, znaczy no nie jakby, bo część usług, żeby z niej skorzystać, to tam trzeba 5 dolarów bazowe płacić, więc to pełen serwer leśny też nie jest, ale w sumie ciekawe, gdzie oni pójdą w końcu też. To wpisuje się w temacie naszego odcinka, bo technik w PL zobaczył, że tam jest Edge Functions i tam dokładnie Cloudflare się pojawia, co prawda z Workers, tak? Ale tak, Cloudflare zaistniał w radarze jako Edge Functions. Tak, myślę, że do tego przejdziemy. Pytanie moje do was jest takie, czy faktycznie coś was tutaj zaskoczyło negatywnie, z czym się mocno nie zgadzacie? Sebastian, myślę, że masz tutaj coś gotowego. Negatywnie? Znaczy są dwie rzeczy, które może trochę mnie zaskoczyły, tak zastanawiam się, czy to coś, jakaś dłuższa historia jest za tym. Pierwsza rzecz, która mnie zaskoczyła w ten sposób, może to jest po prostu takie premature, to jest ten test text SQL, bo ja widziałem tego typu rozwiązania, tam jest też QuickSQL, Qt, który też ma tego typu rzeczy, natomiast to jest dla mnie mimo wszystko ciągle jakieś zastosowanie hobbystyczne trochę. Czyli jeżeli ktoś faktycznie chce pracować z danymi na poważnie, to ten język naturalny jest trochę zbyt mało precyzyjny. A ja tu, wiesz co, ci skomentuję chyba, bo ja chyba rozumiem, skąd to się bierze. Bo wiesz, jest kwestia tego, żeby pokazać użyteczność tych elementów, nie? I jedną z takich rzeczy to jest to, żeby dać ludziom, którzy są nietechniczni, dostęp do danych w ten sposób, więc ja myślę, że jeżeli miałbym strzelacz, skąd to się wzięło, to to się bierze z tego, że rośnie zainteresowanie tym, żebym ja mógł powiedzieć typu, daj mi takie i takie zestawienie i ono się wykona w języku naturalnym, żebym mógł to zadać, nie? Przemek subskrybował taki projekt już dla swojego Power BI-a. I jakbym miał strzelacz, to to się pojawiło z tego powodu, że zainteresowanie na takie rozwiązania jest. Okej, ja rozumiem. Natomiast zazwyczaj tego typu jest jakaś konwersacja. Ty zaczynasz od czegoś, no a potem doprecyzowujesz. I wtedy już może się okazać, że ten język naturalny jest po prostu zbyt niedoskonały. Ale dobrze, no może będę tu w błędzie, może okaże się, że te rozwiązania są lepsze niż mi się wydaje. Inna rzecz, broad integration tests, to jest taka chyba trochę filozoficzna kategoria, oni to dali na hold. I to jest ciekawe, dlatego że, no, tam różnie to argumentowali, zalecają raczej skupienie się na testach kontraktów. Szczerze mówiąc, to się trochę rozmija z moim osobistym doświadczeniem, bo uważam, że rezygnacja z tego typu broad integration tests, zwłaszcza tych, które są znane też, czy tam tagowane, jako operational ignorance, smoke risk i tak dalej i tak dalej, raczej powoduje właśnie niewyłapywanie pewnych edge case'ów, które wychodzą dopiero właśnie już na tym finalnym etapie integracji. Ale no, dobra. Ale to, co mi się... Bo Wojtek się zapytał, co negatywnego mnie zaskoczyło. Tam jest taka rzecz, która zaskoczyła mnie pozytywnie, bo uważam, że będzie z tego fajny trend przyszłościowy. To już się pojawiło w radarze w postaci dwóch kategorii, ale jeszcze troszkę bez konkretu. Mówię konkretnie o AI team assistance i using Gen AI to understand legacy code bases. Dlatego, że to są fajne scenariusze, które wychodzą poza wykorzystanie LLM-ów do takiej pracy indywidualnej. Czyli na przykład, przez 25 lat zmagaliśmy się z tym, jak pisać dokumentację albo jak zarządzać wiedzą, ale może już nie będziemy tego zrobić, bo będziemy mieli taką sekretarkę, tak naprawdę, nie wiem, projektową czy produktową, która będzie to ogarniać dla nas. Która dla nas będzie już tylko i wyłącznie agentem, którym będziemy wpinać w pipeline narzędzia, w tooling i tak dalej, który rozwiąże ten sam problem, ale w zupełnie inny sposób, niż nam się to do tej pory wydawało. Co to jest minusem? Tego, to, że jeszcze tu nie ma gotowych rozwiązań. Albo oni tych rozwiązań nie wymieniają, albo te rozwiązania są jeszcze zbyt niedoskonałe. Ale uważam, że to jest bardzo ciekawy kierunek. Odnośnie gotowych rozwiązań, tylko żeby dać przykład, że coś tam się dzieje i jest to niedoskonałe, chyba jeszcze nie gotowe. Microsoft ma taki projekt, gdzie próbują używać LLM-ów do migracji kodów z BB6. Istniało też takie jak Visual Basic. Kiedyś było dość popularne. I jest taki projekt, że chcą skrypować, chyba zmigrować ten codebase, używając LLM-ów. Tomek, podniosłeś rękę. To się już dzieje, przy użyciu Open Rewrite'a, wspinają LLM-y z Open Rewrite'em. Wiecie, to ja podniosłem rękę. Jak gadacie, to się jeszcze zastanawiam tego kwestii. Kwestia pierwsza to jest taka, że pytanie właściwie, co to całe AI ma rozwiązać. Ja siedząc w tym, to bym prędzej powiedział, że to jest pewne dalszy ciąg automatyzacji, że właśnie zaczynamy od automatyzacji takich prostych rzeczy. Mnie to trochę osobiście wkurza, jak idzie taka fala, że ojeju, jest już na inteligencję, zaraz będą roboty. Tymczasem główną funkcją tego wszystkiego, tego całego AI-a, jest to, żeby automatyzować proste rzeczy. Zaczynając od takich funkcji, które są codzienne. Takich rzeczy, które są takie, które nawet w opisaniu kodu kopiuj w chlej. Zrobię mały spoiler pod moją grą, która wyjdzie pewnie dzisiaj. No dobra, a druga kwestia, którą chciałem Wam rzucić, to jest kwestia governance. Mam na myśli, zaczynając od podejścia, kto powinien mieć wpływ na to, jak są zarządzane wszystkie projekty. Ja Wam podam taki klasyczny dla mnie przykład, bo jakoś moje tło w ogóle nie jest technologiczne. Moje tło, bym powiedział, jest dinozauryatyczne. Moje tło to jest prawnicze, więc mam tutaj kontakt z ludźmi, którzy bardzo lubią tak mówić, że wszystko tam musi być na papierze, książki na papierze, wszystko na papierze, a z drugiej strony sobie siedzę w IT. No to tak się zastanawiam, czy prawnicy powinni decydować o tym, jak jest robione AI? Ja osobiście uważam, że prawników należy odsunąć od tego, a w szczególności należy odsunąć ludzi, którzy na przykład mówią, siadł do studentek jak psa. Uważam, że tacy ludzie nie powinni mieć w ogóle dostępu do sztucznej inteligencji czy w ogóle dostępu do AI. No a ja was pytam w sumie, co sądzicie? Jak powinno być governance robione? W sensie, governance na przykład powinni robić ludzie z IT czy może governance powinien mieć też jakiś udział w torcie na przykład prawnicy? Ja uważam, że prawników należy odsunąć w ogóle od governance. Ja to zaparkuję na ostatni temat, co my zrobimy. Powiem tylko, że wiesz, to zależy, bo są branże, w których jest to wymagane. Na drugą pradażę też się to trochę pojawia. Tam jest taki punkt w technikach, technik kontinuous compliance. Ale tak, są różne wymagania. Ja pracowałem z branżą Farman, tam się to trochę inaczej robili. Finance też. Tak że zaparkujemy, może weźmiemy kiedyś na temat. To jest bardzo dobry temat governance ogólnie. Ja się zgadzam, w dobie LNM-ów jak najbardziej jest ważny. Zaparkujmy faktycznie. Ja chciałem nawiązać jeszcze do tego, co mówił Sebastian. Mnie to podejście do testów bardzo zdziwiło. Myślę, że to trzeba wziąć przez ten kontekst, o którym powiedzieliście na wstępie. To jest jakieś okno z to, co robi ThoughtWorks ze swoimi klientami. I tam jest mnóstwo Kubernetesa, więc to też na to wpływa. Po prostu technologie, których używają i to, z czym przychodzą do nich klienci. Bo ja sobie nie wyobrażam dewelopmentu serverless, na przykład bez testów integracyjnych. Ja tu myślę, że do tego dojdziemy jeszcze. To tutaj trzeba dodać kontekst. ThoughtWorks to jest dziesięć tysięcy osób. To jest naprawdę duża firma, jeżeli chodzi o software house, bo tak naprawdę tym jest ThoughtWorks. Więc myślę, że tam będzie się działo. To jest ciekawe, tak jak powiedziałeś, dziesięć tysięcy osób, że oni... To taka uwaga też do radaru, że tam jest kilka takich pozycji, przez które widać, że na przykład oni mają jedną dużą część w Chinach. Tu widać w ogóle, tak jak mówimy, ale to myślę, że podsumujemy. Ja może zamknę. Mój ostatni punkt, takie zdziwienie, to było używanie GNI do analizy legacy codebase'u. No życzę powodzenia. Po pierwsze, to tutaj też tak jak Tomek powiedział, trzeba sobie zadać pytanie, po co my to chcemy robić, tak? I myślę, że naprawdę przy dużych codebase'ach, to jeszcze długo, zanim model będzie mógł nam w stanie wytłumaczyć, w wiarygodny sposób, co nam pod maską siedzi. Tym bardziej, że z reguły pytania od codebase'u, takie... Wiecie, to są skomplikowane pytania, zahaczające o architekturę, o procesy biznesowe, o kontekst. Więc myślę, że... To byłem zaskoczony, że ThoughtWorks mówi, że słuchajcie, trzeba teraz zwrócić uwagę, czy przypadkiem nie będziemy używać LLM-ów do analizy kodu. To się totalnie z Tobą nie zgadzam. Uważam, że tu się kłania tak zwany krefin. Czyli tak naprawdę w momencie, kiedy odpala się w ludzkich głowach ten cognitive load, i ludzie po prostu nie dają rady, bo przyrasta ich skala, albo przyrasta ich ilość powiązań, ilość zależności i tak dalej, to w tym momencie właśnie taki LLM, jeszcze spięty agentami, byłby w stanie sobie poradzić z tego typu codebase'em. Bo w przypadku, kiedy mamy 10-letni legacy często, to w firmie ludzie, deweloperzy, czują się bardzo niekomfortowo, i wszystko trwa 10 razy dłużej, dlatego, że czują się niepewni, czy to jest jedyne miejsce w kodzie, które powinienem zmienić, bo oni tak naprawdę w czasie rzeczywistym robią inwestygację, gdzie powinni wykonać zmiany, żeby zaimplementować dany feature. I uważam, że jeżeli to rzeczywiście zostanie dobrze zaimplementowane, to ten problem zostanie przynajmniej wcześniej rozwiązany. Więc akurat tutaj ja trzymam kciuki. Dodam może kontekst do tego, co powiedziałeś. Wiesz, z reguły legacy codebase to jest bardzo, zakładam, spory kawałek kodu, naprawdę spory, gdzie mówimy prawdopodobnie w milionach linii kodu. Jest on z reguły też w legacy, jeżeli chodzi o technologię, w legacy, jeżeli chodzi o architekturę, jest bardzo, bardzo kontekstowy, tak? Więc tutaj myślę, bo jeżeli my chcemy wziąć mniejszy projekt, mniej skomplikowany, jasne. Natomiast myślę, Sebastian, że przy dużych projektach to nie wierzę, że to będzie takie proste. Gdzie jeszcze dodam, mamy integrację bardzo często, dosyć skomplikowane wzorce integracyjne, pomieszane, niekoniecznie dobrze zaimplementowane. Zobaczymy, co wymyśli, jak to się robi i w sensie przyszłości. Ania do nas dołączyła. Tak, hej, słychać mnie? Tak. O, super. Ja tylko chciałam dodać, Wojtek. Oni mają w Assess ten używanie GenAI do zrozumienia legacy codebase'u, więc to nie jest tak, że oni od razu mówią, że a, to weźcie sobie jakieś ogromne tam, ogromne legacy codebase i używajcie GenAI, tylko look closely i zobaczcie, czy to pasuje, i że ja się zgadzam z tym, że do małych legacy codebase'ów to może być dobry pomysł, no ale oni nie mówią weźcie to i to już jest gotowe, nie? To jest taki, no spróbujcie, jeśli to do ciebie pasuje. Więc ja tego tak nie odbieram, że oni mówią dobra, to już jest ta droga. Jasne, natomiast słuchajcie, tak komentarz zupełnie obok. To jest świetna wskazówka, jeżeli ktoś szuka pomysłów, jak wykorzystać AI i zyskać pieniądze inwestorów, to właśnie ThoughtWorks wrzucił, słuchajcie, można to robić, uważamy, że to będzie działało, więc na pewno może to jest wskazówka, jak podnieść teraz parę milionów euro. Chyba tak daleko bym nie szła, no ale może jest to jakaś droga zdobycia. No, nie pomyślałam o tym, rzeczywiście może ktoś by chciał. Dobra, słuchajcie, to myślę, że Technics wyczerpaliśmy dosyć mocno. Kolejna kategoria, którą mamy, to narzędzia, czyli tools, tak ładnie zwane. Tomek, czy chcesz zacząć tą kategorię? Nie, wyjątkowo nie. Wyjątkowo nie, okej, Sebastian? Czemu nie? Zastanawiam się, od czego zacząć, czy od tych narzędzi, gdzie widzę potencjał, czy od tych, gdzie to jest w ogóle no-brainer. Może zacznę od tych no-brainerów. Jak dla mnie, z kim się całkowicie zgadzam i w sumie nawet bym w ogóle nie polemizował, to tak, Carpenter zdecydowanie, to jest narzędzie, które zupełnie nie robi różnicy. Jeżeli ktoś jest ze świata CNC, a jeżeli ktoś jest ze świata Kubernetesowego, to to jest narzędzie, które bardzo pomaga i przyspiesza tak naprawdę wszelkie kwestie związane z autoscalingiem. No może nie wszelkie, przesadziłem, ale tak, jest bardzo pomocne i staje się powoli takim trochę defaultem. Kolejna rzecz, Gradio. Ja z Gradio korzystam namiętnie, przy czym ja powiem, że korzystam z niego głównie do wizualizacji w eksperymentach. Gradio i Streamlit, one się fantastycznie uzupełniają, mają trochę inny poziom abstrakcji. Jedna jest, powiedzmy, szybszy efekt, drugie jest bardziej elastyczne, ale tak, polecam, polecam. I jeszcze kolejny nooblainer, który tutaj mógłbym polecić, i to jest ze względu na takich czysto doktrynalnych, bo w życiu tego nie użyłem, ani w życiu tego nie miałem z tym takiego, powiedzmy, projektowego do czynienia. To jest Open Policy Agent. A dlaczego? Powiedziałem, że jest z powodów doktrynalnych. Ja bardzo mocno wierzę w decentralizację poprzez protokoły. Dla mnie OPA to jest bardzo dobry przykład. To jest zaproponowanie standardu dla policies. Jestem cały za, i jest jeszcze jeden taki przykład, tylko już może poza Tools, więc powiem sobie o nim troszkę później. Natomiast właśnie ze względów takich, powiedziałbym, czysto ideologicznych tutaj bym się tego trzymał. Więc z tych takich rzeczy, powiedzmy, zupełnie niekontrowersyjnych to tyle, a resztę pewnie jeszcze będzie okazja do powiedzenia. To ja może wejdę, ale z takim trochę komentarzem, przyznam szczęście, że większość z tych narzędzi niestety na co dzień nie używam. Ale kilka takich obserwacji. Po pierwsze, jak sobie przeglądałem te narzędzia, użyłem tego, żeby się poedukować, to tam w trialu pojawiły się dwa AWS Pudos i AWS New York. I sobie pomyślałem, że jeżeli patrzymy na to właśnie przez przyznanie tego, że SustWorks robi projekty i tak jakby mówi, co jest ten lutnik, gdzie jest problem albo do czego używają, to te dwa narzędzia pokazują, że problem jest w kosztach. To dla Pawła Zubkiewicza taki temat. Bo to są narzędzia, które służą do kontroli kosztów i nieużywanych zasobów. I to mnie o tyle zdziwiło, że... Zdziwiło, bo ja wiem, że to nie jest ogarnięte, ale to pokazuje, że w większej skali też nie jest ogarnięte. Czyli to jest na poziomie trial, to znaczy, że problem istnieje, a skądś dalej gdzieś tam z nim walczy, nie? Takich narzędzi też... Mogę tutaj się wtrącić, skoroś mnie wywołałeś? Po pierwsze, jakby te narzędzia są w miarę podstawowe, jak już pracuję z AWS-em dłużej. I tam jeszcze jest trzeci mały tool, który się nazywa AWS New York, który służy do kasowania wszystkiego na koncie. Aha, to jakoś nie zrozumiałem. Moim zdaniem to pokazuje, że oni są w miarę, jakby, nie wiem, chodzą szerzej dopiero u klientów z AWS-em. A jeżeli chodzi o te koszty, no to też może oni za bardzo nie chcą poleczyć jakiegoś konkretnego field party. Bo to Kudos jakby jest fajnym narzędziem, jest darmowym narzędziem, pomijając koszty, powiedzmy, tego, że ono musi działać na AWS-ie. Ale nie adresuje wszystkich problemów, które różne sasy adresują potężne. Ale fajnie, że się znalazłeś. To jest takie w miarę dla mnie zdziwienie, że to są w sumie podstawowe rzeczy, jakie jesteś w tym temacie. Czyli z boku dostałeś kudoszy za ptaki w tle od ekipy Coffee na czasie, w których gdzieś tam prowadzimy. Ale właśnie o to mi chodziło, że ja to wyjaśniłem, dlatego że to pokazuje, że oni gdzieś ten problem też widzą od swoich klientów i po prostu zaczynają go adresować. To pokazuje, że po prostu, jak wszyscy wiemy, ten problem jest gdzieś nierozwiązany. No i wrzucili tak bardziej tylko obserwacje. Wszyscy używają Copilot, ale ich opis Copilot jest pozytywny. Czyli piszą, no tak, to nam pomaga. Więc to też tak uważałem, że jednak doszli do wniosku, że chyba to im pomaga. Wiesz co, może ja Cię dołączę i rzucę takiego hot take'a teraz, że może podejście odwrotne, to znaczy zamiast dodatkowych narzędzi, to może właśnie się zastanowić, żeby ograniczyć liczbę narzędzi i też trochę takie podejście z serverless bym powiedział. To znaczy, że nie dodajemy multum kolejnych bibliotek do funkcji VWS, tylko kombinujemy, jak zrobić, żeby było mniej. Bo wiecie, tak szczerze mówiąc, mnie to osobiście wkurza. Mamy jakieś rozwiązanie i każdy sobie tam wciska LLM-a. No to w tym tempie to niedługo nawet Dostal będzie nam LLM-a wciskał, tylko po co? Jak możemy rozwiązać to prościej. Zaczniecie od tego, jaki mamy problem i czy możemy go rozwiązać prościej niż wrzucanie LLM-a wszedzie. No bo bądźmy szczerzy, no skończy się to niedługo tym, że ten mem o tym gigabajtowej aktualizacji tostera zaraz stanie się rzeczywistością i będziemy włączać toster, a tam gigabajtowy LLM się włącza, a potem zdziwienie, dlaczego mój toster ma gigabajtową aktualizację. No właśnie przez to, że ktoś sobie dla marketingu wstawił. No tosta, więc to jest, słuchaj, albo historii tosteru. Oczywiście podpisuję się pod tym, co mówisz, ale myślę, że to jest dokładnie to, co... To jest ta mądrze, która się powtarza, tak? To jest dobra okienko na to, gdzie 10 tysięcy osób w ThoughtWorks się spędza, słuchajcie, swoje dni. I ewidentnie widać, że ThoughtWorks bardzo mocno płynie na tej fali, że każdy powinien mieć LLM-a i myślę, że, słuchajcie, no jeżeli ktoś jest w technologii przez, powiedzmy, 50 lat, to wie, że nadchodzą kolejne fale, tak? Kiedyś było, nie wiem, tam big data, później było na przykład machine learning, później były krypto, później data mesh'e wpłynęły itd., itd., tak? I teraz kolejna fala, w jaki sposób musimy wydawać pieniądze, no róbmy wszyscy LLM-y. Natomiast tutaj, tak jak Tomek powiedział, paradoksalnie oni mówią wprost, tylko ciekawy ilość osób to zauważy, że no nie, spokojnie z tymi LLM-ami, bo one wam, waszych problemów nie rozwiążą. Czyli bardziej ja to widzę na zasadzie, widać, że oni mają dużo projektów, które wokół tych LLM-ów dosyć mocno gdzieś tam sobie krążą. Ja może, słuchajcie, ja może też, patrząc na sekcję tooling, też dodam, że właśnie widać, z czym najczęściej klienci pod worksa mają do czynienia, czyli Kubernetes i Terraform. To, co było fajne, to prawda, to wszystko, o czym rozmawiamy ostatnio, czyli licencje wokół open source'u, które mogą się zmieniać, mogą być dosyć niebezpieczne dla wielu firm, czyli np. OpenTofu, wszystkie narzędzia Kubernetes, które, tak jak mówicie, one są, jeżeli ktoś faktycznie ma duży projekt już i te licencje mogą być bardzo kosztowne, no to one są znane, więc przynajmniej mam nadzieję, że poprzez Technology Radar to te narzędzia faktycznie staną się dużo bardziej rozpoznawalne, więc to mnie, powiedzmy, to mnie cieszy, jeżeli chodzi o to, co się pojawiło. Druga rzecz, która mnie cieszy, to my rozmawialiśmy już kilka razy na temat też open source LLM-ów i jest tutaj tego, jest tutaj trochę narzędzi pokazanych, które pomagają w pracy z LLM-ami i z produktami opartymi o LLM-y, wliczając też, prawda, jak skalować LLM-y, jak je deployować na wielu maszynach, więc te narzędzia się pojawiły, więc to mnie np. cieszy. Pozytywnie mnie zaskoczyło, mogę powiedzieć tak, że Philips self-hosted GitHub runner, taka ciekawostka. Nie sądziłem, że Philips, słuchajcie, ma aż tak zaawansowany open source, nie kojarzyłem ich tak bardzo. Wczytałem się w to, to jest fajne, z chęcią sobie zobaczę, czy to działa i mi się osobiście spodobało, to mogę powiedzieć jako taką ciekawostkę. Jeszcze może taka trzecia rzecz, taka trzecia kategoria, słuchajcie, czego mi naprawdę zabrakło tutaj, to powiedział Security Tuning. No kurczę, w 2024 roku, gdzie mamy ataki z lewej, z prawej, napiętą sytuację geopolityczną, to, że tutaj nie ma praktycznie w ogóle żadnych narzędzi security, to było dla mnie takie zaskoczenie bardzo mocno. Ale widzisz, i tutaj zrobiłem taki mały lup do poprzedniej sekcji, bo tam się pojawiło Security Champion. Ale to wiesz, odnoszę się do Security Championa, masz rację, natomiast ja bym dodał, że brakuje. Powinien być jeszcze Lops Champion itd., itd. Ale to bardziej chodzi o to, że ja bym to czytał tak, pod tytułem, tak, mamy problem z security, narzędziami go nie rozwiążemy, najpierw musi się pojawić ktoś, kto w ogóle o tym myśli. Ale wiesz, masz Shift Lab Security Tuning, tak? Są takie narzędzia, więc... Tak, są, ale jak, wiesz, te narzędzia same z siebie rozgadzą, i to jest główny klucz tego. Ale to byłby drugi temat na follow-up. No myślę, że tutaj mogę... Jasne, tu się nie zgadzamy, natomiast... No dobra, słuchajcie, czy macie jeszcze jakieś przemyślenia, może komentarze do tego, co powiedziałem? Znaczy, może ja się... To nie wiem, kto pierwszy chce mówić. Tomku, to mów, jesteś gościem. Dobra, to ja chciałem powiedzieć w ogóle, jak zaczęliście temat security, chciałem rzucić taki temat z dalschodniej granicy tutaj u nas, czyli z Ukrainy. Mianowicie to, że no przecież... Przecież całe EIA... No dobra, ja nie lubię terminu EIA, wiecie dlaczego, już wyjaśniłem, że tam najpierw proste rzeczy, no ale mi chodzi o to, że jest już wykorzystywane, żeby poprawić celność broni, tak? Więc w ogóle tutaj wchodzimy w temat tego, że przetwarzanie obrazów jest wykorzystywane, żeby skuteczniej zabijać ludzi. I to za naszą granicą, więc... No samo security, no ale mamy też taki temat, tak? Militarnego wykorzystywania, szczególnie, że no wiecie, no... Sporo tam weteranów przechodzi z Stanów Zjednoczonych w szczególności do techu, tak? No więc mamy tym bardziej militarne wykorzystywanie technologii. Wczoraj pojawiła się duża ciekawostka w tym temacie, ale to też bym zaparkował, bo to nie na dzisiaj. Ale tak, taki temat istnieje. Jak ktoś pogrzebie, to wczoraj pojawił się ciekawy artykuł. Może podlinkuję to tym. Ania, zacznę, żeby mówić o tym, nie jestem kim. Tak, nie chciałam wchodzić w słowo. Też chciałam nawiązać do tematu security. Temat security był bardzo mocno poruszany w poprzedniej edycji, tej wrześniowej. Wydaje mi się, że ktoś z Was to mówił, że to jest po prostu takie okno, to, co oni teraz robią. Wydaje mi się, że to nie jest tak, że oni temat porzucili. No tylko nie da się... My też robiliśmy swojego TechRadar'a. Trzeba się zdecydować, nie da się tam o wszystkim napisać i wydaje mi się, że to powinniśmy tak traktować, że to jest tak tu i teraz, o tym teraz rozmawiamy. Ale te tematy, które oni poruszali w poprzednich edycjach, no to one nie znikają. I w tej wrześniowej, podejrzewam, no to tam jest tego całkiem sporo. Temat o security. Tak, tak było. Tylko wtedy rozmawialiśmy w BRU, chyba, jeżeli ktoś nie oglądał, to może zajrzeć, ale tam było dużo na temat security. Nawet ja wtedy wspominałem o tym, że to było zaskoczenie, bo tam się tego pojawiło, to ma to dużo opaść. Ale tak, to już mamy trzy tematy dzisiaj, follow-upy. Governance, security, użycie AI w różnych dzielnych miejscach związanych z militariami, co on odrzucił. No dobrze. Sebastian, czy ty masz coś jeszcze tutaj w temacie? Powiem, że masz akurat przypadkiem. Pewnie powinniśmy już skakać do następnej kategorii, natomiast ja powiem, tak obiecałem wcześniej, patrzyłem też na stare radary, czego nie ma, albo co znikło. Czyli tak, znikł cały ten IPF-owy szał, czyli nie ma już tego, tej nowej fali obserwability, która była obiecywana. Ja tu chyba nie widzę żadnego narzędzia, które się to wpasowuje. Znikły też na wszystkie cloud carbon footprinty i narzędzia sustainability, bo oczywiście wszyscy klienci strasznie chcieli wiedzieć, jaki to wpływ mają chmurowe na przykład rozwiązania na środowisko, więc już chyba sobie z tym, w tej dobie kryzysu, dali na wstrzymanie. W ogóle jest też brak holdów w tej kategorii, co jest ciekawe. I jeszcze tak zupełnie kończąc, jest tu kilka narzędzi, które mnie zaciekawiają, których wcześniej nie dotykałem, ale już właśnie po tym opisie stwierdziłem, że to może być ciekawa rzecz. Pierwsze takie narzędzie to jest LinearBeam, nie wiem, czy widzieliście, to jest taki dashboard zarządczy z interesującymi metrykami właśnie od strony zarządczej dla engineering leaders. To jest ciekawe. Jestem ciekawy rzeczywiście, jak to się integruje, co tam w ramach tego jest, więc to jest coś, co sobie wrzuciłem na rozkład i będę chciał się przyjrzeć. Fajne są dwie rzeczy, bo Wojtek chyba powiedział gdzieś tam na początku, że tak, uruchamiajcie swoje własne LLM-ie, i to są dwie takie rzeczy, dwa takie narzędzia, które też wpadają trochę w ten powiedzmy trend. To jest Continue i to jest Kill Anything. Wydaje mi się, że jeżeli one będą dobrze zbundlowane, to może nie to, że one rzeczywiście staną się jakimiś wirującymi narzędziami, ale one są w stanie wytyczyć pewną ścieżkę. I to jest też dla mnie ciekawe, np. przyspieszyć rozwój tych mikromodeli, które tam powiedzmy 7-biliardowych, jeżeli chodzi o ilość parametrów, które byłyby deplojowane lokalnie. Więc to jest też taki ciekawy trend. Mnie pewne niekonsekwencje też trochę na pocie czasami zadziwiają, bo np. nie mam nic przeciwko Pentofu, ale zastanawiam się, dlaczego tu jest jako ASS. Jeżeli ona na obecnym etapie jest tak naprawdę, no po prostu 14 terraforma, czyli funkcjonalnie się szczególnie go nie różni. Jakie tu będzie podejście footworksa, jeżeli chodzi również o inne klony? No bo mamy więcej narzędzi, gdzie zmieniają się te licencje, gdzie takie typu zjawiska będą miały miejsce. Więc tutaj chodzi właśnie bardziej o takie zadeklarowanie poparcia, dlatego związane czysto open source, a w przypadku komercyjnej firmy takie też ciekawe podejście. Czy kryje się na tym coś jeszcze więcej? Bo tam oczywiście w tym opisie nie zostało to jasno sklaryfikowane. Myślę, że jeżeli chodzi o tę kategorię, to tyle moich komentarzy. Chyba płynnie przechodzimy do kolejnej kategorii, czyli platformy. Słuchajcie, więc Tomku, może tutaj byś chciał nam powiedzieć, co ciekawego znalazłeś? Co ciekawego znowu, jak ostatecznie platformy, to ale dużo Azure'a się pojawiło i tak to znowu to jest spojrzenie na to, co oni robią, nie? I pojawiło się Azure Container Apps i też pewnie zaszkodzijąc, znaczy ok, jest to pewnie jako trial, tak? Więc gdzieś próbują prawdopodobnie iść w stronę aplikacji opartej o kontenery, ale bez Kubernetesa jako skomplikowanego elementu. Tutaj to jest o tyle ciekawe, że pojawiło się to trochę z mojego podwórka, ale że pojawiło się wprost, nie? Azure Container Apps jako platformę i też bardziej ciekawego. Takich bardziej ciekawych, tam jest wspomniany, tam jest Army in the Cloud, tego trialu, to już byli tańsze maszyny, szybsze i tak dalej. I tam się pojawiło, chyba nawet rozmawialiśmy o tym chwilę, że to było kompletnie poza moim bąbelkiem, ale potem jak pokomentowaliśmy w Assef jest RISC for Embedded. I to mnie trochę zdziwiło, że ja po prostu RISC jako platforma zniknęła mi dawno z oczu, ale to też wskazuje, że tam gdzieś może w Chinach więcej tego się używa, bo oni mają swoje platformy i oni to też widzą, nie? Czyli... To jest RISC-V albo RISC-V, jak niektórzy mówią, to jest ważna różnica. Tak, ale ogólnie to dla mnie wystarczyło o tyle, że po prostu kiedyś dawno, dawno temu RISCiem się trochę zajmowałem, więcej to jeszcze w czasach przedkomercyjnych bym powiedział, a potem kompletnie mi to gdzieś zniknęło z radaru. I to znaczy, że się zainteresowałem, czytałem chwilę, co to jest, skąd to się wzięło i tak dalej. Wiesz, no to może ja się dorzucę i tutaj też dorzucę takiego hot-take'a, że właśnie pytanie, jak obecnie definiujemy platformę, w szczególności w kontekście tego, że teraz wszyscy się biją krótko mówiąc od GPI, od NVIDII, tak? A z kolei Chińczycy narzekają, że przez... zostali trochę odcięci od tego GPI, od NVIDII, tak? No więc mamy wojnę na GPI, ale ja chciałem jeszcze tutaj dorzucić co do platform jeszcze tutaj drugą kwestię, mianowicie tam, co wkleiłem w sumie, temat cyber security, to znaczy mam na myśli to, że przecież elementy są wykorzystywane nie po to, wiecie, żeby teraz jakieś super machu, jakieś rzeczy robić, tylko żeby na przykład szybko generować przy pomocy platform właśnie maile phishingowe, tak? Bierzesz czyjś... bierzesz czyjś profil z jęklina, szczególnie jeżeli wiesz, że ta osoba nie jest techniczna, tak? Generujesz generujesz maila phishingowego, wysyłasz i masz co chcesz, nie? I nie dlatego właśnie, że AI zrobił wszystko jako sztuczna inteligencja za ciebie, tylko że ci pomógł pewne rzeczy zautomatyzować, szybciej zrobić, nie musiałeś całego maila phishingowego generować od nowa, tylko masz spersonalizowanego maila dzięki właśnie narzędziu. Ale może tu wbiję, bo skupmy się jednak na zawartości radaru i na tym, co tam komentowali ludzie z ThoughtWorks'a, polecają itd., bo możemy tak naprawdę dyskusję bardzo szeroko rozpuścić, natomiast wtedy nie ogarniemy tego, przez co chcieliśmy przejść. Tylko powiem, że masz rację, ale też znowu zapatrujmy, bo to jest, jeżeli ktokolwiek w tej chwili w security korzysta z AI, to najlepiej wychodzi to tzw. bad guys, ale mówię, no to jest też osobny temat. Do wszystkiego korzystają. Proszę o życie. Słuchajcie, to może ja powiem właśnie, jeżeli chodzi o platformę, pod czym się na pewno podpisuje. Podpisuje się pod Cloud Events. Fajnie, że się pojawiło, może dobrze, żeby to było szerzej znane. Czyli Cloud Events to w wielkim skrócie to jest swagger dla event-driven architecture, tak? Czyli platforma do dokumentacji, albo raczej standard dokumentacji eventów. Brakuje jeszcze według mnie toolingu do tak naprawdę, bo to Cloud Events opowiada o konkretnym, znaczy to jest konkretny standard, natomiast brakuje jeszcze toolingu wokół tego, więc zobaczymy, ale fajnie, że się pojawił to jako adopt. Arm in the Cloud to jest coś, co też mnie ucieszyło, że chociaż dziwię się, że to nie jest adopt, przy tej, szczególnie przy tej ilości słuchajcie, różnych konfiguracji, które mamy od do tego, na czym to uruchamiamy, dany serwis, to dobrze, że to się pojawiło, bo uważam, że no to była taka dosyć duża dziura, jeżeli chodzi, jeżeli na całkiem innej architekturze piszemy, testujemy, później uruchamiamy i to działa, no to różne dziwne rzeczy mogą się dziać po drodze. Coś, co też mnie cieszy, że się pojawiło to Pulumi. To jest bardzo ciekawa alternatywa do platforma, więc możemy w języku programowania, w językach programowania typu Java albo Python stworzyć sobie całą Infrastructure as Code, przetestować ją, więc jest to narzędzie dużo bardziej przyjazne, myślę, dla programistów, więc jeżeli chcemy na przykład właśnie infrastrukturę przybliżyć programistom, to jest to dobre rozwiązanie i tak jak Sebastian powiedział, jest kilka rzeczy, o których nie wiedziałem, a chętnie sobie zobaczę. Więc pierwsze, to było, muszę przyznać, że HyperDX to było coś, co całkowicie było poza moim radarem właśnie, więc to jest Observability Platform, a to jest coś, co nas bardzo mocno wszystkim dotyczy, czyli tak naprawdę wiecie, logi, metryki, tracing, alerty w jednej platformie i jest to alternatywa opensource'owa, więc jestem bardzo ciekaw, jak to wygląda i jak to sobie radzi przy większej skali szczególnie. I też jestem bardzo ciekaw, czyli znowu wracamy do kosztów i narzędzie, które między nimi właśnie pomaga na podstawie metry, analizować metryki, które metryki nas kosztują, bo przy pewnej skali, na przykład w mojej firmie mogę powiedzieć, że logi i metryki to jest top 3, jeżeli chodzi o koszty całej infrastruktury, więc takie narzędzia są ciekawe. Czego mi zabrakło ewentualnie? To platform do knowledge discovery, tak, czyli jak na samym początku wspomniałem, oniteraki JLM bardzo promują jako koncept, ale na przykład w platformach zabrakło tego całkowicie, więc myślę, że tutaj już można by coś pokazać, ale tego, przepraszam, nie zabrakło całkowicie, bo mamy Elastic Search Relevance Engine, ale to jest jedyna rzecz, która się pojawiła. Sebastian. Mam parę punktów. Cloud Events zupełnie się podpisuje, to jest taki mój hobby-project. Robię jakieś prezentacje nawet na ten temat. To jest projekt, który już raz zdążył umrzeć, tam CNCF go podłapał, więc teraz znowu łapię aktywność, będę trzymał kciuki. Dla mnie to jest coś więcej niż to, co powiedziałeś, czyli taka specyfikacja, to jest bardziej, bo tam się już pojawiają SDK-ki, tam się pojawia różny middleware, tak naprawdę, do takiej eventowej integracji pomiędzy różnymi dostawcami, na przykład, różnymi rozwiązaniami chmurowymi i nie tylko. Natomiast ja się tutaj trochę boję właśnie o to komercyjne wsparcie, jakby na ile duże firmy, duży gracz mają rzeczywiście interes, żeby w to pójść, bo mam wrażenie, że unikają tego jak mogą, więc ja trzymam kciuki. A mini-cloud też się zgadzam, że czemu trial? To już jest tyle generacji, chyba AWF zdążył chyba trzecią generację wypuścić tego swojego Gravitona, więc to zdecydowanie tak. Fajnie, że pojawił się ban, znaczy ban to już był chyba wcześniej, tylko gdzieś tam jako trial. Ja jak pierwszy raz zacząłem wykorzystywać bana i zobaczyłem na ile jest stabilny i jak jest, jak mrywa łeb, jeżeli chodzi o prędkość, stwierdziłem, że hell yeah. Niczego innego i nie chcę już używać, jeżeli chodzi o... Czyli zadajmy runtime javascriptowy, prawda? Napisany wreszcie, tak. Śmiga, i to jest tak naprawdę drop-in replacement dla, nawet nie dla node'a i npm'a, dla całego ekosystemu tego node'owego. Śmiga i furczy. Ostatnio chyba jest wyszła wersja 1.1.1, która już działa na Windows, czyli tak zwany bundles. Icepanel to jest fajne narzędzie. To jest narzędzie do C4 modelu, który jak dla mnie jest bardzo prostą notacją, która działa znacznie lepiej, jeżeli chodzi o dokumentowanie architektury, właśnie dlatego, że rozwiązuje kilka problemów, które na przykład DDD obiecało rozwiązać i ich nie rozwiązało. Tutaj jak ktoś jest zainteresowany, polecam, kiedyś popełniłem serię artykułów na ten temat, Icepanel jest bardzo fajny, bardzo dopieszczony, a minusem są kwestie pricingu, bo jest to narzędzie drogie, zwłaszcza jeżeli ktoś robi jakiś indywidualny consulting. RISC-V for Embedded. Ja w ogóle jestem fanem tej otwartej architektury RISC-V, natomiast jest też sporo ludzi, którzy to krytykują ze względu m.in. na to, że jest tam idea całkowicie otwarte architektur procesorowych i jest to wykorzystywane przez pewne państwa do omijania sankcji międzynarodowych. W związku z tym, czy to dobre, czy to złe rozwiązanie, każdy już może sobie ocenić sam. I to ostatni, mój punkt, to jest związane z tym, co wyleciało, więc tu tylko jeden punkt wymienię. Wyleciało Trino i to jest ciekawe, dlatego że ostatnio szeroko komentowany był ogólny trend tego, że jeżeli chodzi o analitykę, dużej ilości danych odchodzi się od jednorodnych baz i jest coraz większe rozpięcie pomiędzy sposobem, w jaki dane są przechowywane, czyli bardziej między formatami danych, a query engine'ami, właśnie żeby zachować tą elastyczność. Czyli firma zachowuje na przykład swoje dane w pewnym formacie i później bez straty jakiejś performasy to jest najmniejstko i wyłącznie query engine. I wydaje się, że ten trend akurat, gdzie radarze tutaj nie jest widoczny, co więcej, jak wcześniej był, to teraz zniknął. To tyle, że chodzi o obserwacje tutaj. Tomas, zaraz dołączę. Ja tylko minimalne wstrącenie, bo też jestem fanem cloud eventów. Tu chciałbym pocieszyć trochę Sebastiana. Microsoft idzie w cloud eventy, usługi ażurowe, tam np. Evergrid aktywnie adoptują, żeby to był wspierany standard, więc to się też do tego mainstreamu chmurowego przebija, więc sądzę, że tu będzie użyto z dużych graczy. To kudosy, bo na pewno pojawią się narzędzia wokół tego, także fajnie. Dobra, słuchajcie, bo jeszcze chcemy zostawić parę minut, żeby porozmawiać o radarze i wiem, że Ania wspomniała już, że wy robicie schuły, więc chętnie byśmy do tego chcieli jeszcze nawiązać, więc languages and frameworks. Z mojej perspektywy jesteśmy w stanie zamknąć to dosyć szybko. Przyznam szczerze, bo ja bym powiedział, tam królują trzy rzeczy chyba, LLM-y, Rust, i to do interfejsów użytkownika, uwaga, więc to było moje chyba największe zdziwienie, i wszelkie rzeczy związane z Androidem, tak, więc tutaj absolutnie widać okienko na to, co podłoż zrobił, i moje zdziwienie Rust do UI, biblioteki, wszelakie właśnie pozwalające na tworzenie interfejsu użytkownika, wreszcie, to aż trzy pozycje w tym radarze, tak, czyli no, absolutnie LLM-y i Rust do UI według mnie zawładną tym raportem. Sebastian, jak z twojej perspektywy to wygląda? Ja też mam tak naprawdę niewiele punktów w tej sekcji. No tak, jest Ray, który nie wiem czemu to jest jako trial, ja bym powiedział totalnie adopt, Ray jest, to jest można powiedzieć framework do rozproszonego przetwarzania w Pythonie, trochę taka alternatywa, można powiedzieć, dla Sparka, to, co jest w nim bardzo fajnego, to jest to, że on pozwala bardzo łatwo przejść od eksperymentowania do uprodukcyjnienia, czyli tak naprawdę jeżeli ktoś eksperymentuje na Pythonie z jakimiś pandasami, to tutaj ma się wrażenie, że nagle można to wszystko wziąć, zbundlować, zacząć pracować na rozproszonych architekturach. Jestem wielkim fanem Ray, w takim dużym skrócie, więc jestem cały za. Dla mnie to, co ciekawe to jest to, że w tym raporcie powiedziałem, że tam jest dużo rzeczy androidowych, ja się w nie akurat nie wczytywałem, ale właśnie miałem takie wrażenie, że ten cały kotlinowy szał w ThoughtWorksie się skończył. No oni wszędzie tego kotlina pchali gdzie się da, teraz już widziałem tego mniej, może to jest jakiś mój bijas się tutaj włączył. I ostatnie dwa punkty, które tu mam, to jest ciekawe, dali lengthchaina na hold podczas, gdy tam wspomnieli jakieś dwa alternatywne rozwiązania, których nazw już nie pamiętam, jak gdzieś tam dali jako trial. Jazd do lengthchaina ma taki bardzo mocno ambiwalentny stosunek, czyli na samym początku, jak on wchodził, to byłem nieprzekonany, a teraz czasem, jak go nie dają hold, to tak naprawdę uważam, że ten rozwój, że ten lengthchain zaczął się robić użyteczny. A więc mnie to trochę nie przekonuje, no ale dobrze, każdy może mieć swoje zdanie. I ostatni taki ciekawy punkt, jak się to pojawił, to jest punkt, który ja osobiście nie używałem i szczerze mówiąc normalnie nie zwróciłem na niego totalnie uwagi. Natomiast jest tam taki język programowania, który nazywa się ZIG. Ja niestety nie słyszę dobrych rzeczy. Nie, nie, nie. Może tak, to też jest ciekawe ze względu na interoperability z Pythonem, ale nie, chodzi mi właśnie o ZIG-a. Że to jest kolejna próba wynalezienia C, C++ na nowo z ucięciem pewnych wad, które ten język miał. Tak jak mówię, ja już znam ludzi, którzy robią w tym produkcyjnie i są z tego bardzo zadowoleni. No jestem ciekawy, czy to rzeczywiście się przebije. Raczej nie wróżę jakichś wielkich sukcesów. Zapadła niezręczna cisza albo chłopaków wyrzuciło. Ja nie mam żadnych komentarzy tutaj, więc jeżeli ktoś się jeszcze chce podłączyć, to zapraszam. A jak nie, to właśnie mamy cztery minuty. No i jak wspomniałeś, że robicie swój radar, to znaczy jakiś tab, w której byliśmy, to może nam powiesz, co robicie, jak robicie, po co robicie i dlaczego robicie. Jasne. Ja mam jeszcze trochę przemyśleń a propos tego Army in the Cloud. Mnie bardzo cieszy, że jest. Trochę inaczej patrzę niż Sebastian, tak szybciutko, bo są cztery minutki. Trochę inaczej patrzę. Wydaje mi się, że podłąc nie zarzucił, wiadomo, wydaje mi się, tylko tyle mogę powiedzieć, nie zarzucił tematu carbon efficiency i tematu green software, który się pojawiał w wielu poprzednich edycjach, bo wydaje mi się, ja to odbieram jako nawiązanie dalej, czyli zróbmy tak, żeby zużywać mniej energii, bo nie jesteśmy w stanie wszystkiego offsetować. I to też prowadzi do takiego przemyślenia, że musimy zużywać mniej zasobów, żeby być też bardziej niezależnymi energetycznie. To znowu trochę bardziej w polityczny temat. Ale to inne, to trzeba zaparkować. Trzeci temat, bo po prostu inwestycje ESG na świecie siadają, bo ekonomia strzeczy i tak dalej, więc generalnie temat ESG idzie nam z drugą stronę. Myślę, że dlatego to zniknął, bo nikt od nich tego nie chce w tej chwili. Być może tak jest. Możemy sobie tylko pogdybać, pogadać, no bo wiadomo, tam w środku nie siedzimy. A propos naszego TEC Radara, tak, robimy, nie jesteśmy tak bardzo konsystentni, w sensie, jak to się to już mówi, tak konsekwentni jak ThoughtWorks, ze względu na to, że wiadomo, oni mają, są kompletnie inną firmą. My robimy po to, żeby trochę edukować naszych klientów, żeby oni sobie mogli czytać, jakoś się zorientować, bo wydaje mi się, że wielu klientów się gubi. My pracujemy w e-commerce, no i to jest tak, każdy coś mówi, tu dostajesz jakiś artykuł, tutaj masz jakiś podcast, a potem jak trzeba podjąć decyzję biznesową, no to jest problem. Więc chcieliśmy się podzielić naszymi przemyśleniami i chyba rozmawiałam z Tomkiem o tym, że to, co nam to dało tak wewnętrznie, a co było takim w sumie zaskoczeniem dla nas, że dało nam to przestrzeń do tego, żebyśmy mogli na spokojnie porozmawiać ze sobą, co się dzieje i jakie my mamy opinie i zacząć dyskutować o tych opiniach. Dlatego, że jak się jest w projekcie w jednym, drugim, trzecim, no to jest się w takiej bajce. I my wyszliśmy tak wyżej i spojrzeliśmy na to, co się dzieje w technologii, z takiego bird eye view. I to było bardzo odświeżające. Oczywiście na to trzeba przeznaczyć budżet, bo to dużo czasu nam zeszło. Wiadomo, że przy tych radarze pracują ludzie, którzy są na tych seniorskich, architektonicznych stanowiskach, więc no to tym bardziej jest drogo, ale jest to dla nas bardzo odświeżające. Tak mentalnie też. No jak się podzieliła potem, czy macie gdzieś to na zewnątrz, bo wtedy w szczególności byśmy też to wrzucili, ale ciekawa inicjatywa. Ja tylko szczerze miałem podejście w firmie do tego, później się do tego źle zabrałem, to był też inny cel, ale to w ogóle fajne jest to, że to jest faktycznie jakby jako metodologia tych podejście jest otwarte, można sobie znaleźć narzędzia, które pozwalają to robić, no i takie przemyślenie o co chcielibyśmy to robić, dlaczego i tak dalej, to jest ciekawe. To jest bardzo ciekawe, bo w ten sposób firma może się zapozycjonować i pokazać swoją, co jest w niej unikalnego, czyli na przykład, że ona ma podejście do realizacji. Tak. Wytłumaczyć swoim klientom swoją przestrzeń, w której jest, przepraszam, że ci wszedłem, ale powiedzieć, słuchajcie, my robimy w tej przestrzeni i wiesz, ograniczyć sobie tak nadal do tej przestrzeni i powiedzieć, w tej przestrzeni myślimy, że takie rzeczy się robią, nie? Oni też mają czas, w sensie klienci, na przeczytanie i zastanowienie się i zadawanie lepszych pytań. Jeszcze taka jedna rzecz, którą odkryliśmy, to pisanie i radość z pisania. Takie bycie sam na sam ze swoimi myślami, tekstem i przekazanie swoich myśli w jasny sposób, na przykład usuwanie niepotrzebnych słów, myślenie o tym dokładnie, co ja mówię, bo ktoś, kto będzie czytał i poświęci swój czas na to, żeby przeczytać to, co ja tam napisałam, to sprawia, że dziesięć razy myślę o tym, co ja robię i co mówię, że ktoś może wziąć tą opinię i na jej podstawie podjąć jakąś decyzję. To w sumie takie narzędzie, bym powiedziała, no pisanie takie typowo analogowe wręcz jako aktywność. Ja myślę, że można to też tak trochę skomentować, że to jest świetne narzędzie dla tej firmy, która to produkuje, narzędzie marketingowe i dojechanie zauważyłaś taki czas, który pozwala firmie przemyśleć to, co robi i gdzie jesteśmy pod względem technologii na rynku w którym momencie, ale użyteczność tak dla tych, którzy to czytają, moim zdaniem, no trzeba się zastanowić. I tutaj się odwołam do Simona Wordleya, który podawał przykład w książce, że jeżeli mamy magazyn dla generałów i w tym magazynie jest napisane, że 8 na 10 generałów bombarduje wzgórza, to nie znaczy, że ja jako generał też muszę bombardować wzgórza. I to trochę tak o tych różnych technologiach, po których przechodziliśmy, to tak znaczy, no jeżeli oni używają Kubernetesa, to znaczy, że dla ciebie, jeżeli jesteś CEO jakiejś firmy, Kubernetes jest czymś, w co musisz teraz wchodzić. Cloud Events, tak, to jest coś, co jest w ogóle fajne, ale tylko wtedy, kiedy używasz multi-clouda i to jest w ogóle znowu dyskusja, która się nigdy nie skończy, więc jej może nie otwierajmy, ale trzeba po prostu mieć pewien dystans do tego i też wziąć pod uwagę, że to jest dla nich przede wszystkim narzędzie marketingowe, moim zdaniem, i coś, co zaoszczędza też czas, żeby jakby mieć jedną wizję tym samym frontem do wszystkich klientów, bo ludzie na pewno ich zadają wiele pytań na zasadzie, co teraz powinniśmy wejść, z czego wyjść. No to proszę, tu jest raport i tak... Tak, to taka roadmapa, zdecydowanie, czy narzędzie marketingowe też, ale dla nas przede wszystkim roadmapa i musi być czytana w kontekście, tak samo raport ThoughtWorks musi być czytany w kontekście, trzeba pamiętać, że oni są dużą firmą międzynarodową, no i nie możemy sobie wszystkiego od nich wziąć, nie wiem, będąc małą firmą działającą na przykład na rynku polskim, w jakimś tam, w jakimś sektorze, to my teraz weźmiemy to, skopiujemy, tak jak mówisz, dobrze, dobra, to dawajcie tego Kubernetesa, bierzemy, robimy, bo to może nie być dobry kierunek. Bierzemy, robimy Kubernetesa, to zawsze jest przepis na sukces. Myślę, że to, co Paweł powiedział i Ania na koniec, to jest dobre podsumowanie całości. My też podobne opinie wyraziliśmy kiedyś tutaj na Coffee, mieliśmy taki odcinek to czyta z nią, po co czyta raporty i tak dalej. Trzeba pamiętać także dla ThoughtWorks, to jest narzędzie marketingowe i sprzedażowe. Nawet nie, że oni sprzedają tę technologię, ale sprzedają siebie jako tych, którzy myślą. Także ja w ogóle z tym dziękuję Wam za odcinek, bo już będziemy kończyć, bo była dobra dyskusja. Jestem trochę zdziwiony, jak dużo osób zdążyło to przeczytać i mieć jakieś przemyślenia. Więc co? Ten odcinek pewnie szybciej wypuścimy na podcastie, żeby był aktualny. Pogoda się poprawia. Życzę miłego weekendu wszystkim. Dzięki. Dzięki bardzo za dyskusję. Trzymajcie się, hej, cześć.