# Jak zbudować prostą integrację Telegrama z Codexem i w końcu pogadać z kodem jak z człowiekiem

Są takie projekty, które nie zaczynają się od architektury, diagramów i wielkich ambicji. Zaczynają się od bardzo prostego pytania: czy da się odezwać do własnego środowiska programistycznego z telefonu, tak samo naturalnie, jak pisze się do znajomego na Telegramie?

Właśnie od tego zaczęła się ta historia. Nie od "budujemy platformę AI", tylko od myśli: fajnie byłoby wysłać krótką wiadomość, dostać sensowną odpowiedź z Codexa i nie otwierać laptopa tylko po to, żeby sprawdzić jeden pomysł, uruchomić jedną komendę albo poprosić o małą zmianę.

Brzmi jak drobiazg, ale w praktyce to zmienia sposób pracy. AI przestaje być osobnym narzędziem w przeglądarce, a zaczyna być czymś bliższym osobistemu interfejsowi do kodu.

Od pomysłu do pierwszego "to działa"

Pierwsza decyzja była zaskakująco ważna: żadnej wielkiej infrastruktury. Żadnego stawiania serwerów, żadnych webhooków, żadnej chmury "na później". Tylko mały lokalny most uruchomiony na laptopie, który:

odbiera wiadomości z Telegrama,
przekazuje je do lokalnego codex CLI,
i odsyła odpowiedź z powrotem do czatu.

To podejście ma w sobie coś odświeżającego. Zamiast od razu projektować system dla miliona użytkowników, budujesz narzędzie, które ma działać dla jednej osoby, dziś, wieczorem, bez zbędnego teatru.

Pierwszy mały sukces wyglądał mało spektakularnie. Nie było tam żadnego wielkiego "wow". Był za to taki log:

python3 -m bridge.main doctor
doctor: ok

Tyle. Dwie linijki. A jednak właśnie wtedy projekt przestał być pomysłem i stał się czymś namacalnym.

Telegram okazał się prostszy niż pamięć rozmowy

Samo odebranie wiadomości z Telegrama nie jest najciekawszą częścią tej historii. Bot może odczytać wiadomość, bot może odpisać. To jest jeszcze etap "echo, ale z ambicjami".

Prawdziwy problem pojawia się chwilę później: jak sprawić, żeby druga wiadomość była ciągiem dalszym pierwszej?

Bo jeśli użytkownik napisze:

"Przejrzyj ten plik"

a chwilę później:

"Dobra, to teraz zrób to samo, ale bez zmiany nazw zmiennych"

to nie chcemy za każdym razem zaczynać rozmowy od zera. I właśnie tu pojawia się najcenniejszy element całej integracji: trwały wątek przypisany do konkretnego czatu.

W praktyce wygląda to bardzo zwyczajnie. Telegram ma swój prywatny czat, a po drugiej stronie ten czat dostaje jeden utrzymywany kontekst w Codexie. Nie trzeba o tym myśleć. Po prostu piszesz dalej.

To był moment, w którym ten projekt zaczął przypominać rozmowę, a nie serię pojedynczych zapytań.

Z notatek z budowy:

thread.started
...
codex exec resume <thread_id>

Właśnie ten fragment robi największą różnicę. Nie "AI na Telegramie", tylko "AI, które pamięta, o czym przed chwilą rozmawialiśmy".

Najbardziej dorosła część projektu? Nie funkcje, tylko hamulce

Przy takich integracjach łatwo zachłysnąć się możliwościami. Skoro Telegram potrafi wysłać tekst do Codexa, to od razu można by przecież pozwolić na edycję plików, odpalanie poleceń, przełączanie projektów, może jeszcze kilka skrótów administracyjnych.

I właśnie tutaj najłatwiej popełnić błąd.

Najrozsądniejsza decyzja w tym projekcie brzmiała: domyślnie wszystko działa w trybie tylko do odczytu.

To świetny przykład czegoś, co dobrze brzmi dopiero po czasie. Na początku wydaje się ograniczeniem. Po chwili staje się dowodem, że ktoś myślał nie tylko o tym, co da się zrobić, ale też co może pójść źle.

W tej integracji zapis do workspace'u nie dzieje się "przy okazji". Trzeba go świadomie odblokować, a potem jeszcze jednorazowo zatwierdzić. Taki rytuał może nie brzmi efektownie, ale bardzo dobrze ustawia relację z narzędziem: najpierw zaufanie, potem uprawnienia.

W logice projektu wyglądało to mniej więcej tak:

/mode write
/approve once

Niby detal. W praktyce różnica między wygodnym narzędziem a proszeniem się o kłopoty.

