System Discord stworzony metodą vibe coding z AI - case study

DiscordOS - kiedy bot na Discorda przestał być botem

DiscordOS zaczął się dość niewinnie, jak większość takich projektów: „Przydałoby się, żeby bot robił X.”, potem dochodzi Y, potem automatyzacja Z, potem panel administracyjny, baza użytkowników, harmonogram,system eventów.

A któregoś dnia człowiek patrzy na projekt i orientuje się, że właściwie nie buduje już bota na Discorda. Buduje system operacyjny własnej społeczności.

Był to kolejny duży projekt, który rozwijałem metodą vibe codingu. Tyle że w przeciwieństwie do wcześniejszego LiveOS nie podchodziłem już do AI wyłącznie z ciekawością: „ciekawe, czy da się to zrobić?”, a coraz częściej zadawałem inne pytanie: „jak ten system powinien działać, żeby faktycznie rozwiązywał moje problemy?” To niewielka różnica w zdaniu, a ogromna w sposobie pracy.

Problem: Discord daje narzędzia. Ja potrzebowałem systemu.

Prowadzenie aktywnej społeczności na Discordzie wygląda zupełnie inaczej z perspektywy administratora niż użytkownika. Użytkownik widzi kanały, role, wiadomości, wydarzenia i innych ludzi.

Administrator widzi jeszcze: kto powinien dostać rolę, kiedy trzeba opublikować wiadomość, który Patron nadal wspiera społeczność, kto pojawił się pierwszy raz na voice, które automaty trzeba uruchomić, jak zebrać zgłoszenia, jak zarządzać aktywnością, jak nie robić pięćdziesięciu powtarzalnych rzeczy ręcznie. I właśnie te powtarzalne czynności zaczęły być fundamentem DiscordOS. Nie chciałem dokładać kolejnego bota z kilkoma komendami.

Chciałem stworzyć własne zaplecze administracyjne dla mojego serwera Discord. Jedno miejsce do zarządzania społecznością.

DiscordOS miał działać tylko dla mnie

To ważne założenie tego projektu. DiscordOS nie powstawał jako SaaS. Nie planowałem sprzedawać dostępu tysiącom administratorów ani budować uniwersalnego systemu obsługującego dowolny serwer. Projektowałem funkcje pod konkretną społeczność i konkretny sposób, w jaki nią zarządzam.

To dawało ogromną swobodę. Nie musiałem zastanawiać się: „czy przeciętny administrator Discorda tego potrzebuje?” Mogłem zapytać: “czy ja będę tego używać?” Jeżeli odpowiedź brzmiała „tak”, funkcja miała sens.

To jedna z rzeczy, które najbardziej lubię w vibe codingu. Można stworzyć oprogramowanie tak specyficzne, że prawdopodobnie żadnej firmie nie opłacałoby się go produkować.

A dla jednej osoby może być idealne.

Automatyzacje: KIEDY - JEŚLI - TO

Jednym z kierunków rozwoju DiscordOS były automatyzacje. Idea była bardzo prosta: KIEDY coś się wydarzy → JEŚLI spełnione są określone warunki → TO wykonaj akcję. Czyli mechanizm znany z narzędzi automatyzacyjnych, tylko działający bezpośrednio na potrzeby mojej społeczności.

Przykład? Kiedy użytkownik wykona określoną akcję, system może nadać rolę. Kiedy rozpoczyna się wydarzenie, może zostać wysłana odpowiednia wiadomość. Kiedy pojawia się określone zdarzenie na serwerze, DiscordOS może zareagować bez mojej ingerencji.

Zamiast implementować każdą taką sytuację jako osobną funkcję, zacząłem myśleć o systemie bardziej abstrakcyjnie: co jest wyzwalaczem, jaki jest warunek i jaka ma być reakcja? To był jeden z tych momentów, w których projekt przestawał być zbiorem ficzerów, a zaczynał być platformą.

Patronite - czyli funkcja, której naprawdę potrzebowałem

Dobrym przykładem projektowania DiscordOS pod realny problem była obsługa Patronite. Osoby wspierające społeczność powinny otrzymywać odpowiednie role na Discordzie. Brzmi banalnie, dopóki nie trzeba tego robić regularnie. DiscordOS dostał więc mechanizm importowania danych aktywnych Patronów z pliku CSV i dopasowywania ich do użytkowników Discorda.

Istotne było to, żeby system nie opierał całego mechanizmu na czymś tak kruchym jak aktualna nazwa użytkownika. Podstawą miało być możliwie trwałe powiązanie użytkownika.

Automatyczne wiadomości i harmonogram

Naturalnym elementem DiscordOS stało się planowanie komunikacji. Wiadomości mogły być przygotowane wcześniej i publikowane według określonego harmonogramu. W praktyce oznaczało to możliwość automatyzowania części rytmu społeczności: ogłoszeń, przypomnień, cyklicznych komunikatów.

