Przygotowanie do hackathonu art-tech: niezbędnik

Format wywodzi się z pierwszego hackathonu z 1999 roku, zorganizowanego w Calgary przez społeczność OpenBSD, ale od tego czasu zdążył przejść sporą ewolucję: z czysto technicznych maratonów dla deweloperów przekształcił się w wydarzenia interdyscyplinarne, na których programiści spotykają się z artystami, designerami i twórcami kultury. Najczęstszy błąd uczestników to przyjście bez wcześniejszego przygotowania — bez skompletowanego zespołu, bez zainstalowanego oprogramowania, bez choćby zarysowanego problemu. W efekcie zamiast budować prototyp, walczą z narzędziami i szukają pomysłu w drugiej godzinie wydarzenia. Ten przewodnik zbiera konkretne elementy przygotowania — od składu zespołu, przez konfigurację środowiska, aż po ostatnie minuty przed wejściem na scenę.

Fundamenty zespołu: od programisty po artystę

W hackathonie art-tech prototyp, który ocenia jury, musi nie tylko działać, ale też coś znaczyć — estetycznie, narracyjnie, kulturowo. Zespół złożony z samych programistów, choćby najzdolniejszych, szybko utknie przy pytaniu „jak to pokazać?". Z drugiej strony grupa samych artystów bez osoby piszącej kod skończy z estetyczną makietą, której nie da się uruchomić. Dlatego dobrze złożony zespół łączy kompetencje, które się uzupełniają.

Sprawdzona struktura to od dwóch do pięciu osób. Mniej niż dwoje — brak krytycznej masy do podziału zadań, więcej niż pięć — narastają koszty koordynacji, które na hackathonie są zabójcze.

Role, które warto zamknąć w składzie

Nie każda z tych ról musi być obsadzona osobno. Na hackathonach z mniejszym budżetem często jedna osoba łączy np. projektowanie i copywriting. Liczy się to, żeby kluczowe kompetencje były pokryte — zwłaszcza kodowanie i warstwa wizualna.

Gdzie szukać współpracowników

Warto szukać ludzi przed rejestracją, a nie na miejscu. Najlepiej działają:

• Społeczności tematyczne — Slacki, Discordery, grupy na Facebooku poświęcone creative coding, grafice generatywnej, projektowaniu doświadczeń.
• Lokalne grupy meetupowe — w większości dużych polskich miast działają regularne spotkania związane z designem, UX, sztuką cyfrową i programowaniem.
• Uczelnie artystyczne i politechniki — najprostsze miejsce, żeby znaleźć osoby z konkretnym warsztatem i zapałem do projektów niestandardowych.
• Poprzednie edycje tego samego hackathonu — organizatorzy często publikują listy uczestników lub prowadzą kanały, na których można szukać partnerów.

Ważna zasada: nie dobieraj zespołu „na szybko" dzień przed wydarzeniem. Zespół, który nigdy wcześniej nie pracował razem, na hackathonie traci kilka godzin na synchronizację — a tych godzin nigdy nie ma w nadmiarze.

Cyfrowy warsztat: co zainstalować tydzień wcześniej

Przygotowanie środowiska pracy to jeden z najbardziej niedocenianych elementów hackathonu. Wielu uczestników zakłada, że organizatorzy zapewnią wszystko — w praktyce hackathony art-tech rzadko narzucają jeden stos technologiczny, a jeśli nawet podają wymagania, to zwykle w formie listy, którą trzeba samodzielnie zainstalować. Próba konfiguracji środowiska w piątek wieczorem, kilka godzin przed startem, to klasyczna receptura na katastrofę.

Minimalny zestaw narzędzi projektowych

Dla osób z mniejszym doświadczeniem technicznym najważniejsze są Figma i Miro — oba działają w przeglądarce, nie wymagają instalacji lokalnej i pozwalają zespołowi pracować równolegle z dowolnego miejsca.

Środowisko programistyczne

