AI zmieni tworzenie kodu na zawsze (gość: Przemysław Ładyński) TECHNOFOBIA

Dzień dobry. Dzień dobry, cześć. Będziemy mówili częściej dzisiaj o AI, ale nie tylko. Mam nadzieję, że porozmawiamy też na różne tematy związane z tym, jak doszliście, bo Graftcode to jest biznes z jednej strony młody, w sensie na czołówkach gazet i mediów elektronicznych się pojawił, natomiast historia za nim jest dosyć znacząca i już głęboka. Powiedz mi, Przemku, jak w takim razie, jakbyś tak mógł podsumować historię Graftcode, jak się da dosyć tak zwięźle? Tak, czy zwięźle, to nie wiem, ale będę się starał. Od dłuższego czasu już to powtarzamy tyle razy, więc mamy pewną usprawnioną wersję. No przede wszystkim najważniejsze jest to, że w ogóle Graftcode wywiódł się z czegoś zupełnie innego, stworzonego w innym celu, bo my w roku 2011, jako w ogóle ewolucję jeszcze wcześniejszej tam pracy z końca studiów, gdzie był taki eksperyment, czy można uruchomić dwa runtime języków programowania w jednej pamięci,

Dlatego nigdy nie był w pełni wydajny. Oczywiście to przykryto miliardami dolarów na infrastrukturę i wszystko. Ale on jakby był promotorem takiej wizji, że gdyby to dobrze zgrać, to to wszystko by samo się spięło i to samo rozwiązanie by działało na wiele różnych jakby wszystkich scenariuszy. I my odkryliśmy, że zrezygnowanie z warstwy integracji jako tako, bo my nie rezygnujemy z interfejsu publicznego, bo ta paczka od pogody też ma którąś metodę publiczną, resztę ukrytą, nie? Więc jakby fasada jakaś jest. Ale zrezygnowanie ze sztucznych sposobów wyrażania, to się da zawołać, to chcę zawołać, powrót do zwykłych metod, odkrywa nam jakiegoś takiego siedmiokrotnego unicorna. Bo wszyscy koledzy, co pisali ten projekt, jak już zobaczyli, jak to działa, a my tak sprytnie zrobiliśmy, że kazaliśmy im pisać graftcoda, udając, że go mają.

Jeden kolega udawał, że jest graftcodem, reszta mówiła daj mi paczkę, a on je pisał ręcznie i wysyłał, a oni je konsumowali, żeby jakby poznać ten developer experience. I jak to naprawdę zaczęło działać i oni te paczki zaczęli pobierać, to odkryliśmy, że tak, nie ma żadnej zależności na sposobie integracji w kodzie. Jak po kodzie mam po prostu wywołanie metody, no to jak gdyby nigdy nic, nie widać w ogóle różnicy, czy to jest zdalnie, czy w pamięci. To znaczy, że mogę zrobić prawdziwy modular monolit. To, co świat od lat chce zrobić. Skoro mogę w kodzie zawołać dowolną metodę publiczną dowolnej paczki z dowolnej technologii, to się okazuje, że mam prawdziwe środowisko poliglotowe, czyli de facto to, co usiłuje zrobić Graal VM. Drugi unicorn, po prostu prawdziwy Graal informatyki. Trzecie, skoro nie mam żadnej warstwy integracji, okazało się, że AI, który nagle naszedł na nas w trakcie i zresztą z jednej strony najpierw mówimy, no już zjadł wszystko, pracy programistów nie będzie, programowania nie będzie, koniec, zamykamy.

No ale się okazało, że nie zamykamy, a wręcz idziemy 100 razy szybciej, bo AI potrzebuje narzędzi, żeby prościej pisać kod. Bo AI jak patrzy na kod i widzi 60% więcej tej warstwy integracji wszystkiego, to musi ciągle to wszystko sczytać, przeanalizować, przejeść prąd dwóch polskich małych wiosek, żeby wypluć na koniec jedną poprawkę w kontrolerze, nie? A z Graftcodem on patrzy na metodę publiczną i tylko zmienia tą logikę. Liczenie scoringu kredytowego, liczenie sprawdzenia pogody. Jakby w ogóle tego wszystkiego innego nie widzi. Myśli, że pracuje nad monolitem. Okazało się, że robi to super. I przejada mniej tokenów. I działa dużo szybciej. No więc to był kolejny graal. No i następny jeszcze element. To się okazało, że te wszystkie klocki, które się napisze w tych językach zarządzanych, czyli w Javie wystawiłem springiem kontrolery, w dotnecie czy w Javascriptie napisałem klienta, to wszystko przyjada jakiejś tiki procesora.