Najciekawsze odkrycie: cały "produkt" mieści się w kilku prostych zasadach

Im dłużej patrzyłem na tę integrację, tym bardziej było widać, że jej siła nie bierze się z rozbudowania. Wręcz przeciwnie. Ten pomysł da się streścić w kilku prostych zasadach:

piszesz do bota na Telegramie,
wiadomość trafia do lokalnego Codexa,
odpowiedź wraca do tego samego czatu,
rozmowa zachowuje kontekst,
a system domyślnie nie robi nic ryzykownego.

To wszystko.

Nie trzeba wielkiej platformy orchestration-first. Nie trzeba panelu administracyjnego. Nie trzeba nawet przesadnie skomplikowanego UI, bo UI już istnieje i nazywa się Telegram.

To chyba najbardziej niedoceniany wzorzec w budowaniu narzędzi AI: nie budować nowego okna, jeśli użytkownik i tak żyje w kilku istniejących.

Co jest naprawdę potrzebne, żeby zrobić taki most?

Jeśli chcesz zbudować podobną wersję u siebie, lista startowa jest krótsza, niż można się spodziewać:

bot token z Telegrama,
lokalnie działający codex CLI,
jeden katalog z kodem, od którego chcesz zacząć,
mały proces pośredniczący, który czyta wiadomości i uruchamia Codexa,
odrobina pamięci stanu, żeby nie zgubić kontekstu rozmowy.

W praktyce to bardziej projekt z kategorii "porządne sklejenie kilku prostych elementów" niż "wymyślanie nowej technologii".

I może właśnie dlatego jest ciekawy.

Bo kiedy opadnie marketingowy kurz wokół AI, bardzo dużo wartości zostanie zbudowane dokładnie tak: przez małe, lokalne, dobrze przemyślane integracje, które skracają dystans między człowiekiem a jego narzędziem.

Mój ulubiony moment: kiedy bot przestaje być botem

Jest taki moment w podobnych projektach, który trudno pokazać na screenie, ale łatwo rozpoznać. To chwila, w której przestajesz myśleć: "piszę do bota", a zaczynasz myśleć: "odzywam się do swojego środowiska pracy".

Pytasz o plik. Prosisz o zmianę. Resetujesz sesję. Przełączasz projekt. Wracasz do rozmowy kilka minut później i wszystko nadal ma sens.

Nagle okazuje się, że nie zbudowałeś "chatbota". Zbudowałeś bardzo cienką warstwę interfejsu nad czymś, czego i tak już używasz.

To dlatego podoba mi się prostota tego podejścia. Telegram nie udaje IDE. Codex nie udaje komunikatora. A most między nimi robi tylko to, co powinien: łączy dwa światy bez zbędnego hałasu.

Jeden z bardziej ludzkich komunikatów w tym projekcie brzmi:

Session reset. Your next message will start a fresh Codex thread.

To tylko techniczny detal, ale dobrze oddaje filozofię całości. Rozmowa ma swoją pamięć, ale pamięć jest pod kontrolą. Możesz zacząć od nowa, kiedy chcesz.

Jeśli chcesz zbudować własną wersję, zacznij skromnie

Najgorsze, co można zrobić na starcie, to próbować zbudować "pełną platformę AI do zarządzania developmentem przez komunikator". To brzmi jak prezentacja dla inwestora, a nie jak projekt, który realnie da się skończyć.

Dużo lepiej zrobić to etapami:

Niech bot po prostu odbiera wiadomości i odpisuje.
Potem dodaj pamięć jednej sesji na czat.
Na końcu dołóż zabezpieczenia, tryby pracy i drobne wygody.

Ta kolejność nie jest przypadkowa. Najpierw trzeba poczuć przepływ. Potem zadbać o ciągłość rozmowy. Dopiero później dokręcać śruby.

To zresztą dobra lekcja nie tylko dla tego projektu. Wiele rzeczy w AI psuje się dlatego, że chcemy zbyt szybko budować "mądre" systemy, zanim zbudujemy systemy przewidywalne.

Na koniec

Najbardziej lubię w tej historii to, że nie ma w niej nic magicznego. Jest telefon, jest Telegram, jest lokalny Codex i jest cienki kawałek kodu pomiędzy nimi.

A jednak efekt końcowy potrafi zmienić sposób pracy. Nie dlatego, że dodaje setki funkcji, ale dlatego, że usuwa kilka niepotrzebnych kroków między pomysłem a działaniem.

Jeśli miałbym streścić sens takiej integracji w jednym zdaniu, powiedziałbym tak: to nie jest projekt o botach. To projekt o skracaniu drogi do własnego narzędzia.

I właśnie dlatego warto go zbudować.