O czym jest ten film
- Gościem Nate’a Herka jest Dave Ebbelaar — ponad dekada zawodowego Pythona (dane, inżynieria AI), który dziś nie pisze ręcznie ani jednej linijki kodu: wszystko przechodzi przez agentów kodujących, głównie Codex i Claude Code.
- Tempo pracy: w porównaniu z 2022 rokiem to realnie około 10x więcej produkcyjnego kodu, a w obszarach, w których wcześniej nie działał (np. frontend), przyrost jest jeszcze większy.
- Specjalizacja odwrócona do góry nogami: agent kończy zadanie szybciej, niż zespół zdąży się dogadać, więc opłaca się ogarniać cały stack; w firmie Glido każdy ma pełną odpowiedzialność za swój fragment produktu od pomysłu do wdrożenia.
- Vibe coding jest w porządku przy zerowym ryzyku (np. własna strona); granica przebiega tam, gdzie do aplikacji wchodzą inni użytkownicy — i ich dane osobowe.
- Centralny motyw rozmowy: „drabina” czterech szczebli — narzędzie dla siebie, narzędzie dla zespołu, produkt lub usługa dla klientów, wreszcie pełnoprawny SaaS. Z każdym szczeblem rośnie złożoność, obowiązki prawne i stawka.
- Praktyka się zmieniła: rok temu wszyscy kazali najpierw generować specyfikacje i plany, dziś lepiej budować od razu i iterować na działającej rzeczy („inżynieria sterowana intencją”); planowanie wchłonęły lepsze modele i ich otoczka narzędziowa.
- Ewaluacja jakości zaczyna się od zdefiniowania, co znaczy „dobrze”; brakujące dane można kazać wygenerować modelowi, a ulepszanie puścić w pętli z jasnym celem.
- Gdy kryterium jakości jest subiektywne (obsługa klienta, montaż wideo), działa technika „LLM jako sędzia” skalibrowana na ocenach człowieka — od ok. 50% zgodności na starcie do 95–99% po kolejnych rundach.
- Skalowanie to architektura na dwóch poziomach: systemowym (stack, backend, frontend, baza) i repozytorium (walka z „spaghetti code”); stack trzeba wybierać pod cel, nie pod przyzwyczajenie — kosztowna lekcja Glido.
- Bezpieczeństwo: garść podstaw (Supabase z RLS, mocne hasła i 2FA, sekrety poza kodem, firewalle z białą listą IP) załatwia większość ryzyka. Jedyny błąd nieodwracalny to wyciek danych osobowych.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zanim zaczniesz budować, ustal, na którym szczeblu drabiny jesteś
Na czym polega: Każdy pomysł wpada w jedną z czterech kategorii: narzędzie tylko dla siebie, narzędzie dla zespołu lub firmy, produkt/usługa sprzedawana klientom albo pełny SaaS na subskrypcję. Im wyższy szczebel, tym większe wymagania — od „otwórz Claude Code i do dzieła” po umowy, prywatność danych i obowiązki prawne.
Jak stosować: Przed pierwszym promptem odpowiedz sobie na jedno pytanie: ile rąk dotknie tego produktu i czy wejdą tam cudze dane? Dla siebie — buduj śmiało. Dla zespołu — sprawdź, kto i jakie dane będzie wprowadzał. Dla klientów — dolicz aspekty prawne i prywatność. SaaS — pełen pakiet obowiązków.
Na co uważać: Nie przeskakuj szczebli: osoba bez doświadczenia, która od razu sprzedaje firmom autorskie oprogramowanie, pomija „pracę domową” i ryzykuje wypadek. Ale nie bój się zaczynać od dołu — z pierwszego szczebla zawsze można wejść wyżej.
2.Różnicę między laikiem a weteranem robią instrukcje i przegląd wyników, nie pisanie kodu
Na czym polega: Po raz pierwszy w historii początkujący i inżynier z dekadą praktyki używają tych samych narzędzi i tego samego procesu. Całe rzemiosło sprowadza się do tego, co każesz agentowi zrobić i jak oceniasz efekt — tam właśnie odbywa się twój „trening”.
Jak stosować: Każdą sesję kończ świadomym przeglądem: powiedz konkretnie, co ci pasuje, a co nie, i popraw. Ucz się na każdej iteracji — to zastępuje lata ręcznego kodowania.
Na co uważać: Agent nie może być jedynym źródłem prawdy o własnej pracy. Buduj świadomość podstaw (architektura, bezpieczeństwo), żeby umieć krytycznie ocenić wynik.
3.Buduj od razu, nie pisz najpierw wielkiej specyfikacji
Na czym polega: Rok temu panowała praktyka „spec-driven development”: najpierw AI generowało dokument wymagań, człowiek go zatwierdzał, dopiero potem powstawał kod. Dziś modele są na tyle dobre, że faza planowania zrosła się z samym procesem — lepiej działać i iterować.
Jak stosować: Powiedz agentowi, co chcesz zbudować, poproś o efekt, potem komentarz: „to wygląda dziwnie”, „ma być szybciej”, „ten wynik jest błędny”. Przed startem warto też przejść „przesłuchanie”: każ AI odpytać cię, czego dokładnie chcesz, czego nie chcesz i jaka jest twoja wizja.
Na co uważać: Rezygnacja z wielkich planów nie zwalnia z myślenia o architekturze całości — im więcej ludzi będzie używać produktu, tym więcej decyzji strukturalnych trzeba świadomie podejmować.
4.Specjalizacja stała się wąskim gardłem — ogarniaj cały stack
Na czym polega: Agent kończy zadanie szybciej, niż ty zdążysz uzgodnić cokolwiek z kolegą od frontendu czy bazy. Kto siedzi tylko w jednym kawałku, szybko blokuje resztę: praca czeka, a agent już od dawna jest gotowy.
Jak stosować: Bierz odpowiedzialność za cały fragment produktu — od pomysłu po wdrożenie, ewentualnie z czyimś przeglądem kodu po drodze. Ucz się zasad inżynierii, a nie konkretnego języka: wybór frameworku ma coraz mniejsze znaczenie.
Na co uważać: Istnieje wyjątek: hiperspecjaliści z topowego procentu w wielkich korporacjach technologicznych — tam głęboka specjalizacja nadal ma wartość. Dla większości budujących lepiej działa model generalisty.
5.Ewaluacja zaczyna się od zdefiniowania, co znaczy „dobrze”
Na czym polega: „Dobrze” zawsze jest związane z konkretną aplikacją. Dla narzędzia do dyktowania to np. przetworzenie mowy w niecałe 500 ms i wklejenie poprawionego tekstu dokładnie tam, gdzie trzeba, z zachowaniem stylu wypowiedzi. Bez takiej definicji nie ma czego mierzyć.
Jak stosować: Opisz dobry wynik mierzalnie, znajdź przykłady (własne dane, dane zespołu), a gdy ich brakuje — każ modelowi wygenerować realistyczne zestawy. Zbuduj ewaluację typu: takie wejście → oczekiwane wyjście, i sprawdzaj przy każdej zmianie.
Na co uważać: Nie przenoś metryk z cudzych projektów — definicja jakości zależy od zastosowania. Jeśli aplikacja ma być prywatna „z założenia”, testuj na danych własnego zespołu, nie użytkowników.
6.Ulepszanie puść w pętlę z jasnym celem
Na czym polega: Modelom można dać kryterium i pozwolić działać: korzystaj z danych, dogeneruj brakujące, rób rozeznanie, odpalaj podagentów — aż będzie lepiej. Nawet „nieporządny” prompt w rodzaju „idź i popraw” uruchamia u czołowych modeli cały cykl badawczo-eksperymentalny.
Jak stosować: Sformułuj cel jak dla człowieka: „mniej błędów”, „szybciej”, „ma wyglądać tak”. Dodaj dane i ewaluację, żeby model w każdej iteracji widział, czy idzie we właściwą stronę.
Na co uważać: Pętla bez zdefiniowanego „dobrze” kręci się w miejscu. I kluczowa jest świadomość, że taka pętla w ogóle istnieje — o nią trzeba po prostu zapytać.
7.Gdy „dobrze” jest subiektywne: LLM jako sędzia skalibrowany z człowiekiem
Na czym polega: Na pytanie klienta można odpowiedzieć na tysiące sposobów i każdy może być dobry albo zły — celem jest zadowolony odbiorca. Rozwiązanie: drugi model ocenia odpowiedzi („dobre? tak/nie — dlaczego”), a jego gust kalibruje się na ludzkich ocenach.
Jak stosować: Człowiek ocenia np. 100 przykładów (nudna, ręczna robota — ale właśnie tu łapiesz „gust”). Przepuść je przez sędziego-LLM i policz zgodność, np. 50% na start. Potem każ AI zoptymalizować prompt sędziego pod te dane: kolejne rundy podnoszą zgodność do 90–99%.
Na co uważać: Po zmianie modelu sędzia może się „rozregulować” — kalibrację trzeba powtarzać, też po to, by uniknąć dryfu. W obszarach wizualnych (montaż wideo) metoda działa, ale dopiero w miarę dojrzewania możliwości multimodalnych.
8.Stack wybieraj pod cel, nie pod to, co już znasz
Na czym polega: W ramach jednego języka można dużo — skalować, refaktoryzować, rozbudowywać. Przenoszenie projektu do innego języka jest za to kosztowne, nawet z agentami. Glido zaczęło na innym stacku niż obecny właśnie dlatego, że wybrano znajome, a nie optymalne.
Jak stosować: Na starcie zapytaj agenta: „buduję X — jaki stack będzie najlepszy? Czy potrzebuję osobnego backendu i frontendu? Jakiej bazy? Jakie jest najprostsze rozwiązanie?”. Drąż i porównuj, kieruj się dowodami, nie przyzwyczajeniem.
Na co uważać: Znajomość technologii przestała usprawiedliwiać wybór — dziś można powiedzieć: „czuję się pewnie w tym, ale są dowody, że tamten będzie lepszy”. Migracja jest łatwiejsza niż kiedyś, ale wciąż nie jest to zamiana, którą chcesz robić w trakcie rozwoju.
9.Nie dopuszczaj do „spaghetti” w repozytorium
Na czym polega: Przy vibe codowaniu balast narasta szybko: porzucone eksperymenty zostają w kodzie, a w środku nich siedzi fragment logiki, którego naprawdę używasz. Po usunięciu „niepotrzebnej” funkcji coś nagle przestaje działać — bo tam właśnie mieszkał potrzebny kawałek. Agentom coraz trudniej nawigować w takim bałaganie.
Jak stosować: Regularnie przeglądaj strukturę projektu (pliki, foldery, funkcje, klasy, moduły). Skorzystaj z gotowych „skilli” do architektury repozytorium — w rozmowie pada konkretna rekomendacja — i trzymaj się zasad głębokich modułów, lokalności i wyraźnych „szwów” między częściami.
Na co uważać: Problem kumuluje się po cichu i objawia dopiero bugami po miesiącach. Struktura repozytorium jest mniej krytyczna niż architektura systemu, ale zaniedbana z czasem blokuje rozwój.
10.Minimum bezpieczeństwa: kilka rzeczy, które załatwiają większość ryzyka
Na czym polega: Na start baza Supabase (chyba że masz mocny kontrargument — wtedy i tak jesteś już na tyle techniczny, żeby decydować samodzielnie). Do tego: bezpieczeństwo na poziomie wierszy (RLS), mocne hasła i dwuskładnikowe logowanie, dane dostępowe w zmiennych środowiskowych — nigdy w kodzie — oraz reguły firewalla otwierające backend i bazę tylko dla znanych adresów IP twojej aplikacji.
Jak stosować: Weź tę listę, wrzuć do czatu z agentem i wspólnie przerób na swój przypadek: gdzie wdrożysz backend, jak skonfigurujesz reguły, co widać w kodzie aplikacji webowej w przeglądarce (a czego tam być nie powinno).
Na co uważać: Zła architektura to błąd odwracalny — aplikacja zwolni albo się wysypie i naprawisz. Włamanie i wyciek danych osobowych jest nieodwracalny: „przepraszamy, poprawimy w następnej wersji” nie istnieje.
Redakcyjne tłumaczenie
Dekada z Pythonem, zero ręcznego kodu
Nate: Dave, piszesz w Pythonie od ponad dziesięciu lat, twój zespół w Glido wdrożył ponad pięćdziesiąt rozwiązań opartych na AI, a nowe funkcje publikujecie niemal co tydzień. Jak z tej perspektywy wygląda dziś inżynieria oprogramowania — w czasach, gdy wszyscy mamy te narzędzia AI?
Dave: No, mocne pytanie na start. Odpowiedź brzmi: zupełnie inaczej. To, co działo się przez ostatnie trzy lata, a zwłaszcza w ostatnim roku, jest szaleństwem, jeśli chodzi o to, co dziś potrafimy. I wszyscy to przeżywamy: używamy tych narzędzi, produkujemy mnóstwo kodu, budujemy. Po pierwsze — jest w tym ogromna ekscytacja. A jeśli pytasz, co konkretnie zmieniło się względem czasów, gdy zaczynałem w 2013 roku, to no cóż… programowanie było wtedy cholernie trudne. I samo uczenie się też. Człowiek spędzał wieki na dopieszczaniu małego programiku i przekopywaniu Stack Overflow, żeby cokolwiek zaskoczyło. Dało się zbudować drobne rzeczy, a jeśli przy czymś siedziało się bardzo długo — może coś użytecznego. Dziś użyteczną rzecz zbudujesz jednym promptem. Widzimy to przecież co tydzień na twoim kanale: jeden prompt i coś działa.
I co z tego wynika? Możemy myśleć większymi kategoriami — jako twórcy — i budować rzeczy, które kilka lat temu nie wchodziły w grę. Automatyzacje dla siebie, dla własnej produktywności, wewnątrz firmy, dla klientów. Można w końcu zbudować całe produkty programistyczne i je sprzedawać, mając znikome przygotowanie techniczne. To wszystko jest teraz możliwe i przyspiesza z każdym tygodniem.
(Informacja dodatkowa: Dave Ebbelaar to inżynier danych i AI; Glido — budowana przez jego zespół aplikacja do dyktowania, o której wielokrotnie mowa w rozmowie.)
Ile razy szybciej? Święte 10x
Nate: Gdybyś miał to skwantyfikować — ile razy szybciej działasz dziś?
Dave: W porównaniu z czasami, gdy zaczynałem? Może sto razy. Choć to nieuczciwe, bo byłem kompletnym laikiem. Weźmy uczciwszy punkt odniesienia: rok 2022. Wtedy już od dwóch–trzech lat pracowałem na własną rękę jako analityk danych i data scientist — zawodowo pisałem kod, głównie w Pythonie, praktycznie codziennie. Jeśli porównam, ile wtedy potrafiłem dostarczyć, z tym, co potrafię teraz, nadal powiem: solidne dziesięć razy szybciej — jeśli chodzi o realny, produkcyjny kod, który da się wdrożyć. A w niektórych projektach nawet więcej, bo mogę dziś brać się za rzeczy, które wcześniej w ogóle nie były dla mnie osiągalne.
Jestem z podstawienia Pythonem — dane, potem inżynieria AI, systemy backendowe. Ale gdybyś kazał mi zbudować elegancki frontend czy dashboard: przez całe życie nie napisałem praktycznie ani jednej linijki JavaScriptu. Wziąłem się za to dopiero, gdy pojawiły się agenty kodujące. Czyli: solidne 10x na pracy, którą już robiłem zawodowo — i więcej niż tyle na możliwościach, których wcześniej po prostu nie miałem.
Koniec specjalizacji — czas generalistów
Nate: Czyli kiedyś inżynier typowo się specjalizował — przynajmniej na wysokim poziomie: backend albo frontend — i to była zupełnie inna filozofia pisania.
Dave: Dokładnie. Ludzie „pełnego stacku” oczywiście istnieli, ale i oni trzymali się zwykle konkretnych języków. Byli legendarni „dziesięciokrotni” inżynierowie, którzy ogarniali wszystko, ale przeważnie każdy robił backend, frontend, bezpieczeństwo albo infrastrukturę i miał jeden–dwa języki, w których czuł się swobodnie. Dziś to się całkiem odwróciło.
I bardzo wszystkim to polecam. Dlaczego? Specjalizacja zawsze ma jakąś wartość — jeśli pracujesz w wielkiej korporacji, w wysoce wyspecjalizowanym zespole, musisz być w czołowym procencie swojego fachu, hiperspecjalistą. Ale bądźmy szczerzy: większość z nas tam nie pracuje. Większość z nas po prostu lubi budować. I tu dziś lepiej wyjść z założenia, że jest się człowiekiem orkiestrą — generalistą — i ufać, że napisze się przyzwoity kod także tam, gdzie wcześniej człowiek nie czuł się pewnie.
Bo popatrz: specjalizacja oznacza, że odpowiadasz za jeden kawałek projektu — a więc potrzebujesz innych ludzi, żeby doprowadzić coś do końca. Tymczasem twój agent pracuje szybciej, niż jesteś w stanie dogadywać się z kolegami. Jeśli nie poruszasz się po całym stacku, bardzo szybko wpadasz w wąskie gardło: agent skończył, jest gotowy do wysyłki i do następnej części — a frontu nie ma kto spiąć, bo ty robisz tylko backend, albo nie wiesz, jak dopasować backend do bazy. Każda taka zależność to problem. Widziałem to i we własnych projektach, i teraz w Glido: podział ról i kilka osób oczywiście mamy, ale każdy dostaje pełną odpowiedzialność za swój fragment produktu — od początku do końca, samodzielnie. Co najwyżej ktoś rzuci okiem na przegląd w trakcie. Nie ma czekania na czyjś kod. Dlatego generalista to moim zdaniem dziś najlepsza droga — i jest wreszcie możliwa: uczysz się zasad inżynierii, a to, w jakim języku czy frameworku je zastosujesz, ma coraz mniejsze znaczenie.
(Sekcja sponsorska) Nate: Krótkie wtrącenie o sponsorze odcinka, CodeRabbit — bo jeśli budujecie z agentami, to kod narasta szybciej, niż jesteście w stanie go przeczytać: agent w jednym przebiegu rusza routing, schematy, testy i konfigurację, a GitHub pokazuje wam potem alfabetyczną listę plaków… plików. Interfejs przeglądu CodeRabbit porządkuje pull request w grupy powiązanych zmian, ułożone według zależności — czytasz więc w kolejności, w jakiej to zbudowano. Dostajecie podsumowanie, przejście po zmianach, informację o blokadach scalania, oś czasu decyzji, a widok „dyfu” semantycznego pokazuje, co faktycznie się zmieniło, zamiast udawać skasowanie i ponowne dodanie przeniesionego kodu. Da się też od razu odpytać agenta o dany PR. Czternaście dni próbnie za darmo, bez karty — link w opisie. Dzięki, CodeRabbit. Wracamy.
Cieszę się na tę rozmowę, bo moja widownia to zwykle ludzie bez technicznego przygotowania, a twoja — dokładnie odwrotnie. Sam też czasem przy budowaniu łapię się na myśli: „czy to na pewno jest dobrze?”. Bo jedynym miejscem, w którym mogę się upewnić, jest odpowiedź agenta — a to nie zawsze jest źródło, któremu człowiek chce ufać.
Vibe coding: gdzie kończy się bezpieczna zabawa
Nate: Zanim zaczniemy od początku, jedno pytanie z boku: jak przyjąłeś całą erę vibe codingu, gdy ten termin wystrzelił? Jako inżynier musiałeś słyszeć dzwonki alarmowe, gdy każdy brał te narzędzia i zaczynał budować aplikacje.
(Informacja dodatkowa: „vibe coding” — budowanie aplikacji z agentem AI „na czucia”: iteruje się na efektach wizualnych, nie zaglądając w kod.)
Dave: Po pierwsze — bardzo mnie to ucieszyło. Bo sam byłem częścią tej fali: budowałem aplikacje frontendowe i całkiem autorskie strony, nie czytając kodu, i kompletnie mnie to nie obchodziło. Czyli formalnie też jestem vibe coderem. To, że umiem ustawić architekturę i zabezpieczyć aplikację, oczywiście pomaga i daje dodatkowe doświadczenie. Ale jestem jak najbardziej za. Trzeba tylko wiedzieć, ile się ryzykuje, zależnie od projektu.
Budujesz własną stronę? Śmiało, pędź na czucia — ryzyko zerowe. Zawsze chodzi o ważenie zysku z ryzykiem. To wspaniałe, że dziś każdy może budować. Ostrożność zaczyna się w chwili, gdy do twojego oprogramowania wpuszczasz innych użytkowników — zwłaszcza gdy w grę wchodzą dane osobowe. Tam trzeba wyznaczyć granicę: do jakiego momentu możesz pchać rzeczy „na oko”, sprawdzając tylko, czy działają, a od którego trzeba zajrzeć głębiej — czy to na pewno jest bezpieczne. Bo nagle nie operujesz już tylko na własnych danych, ale na cudzych.
Nate: I jest w tym coś pięknego, bo co chwilę słychać o kimś, kto — niezależnie od zamiłowania — ma pomysł, siada z agentem i go realizuje. Były już udane exity, ludzie zmieniali sobie życie, bo potrafili zamienić pomysł w coś realnego. To rozłóżmy na części: ktoś ma pomysł i chce w ten weekend zacząć budować. Jak byś do tego podszedł? Jakie kroki i planowanie?
Drabina czterech szczebli
Dave: Świetne pytanie, chodźmy przez to po kolei. Najpierw musisz z grubsza ocenić, jak duża jest rzecz, którą chcesz zbudować. Skupmy się na produktach programistycznych, żeby nie komplikować. Są tu różne poziomy.
Pierwsze pytanie: czy to narzędzie tylko dla ciebie? Bo chcesz coś mieć — na przykład przestać płacić za subskrypcję, albo czegoś takiego w ogóle nie ma na rynku, albo chcesz scalić kilka narzędzi w jedno. To jeden poziom. Drugi: tak, dla mnie, ale też dla ludzi w mojej firmie — rzecz zespołowa, firmowa. Albo: „chcę zbudować coś i sprzedawać innym” — jako element oferty agencji AI, firmom albo osobom. I to może być częściowo sproductyzowane: budujesz, pakujesz, sprzedajesz; a częściowo usługa — wdrażasz u klienta, bo w automatyzacjach, jak sam wiesz, żadne dwa wdrożenia nie są w stu procentach takie same i zawsze jest element dopasowania. Wreszcie czwarty poziom: pełnoprawny produkt — ktoś wchodzi na stronę, zakłada konto, płaci subskrypcję i używa. Jak my z Glido.
Czyli cztery kategorie, do których może trafić twój pomysł. I to jest ważne, bo ja to widzę jak drabinę: im wyższy szczebel, tym większa złożoność i stawka. Budujesz dla siebie? Stawka minimalna — po prostu otwórz Claude Code i do dzieła. Narzędzie dla zespołu? To wciąż „rzecz wewnętrzna”, ale już warto się zastanowić, kto będzie tego używał i jakie dane znajdą się w aplikacji. Sprzedajesz firmie? Dochodzi aspekt prawny: umowa, warunki świadczenia usług, obowiązki z zakresu prywatności i ochrony danych — ryzyko rośnie. A na samym szczycie, gdy z twojego produktu korzystają konsumenci, dochodzi pełnia kwestii prywatności i praw osób, których dane dotyczą — i po prostu więcej użytkowników, a więc większe ryzyko. Warto na chwilę przystanąć właśnie tutaj, bo od tego dobrze zacząć. Wszystko jasne?
Nate: Jasne. Czyli zanim zaczniesz budować, chcesz mieć pojęcie o „wielkości” — a to każe myśleć: ilu ludzi tego użyje, ile rąk tego dotknie. I czy dobrze rozumiem, że sensownie jest zacząć od pierwszego szczebla — „buduję dla siebie”? Nie znaczy to przecież, że za pół roku nie mogę wzmocnić backendu… Po drodze, im wyżej, tym więcej myślenia o architekturze, bazie, wydajności, prywatności. Ale na start pierwszy szczebel jest jak najbardziej w porządku, a gdy przyjdzie potrzeba, wchodzisz wyżej. Nie zamrażasz się w decyzji „to narzędzie osobiste” — drabina zawsze pozwala piąć się dalej.
Dave: Tak, to bardzo dobra precyzacja — ambicję projektu zawsze można powiększyć. Jedno ostrzeżenie: przeskakiwanie szczebli. Ktoś bez przygotowania technicznego wskakuje od razu na górę — buduje autorskie oprogramowanie i sprzedaje je firmom, które na nim polegają. Taki człowiek ominął kilka kroków odrobiania pracy domowej: jak to wszystko wygląda, co to znaczy, jakie dane przez to płyną. Naturalna droga to wspinaczka po szczeblach.
A taktycznie — co się różni między szczeblami? W samym procesie nie ma dziś prawie żadnej różnicy. Ja też nie piszę już ani jednej linijki kodu. Ani jednej. Wszystko idzie przez Codex albo Claude Code, czasem przez agenta innego dostawcy — zależnie od tego, kto akurat ma najlepsze modele. Całość przechodzi przez agentów kodujących.
I to jest naprawdę ciekawe: pierwszy raz w historii osoba bez żadnego doświadczenia w kodowaniu i ktoś z ponad dekadą praktyki używa dokładnie tych samych narzędzi w dokładnie tym samym procesie. Mówię to i dopiero teraz do mnie dociera, jakie to jest dzikie. Pomyśl o nauce dowolnej umiejętności — koszykówki, czegokolwiek. Nie zaczynasz od poziomu elity; twoje ćwiczenia od samego początku wyglądają zupełnie inaczej. A tutaj wszyscy startujemy z tych samych znakomitych narzędzi do produkcji kodu. Różnica sprowadza się do dwóch rzeczy: jakie instrukcje dajesz i jak przeglądasz wynik. I to jest całe rzemiosło — tam są twoje powtórzenia, twój trening. I tam stawka rośnie, im więcej ludzi używa twojego oprogramowania.
To powinno dodawać otuchy: masz te narzędzia, wchodzisz na abonament za dwadzieścia dolarów… no, realnie szybko trzeba będzie dołożyć do stu–dwustu, bo inaczej limit się skończy i do końca tygodnia siedzisz i czekasz na odnowienie. Ale dla większości ludzi to jest w zasięgu. I od tego można zacząć budować naprawdę fajne rzeczy. Zacznij od czegoś, czego sam używasz i co uważasz za fajne, potem to doskonal. Na niższych szczeblach vibe coding jest w zupełności w porządku. Jest jeden obszar, w którym nie można sobie pozwolić na ryzyko: bezpieczeństwo. Bo gdy zbudujesz aplikację „na czucia” i architektura będzie słaba — co najgorszego się stanie? Zwolni, w końcu się wywali. Zauważysz, bo ludzie zaczną narzekać, i naprawisz. Odwracalne. Ale włamanie i wyciek danych — tego nie cofniesz. „Przepraszamy, poprawimy w następnej wersji” nie istnieje. Gdy maile i dane osobowe wyciekły, nie ma drogi powrotu. To jest ten jeden aspekt, o którym trzeba pamiętać, wchodząc na wyższe szczeble.
Nate: Właśnie o tym pogadamy — będziemy piąć się w górę. Uwielbiam tę drabinę, bo na każdy szczebel trzeba sobie zasłużyć. Nie da się przeskoczyć z ziemi na czwarty — spadniesz i wracasz na dół. Czyli krok pierwszy: oceniasz wielkość i ryzyko. Co jest następne? Jak mapujesz wymagania?
Buduj od razu, iteruj na działającym produkcie
Dave: To na pewno następny krok. Zerknij, jak zmienia się praktyka: rok temu wszyscy forsowali „spec-driven development”, rolę planów — pamiętasz zapewne. A im lepiej widzę, jak modele idą do przodu, tym mniej ważna robi się faza planowania i generowania specyfikacji.
Nate: Rozwiń: co to właściwie jest?
Dave: To sposób budowania, w którym AI używasz najpierw nie do pisania kodu, lecz do stworzenia specyfikacji — opisu w naturalnym języku, jak produkt ma działać. Mówisz: „chcę zbudować X, stwórzmy specyfikację”, a AI generuje dokument: produkt ma to, ma tamto, ma owamto… Tworzysz plan, czytasz, zatwierdzasz — i dopiero wtedy przechodzisz do developmentu i każesz agentom pisać kod. To była panująca praktyka rok temu, gdy przełom przyniosły Claude Code i modele Opus 4.5 i 4.6 — złoty wiek agentów. A teraz robi się jeszcze ostrzej.
W tym procesie wciąż jest wartość i nie uważam, że to błąd — pomaga choćby pomyśleć, czego się naprawdę chce. Ale dziś najczęściej po prostu siadam i buduję, a o strukturze projektu decyduje model. Pewne standardy, do których steruję model — na przykład w Pythonie, bo mam z nim najwięcej lat — oczywiście zostały. Ale w skrócie: coraz łatwiej powiedzieć, czego chcesz, a on zacznie budować. Więc wracając do twojego pytania: następnym krokiem jest wejść na Codex albo Claude Code, wziąć GPT-6 Astra albo Opusa 5.5 — dwa czołowe modele; Opus 5.5 jest dotąd znakomity…
Nate: Rewelacyjny.
Dave: …i po prostu powiedzieć mu, co chcesz zbudować. I choć brzmi to banalnie, dla początkujących nie ma w tym wiele więcej. Patrzysz na wynik, mówisz, co ci się podoba, a co nie — i samą tą pętlą zajedziesz naprawdę daleko.
Inżynieria sterowana intencją
Nate: A fajne w tym jest to, że ludzie są naprawdę dobrzy w wyjaśnianiu, czego chcą. Łatwo powiedzieć „chcę to i to”. Ale warto przejść proces „przesłuchania”: niech AI odpyta ciebie — czego dokładnie chcesz, czego nie chcesz, jak to ma wyglądać, jaka jest twoja wizja. Rozmawiałem niedawno z kilkoma inżynierami Google i ujęli to tak: cała ta „hydraulika” — nudne instalacje na backendzie, które kiedyś trzeba było ułożyć, zanim człowiek w ogóle mógł zacząć się wybrać kreatywnie — dziś załatwia się sama. Wyjaśniasz, czego chcesz, a agenci wiedzą, jak to spiąć. Oni nazywali to „intent driven automation”, inżynierią sterowaną intencją. Podoba mi się to. Ty jak to widzisz?
Dave: Zgadzam się, ładny termin. Co znaczy? Mówisz modelowi, czego chcesz. Masz jako twórca intencję, pomysł — i chcesz go zamienić w rzeczywistość. A rzecz w tym, że choć na starcie masz mgliste pojęcie, dokąd to zmierza, dopóki nie zobaczysz rzeczy na własne oczy i nie zaczniesz jej używać, nie jesteś w stanie dać najlepszej informacji zwrotnej. Właśnie dlatego odszedłem od wielkich planów i specyfikacji: „zbuduj mi to” — patrzę, testuję: „to jakoś tak nie zgrzyta”, „może być szybciej”, „to wygląda źle” — wizualnie albo w logice — „ten wynik jest błędny, popraw”.
Tak zresztą rozwija się dziś Glido: głównie pomysły i naturalny język. I zabawnie się robi, bo używamy Glido do budowania Glido. Mówimy do niego: „hej, spróbuj tego, rozłóż to”. Często robię to wprost na produkcyjnym repozytorium — na osobnej gałęzi, więc nic natychmiast nie jedzie do użytkowników — ale bez żadnego osobnego „plac zabaw”: tworzę gałąź, każę zbudować i od razu widzę, jak to wygląda w produkcie. I iteruję. To moim zdaniem idealny opis developmentu sterowanego intencją: mówisz, czego chcesz, a to powstaje.
(Autopromocja) Nate: Przy okazji: mam dla was zupełnie darmową, gotową instrukcję krok po kroku o zdobywaniu pierwszego klienta na automatyzacje AI — sprawdzoną przez setki członków naszej społeczności. Jest w niej m.in. zdanie-pitch na start, dlaczego pierwszy klient powinien cię kosztować, pięciominutowe wideo, które odpowiada na pytanie „czy ty naprawdę umiesz to dostarczyć” — zanim w ogóle dostaniesz pieniądze — oraz co robić, gdy nie masz jeszcze żadnych case studies. Link w opisie; warto sięgnąć, nawet jeśli klientów już masz.
Ciekawe, jak jeszcze rok temu panowało planowanie, a dziś budujesz najpierw i bawisz się efektem. Kiedyś sam odpalałem tryb planowania do wszystkiego, domyślnie, choćby do samego burzenia mózgów. Czy praktyka się przesunęła po prostu dlatego, że modele i ich otoczka stały się lepsze?
Dave: Na pewno to kombinacja obu rzeczy — i to ważne do zrozumienia. Myślę, że nawet ludzie rozwijający Claude Code, inżynierowie Anthropic, pisali o tym publicznie: tryb planowania przestaje być potrzebny. Bo czym właściwie jest plan? Zawsze zaczynasz od celu: „chcę zbudować to”. Kiedyś modelowi pomagało, zanim rzucił się generować kod, żeby najpierw się odsunął, przemyślał całość, sprawdził, czy wszystko się spina — i dopiero potem egzekwował plan. Inżynierom OpenAI i Anthropic, poprawiając modele i ich otoczkę narzędziową — tzw. harness, czyli środowisko, w którym model wykonuje pracę — udało się wtopić ten proces w samą parę model–otoczka: planowanie stało się cechą, którą ona po prostu ma, bez włączania żadnego trybu.
Ewaluacje: najpierw zdefiniuj, co znaczy „dobrze”
Nate: Mówisz: mamy już pierwsze efekty. W automatyzacjach robimy dużo ewaluacji: mamy wejścia, wyjścia, coś wychodzi na 90% poprawnie — iterujemy do 98–99. Jak ty myślisz o ewaluacji w aplikacji? Jak sprawdzić, że coś naprawdę działa, zamiast zakładać albo klikać kilka razy na chybił trafił?
Dave: To zależy od tego, co budujesz, bo „dobrze” zawsze jest związane z konkretną aplikacją. Weźmy Glido. Co znaczy „dobrze”? Naciskasz przycisk, mówisz — i w niecałe pięćset milisekund przetworzony tekst wraca do aplikacji, dokładnie w formie gotowej do wklejenia, z drobnymi błędami poprawionymi, ale z twoją mową w dużej mierze nietkniętą. Bo o to właśnie chodzi w dyktowaniu. Zaczyna się więc od doprecyzowania, co znaczy „dobrze”.
Drugie pytanie: czy potrafisz znaleźć tego przykłady — przypadki, kiedy wyszło dobrze? W Glido nie używamy danych użytkowników, bo projektowaliśmy aplikację jako prywatną z założenia — korzystamy z nagrań własnych kont, czyli nas, deweloperów. Taki zbiór rośnie razem z zespołem, a na nim uruchamiamy eksperymenty: wchodzą takie dane — z systemu ma wyjść taki wynik. I to właśnie staje się ewaluacją, którą można uruchamiać i sprawdzać.
I fajna rzecz: modele są już tak dobre, że gdy brakuje ci danych, możesz poprosić model o wygenerowanie realistycznych danych do twojego przypadku — czy to chatbota, czy automatyzacji czegokolwiek. A gdy dasz modelowi cel — „tak to ma wyglądać, popraw to, ma być szybciej, mniej błędów” — i puścisz to w pętli, to znaczy każesz mu działać: używaj danych, dogeneruj brakujące, rób rozeznanie, odpalaj podagentów, kręć, aż będzie lepiej — to nawet taki nieporządny prompt rzucony Opusowi 5.5 uruchamia cały cykl badawczo-eksperymentalny, w którym model sam szuka sposobów ulepszenia.
I zauważmy prawidłowość, która wraca do mnie w kółko: im lepsze modele i ich otoczka, tym łatwiejsze robi się wszystko, co robimy jako twórcy oprogramowania. Planowanie, specyfikacje, testy jakościowe, debugowanie, bezpieczeństwo, ewaluacje — wszystko to lekzczeje razem z modelami. Bardzo ciekawa właściwość — i coś, o czym trzeba po prostu wiedzieć. Bo o tę pętlę trzeba zapytać. Trzeba wiedzieć, że ewaluacje istnieją, że można ustawić pętlę poprawiania aplikacji. Już samo to przeświadczenie — i zadanie pytania — to właściwy punkt startu.
Nate: Czyli zdefiniować „dobrze” — zupełnie jak z człowiekiem: uzgodnić oczekiwania. Bo jeśli nie uzgodnisz z człowiekiem ani z agentem, czego oczekujesz, a wróci coś niezgodnego — to niekoniecznie porażka; może po prostu nie byłeś dość precyzyjny. A potem dać sposób weryfikacji: czy to ty sprawdzasz, czy agent — pewnie jedno i drugie.
To, co mówiłeś o pętli, przypomniało mi moment, gdy u Karpathy’ego wyszło „auto research”. Pamiętam, że wtedy uderzyło mnie: agent potrafi zobaczyć cel, dowieść, czy osiągnięty, i dalej próbować, aż trafi. Niesamowite. A teraz trudniejsze: najlepsze pętle działają, gdy jest obiektywny punkt kontrolny. Co, gdy kryterium jest subiektywne — gust, „dobrze” nie da się obiektywnie udowodnić?
Gdy „dobrze” to kwestia gustu: LLM jako sędzia
Dave: Prawda. Najlepiej działa, gdy jest jednoznacznie dobrze albo źle — bo masz zbiór przykładów — albo gdy chodzi o szybkość. W Glido mamy sporo infrastruktury: modele, którymi zarządzamy, kod i architektura wokół nich. Dasz cel: „taką mamy teraz latencję, test ją mierzy — idź, przyspiesz” — i jest jasno, bo po każdej iteracji model widzi, czy jest nad czy pod celem, czy zmierza we właściwą stronę. A co z przypadkami bez takiego punktu odniesienia? Podam przykład, żeby to zrobić namacalnym. Mój najczęstszy to montaż wideo: „ma być profesjonalnie, ma wciągać”. Skąd on to wie?
Tak, to naprawdę podchwytliwe. Dam ci inny przykład, a potem wrócę do twojego. Dużo pracowaliśmy w obsłudze klienta. Klient zadaje pytanie, agent odpowiada. Jest setki, tysiące, pewnie miliony sposobów odpowiedzenia — i wszystkie mogą być poprawne albo wszystkie błędne, bo ostatecznym celem jest zadowolony klient: dostał dobrą odpowiedź. Czy użyjesz tego słowa czy innego — to subiektywne, dopuszczalne różnice.
Jest na to technika: „LLM jako sędzia”, uruchamiany na skalę. Jak to działa? Najlepszy sposób sprawdzania wyników agenta przy subiektywnej jakości — i jednocześnie najdroższy oraz nieskalowalny — to człowiek: AI robi robotę, człowiek ocenia: dobre, niedobre. Ale po co wtedy automatyzować? W obsłudze klienta, jeśli człowiek musi przeglądać każde zgłoszenie, równie dobrze może sam odpisać — bo odpowiedzenie jest łatwiejsze niż napisanie sensownej recenzji. Więc: nieskalowalne. Ale jeśli zrobisz to przez jakiś czas, budujesz mały zbiór danych: „klient zapytał o to, AI odpowiedziało tamto, człowiek uznał: dobre — tak albo nie”. Zbierasz dane. I istota „sędziego-LLM”: inny model — niezależne wywołanie, jedno lub więcej — przegląda wynik. Patrzy na odpowiedź dla klienta i mówi: „czy to jest dobre? tak albo nie — i dlaczego”.
Wyzwanie: na początku skąd wiesz, że sędzia ocenia dobrze? Przesunąłeś problem z modelu, który trzeba sprawdzać, na drugi model, który też trzeba sprawdzać. Jest na to trik: stworzenie zgodności między ludzkim recenzentem a LLM. Robisz tak: masz, powiedzmy, sto przykładów; człowiek je ocenia i spisujesz wszystko — w arkuszu, w czymkolwiek. Ręczna robota, nikt jej nie lubi, nieskalowalna — ale trzeba, bo właśnie tu łapiesz „gust”: to mi się podoba, tego nie chcę, tu powinno być lepiej. Następnie przepuszczasz te przykłady przez LLM i patrzysz, gdzie się zgadzają — gdzie człowiek i model mówią zgodnie „dobre” albo „złe” — i dostajesz wynik: procent zgodności. Może wyjść 80%, a może nawet 50% — w połowie przypadków LLM zgadza się z człowiekiem. To twój punkt wyjścia.
I teraz robi się ciekawie, bo znowu używasz AI: „oto oceny człowieka, oto oceny modelu — zoptymalizuj prompt systemowy sędziego, żeby zgodność rosła”. Bo sędzia-LLM to w praktyce prompt systemowy i model, niewiele więcej. Pozwasisz LLM-owi to przejrzeć: „widzę, że w tych i tych przypadkach sądzę inaczej niż człowiek — uznawałem za dobre, a człowiek nie; poprawiam w prompcie”. Odpalasz ponownie: zgodność 75%. Kolejna runda: 80, 90, 95, 99%. Przy wystarczająco dużej próbie — i okresowym powtarzaniu kalibracji, żeby uniknąć dryfu modeli — masz sędziego, który z dużą pewnością oceni tak, jak człowiek. Tak się to robi w prawdziwych projektach.
A wracając do twojego montażu wideo: ten sam proces zadziała, tylko będzie trudniejszy. W ocenie cięcia, animacji, montażu jedne błędy są oczywiste, ale gdy jakaś animacja tytułu ma wzorzec, który ci się po prostu nie podoba — to trudne. Głównie dlatego, że chodzi o zdolność modelu do oglądania obrazu. Gdy możliwości multimodalne dojrzeją, dokładnie ten sam proces zastosujesz do optymalizacji i „trenowania” agentów do montażu.
Nate: I ciekawostka: dopracujesz takiego sędziego, a przy zmianie modelu może się to posypać, bo inny model inaczej interpretuje. Ale to, że wkładasz żmudną robotę w stworzenie standardów, wcale nie przepada — bo potem możesz puścić na nich pętlę auto researchu i mieć ciągłą optymalizację. Przypomina mi to skautów w sporcie: obserwują mecze, a są statystyki obiektywne — wzrost, waga, ile razy wyciśnie na ławce 225 funtów — ale klub ufa też oku skauta: „ten zawodnik ma potencjał, jest eksplozywny, świetnie czyta grę”. Tego nie ma na papierze. I właśnie o to chodzi: jak nauczyć LLM gustu i osądu takiego skauta — albo twojego własnego. Bardzo to ciekawe.
Skalowanie: architektura systemu i wybór stacku
Nate: Przejdźmy dalej: mamy weryfikację, coś, co działa. A gdy chcemy skalować — z aplikacji jednoosobowej lub zespołowej — o czym zaczynasz myśleć? Nie musimy wchodzić w techniczne głębie, chodzi o poziom ogólny: infrastruktura, bazy danych, bezpieczeństwo. I przy okazji — może masz jakieś „miny”, na które nadepnąłeś przy skalowaniu?
Dave: Wchodzimy w mój żywioł. Zróbmy to bardziej taktycznie, a więc i techniczniej. Bo dotąd moje rady sprowadzały się do „używaj Claude Code, po prostu zapytaj model, bracie”. I zabawnie: to jest właściwa rada. Ale jest moment, gdy chcesya przejść na wyższy poziom i naprawdę opłaca się doszkolić i zrozumieć, jak działa oprogramowanie. Sprowadzam to do opisu architektury na wysokim poziomie — i są tam dwa rozróżnienia, które bardzo warto zbadać. Można to zrobić nawet z samym agentem: spędź chwilę, pytając o terminy, które zaraz padną.
Po pierwsze architektura na poziomie systemu: jak wszystkie składniki — backend, frontend, baza, czasem inne usługi — rozmawiają ze sobą. Większość produktów to kombinacja tych rzeczy. Kluczowe jest rozumienie roli każdego z nich, tego, jak się komunikują, co mają szczególnego i na co przy nich uważać. Zależy to od tego, co budujesz — aplikację webową, desktopową, mobilną czy ich kombinację — i od języka. Czy masz wyraźny podział: backend w Pythonie, Rust czy C, a warstwa wizualna w JavaScripcie, na przykład na Next.js — czyli zwykle zupełnie osobne bazy kodu? Czy może projekt żyje w jednym stacku, czyli zestawie technologii — np. wszystko w TypeScript: i backend, i frontend?
Kiedy sprawa robi się poważna, to jest dobre pierwsze pytanie do agenta: „buduję X i Y — jaki stack będzie najlepszy?”. Stack to słowo klucz. „Czy potrzebuję osobnego backendu i frontendu? Jakiej bazy? Mogę wszystko scalić?”. Dostaniesz przykłady — i drąż: „co to znaczy? jakie jest najprostsze rozwiązanie? co najlepiej pasuje do mojego przypadku?”. To ważny punkt wyjścia, bo w ramach języka można dużo — skalować w górę i w dół, refaktoryzować, rozbudowywać — natomiast przenoszenie projektu do innego języka, choć z agentami coraz prostsze, to zwykle nie jest zamiana, którą chcesz robić.
Sam musieliśmy ją przejść w Glido: zaczęliśmy na innym stacku niż obecny, bo na starcie nie zrobiliśmy porządnego rozeznania. Trochę przez strukturę zespołu — jedna osoba tutaj, druga tamtam — wybraliśmy kierunek, a po czasie okazało się, że trzeba inaczej. To jest właśnie mina, na którą nadepnęliśmy: wybraliśmy to, co znaliśmy, zamiast narzędzi zoptymalizowanych pod to, co ostatecznie chcieliśmy zbudować. Kiedyś taki wybór był w zasadzie przesądzony: jeśli dziesięć lat siedzisz w jakimś stacku, najpewniej go użyjesz. Dziś możesz spokojnie powiedzieć: „czuję się pewnie w tym, ale są dowody, że tamten będzie dużo lepszy pod nasz cel — bierzmy tamten”.
Architektura repozytorium, czyli wojna ze „spaghetti”
Dave: Druga płaszczyzna to architektura na poziomie projektu. To już wnętrze twojego repozytorium: jak układasz projekt w pliki i foldery, co tam ląduje, i jak porządkujesz kod na funkcje, klasy i moduły. Mniej krytyczna niż architektura systemu, ale wciąż warto mieć zgrubne pojęcie. Bo bazy „spaghetti” nadal się zdarzają — agenty są co miesiąc lepsze, ale ten bałagan narasta szybko właśnie przy vibe codowaniu, gdy skaczesz z pomysłu na pomysł i dużo eksperymentujesz.
To nowy sposób budowania: każesz coś zbudować, powstaje artefakt. „Zostawmy, nie podoba mi się, wrócimy później” — budujesz dalej i zapominasz. I masz śmietnik, a w środku niego kawałek logiki, którego naprawdę używasz i potrzebujesz, okalający go balast po funkcji-eksperymencie. Zaczynasz na tym budować nowe rzeczy — świetnie — ale wszystkie zależą od tego brudnego kawałka głęboko w kodzie. Tak powstaje spaghetti. Z czasem agentom trudniej się w tym połapać i odnaleźć elementy. I tu łapiesz błędy na skalę: nagle coś przestaje działać. Trzy miesiące było dobrze, a tu bum — bo usunąłeś funkcję „już niepotrzebną”, a w niej siedział fragment, którego wciąż potrzebowałeś. Rozumienie tego na wysokim poziomie jest bardzo cenne.
Dam ludziom jedną wskazówkę: jest na to znakomity skill — gotowy plik instrukcji, który podpina się do agenta, żeby zmienić sposób jego pracy. Autorski, od Matta, twórcy słynnego z publikowanych skilli. Nazywał się „improve codebase architecture”, chyba przerobił go na „codebase design” czy jakoś tak.
Nate: Znajdziemy go i wstawimy link w opisie.
Dave: Poszukaj u niego materiałów o poprawianiu architektury, o tworzeniu głębokich modułów, lokalności i pracy ze szwami między częściami kodu. Bardzo często używam tego skilla do przeglądu własnych baz kodu; on sam mówił, że stworzył go do walki z masowo generowanym kodowym chłamem (tzw. AI slop) i po to, żeby kod był łatwiejszy do nawigowania przez AI. I pomyśl, jakie to fajne: mówiłem, że dwa elementy wciąż dają największą dźwignię — architektura systemowa i architektura repozytorium. Na tę drugą jest po prostu gotowy skill: przeczytasz go, podłączasz do agenta — i już jesteś w tym lepszy. Że da się doskonalić w ten sposób — to samo w sobie jest niesamowite.
A frontend, baza, backend: spędź na tym dzień. Jeśli poważnie myślisz o budowaniu — po prostu pytaj. Zrób to na przerwie na lunch, na spacerze: poznaj, co te warstwy znaczą, jak rozmawiają ze sobą i jakie aspekty bezpieczeństwa dotyczą każdej z nich. Bo bezpieczeństwo dotyka całej aplikacji, ale baza, backend i frontend mają swoje konkretne obowiązki — i warstwy komunikacji między nimi również.
Nate: Fajnie, że przywołałeś tego Matta, bo właśnie o tym myślałem, gdy mówiłeś: pod maską inżynieria wciąż jest taka sama — zmieniła się rola człowieka. Te rzeczy są bystre i szybkie, ale zasady dobrego kodu to wciąż zasady dobrego kodu. Dla kogoś takiego jak ja — a pewnie i dla sporej części widzów — gdy padło „Python, C, Rust”, ktoś mógł pomyśleć: „co to w ogóle jest?”. A to istnieje od lat. Ludzie tacy jak on czy ty wiedzą, jak wygląda dobra baza kodu — i to znaczy, że możesz czerpać z cudzej wiedzy eksperckiej: zadając właściwe pytania, każąc agentowi robić rozeznanie, podpinając gotowe skille. To bardzo krzepiące: nie jesteś z tym sam. Jest mnóstwo materiałów od ludzi, którzy potrafią zdefiniować „dobrze” tam, gdzie ty jeszcze nie umiesz.
Bezpieczeństwo w pigułce: baza, backend, firewalle, sekrety
Nate: Ostatni temat, trochę go już tknąłeś: bezpieczeństwo. Nie tylko prywatność danych, ale i myślenie o tym, że aplikację mogą zhakować. Jak do tego podchodzić, zwłaszcza nie mając żadnego doświadczenia w cyberbezpieczeństwie?
Dave: Najfajniejsze jest to, że z samych podstaw można zajść naprawdę daleko. Bezpieczeństwo to wielka domena z poziomami, ale i ja nie wywodzę się z niej — nie nazwałbym siebie ekspertem; mamy w zespole osobę, która zna się na tym znacznie lepiej, i od niej przez lata zbierałem większość tego, co wiem. Rzecz w tym, że garstka rzeczy czyni cię praktycznie nie do zhakowania. Podejmę kilka przykładów.
Jest tu trochę wspólnego obszaru z tym, co nazywamy infrastrukturą. Mówiliśmy o architekturze systemu — backend, frontend, baza — a infrastruktura odpowiada na pytanie: gdzie te usługi mieszkają, gdzie są wdrażane, jak rozmawiają i jakie zapory sieciowe (firewalle) stoją wokół nich. Też warto w to zaglądnąć, choćby z ciekawości.
Zacznijmy od bazy. Większość budujących potrzebuje bazy danych: konta użytkowników, hasła, wszelkie informacje. Najpopularniejsza dziś opcja to Supabase. I Supabase jest świetny. Powiem każdemu: jeśli nie masz bardzo mocnego powodu, by go nie używać — używaj Supabase. Jesteś nietechniczny, dopiero zaczynasz? Supabase. Jest na tyle elastyczny, że zrobisz nim wszystko. Nie daj się zniechęcać ludziom mówiącym „tu potrzebujesz bazy niestrukturalnej” albo „dedykowanej bazy wektorowej” — Supabase ogarnia to wszystko. Po prostu go używaj. A jeśli masz mocny kontrargument przeciw, to znaczy, że jesteś już dość techniczny, żeby wybrać samodzielnie — rozumiesz, o co chodzi? Supabase da się też hostować we własnym zakresie, ale większości polecam chmurę: wchodzisz na stronę, zakładasz konto, tworzysz bazę, wybierasz plan — i masz.
Potem polecam poświęcić kilka godzin na kwestie bezpieczeństwa i dobre praktyki wokół Supabase. Z pudełka jest świetny, ale są rzeczy do ogarnięcia. Głównie chodzi o bezpieczeństwo na poziomie wierszy — row level security, mechanizm, który ogranicza dostęp do poszczególnych wierszy tabel zależnie od tego, kto pyta. Wyrzucam te terminy nie po to, żeby je tu omawiać, lecz żebyście w nie zaglądali: sprawdźcie, co znaczy i jak się z tym pracuje. Upewnij się, że baza ma mocne hasło — zdrowy rozsądek. Że konto w serwisie ma mocne hasło, najlepiej z logowaniem dwuskładnikowym. Banalne rzeczy — ale właśnie odsuwają ludzi i losowe boty zgadujące hasła. I to tyle, jeśli chodzi o bazę: używasz Supabase w chmurze, włączyłeś bezpieczeństwo na poziomie wierszy, masz mocne hasła i wszystkie usługi łączące się z bazą trzymają dane dostępowe w zmiennych środowiskowych — a nie w kodzie — i od strony bazy jesteś już w niezłej sytuacji. Można zrobić więcej, ale to dobry start.
Druga najważniejsza rzecz to backend, bo przez backend zwykle płyną dane. Frontend może pobierać dane wprosto z bazy albo przez backend — backend rozmawia z bazą i podaje dane dalej. Przy backendzie pytaj: w jakim języku piszesz i gdzie to wdrażasz? Na starcie kod żyje na twoim laptopie, na localhoście — testujesz. Wdrożenie to przeniesienie do chmury, gdzie inni mogą sięgnąć. Dróg jest wiele: Railway i Render z wdrażaniem jednym kliknięciem, wynajęty serwer VPS, Azure, AWS, GCP. Najważniejsze: po wdrożeniu backendu ustaw reguły zapory, które ograniczają do niego ruch. Znowu — temat do rozeznania, zależnie od platformy i języku, i idealny do przepracowania z agentem: „co to jest firewall i jak go ustawić?”. To samo dotyczy bazy — skonfigurujesz to w panelu Supabase.
Dlaczego to ważne? Zwykle jedna część aplikacji jest zwrócona do użytkownika — typowo frontend: to ludzie widzą w przeglądarce czy w aplikacji i tego używają. A backendu i bazy nikt z zewnątrz dotykać nie powinien; tylko twoja aplikacja powinna z nich czerpać dane. Frontend też jest gdzieś wdrożony — na dowolnej z tych usług — i jego wdrożenie ma konkretny adres IP, z którego sięga do bazy albo backendu. Wiem, że robi się technicznie, ale zapora to w gruncie rzeczy reguła: w backendzie i bazie „otwieraj drzwi tylko, gdy prośba przychodzi z adresu IP, który wpisałem na białą listę — czyli z mojego znanego frontendu lub aplikacji”. Zależnie od infrastruktury zasady się różnią, ale to jest istota dobrych praktyk: właściwe zapory oraz poprawne obchodzenie się z sekretami — kluczami API i danymi dostępowymi — tak, by nie dało się ich odczytać z kodu aplikacji. Żeby nikt nie wyczytał ich choćby przeglądając kod aplikacji webowej w przeglądarce. Jeśli chronisz sekrety, masz bezpieczeństwo na poziomie wierszy i stawiasz zapory na bazie i backendzie z białą listą adresów frontendu — to jest bezpieczeństwo w pigułce. Techniczne? Tak. Ale wystarczy wziąć ten fragment, wrzucić agentowi do czatu i wspólnie przerobić, co to oznacza dla twojej aplikacji.
Świadomość ważniejsza niż umiejętności
Nate: Świetnie — to była mała akademia. Z rozmowy wyłania się coś bardzo wyraźnego: przy wszystkich tych pojęciach technicznych chodzi głównie o świadomość. Możesz podsunąć temat agentowi i pozwolić mu myśleć i wdrażać — ale to ty musiałeś wiedzieć, o co zapytać. I to jest fajne.
Dave: To są właśnie „nieznane nieznane” — na początku, jako nowy twórca, musisz je odkryć, żeby umieć zadać agentom właściwe pytania. Nie chodzi o umiejętności, inteligencję czy lata szkolenia. Chodzi o świadomość: umieć pytać o właściwe rzeczy i — mając podstawowe rozumienie — jakoś oceniać odpowiedzi. Powiedzieć: „to jest ważne, a w to nie wchodzimy teraz, bo to nie są podstawy, to idzie głębiej i na tym etapie nie jest istotne dla mojej aplikacji”.
Na koniec: dżin w butelce i szansa dla każdego
Nate: Pięknie. Zakończmy jednym wielkim zdaniem, które zaczniesz tak: „Gdybym zaczynał dziś, bez doświadczenia technicznego, najbardziej cieszyłbym się z tego…” — co cię ekscytuje w tym, dokąd zmierza AI i co można z nim zrobić w budowaniu aplikacji?
Dave: Ładna prowokacja. Odpowiem tak: gdybym dopiero zaczynał i patrzył, co się dzieje wokół, najbardziej cieszyłbym się z szans, jakie to wszystko stwarza dla każdego z nas. Ja po studiach zupełnie przypadkiem trafiłem na zlecenie na własny rachunek i od tamtej pory praktycznie działam samodzielnie; budowałem na tym kolejne przedsięwzięcia — a dało mi to ogromną wolność i możliwość pracy nad tym, co sam chcę budować. I myślę, że dzięki tej wielkiej transformacji AI takie życie wchodzi w zasięg coraz większej liczby ludzi.
Powiesz: „gdy narzędzia się uproszczą, każdy będzie mógł”. Prawda — ale wciąż potrzebni są wykonawcy. Budowniczowie. To, że coś jest możliwe, nie znaczy, że każdy i każda firma faktycznie się za to weźmie. Dlatego okazji będzie mnóstwo: własne przedsięwzięcia, budowanie na własną rękę, sprzedaż, tworzenie treści, pomaganie firmom — lokalnym i większym — ekscytowanie się technologią i automatyzacją, doskonalenie rzemiosła po drodze i w końcu jego monetyzacja. Jeśli kogokolwiek to kręci — a znam twoją widownię, więc wiem, że kręci — to wskakujcie z całych sił. A nawet jeśli nie zaczynacie od zera i macie etat: zobaczcie, jak to robić obok pracy. Prowadzę całą społeczność freelancerów — deweloperów i specjalistów od danych — i dzielę się tym doświadczeniem, bo okazje są realne. Da się to pogodzić z pełnym etatem. Bierzesz projekt, a w trakcie dnia pracy po prostu odpalasz kolejnego agenta i on robi robotę. Możesz w przerwie na lunch pogadać z Claude’em przez telefon, dać mu jeden porządny, wzorcowy prompt — a gdy wieczorem wrócisz do domu, automatyzacja dla klienta jest zbudowana.
Ostatnio słuchałem podcastu Lexa Fridmana, z udziałem DHH — Davida Heinemeiera Hanssona — i określił to jako dżina w butelce. Twórcy oprogramowania mają teraz dżina w butelce: pomyślisz o czymś — i wypromptujesz to w istnienie. Bez limitu trzech życzeń. Pytasz dalej i dalej.
(Informacja dodatkowa: DHH — David Heinemeier Hansson, twórca frameworka Ruby on Rails, znany komentator rozwoju AI.)
Nate: Ogranicza cię tylko tygodniowy budżet tokenów.
Dave: Na tym trzeba uważać! Ale to znakomity opis. I sam to znasz, Nate: za każdym razem, gdy wychodzi nowy model, rzeczy, które potrafi, robią się coraz bardziej niedorzeczne. Kiedyś postęp mierzyło się w latach — spojrzysz rok wstecz i modele były nieporównywalnie lepsze. Dziś to się dzieje co kwartał: „nieźle, to jest o klasę lepsze niż to, co mieliśmy”. I nie widzę świata, w którymby to stanęło. Trzeba więc nauczyć się tych narzędzi, budować z nimi — i ostatecznie ułożyć sobie dzięki nim życie, jakie się chce. Bo budowanie dla samego budowania jest fajne, ale mamy też okazję: pomóc sobie, swojej rodzinie, ułożyć wokół tych narzędzi życie, które jeszcze kilka lat temu nie było możliwe.
Nate: Jedyny scenariusz, w którym postęp zwolni, to jeśli prowadzone dziś dyskusje o regulowaniu tempa rozwoju modeli zamienią się w realny standard i koordynację krajową z globalną. Zobaczymy. Moglibyśmy gadać o tym kolejną godzinę… Dzięki, że wpadłeś — bardzo merytoryczna rozmowa. Gdzie ludzie mogą cię znaleźć?
Dave: Dzięki, Nate. Mój kanał na YouTube — Dave Ebbelaar. Materiały głównie dla bardziej technicznej widowni. Ale czy to dziś cokolwiek zmienia? Do każdego tutorialu robię teraz także przewodniki-poradniki, bo to takie proste: kiedyś nagrywałem tutorial i uczyłem; dziś nagrywam tutorial i mówię AI: „zrób z tego pełną stronę dokumentacji krok po kroku” — i każdy może się przez nią przejść. Robię głównie duże projekty typu „jak zbudować to”. Właśnie wrzuciłem film o budowaniu całej bazy wiedzy firmy — i to porządnie, nie jako projekt zabawkowy: coś, co realnie można zaoferować firmie. Materiał jest dla technicznych, ale wystarczy wycelować swojego agenta w repozytorium i poradnik — i zbuduje to za ciebie. Więc: YouTube, Dave Ebbelaar.
Nate: Świetnie. Dzięki za wpadnięcie — może powtórzymy kiedyś.
Dave: Cała przyjemność po mojej stronie. Na razie.