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,

Stworzyliśmy taki wynalazek, że wtedy to się dało, więc stwierdziliśmy, może zrobić z tego, żeby to działało na jakikolwiek przypadek i może będzie na to rynek. No i zrobiliśmy tak, jak każdy język programowania w czymś się uruchamia, prawda? Java się uruchamia w JVM-ie, .NET w CLR-ze, Python w Pythonie, czy tam Perl w Strawberry Perlu, JavaScripta w Node'zie. To te runtime'y stwierdziliśmy, że można by je w jednym procesie połączyć razem i sprawić, że jakby Java może używać rzeczy napisane w .NET-cie, jakby był to jeden język. No i jak to stworzyliśmy, okazało się dość szybko, że to jednak ma amatorów i nagle momentalnie mieliśmy klienta Amerykański Bank, Premier Bank, firmy logistyczne IQVIA, Total Energies, dużą firmę ubezpieczeniową z południowej Afryki, no w zasadzie bardzo dużo takich wielkich enterprise'owych klientów. Jakby na tamten moment, no oczywiście to była taka eureka, że w ogóle to jest możliwe i klient od razu po prostu bardzo tego chciał.

Dlatego ciągle to było to samo podejście, które poszło tą dziwną ścieżką z boku, która sprawiała, że zamiast... Normalnie mam publiczną metodę, to znaczy ją wołam, Trzeba było robić całą stertę różnych dziwnych rzeczy, tylko innych dziwnych. Jak nie Jasona, to Idela, jak nie Idela, to OpenAPI albo coś takiego. I my mówimy, jak sprawić, że skoro runtime bridging pozwalał naszym klientom od lat, i to działa na produkcji, miliony wywołań każdego dnia, w prawdziwych naprawdę business critical systemach, bo te firmy kupiły to do najbardziej kluczowych ich rozwiązań na świecie, bo nie było alternatywy, więc byli gotowi pójść w małą polską firmę na dependencję. Tam się da wołać metody bezpośrednio, co prawda trzeba by się miesiąc uczyć, jak to zrobić, no bo mówimy jak to opakować, żeby w każdym scenariuszu integracja programowania, czyli IoT, mobile, przeglądarka do chmury, w chmurze między serwisami, chmura do chmury przez publiczne API, czy w serwisie wewnątrz, czy teraz dzisiaj najnowszy trend, chmura do AI, bo dzisiaj LLM chce pytać nasze API.

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.

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.