Dla programisty kluczowe jest, żeby na dzień przed hackathonem mieć działające lokalne środowisko: edytor kodu (VS Code jako najpopularniejszy wybór w społeczności creative coding), Node.js lub Python w aktualnej wersji, przeglądarkę z zainstalowanymi narzędziami deweloperskimi oraz dostęp do kont na platformach, z których będzie korzystał projekt — GitHub, Vercel, hosting modeli AI, jeśli są w planie.

Warto też wcześniej zainstalować biblioteki, które prawdopodobnie będą potrzebne:

• do interakcji webowych — p5.js, Three.js, React lub Vue.js (w zależności od skali projektu);
• do przetwarzania audio-wideo — Tone.js, ml5.js, TensorFlow.js;
• do komunikacji z API — gotowe pakiety HTTP w danym języku, frameworki testowe.

Nie chodzi o to, żeby znać każdą bibliotekę na pamięć — chodzi o to, żeby w sobotę rano nie spędzać dwóch godzin na rozwiązywaniu konfliktów zależności.

Logistyka: konta, loginy, dostępy

Brzmi banalnie, ale w praktyce ogromna część stresu pierwszych godzin hackathonu wynika z braku dostępu. Tydzień wcześniej warto sprawdzić:

• czy wszystkie klucze API (OpenAI, Stability, Hugging Face, Google Cloud) są aktywne i mają wystarczające limity;
• czy konta hostingowe (Vercel, Netlify, GitHub Pages) mają poprawną konfigurację domeny i nie wymagają dodatkowej weryfikacji;
• czy licencje na oprogramowanie (Figma, Adobe) są aktywne i nie wygasają w trakcie wydarzenia;
• czy zespół ma wspólny kanał komunikacji (Discord lub Slack), w którym będzie koordynował pracę.

Te pięć punktów wydaje się oczywistych, ale zaskakująco wiele zespołów traci godziny na ich ogarnianie w trakcie hackathonu.

Strategia pracy: od pomysłu do prototypu w 48 godzin

Większość uczestników przychodzi na hackathon art-tech bez sprecyzowanego problemu. To znaczy: wiedzą, że chcą „zrobić coś fajnego", ale nie wiedzą, dla kogo, po co i dlaczego akurat w ten sposób. Efekt jest taki, że zamiast budować prototyp, cały zespół spędza pierwsze osiem godzin na burzy mózgów, a potem pracuje w pośpiechu z pomysłem, który nie miał czasu się ustabilizować. To dokładnie odwrotna kolejność niż ta, która działa.

Wybierz problem przed wejściem na salę

Nie chodzi o to, żeby przyjść z gotowym rozwiązaniem — chodzi o to, żeby przyjść z wybranym obszarem problemowym, na którym zespół chce się skupić. Dwa–trzy konkretne pytania, które projekt ma odpowiedzieć, plus jedna osoba lub instytucja, dla której projekt ma wartość. Bez tego nawet najlepszy zespół dryfuje.

Pomocna technika: na tydzień przed hackathonem każdy członek zespołu przygotowuje krótką (jedno zdanie) odpowiedź na pytanie „co chcę zbadać albo zbudować?". Na spotkaniu przedstartowym te zdania skrzyżowane są w dwóch–trzech kierunkach tematycznych, z których wybierany jest ten najciekawszy dla całego zespołu.

Podział czasu i kamienie milowe

Hackathon trwa zwykle od 24 do 72 godzin. W każdym wariancie obowiązuje ta sama zasada: pierwsza trzecia czasu to planowanie, druga to budowa, trzecia to dopracowanie i przygotowanie prezentacji. Wielu uczestników popełnia błąd odwracając tę proporcję — zaczyna od kodowania i dochodzi do prezentacji w ostatnich godzinach, kiedy nie ma już czasu na polerowanie detali.

Przykładowy harmonogram dla 48-godzinnego hackathonu:

Proporcje te można przesuwać, ale sam podział na fazy powinien być egzekwowany jak w prawdziwym projekcie — z krótkimi codziennymi spotkaniami statusowymi (po 10–15 minut), na których zespół sprawdza, czy jest w dobrym miejscu względem planu.