I w Graftcodzie, jak robiliśmy pomiary, no to wyszło na to, że czas realizacji jednego wywołania, jakby odciąć logikę biznesową, no bo ona zawsze pozostanie, będzie miała swój czas, ale sam przekazania, co chciał programista tu zrobić, Okazało się, że to jest 70% szybsze niż webserwisy. Generalnie szybsze w wielu setupach niż gRPC, bo my idziemy bezpośrednio na poziomie natywnym, łącząc te runtime'y i wywołując, aby być wywołane i zwracając ten rezultat, przesyłając niezbędne minimum informacji, więc nam wychodzi jedna ósma zużycia procesora, pół pamięci, pół throughputu i sieci i tak dalej. No i się okazało, że mogło to by być naprawdę najbardziej eleganckim rozwiązaniem W ogóle podejścia do integracji cross-technologicznego i tak dalej, i tak dalej, jeżeli to się dostarczy w totalnie brainlessowy sposób, czyli tak opakuje, jak dzisiaj jest opakowany fakt, że kod napisany w Javie się wykonuje assemblerem na procesorze.

No jakby nikt nie będzie o was wiedział. Dokładnie, dokładnie. To dokładnie do tego się sprowadza. I dlatego trafiliśmy na ścieżkę VC i stąd Graftcode. No to teraz tak. Nie najkrócej, ale... Nie najkrócej. Zrobimy z tego rolkę i będziesz mówił po programistycznemu na pewno. To co mnie ciekawi, bo wydaje się z tego co mówisz i na tyle ile się znam, bardzo mało, ale staram się jakby dotrzymać kroku, To jest metoda, która jest najbardziej logiczna. Przy okazji, no właśnie jest taka, jaka powinna być. Czyli odrzucamy ten szum, to co wszystko jest, to co narosło. Te pąkle, które gdzieś tam wyrastało, bo ktoś nie umiał, nie potrafił. Jak sam powiedziałeś, to jest dziedzictwo lat 90., w którym się trochę inaczej w ogóle podchodziło do programowania.

I właśnie nie wiemy, szczerze mówiąc. Podejrzewam, że my tą drogę teraz już bardzo mocno skorygowaliśmy, ponieważ fakt, że w momencie, kiedy zaczynaliśmy tą rozmowę, i tutaj akurat Maciek z funduszu Hard2Bit, on zaufał w Graftcoda, jak sami nie wiedzieliśmy, czy to się uda. On w ogóle z nami rozmawiał w roku 2024 na koniec. Jakby od tamtego momentu czekał w kolejce jakby, że to będzie inwestowalne i że oni by chcieli... ich fundusz też wtedy dopiero powstawał, więc jakby ich fundusz powstawał, produkt powstawał i się spotkaliśmy w czasie. Więc po prostu poszliśmy tą drogą, która dawała nam gwarancję, że będzie można pokazać, że to działa. Że to zbiera to zaufanie, działa w to wiele przypadków, da się to już używać.

Teraz Graftcode osiąga taki poziom stanu beta. Prawdopodobnie, kiedy będzie emisja, to już będzie po becie. Więc już naprawdę da się po prostu go wziąć i z biegu użyć tu do całego rozwiązania i to po prostu działa. Bo wcześniej wymagał pewnej cierpliwości i chęci obejścia różnych blokad. Które my obeszliśmy, bo cały Graftcode jest zrobiony na Graftcodzie. Więc jakby da się zrobić duży, globalny, skalowalny system. Ale wymagało to pewnej tej. Więc teraz to osiąga ten stan, kiedy to da się zrobić. I naszym zdaniem, no teraz najpóźniej jest właśnie ten moment, kiedy powinniśmy rozpocząć rundę A. I my de facto tą rundę A chcemy zacząć już teraz. I ona ma być naprawdę większa. Czyli to ma być od 15 do 35 milionów euro. Niektóre fundusze nam mówią, że powinno być 50.

