Jestem jedną osobą, a prowadzę siedem projektów. W pewnym momencie przestało chodzić o to, żeby pisać szybciej — zaczęło chodzić o to, żeby mieć zespół, którego nie mam budżetu zatrudnić. Dlatego buduję bota, który ma być moją prawą ręką: mózgiem firmy, z którym rozmawiam na Discordzie.
To wczesny etap. Pokażę uczciwie, co już działa, a co jest jeszcze planem.
Po co jednej osobie „zespół”
Kiedy budujesz sam, wąskim gardłem nie jest pisanie kodu. Jest nim wszystko dookoła: pilnowanie decyzji, przygotowanie treści, ogarnianie operacji, łączenie wątków z siedmiu projektów. To praca, którą w normalnej firmie robi kilka osób.
Nie chcę „asystenta AI” w sensie okienka czatu, do którego wklejam pytania. Chcę czegoś, co żyje w moim środowisku pracy (Discord, bo i tak tam jestem), zna kontekst firmy i potrafi sięgnąć do narzędzi — wiki, repozytoriów, danych.
W docelowej wizji to nie jeden asystent, tylko kilka „person” o różnych rolach — coś jak wirtualny zespół DRI (od directly responsible individual): jedna pilnuje launchu, inna treści, inna operacji. Każda z własnym zakresem i własnymi narzędziami. Tu jestem na początku tej drogi — na razie buduję fundament, na którym te persony staną.
Najważniejsza decyzja: mózg nie zna Discorda
Najłatwiej byłoby napisać „bota discordowego”. Świadomie tego nie zrobiłem.
Rdzeń — router, pamięć, warstwa bezpieczeństwa, dostęp do narzędzi — nie wie, że istnieje Discord. Discord jest tylko jednym z wymiennych adapterów komunikacji. Cała wiedza o tym, jak rozmawiać z Discordem, siedzi w osobnej, cienkiej warstwie.
Dlaczego to ważne? Bo nie chcę być uwiązany do jednej platformy. Jeśli za pół roku okaże się, że lepszy jest Slack, własny panel webowy albo zwykłe CLI — wymieniam adapter, a mózg zostaje nietknięty. To różnica między „mam bota na Discordzie” a „mam system, który dziś akurat mówi przez Discord”.
Bezpieczeństwo, zanim cokolwiek innego
Jedną z pierwszych rzeczy, jakie zbudowałem, nie jest żadna „fajna” funkcja. To filtr danych osobowych. Zanim cokolwiek trafi do modelu AI, przechodzi przez warstwę, która usuwa albo maskuje dane wrażliwe. To samo podejście co w całym juz-ide.pl: prywatność nie jest dodatkiem, jest warunkiem.
Do tego dziennik audytu (co bot zrobił i dlaczego) oraz liczenie kosztów każdego zapytania do AI. Bo „zespół AI” bez kontroli kosztów to świetny sposób, żeby obudzić się z rachunkiem nie do obrony.
Dokąd to zmierza
Następne kroki to: pierwsza persona z prawdziwym zakresem obowiązków, dostęp do narzędzi (wiki, repozytoria) i pierwsza zamknięta pętla — czyli zadanie, które bot wykonuje od początku do końca bez mojego udziału, a ja tylko zatwierdzam wynik.
Cel nie jest taki, żeby AI zastąpiło ludzi. Dziś, póki jestem sam, bot pozwala mi robić to, co normalnie wymaga zespołu. Docelowo juz-ide ma być firmą z zespołem — i wtedy bot zostaje dźwignią dla tego zespołu, nie jego substytutem. I zawsze z granicą: gdzie AI kończy, a zaczyna się ludzka decyzja.
Architektura w skrócie
Bot to runtime złożony z dwóch agnostycznych warstw i wymiennych adapterów:
- Rdzeń (messaging-agnostic) — router intencji, pamięć (sesyjna + semantyczna), warstwa bezpieczeństwa (filtr PII, dziennik audytu, kill switch, uprawnienia), obserwowalność (śledzenie kosztów AI). Nigdy nie odwołuje się do konkretnej platformy czatu.
- Warstwa narzędzi (MCP) — osobne „serwery narzędzi”, przez które model może działać: zapis do wiki, operacje na repozytoriach, odczyt danych analitycznych (osobny użytkownik bazy tylko do odczytu).
- Adaptery klienta — Discord na start (wymienny na Slack/CLI/web). Adapter tłumaczy zdarzenia platformy na język rdzenia i z powrotem.
Stack: TypeScript + Node, PostgreSQL (z migracjami przez Kysely). Wymiana Discord → inny komunikator to przepisanie tylko warstwy adaptera — rdzeń i narzędzia zostają bez zmian.