Najczęstsze pułapki

W trakcie samej pracy najczęściej zespół wpada w trzy pułapki:

• Zakres-pułapka — zachęcony pomysłem zespół obiecuje sobie zbudować wszystko, co przychodzi do głowy. Efekt: na koniec weekendu prototyp nie działa w całości, a każda funkcja jest ledwie zarysowana. Lepsze podejście: jeden wyraźny rdzeń projektu plus dwie–trzy funkcje poboczne, które można wyciąć bez żalu.
• Perfekcjonizm wizualny — zespół spędza godziny nad detalami interfejsu, zanim prototyp zacznie działać. Estetyka jest ważna, ale najpierw musi być co pokazać.
• Brak komunikacji między rolami — programista buduje backend, designer czeka na podgląd, copywriter nie wie, jaki jest kierunek. Codzienne krótkie spotkania (nawet 10-minutowe) są skuteczniejszym rozwiązaniem niż próba koordynacji przez czat.

Najgorsze, co może przydarzyć się zespołowi na hackathonie, to ukończony prototyp, którego nikt w zespole nie potrafi opowiedzieć jurorom.

AI jako akcelerator: kiedy pomaga, kiedy przeszkadza

Narzędzia sztucznej inteligencji zmieniły obraz hackathonów art-tech w ciągu ostatnich kilku lat. To, co kiedyś wymagało wielu godzin kodowania albo współpracy z designerem, dziś może powstać w ułamku czasu — pod warunkiem, że zespół rozumie, do czego AI warto używać, a do czego nie.

Asystenci kodowania w praktyce

Narzędzia takie jak GitHub Copilot, Cursor czy ChatGPT w trybie programistycznym pozwalają osobom bez głębokiego tła technicznego szybko postawić szkielet aplikacji. Praktyka uczestników ostatnich edycji pokazuje, że praca nad szkieletem prototypu potrafi dzięki temu przyspieszyć kilkukrotnie — ale pod warunkiem, że zespół umie z tych narzędzi korzystać świadomie.

Dobrą praktyką jest:

• Generowanie szablonów — AI świetnie sprawdza się w tworzeniu bazowego kodu dla prostych funkcji (formularz, integracja z API, prosty efekt wizualny).
• Debugowanie — wklejenie komunikatu błędu i prośba o wyjaśnienie jest zwykle szybsze niż przeszukiwanie forów.
• Tłumaczenie koncepcji — „jak w p5.js narysować linię reagującą na dźwięk z mikrofonu" to pytanie, na które AI odpowie w kilka sekund.

Trzeba jednak pamiętać, że AI nie zwalnia z rozumienia kodu. Zespół, który wkleja wygenerowane fragmenty bez przeczytania, na etapie prezentacji końcowej nie potrafi odpowiedzieć na pytanie „dlaczego to działa" — a takie pytania się pojawiają.

Generowanie zasobów wizualnych i dźwiękowych

W projektach art-tech AI otworzyło też nowe możliwości po stronie wizualnej. Narzędzia do generowania obrazów (Midjourney, Stable Diffusion, Firefly) i dźwięku (Suno, Udio, modele open-source) pozwalają w ciągu godzin wyprodukować materiały, które jeszcze kilka lat temu wymagałyby studia i tygodni pracy.

Praktyczna rada: nie polegaj wyłącznie na generowaniu. Autorskie elementy — ręcznie narysowane grafiki, nagrane w terenie dźwięki, własne teksty — wyróżniają projekt w oczach jurorów, którzy widzieli już setki gotowych ilustracji z generatorów.

Granice, których nie warto przekraczać

AI nie zastępuje koncepcji. Na hackathonie art-tech wygrywają projekty, które mają wyraźny punkt widzenia — odpowiadają na konkretne pytanie kulturowe, adresują konkretną grupę odbiorców, opowiadają historię, której nie da się streścić w jednym zdaniu. Narzędzia AI pomagają to zrealizować szybciej, ale nie wymyślą tego za zespół.