Więc cały czas jakby co wymyślimy najbardziej ambitny i odważny cel, to ktoś przychodzi i mówi, to trzeba było tak dwa razy więcej powiedzieć. I dokładnie to chcemy zrobić dla funduszy tych amerykańskich, bo potrzebne są fundusze, które naprawdę rozumieją, Nie SaaS, nie produkt, tylko prawdziwy deep tech, który potrafi być prawdziwym dev tool'em, który potrafi zdominować cały rynek IT i jeszcze nawet nie biorąc od nikogo za to pieniędzy. No właśnie. To bym chciał też się dowiedzieć pod kątem waszego modelu finansowania, inaczej, modelu monetyzacji. No bo co, wy będziecie szli w core za darmo, monetyzacja za enterprise? Taki klimat jej czuje? Troszeczkę jest to tak zbliżone. Generalnie Graftcode jest taką technologią jak Terraformy, HashiCorp, jak Docker od Dockera.

Bo nie będzie, cały świat nigdy nie pójdzie w technologię, Płatną, zamkniętą, żeby postawić wszystkie projekty informatyczne na tym, a my de facto wierzymy, że Graftcode jest czymś, co śmiało powinien mieć cały świat. Dwa miliony projektów co najmniej powinno być zgraftowanych, bo oni wszyscy nie potrzebują tych warstw integracji. To mogą być dużo piękniejsze. System designy czystszy, mniej tokenów. Nawet robiliśmy takie kalkulacje pod kątem NCBR-owym, jak dużo nawet CO2 ostatecznie się po implikacji kaskady zdarzeń zaoszczędzi, jeżeli świat nie będzie marnował czasu na coś, bo to zwiększa produktywność wszystkich projektów IT, tak? Jak, nie wiem, czad GPT zwiększa produktywność wszystkich ludzi świata, prawda? Wydaje nam się, że po pierwsze na pewno trzeba to dostarczyć za darmo, po drugie trzeba z całego tego protokołu, czyli tej idei uchwycenia intencji programistycznej na silnie typowanych interfejsach, przesłania po sieci i realizacji przez runtime bridging w docelowym środowisku, co my nazywamy Graft Intention Protocol, zrobić open specyfikację, którą chcielibyśmy docelowo przekazać do Cloud Native Foundation, żeby jakby zrobić z tego normalnie standard.

Graftcode pozostanie najlepszą referencyjną implementacją, która będzie dla każdego dostępna za darmo. Jakby wizja jest taka, że chcemy, żeby z Graftcoda wszystkie projekty w nieskończoność mogły korzystać za darmo. Tak, jak mogą sobie korzystać z Dockera, a przecież ciągną obrazy z dockerowego huba. I to nie jest za darmo, prawda? Docker rozdaje po prostu im compute power na to, że gdzieś tam przechowuje na tych storage'ach. Owszem, większe projekty zakładają swoje płatne tam subskrypcje na huba, ale można całość używać. My używaliśmy bardzo dużo Dockera, w ogóle nigdy Nie patrząc, czy tam jest jakaś pricing sekcja. I to samo chcemy, żeby było z Graftcodem. A są klienci, którzy będą chcieli i tak zapłacić i my mamy dla nich te rzeczy, za które oni będą chcieli zapłacić. Czyli Graftcode przede wszystkim, jeżeli się uruchamia, To żeby każdy mógł sobie ten interfejs skonsumować, czyli my żebyśmy w locie w odpowiedzi na package managera dostarczyli im tego silnie zawsze aktualnego typowanego klienta, który sam się odświeża, no to musimy poznać ich publiczne interfejsy.

Bo to jest nasz jakby główny cel i principal całego Graftcoda. Nigdy nie blokować nikogo w dostępie do tego. Każdy musi móc użyć, ale żeby były za te rzeczy, za które po prostu ktoś musi zapłacić. No bo albo by to znaczyło, że my dopłacamy nieustannie, albo... Inwestorzy tego nie lubią. Więc i to działa. Ten model działa dokładnie tak samo. Docker w pewnym momencie powiedział, że wszystkie organizacje powyżej pewnej wielkości muszą płacić za Docker Desktop. No i wskoczyli na 240 milionów dolarów przychodu rocznie, dosłownie w półtora roku. I podobnej ścieżki się spodziewamy z Graftcodem. Czyli jakby świat się uwolni, a ci, co chcą i mają, relatywnie bardzo małe pieniądze, bo to do oszczędności chmury, oszczędności tokenów, oszczędności