Niewielka funkcja? Tak. Ale gdy takich czynności wykonuje się dziesiątki, własny scheduler zaczyna być jednym z bardziej praktycznych elementów całego systemu.

Wiadomości głosowe i audio

Eksperymentowałem również z wykorzystaniem audio. System miał możliwość publikowania przygotowanych wiadomości głosowych o określonych porach, a jednym z rozwijanych kierunków było także wykorzystanie Discordowego voice'a do bardziej radiowego sposobu działania.

Pojawił się więc pomysł radia działającego na kanale głosowym, korzystającego z zewnętrznych źródeł muzyki. I to bardzo dobrze pokazuje charakter całego projektu: DiscordOS nigdy nie miał jednej konkretnej funkcji. Był miejscem, do którego mogłem dobudowywać kolejne rzeczy, jeżeli pojawiała się potrzeba w społeczności.

Urodziny i Centrum społeczności

Z czasem coraz mocniej interesowała mnie nie tylko administracja, ale również to, czy system może pomagać ludziom lepiej się poznawać, stąd rozwój funkcji społecznościowych. Jednym z prostszych przykładów były urodziny.

Użytkownik mógł podać dzień i miesiąc urodzenia, opcjonalnie rok, a system mógł wykorzystać tę informację w funkcjach społecznościowych.

Gra o Melon urosła do systemu wewnątrz systemu

Jednym z największych modułów DiscordOS stała się Gra o Melon. I tutaj skala zrobiła się już naprawdę ciekawa. Nie chodziło wyłącznie o wysłanie pytania na kanał i sprawdzenie, kto pierwszy odpowie poprawnie.

System zaczął obejmować między innymi: biblioteki pytań, zestawy, harmonogram rund, sezony, punktację, rankingi, statystyki, historię rozgrywek oraz zaplecze pozwalające tym wszystkim zarządzać.

Czyli wewnątrz DiscordOS zaczęła właściwie powstawać druga aplikacja. Tylko że ściśle połączona ze społecznością. I to chyba najlepiej pokazuje, jak bardzo projekt oddalił się od początkowego „zróbmy bota”.

Największym problemem dużych projektów vibe codingowych jest… ich własny sukces

To brzmi trochę absurdalnie, ale jeżeli vibe coding działa, zaczynasz bardzo szybko dodawać kolejne rzeczy. Funkcja działa? Super. To jeszcze zróbmy drugą, i trzecią. Skoro mamy użytkowników, to dodajmy filtrowanie. Skoro mamy filtrowanie, to może centrum społeczności. Skoro mamy role, zautomatyzujmy Patronite. I tak dalej…

I po pewnym czasie aplikacja, która miała kilkanaście prostych funkcji, ma własne moduły, zależności, dane, konfigurację i panel administracyjny.

Wtedy zaczyna się etap, którego nie pokazują filmiki pod tytułem „I BUILT AN APP WITH AI IN 8 MINUTES”. Trzeba tym wszystkim zarządzać.

DiscordOS nauczył mnie myślenia modułami

Przy LiveOS uczyłem się głównie tego, jak w ogóle prowadzić większy projekt z AI. DiscordOS nauczył mnie czegoś następnego: nie budować wszystkiego jako jednej wielkiej aplikacyjnej masy, a podzielić aplikację na moduły. Każdy z nich ma własną odpowiedzialność, ale musi współpracować z resztą systemu. To podejście brzmi oczywiście dla programisty, ale dla osoby uczącej się budowania aplikacji poprzez vibe coding było kolejnym ważnym etapem.

Najciekawszym elementem DiscordOS nie jest technologia

Najciekawsze jest to, że projekt wyrósł z bardzo konkretnych zachowań jednej społeczności. Nie siedziałem przed pustą kartką, zastanawiając się: „jaką aplikację mógłbym stworzyć?” Miałem serwer, ludzi i problemy. Miałem rzeczy, które regularnie robiłem ręcznie.

I zacząłem je po kolei zamieniać w oprogramowanie. Dlatego DiscordOS jest dla mnie jednym z najlepszych przykładów tego, gdzie vibe coding ma naprawdę ogromny sens. Nie przy tworzeniu kolejnej aplikacji do robienia listy zakupów.

Tylko wtedy, kiedy możesz powiedzieć: „nikt nie stworzył dokładnie takiego narzędzia, jakiego potrzebuję, więc zbuduję je sobie sam.”

Jeszcze kilka lat temu oznaczałoby to znalezienie zespołu programistów, przygotowanie budżetu i prawdopodobnie rezygnację z połowy pomysłów jako ekonomicznie nieuzasadnionych.

Dzisiaj granica pomiędzy: „fajnie byłoby mieć takie narzędzie” a „dobra, spróbuję je zbudować” stała się znacznie mniejsza. DiscordOS jest dokładnie historią tego, co się dzieje, kiedy zaczyna się tę granicę regularnie przekraczać.

Bezpłatna konsultacja