Druga granica: licencja i prawa autorskie. Generowane materiały mają różne zasady użycia — warto sprawdzić warunki danej platformy, szczególnie jeśli projekt ma być później publikowany lub rozwijany poza hackathonem.

Pitch: jak zamknąć projekt w pięciu minutach

Finał hackathonu to moment, w którym jury widzi projekty przez kilka-kilkanaście minut łącznie. Na większości wydarzeń art-tech limit prezentacji wynosi około pięciu minut — wystarczająco dużo, żeby pokazać istotę projektu, ale zbyt mało, żeby opowiadać o wszystkim. Pitch, który nie jest przygotowany, zwykle kończy się albo chaotycznym wyliczaniem funkcji, albo zbyt długą historyjką o genezie pomysłu.

Struktura pięciominutowej prezentacji

Te proporcje działają, gdy demo jest sprawne. Jeśli prototyp zawiera elementy ryzykowne (np. zależy od zewnętrznego API, które akurat nie odpowiada), warto przygotować dwa warianty pitchu: jeden z demo na żywo, drugi z nagranym filmem. Na kilka minut przed wejściem na scenę zespół decyduje, który wariant wybrać — w zależności od tego, czy demo działa.

Demo czy makieta?

Pytanie, które pada w każdym zespole: czy prezentujemy działający prototyp, czy makietę? Na hackathonach art-tech odpowiedź brzmi: zawsze działający prototyp, nawet jeśli jest prosty. Jury potrafi rozpoznać projekt, który „tylko wygląda" — i choć estetyka jest ważna, to właśnie moment, w którym prototyp reaguje na ruch użytkownika, generuje obraz lub odtwarza dźwięk, decyduje o wrażeniu.

Jeśli prototyp jest na dany moment za prosty, żeby robić wrażenie, lepiej wyciąć zakres niż pokrywać braki makiety. Pięć minut czegoś, co działa, bije pięć minut czegoś, co wygląda.

Pytania od jury

Po prezentacji jury zwykle zadaje kilka pytań — technicznych (jak to działa?), koncepcyjnych (dlaczego tak, a nie inaczej?) i wdrożeniowych (kto mógłby z tego skorzystać?). Warto przygotować się do każdego z tych trzech typów:

• Pytania techniczne — czy każdy członek zespołu rozumie architekturę projektu na tyle, żeby ją wytłumaczyć w jednym zdaniu.
• Pytania koncepcyjne — czy istnieje jedna osoba, która potrafi opowiedzieć genezę i sens projektu w kilku zdaniach, bez wchodzenia w dygresje.
• Pytania wdrożeniowe — czy zespół ma przygotowaną odpowiedź na pytanie „co by było, gdyby to miało działać za pół roku".

Pitch nie wygrywa hackathonu — pitch go zamyka. Wygrywa go prototyp, który za nim stoi. Pięć minut to za mało, żeby nadrabiać braki projektu mówieniem.

Na koniec

Przygotowanie do hackathonu art-tech to nie jednorazowa lista wykonana w piątek wieczorem. To proces, który zaczyna się na dwa–trzy tygodnie przed startem — od skompletowania zespołu, przez wybór problemu, po konfigurację narzędzi. Im wcześniej się go zacznie, tym więcej czasu zostaje w samym weekendzie na to, co naprawdę ma znaczenie: na myślenie o koncepcji, iterowanie prototypu i dopracowanie momentu, w którym projekt staje przed jury.

Hackathon nie jest miejscem, w którym powstają gotowe produkty rynkowe — jest miejscem, w którym powstają prototypy pokazujące kierunek. Jeśli zespół przychodzi przygotowany, prototyp powstaje w weekend. Jeśli nie — powstaje w panice albo nie powstaje wcale. Różnica między tymi dwoma scenariuszami leży zwykle w kilkunastu godzinach przygotowania rozbitych na tygodnie przed startem.