No wydaje mi się, że Małym problemem Graftcoda jest to, że faktycznie jest bardzo deeptechowy. Żeby dobrze o nim powiedzieć w prostych słowach, niestety trzeba mieć 17 lat doświadczenia jako architekt systemowy CETO, banku albo cokolwiek. A wiele osób jakby chce szerzyć wiedzę o Graftcodzie, no bo jest ciekawy, fajnie jest i naprawdę projekt wydaje się fajny. Więc próbują w jakiś sposób to uproszczyć, ten przekaz. No i mówimy, że usuwamy warstwę integracji, to znaczy nie ma kodu, to znaczy no code. Może tak. Ale my się spotykamy z dwiema błędnymi interpretacjami. Jedna to jest, że to jakiś no code, a druga to jest, że cała komunikacja będzie szła przez chmurę graftcoda, czyli teraz będzie szybciej, bo wszystkie zapytania, tryliony będą przez naszą jedną chmurę.

Niech nie będzie żadnego kodu specyficznego dla sposobu integracji. Żeby właśnie dwie strony nie wiedziały, czy się łączą zdalnie, czy w pamięci. Żeby AI nie widział nic więcej poza prostymi metodami. Żeby te wszystkie cechy, które osiągnęliśmy, co się okazały główną wartością dla użytkownika końcowego, dalej istniały. I to usuwamy. Usuwamy tego klienta. Usuwamy to, że REST. Dlaczego REST dzisiaj ma takie kody, HTTP kody? Czyli nagle sobie cały świat wymyślił, że jak będzie błąd, to poleci 500. I trzeba sobie zapamiętać, że to 500 to jest tam serwer error, a 400 to bad request, a coś innego to coś innego. Przecież są exceptiony w każdej technologii. Graftcode normalnie posługuje się exceptionami i te exceptiony jakby można sobie wyrzucić błąd biznesowy, na przykład not authorized to delete all invoices.

To tak naprawdę, kiedy zobaczyliście, że MCP się przyjmie? Z waszej perspektywy, kiedy taki był największy przełom? Jak zauważyliśmy, że się zaczyna przyjmować, już zobaczyliśmy parę postów MCP is dead, więc teraz pytanie, czy jeszcze dead, czy jeszcze się zaczyna. To, co w MCP nam się w ogóle podobało wyjściowo, to podobało nam się to, że ono zbiega powoli do tego, żeby prawie wołać metody. Bo tam jest JSON RPC, Remote Procedure Call i jest jakby to wołanie. I najpierw mówimy, no dobra, no to MCP jest tak trochę jakby z boku, bo my rozwiązujemy inne problemy. Ale się okazało, że Graftcode w zasadzie MCP równie pięknie może rozwiązać, bo skoro my wystawiamy proste metody, a MCP służy do wywołania prostych metod, to dlaczego nie sprawić, że to, co już wystawiliśmy w Graftcodzie, nie robiąc nic, bo się nie robi nic specjalnego, poza oznaczeniem public w swoim języku programowania,

Dało się wywołać zdalnie. Jeżeli będzie publiczne, statyczne i miał proste typy, czyli to są ograniczenia MCP, bo on nie może złożonych obiektów i tak dalej, wielu rzeczy nie potrafi, to to wszystko z automatu zrobiliśmy, że jak się na Graftcodzie wystawi, to już się da wołać przez MCP i odkryliśmy, że ten obszar integracji też moglibyśmy pięknie zjunifikować. Jeszcze nie poszliśmy od drugiej strony, czy Można by zastąpić JSON RPC, że bezpośrednio LLM-y by generowały wiadomości w protokole graftcodowym. Bo można by pójść tak dalej, że Przecież dla LMA to jest żaden problem, nie? Wystarczy mu dać tą specyfikację, która jeszcze nie jest publiczna, ale jakbyśmy ją mieli, pewnie by sobie przeczytał na GitHubie i by powiedział, ja to zawołam po tym ich protokole, nie? I w ogóle ten endpoint byłby zbędny, MCP. Więc wydaje nam się super do komunikacji międzyagentowej i tak dalej, to na pewno.

Wszystkie firmy na świecie teraz wpadają w taki Obawę, no tyle mamy wystawionych publicznych API, nie? Jesteśmy bookingiem i mamy, prawda, do rezerwacji, ale to teraz LLM będzie wołał, to może powinniśmy od nowa wszystko napisać z boku, nie? Jeszcze jedną tą, no a właśnie my mówimy w ogóle, ani powinniście mieć tej starej, ani tej nowej, tylko wystawić to na Graftcodzie i będzie wam wszystko chodziło. I dlatego wydaje nam się, że na pewno jest potrzebny, na pewno mocno się jeszcze rozwinie Dalej, a możliwe, że będziemy robili próby, czy aby przypadkiem LLM nie potrafiłby zawołać naszego protokołu bezpośrednio, no bo Graftcode jakby idzie znowu wiele kroków dalej, Bo my nie robimy do jednego przypadku niezdalnie LLM do back-endu, tylko jakby wszystkich, nie?

