Mentionsy

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?

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,

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.

A z Graftcodem on patrzy na metodę publiczną i tylko zmienia tą logikę.

I dlatego trafiliśmy na ścieżkę VC i stąd Graftcode.

Teraz Graftcode osiąga taki poziom stanu beta.

Które my obeszliśmy, bo cały Graftcode jest zrobiony na Graftcodzie.

Generalnie Graftcode jest taką technologią jak Terraformy, HashiCorp, jak Docker od Dockera.

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.

Graftcode pozostanie najlepszą referencyjną implementacją, która będzie dla każdego dostępna za darmo.

I to samo chcemy, żeby było z Graftcodem.

Czyli Graftcode przede wszystkim, jeżeli się uruchamia,

I podobnej ścieżki się spodziewamy z Graftcodem.

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.

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,

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,

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.

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

Groch nam obiecał, ja będę potrzebował frameworki, Graftcode ma sens.

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ć.

Graftcode, AI Architekt.

To, co wiemy i od początku wiedzieliśmy, to, że Graftcode jest idealnym narzędziem do pozwolenia AI-owi wydatniej tworzyć systemy rozproszone.

Zgłosi się w Graftcodzie, no bo odpali się na Graftcode Gateway, więc wyśle do nas tą definicję publicznego interfejsu, więc od razu na mapie będzie widać, że ten serwis się uruchomił, stoi i ma taką metodę, możesz ją zobaczyć, możesz ją przetestować i możesz ją tym jednym package managerem już konsumować skądkolwiek chcesz.

Chcemy, żeby Graftcode stał się prawdziwym Robin Hoodem open source'a.