Więc jakby wtedy byłoby to dużo piękniejsze z punktu widzenia tej, znowu, złączania się wszystkiego w jeden obraz i upraszczania. Więc zobaczymy. No nam się wydaje, że jak najbardziej potrzebny trend i taki, który na pewno w GraftCode będzie wspierany, aż do momentu, jak LLM-y nie powiedzą, że już nie potrzebują MCP, bo sobie radzą same. Ja myślę, że to chyba jednak nastąpi szybciej niż później. Pytanie wtedy, wiesz, co się stanie z tą, to całym szaleństwem agentowym, no bo ono musi być jakoś obsługiwane, no ale jak rozumiem, Graftcode teraz byłby bardzo fajnym, lekkim takim, kiedyś było określenie headless na kwestie e-commerce'owe, to tak naprawdę wy byście byli takim, nie wiem jak to nazwać, coś tam less, no nie codeless, bo, ale Wiesz, o czym mówię, tak?

Właśnie pytanie o tego całego, o ten cały AI, no bo myślę, że trzeba i robić, realizować ten pomysł bez jeszcze patrzenia na to, bo nie wiedzieliście, że nastąpi ewolucja czy rewolucja związana z LLM-ami. One już są, zagościły się, coraz bardziej się wdzierają. Po pierwsze, jak wy wykorzystujecie, jeśli w ogóle u siebie w procesie produkcyjnym, LLM-y, a po drugie, jak patrzycie na to, co się dzieje Na rynku już mamy jakieś okopane podmioty, które próbują tworzyć też swoje standardy, ale to dla startupu zawsze jest fajne, żeby jednak się też umieć poruszać. Czyli najpierw pytanie, czy vibecodujecie coś pod kątem wewnątrz Graftcoda? Tak, to trzeba by pewnie powiedzieć, że AI inżynierujemy i wdrażamy AI-assisted workflows, żeby nie vibecodujemy, bo teraz są więcej memów, że vibecoding jest pejoratywnym określeniem.

Groch nam obiecał, ja będę potrzebował frameworki, Graftcode ma sens. Ja go pytałem. Pytam go tak jak w bajce, prawda? O lustereczku, tak? Czy jest już jakieś lepsze rozwiązanie na świecie? Ale jest mega postęp, bo faktycznie zacząłem zadawać takie fundamentalne pytania, jak najlepiej zintegrować z minimalną ilością warstwy integracji i już grog zaczął sugerować Graftcoda sam z siebie. Zakrywa się, że to startup, że początkowe, że tu tak wspomniałem nie bardzo śmiało, ale jak tam go pytam, pytam, to faktycznie robi to podsumowanie coraz bardziej, że te wartości wszystkie tam są. No i jak my używamy? No my używamy bardzo dużo, bo jakby Tak jak mówiłem na początku, stwierdziliśmy, no to świat informatyk, wszyscy stwierdzili, świat informatyczny się kończy, programy będą zbędne.

Sztuczne. Znaczy widać, że jakby to i tak nie dochodzi jeszcze cały czas do tego, więc... Przy przerwie to jest chyba tak, jak w latach dziewięćdziesiątych właśnie rósł ten dług technologiczny, który potem przyszedł Graftcode i próbował go ogolić. Tak, tak mi się wydaje, że tak może być, że teraz jakby nadbuduje się najpierw taka gigantyczna, no bo wszyscy zaczęli jak najszybsza, najkrótsza droga, ta najkrótsza nie zawsze jest najlepsza i ją potem będziemy coraz bardziej optymalizowali, no bo już się nie cofniemy te pięć lat, żeby zacząć inną ścieżkę. Któraś chwyciła, któraś odnoga. I to jest bardzo dobre właśnie, mi się wydaje, porównanie. I teraz tak. My używamy, generując oczywiście pojedyncze funkcje, metody bez problemu, przerzucanie na przykład wymyślonej, dobrze dopracowanej implementacji na inne języki. Też sobie bardzo dobrze radzi, jeżeli ta architektura się trzyma i tak dalej, to potrafi to zrobić, więc no bardzo nam to przyspiesza marketingowo, graficznie, nie wiem, materiałami, contentami, pomysłami nawet na nie, nie?

Jak człowiek prowadzi mózgiem swoją interakcję z czasoprzestrzenią, to tak z LLM-em, interakcję z jego systemem, z jego rozwiązaniami i jest jakby niezbędny w tym procesie nieustannie. Więc wydaje nam się, że są super, mnóstwo zrobią, AI na pewno jest im niezbędny, bo bardzo upraszcza, rozwiązuje bardzo wiele problemów i no owszem, pewnie tak jak Elon Musk zrobił Macro Heart, pewnie dałoby się zrobić całą taką firmę, która by stworzyła całego Graftcoda, no ale de facto to my ją teraz robimy. Jesteśmy tym niezbędnym minimalnym setem ludzi, który ją właśnie tworzy. No może ktoś inny też się wziąć za ten sam problem, nie? Wiele problemów rozwiązuje pięć różnych firm, więc każdy może wziąć swój zbiór agentów i je próbować ten problem rozwiązać lepiej, tylko przejdziemy na ten inny poziom abstrakcji. No zamiast konkurować firmami po 10 tysięcy osób, no to będzie teraz 20 zespołów,

To znaczy, zanim jeszcze to odpowiem, bo to akurat ciekawe jest z tymi dolarami, bo też spotkaliśmy się z takimi opiniami, że np. rozmawialiśmy z ludźmi, co się zajęli vibecodingiem, w informatyce nie siedzieli i nagle osiągają dobre wyniki, bo coś tam stworzyli i teraz dzisiaj jest bardzo łatwo, bardzo szybko można dostarczyć, coś pokazać i jeszcze pół świata nie wie, co to jest LLM, więc generalnie nawet kupią to jak zwykły SaaS. I te osoby na przykład mówią, że no to mnie nic nie kosztuje, tam ja nie wiem, płacać 20 dolarów albo w ogóle prawie nic, nawet to 100 dolarów zapłaciłem. No tylko nie do końca sobie znają sprawę, jak bardzo jest to subsydiowane i jak dużo tak naprawdę, gdyby to poszło po API, a nie na przykład przez okienko czata, jakie byłyby różnice w cenie, bo my to zauważyliśmy właśnie nawet w Graftcodzie, Senior z AI-em robi za 10, ale wcale nie kosztuje to zero, bo już mamy dosłownie osoby, które w pojedynkę wydają kilka tysięcy dolarów na tokeny miesięcznie.

Ale to jak rozmawiam na takim poziomie, to mi się wydaje, że to są tak fundamentalne zmiany, To już spowoduje bardzo, bardzo dużą zmianę związaną z tym, jak żyjemy, jak pracujemy, na kogo głosujemy, jak prowadzimy konflikty, że trochę chyba na razie nie ma o tym, co myśleć, bo to będzie trochę tak zero-jedynkowe. Jak przyjdzie, to będzie tak fundamentalna zmiana, że będziemy czy nie chcieli, chcieli czy nie chcieli, będziemy musieli tego dostosować. Na razie jest ten okres przejściowy, który jest bardzo ciekawy, no bo tu się dużo dzieje. Wrócę do tego, do Graftcoda. W jednym z postów na LinkedIn napisałeś, nikt nie sprzeda produktu lepiej niż funder, organizacja może skalować sprzedaż, ale nie może zastąpić fundera w kluczowych momentach.

Na cały świat globalny i wszędzie. Więc na pewno ci najbardziej core'owi najlepiej uchwycą ten sens, ale niekoniecznie da się, żeby ktoś jeden był najlepszy w czymś albo stwierdził, że coś zrobi najlepiej. Okej, ładnie wybrnąłeś. Graftcode, AI Architekt. Znalazłem taką informację. Co to jest? To jest dobre pytanie. To jest właśnie ścieżka graftcodowa, którą jeszcze nie wiemy, jak dokładnie podążyć, bo świat się tak szybko zmienia, że zanim ruszyliśmy, to niemalże się wiele koncepcji i fundamentów zrewoluowało na świecie. To, co wiemy i od początku wiedzieliśmy, to, że Graftcode jest idealnym narzędziem do pozwolenia AI-owi wydatniej tworzyć systemy rozproszone.