O czym jest ten film
- Weszliśmy w erę oprogramowania osobistego — małych narzędzi zrobionych pod jedno konkretne życie, których żadna masowa aplikacja nie zastąpi.
- Prawie wszystko, co ludzie chcą zbudować, mieści się w pięciu kształtach: narzędzie lokalne, aplikacja webowa, natywna aplikacja mobilna, usługa działająca w tle, projekt sprzętowy.
- Kształt oprogramowania wynika z opisu życzenia — z tego, skąd bierze się sygnał, gdzie ma się pojawić wynik i kto ma go widzieć — jeszcze zanim padnie nazwa jakiegokolwiek narzędzia.
- Dla osoby nietechnicznej domyślną ścieżką jest Lovable: hostowany builder, w którym opisujesz aplikację i publikujesz ją jednym kliknięciem. Alternatywy to Replit i Bolt.
- Ścieżka „więcej kontroli” to agent kodujący (Codex albo Claude Code) plus GitHub Desktop, Supabase i Vercel — więcej kont, ale każdy element wymienny osobno.
- Model, agent kodujący i hostowany builder to trzy różne warstwy; można je mieszać między dostawcami.
- Sprzęt przestał być barierą — agent kodujący rozpozna płytkę ze zdjęcia, wyjaśni piny i pomoże w diagnostyce.
- Cztery pliki tekstowe przy projekcie (
project.md,decisions.md,scenarios.md,agents.md/claude.md) zmieniają rolę modelu z wykonawcy w partnera, który musi ujawniać swoje decyzje. - Bezpieczeństwo w prostych słowach: prywatne domyślnie, gotowy system logowania, klucze w sekretach hosta, kontrola dostępu wymuszona w bazie, przetestowany backup.
- Nie ma substytutu dla ludzkiego testu — deklaracja agenta „gotowe” nie jest dowodem, że aplikacja działa.
Redakcyjne tłumaczenie
Życzenie i droga do działającego programu
Założę się, że wiesz, co chcesz zbudować z pomocą AI, tylko nie wiesz, jak zamienić to życzenie w coś, co naprawdę działa — na telefonie, na komputerze albo na małym pudełku gdzieś w domu. Uprośćmy to maksymalnie. Istnieje pięć kształtów oprogramowania, które pokrywają większość rzeczy, jakie ludzie chcą tworzyć. Dam ci kompletną mapę, z której sam bym dziś korzystał jako osoba nietechniczna: co budować, na co się zapisać i czy dana ścieżka wymaga Lovable, Replita, Codeksa, Claude Code, czy może modelu takiego jak GLM 5.3. I od razu zdradzę zakończenie: jeśli jesteś osobą nietechniczną, zacząłbym od Lovable. Wyjaśnię dlaczego.
Nazywam się Nate B. Jones. Przez dwadzieścia lat budowałem produkty — od Amazona po startupy. Pomagałem liderom na całym świecie wdrażać AI w firmach. Teraz chcę pomóc ci zbudować życie, jakiego szukasz, z pomocą AI. AI naprawdę nie jest straszne. Nie jesteś w tyle.
Wielu z nas nosi w głowie coś takiego: wyświetlacz, który mówi, czy autobus twojego dziecka faktycznie jedzie, albo prywatne narzędzie pilnujące każdej decyzji i naprawy w domu. Cokolwiek to jest, nie musisz uczyć się na pamięć całego stosu technologicznego. Wystarczy, że zrozumiesz wybory na tyle dobrze, by podejmować po jednej dobrej decyzji naraz.
Dwa przykłady, które pokazują, o co chodzi
Wczoraj widziałem człowieka z Amsterdamu, który rozwiązał problem z promami — pewnie irytował go od lat. Publikowany rozkład był na tyle często błędny, że stał się bezużyteczny. Komercyjne kanały z pozycjami statków na żywo kosztują setki euro miesięcznie, więc odpadały. Zorientował się, że informację można dociągnąć do źródła: do AIS, czyli sygnału radiowego, który statki i tak muszą nadawać z mocy prawa. Wycenił odbiornik, antenę i Raspberry Pi, które mogłoby nasłuchiwać z jego domu. Cały zestaw kosztował około 200 euro — po to, żeby wiedzieć, kiedy wyjść z domu.
(Informacja dodatkowa: AIS — Automatic Identification System — to otwarty, nieszyfrowany system meldunków radiowych, w którym statki nadają swoją pozycję, kurs i prędkość. Odbiór jest legalny i możliwy zwykłym tanim odbiornikiem SDR.)
Widziałem też osobę, która zbudowała aplikację dokładnie dla domu, w którym mieszka z żoną. Aplikacja zna ich konkretne sprzęty, konkretne rośliny, ich ogród. Sama tworzy zadania konserwacyjne na dany tydzień. Trzyma w jednym miejscu instrukcje do wszystkiego, co trzeba utrzymywać, i typowe wskazówki na wypadek awarii.
To nie są wyrafinowane programy. Są małe, wręcz maleńkie. Są też niesamowicie użyteczne, bo pasują do życia jednej osoby tak, jak nigdy nie dopasuje się aplikacja masowa. Weszliśmy w erę oprogramowania osobistego — i przyszedłem ci powiedzieć, że nie musisz być technicznym człowiekiem, żeby swoje osobiste oprogramowanie zbudować.
Zacznij od zmiany, którą chcesz zobaczyć w swoim życiu
W projekcie promowym pożądana zmiana jest banalnie prosta: chcę spojrzeć na telefon i wiedzieć, kiedy naprawdę przypłynie następny prom. Rozkład jest niewiarygodny, więc nie można mu ufać. Użyteczny sygnał jest gdzieś tam, w świecie — to transmisja radiowa ze statku. Wynik musi pojawić się na telefonie i prawdopodobnie służy tylko jednemu gospodarstwu domowemu. Jeśli coś zawiedzie, ktoś poczeka dłużej albo spóźni się na prom. Irytujące, ale to nie medycyna i nie system krytyczny dla bezpieczeństwa. To po prostu aplikacja, która ułatwia życie.
Sam ten opis mówi nam bardzo dużo. Projekt musi odbierać fizyczny sygnał ze świata zewnętrznego. Potrzebuje małego komputera przy antenie. Musi zapisywać świeże dane. Musi produkować ekran albo alert przyjazny telefonowi. Sklep z aplikacjami, publiczny system kont, infrastruktura dla milionów ludzi — to dołożyłoby ogrom pracy zupełnie nie na temat.
Weźmy aplikację do utrzymania domu. Pożądana zmiana: żona i ja mamy wiedzieć, czego ten dom potrzebuje, kiedy tego potrzebuje i jak to zrobić. Informacje pochodzą z tabliczek znamionowych, z instrukcji, ze zdjęć, z dat serwisów, z roślin, z historii domu. Dwie osoby muszą widzieć i zmieniać te same rekordy, żeby wiedzieć nawzajem, co zostało zaktualizowane. Ma działać na telefonie. Pomyłka bywa uciążliwa, ale zwykle nie jest końcem świata — użyjesz nie tego klucza przy syfonie albo zapomnisz podlać trawnik, i jakoś to będzie.
To wskazuje na prywatną aplikację webową ze wspólną bazą danych, miejscem na zdjęcia i paroma domowymi kontami. Życzenie — pomyśl o tym niemal w stylu Disneya: składasz życzenie, ono się spełnia — ujawnia więc kształt techniczny, zanim jeszcze wybierzemy model i poprosimy go o napisanie choćby linijki kodu.
Pięć kształtów oprogramowania
Pierwszy: narzędzie lokalne. Działa na jednym komputerze i korzysta z plików albo malutkiej bazy danych na tym komputerze. To absolutnie najprostsza droga dla czegoś, z czego korzystasz tylko ty: organizator dokumentów, prywatne narzędzie do researchu, program, który zmienia nazwy zdjęć i je sortuje. Może nigdy nie potrzebować strony ani logowania.
Drugi: aplikacja webowa. Otwiera się z linku, działa w przeglądarce i zwykle daje się dodać do ekranu głównego telefonu. To domyślny wybór, który poleciłbym dla większości oprogramowania osobistego — chyba że masz dobry powód, by skomplikować sobie życie. Jedna wersja działa na laptopie, na telefonie, także na Androidzie. Możesz ją udostępnić małżonkowi albo kilku współpracownikom bez rejestracji w żadnym sklepie z aplikacjami i bez udawania, że jesteś deweloperem Apple.
Trzeci: natywna aplikacja mobilna. To właśnie wyobraża sobie wielu z nas na hasło „aplikacja”, bo Apple nas tak wytresowało. Ale wiąże się z większą pracą. Potrzebujesz jej, gdy program zależy od głębszej funkcji telefonu: niezawodnych powiadomień push, Bluetootha, lokalizacji w tle, NFC — albo gdy naprawdę zależy ci na dystrybucji przez sklep. Jeśli żadna z tych rzeczy nie jest ci potrzebna, nie wskakuj do basenu z aplikacjami. Zacznij od weba.
Czwarty: usługa działająca w tle. Może w ogóle nie mieć ekranu. Budzi się według harmonogramu albo w reakcji na zdarzenie, wykonuje zadanie i wysyła wynik gdzieś dalej. Taka usługa może codziennie rano sprawdzać publiczny rejestr, przetwarzać plik zaraz po jego pojawieniu się albo wysyłać alert, gdy czujnik przekroczy próg. To bardzo podstawowe rzeczy: bierzemy dane z jednego miejsca i wkładamy je w drugie.
Piąty: projekt sprzętowy. Odbiornik promowy, domowy wyświetlacz, własny przycisk, kamera, czujnik w fabryce. Oprogramowanie musi mieszkać tak blisko świata fizycznego, jak to możliwe. Raspberry Pi jest tu bardzo użyteczne, bo to po prostu mały komputer ogólnego przeznaczenia. ESP32 sprawdza się, gdy zadanie sprowadza się do odczytu jednego czujnika albo sterowania jednym urządzeniem. Home Assistant przydaje się, gdy urządzenia już są w domu, a ty chcesz mieć jedno miejsce, które je spina.
(Informacja dodatkowa: ESP32 to popularny mikrokontroler z Wi-Fi i Bluetooth, kosztujący kilkanaście–kilkadziesiąt złotych. Home Assistant to otwarte oprogramowanie do zarządzania inteligentnym domem, uruchamiane zwykle właśnie na Raspberry Pi.)
Kiedy znasz kształt, wybór narzędzi staje się prosty
Do najszybszej pierwszej aplikacji webowej użyłbym prostego hostowanego buildera AI. Tu wchodzi Lovable — najłatwiejszy, jaki mogę polecić. Do tej samej kategorii należą Replit i Bolt. Opisujesz oprogramowanie, builder tworzy projekt, pokazuje ci podgląd i daje sposób na publikację. Serwis ma już przygotowane środowisko deweloperskie, więc nie musisz instalować języka programowania, uruchamiać serwera ani rozumieć wiersza poleceń, zanim zobaczysz pierwszy działający efekt. Lovable jest mocnym domyślnym wyborem, gdy efektem ma być czysta aplikacja webowa, a ty chcesz najkrótszej możliwej drogi od opisu do interfejsu.
Przy aplikacji do utrzymania domu możesz od tego zacząć: podłączasz GitHuba, tworzysz pierwszy ekran i dodajesz rekordy dla jednego urządzenia. GitHub to miejsce, w którym trzymałbym kopię kodu źródłowego i historię zmian. Lovable tego nie wymaga — ale jeśli podłączysz go od początku, projekt staje się przenośny i możesz go zabrać, gdzie chcesz. Konfiguracja GitHuba nie jest trudna; opisałem ją w przewodniku publikowanym na Substacku razem z tym materiałem.
Lovable Cloud czy Supabase — pytanie, które naprawdę ma znaczenie
W pewnym momencie Lovable zada ci ważne pytanie: czy dane mają mieszkać w Lovable Cloud, czy aplikacja ma się podłączyć do usługi bazodanowej o nazwie Supabase. Lovable Cloud to najprostsza droga, bo builder zarządza bazą i logowaniem za ciebie. Supabase wymaga więcej konfiguracji, ale trzyma bazę i uwierzytelnianie w oddzielnym serwisie, zbudowanym wokół powszechnie używanego standardu bazodanowego, czyli Postgresa.
I to jest dokładnie to samo pytanie co przy GitHubie: jak bardzo zależy ci na dostępie do tego z innej strony w przyszłości? Jeśli to twoja pierwsza osobista aplikacja i celem jest po prostu uruchomić coś użytecznego — Lovable Cloud jest zupełnie rozsądny. Jeśli nie czujesz się na siłach z GitHubem za pierwszym razem, to też w porządku. Ale jeśli informacje są na tyle ważne, że już teraz zależy ci na możliwości przeniesienia aplikacji gdzie indziej albo zbudowania kolejnego narzędzia na tych samych danych — użyłbym Supabase od początku. To trochę więcej pracy, ale zmiana interfejsu jest zwykle dużo łatwiejsza niż przenoszenie lat danych. Podejmij tę decyzję świadomie — i nie bój się jej podjąć. W obu wariantach będzie dobrze.
Replit to mocna alternatywa, gdy projekt potrzebuje czegoś więcej niż interfejsu webowego. Może używa języka skryptowego jak Python, może potrzebuje stale działającego serwera, zaplanowanego zadania albo builda mobilnego. Replit upycha większość tej ścieżki w jednej usłudze: kontrolujesz środowisko budowania, bazę, uruchomioną aplikację i publikację. To bardzo wygodne. Oznacza też, że większa część projektu zależy od jednego dostawcy. Jeśli budujesz w Replicie, to budujesz w Replicie — tam to mieszka.
Bolt to kolejna droga do szybkiej pełnej aplikacji webowej: interfejs, baza, uwierzytelnianie, storage i publikacja w jednym środowisku. Obowiązuje ta sama zasada własności: trzymaj kopię źródeł, wiedz, gdzie mieszkają twoje dane, i wiedz, co trzeba by zrobić, żeby odejść z aplikacją i danymi w całości.
Ścieżka z większą kontrolą
Załóżmy, że chcesz iść nieco dalej i mieć więcej kontroli na całej trasie. Chcesz użyć agenta kodującego na własnym komputerze, trzymać projekt na GitHubie, korzystać z osobnej usługi na dane i jeszcze innej do publikacji. To wciąż nie jest poza zasięgiem początkujących. Typowy zestaw dla początkującego w tym wariancie to Codex albo Claude Code, do tego GitHub Desktop, Supabase i Vercel do publikacji.
Agent kodujący jest tu budowniczym. Widzi pliki projektu, tworzy je i zmienia, potrafi uruchomić aplikację lokalnie, przeczytać błędy i spróbować jeszcze raz. GitHub Desktop daje wizualny sposób zapisywania działających wersji i cofania się po nieudanej zmianie albo błędzie. Supabase daje wspólną bazę, logowanie i przechowywanie plików. Vercel wystawia aplikację do sieci i daje linki podglądowe, żebyś mógł sprawdzić zmianę, zanim zastąpi wersję, z której ludzie korzystają. Sam używam Vercela niemal codziennie, kiedy chcę coś wystawić, żeby ludzie mogli to zobaczyć.
Ta trasa ma więcej kont i więcej wyborów niż Lovable. Ma za to inną zaletę: łatwiej wymienić jeden element bez wymiany całości. Model może się zmienić, a baza zostaje. Host może się zmienić, a kod zostaje. Interfejs może się zmienić bez ruszania danych — nie przenosisz swoich domowych rekordów, tylko podmieniasz okno na to samo pomieszczenie.
Model, agent, builder — trzy różne warstwy
Codex i Claude Code to agenci kodujący, napędzani modelami. Napędzać je mogą modele OpenAI albo modele Claude. Możesz nawet użyć modelu otwartego, takiego jak GLM. Wszystkie dostarczają zdolności rozumowania i pisania kodu, z których te środowiska korzystają.
(Informacja dodatkowa: w materiale pada raz „GLM 5.3”, raz „GLM 5.2” — autor ma na myśli tę samą rodzinę otwartych modeli.)
Ludzie często porównują te wszystkie rzeczy tak, jakby były jednym rodzajem produktu. Chcę postawić sprawę jasno. Model to po prostu warstwa rozumowania i kodowania pod spodem. Agent kodujący daje temu modelowi dostęp do folderu, poleceń, podglądów i narzędzi. Hostowany builder pakuje agenta razem ze środowiskiem i przyciskiem „opublikuj”.
Możesz wybrać Codeksa, bo lubisz jego środowisko pracy. Możesz wybrać Claude Code, bo podoba ci się sposób, w jaki Claude podchodzi do projektu. A jeśli jesteś gotów skonfigurować klucz API, możesz użyć modelu takiego jak GLM przez obsługiwane narzędzie. Model i środowisko pracy nie muszą pochodzić od tej samej firmy — powtarzam to uparcie, bo ludzie zakładają, że skoro używam Codeksa, to musi to być model OpenAI. Możesz wymienić samą obudowę. To właśnie różnica między narzędziem a modelem.
Przy pierwszym projekcie wybierz jedno środowisko. Nie wpuszczaj trzech agentów do projektu, bo wydaje ci się to fajne. Wolność bierze się z tego, że jesteś właścicielem plików, danych i decyzji, i czujesz, że panujesz nad tym, co robi model. Nie bierze się z tego, że każesz trzem modelom kłócić się o każdy przycisk, żeby móc powiedzieć, że robisz multi-agenta.
Kiedy chcesz dotknąć świata fizycznego
Przykład promowy jest tu dobry. Potrzebujesz sygnału, który wciągniesz do projektu — w tym wypadku radia AIS. Raspberry Pi jest tam nie dlatego, że jest zabawne (choć jest), tylko dlatego, że odbiornik i antena potrzebują małego komputera w domu, który zdekoduje sygnał i będzie działał bez przerwy. Mała lokalna baza danych o nazwie SQLite może przechowywać świeże pozycje statków i wyliczenia czasu przybycia. Prywatna strona na Pi może pokazać wynik. A narzędzie takie jak Tailscale pozwala zatwierdzonym urządzeniom domowym dotrzeć do tej strony spoza domu, bez wystawiania Raspberry Pi do internetu. Tailscale ma w sobie odrobinę magii.
(Informacja dodatkowa: Tailscale tworzy prywatną sieć między twoimi urządzeniami — działa to jak VPN, w którym połączyć się mogą tylko urządzenia, którym na to pozwolisz.)
Przy światłach, termostatach, gniazdkach czy istniejących czujnikach zacznij od Home Assistant, zanim zbudujesz własną platformę. A jeśli potrzebujesz nowego czujnika temperatury, ruchu albo wilgotności, może wystarczy ci ESP32 z ESP Home. Chodzi mi o to, że im bliżej jesteś czujników, które i tak są w zwykłym inteligentnym domu, tym mniej musisz myśleć o projektach typu Raspberry Pi i tym więcej masz gotowych rzeczy z półki, które łatwo spiąć. Jeśli masz radio, kamerę albo urządzenie USB i chcesz jeden prosty strumień danych — szukaj najprostszej możliwej opcji. A jeśli już potrzebujesz Raspberry Pi, agent kodujący poradzi sobie z nim bez problemu. Nie musisz dziś umieć programować, żeby go użyć.
Jeśli twoja pierwsza reakcja brzmi „ale ja nie wiem, jak to podłączyć” — to jest właśnie miejsce, w którym agent kodujący pomaga. Ludzie już teraz pokazują agentom zdjęcia płytek i komponentów i mówią: nie wiem, co robię, zidentyfikuj połączenia, wyjaśnij, za co odpowiada każdy pin, sprawdź mój proponowany układ i pomóż go zdiagnozować. Claude to zrobi, Codex to zrobi. To ogromna wartość — mieć narzędzie, które stoi ci nad ramieniem jak starszy inżynier i mówi, jaki jest następny krok. Wcześniej tego nie mieliśmy i mam wrażenie, że wielu ludzi nie zdaje sobie sprawy, że to możliwe. Granica między człowiekiem od softu a człowiekiem od sprzętu nigdy nie była łatwiejsza do przekroczenia.
A jeśli naprawdę potrzebujesz aplikacji mobilnej
Jeśli twoje życzenie faktycznie wymaga natywnej aplikacji, użyłbym agenta kodującego razem z Expo, backendem w rodzaju Supabase i Expo Application Services. Expo pozwala z jednego projektu zrobić aplikację na iOS i Androida, a usługa budująca bierze na siebie sporą część podpisywania i pakowania. Nadal będziesz potrzebować kont deweloperskich Apple i Google do dystrybucji w sklepach i nadal będziesz musiał przejść ich weryfikację. Nie będę ściemniał: to trochę proces.
Dlatego moja rekomendacja brzmi: udowodnij swój pomysł jako prywatną aplikację webową, chyba że funkcja telefonu jest absolutnie nieodłączna od pomysłu. Nie chcesz płacić podatku sklepowego po to, żeby dopiero sprawdzić, czy twojemu małżonkowi w ogóle spodoba się lista obowiązków domowych. To byłoby głupie. Po co komplikować?
Pułapka, w którą wpada nietechniczny budowniczy
Mamy już główne trasy — i tu zaczyna się miejsce, w którym osoba nietechniczna daje się złapać. Model może wybrać znajomą sobie bazę danych, nie tłumacząc wyboru. Może dodać płatną usługę. Może upublicznić aplikację. Może mimochodem umieścić prywatne informacje w niewłaściwym miejscu. Ludzie to przeczuwają i się boją: „właśnie dlatego nie chcę się w to bawić”.
Odpowiedzią nie jest jeden magiczny prompt, bo tak się po prostu nie buduje oprogramowania. Odpowiedzią jest zmiana roli, jaką model odgrywa w projekcie. Model — jakikolwiek — ma zachowywać się jak partner budowlany, który musi ujawniać swoje wybory.
Trzymałbym przy projekcie cztery małe pliki tekstowe. Każdy model potrafi je przeczytać.
Pierwszy to project.md. Mówi możliwie prosto, dla kogo jest to oprogramowanie, co dzieje się dziś, co ma się dziać zamiast tego — stan przed i po — gdzie oprogramowanie ma działać i jakie informacje muszą zostać prywatne.
Drugi to decisions.md. Za każdym razem, gdy model dochodzi do wyboru wpływającego na koszt, dane, dostęp, wdrożenie albo na możliwość zmiany decyzji później, ma zapisać opcje, rekomendację i uzasadnienie — zwłaszcza jeśli decyzja zapadła w rozmowie z tobą.
Trzeci to scenarios.md. Zawiera realne sytuacje, które oprogramowanie musi obsłużyć: dodaj urządzenie ze zdjęcia zrobionego telefonem, znajdź właściwą instrukcję, utwórz kolejne zadanie konserwacyjne, oznacz jako wykonane. To konkret. Te scenariusze tworzą przypadki testowe, które model ma sprawdzać w trakcie budowania.
Czwarty to krótki plik z instrukcjami dla agenta budującego. Codex czyta agents.md, Claude Code czyta claude.md. Trwała prawda o projekcie zostaje w pierwszych trzech plikach; ten ostatni mówi wyłącznie bieżącemu narzędziu, jak ma się zachowywać.
Twoje instrukcje dla modelu są proste. Kiedy dochodzisz do wyboru wpływającego na dane, koszt, prywatność, przenośność, wdrożenie albo utrzymanie — wyjaśnij mi go zwykłym językiem. Daj dwie–trzy realistyczne opcje. Zarekomenduj jedną. Powiedz, co staje się łatwiejsze, a co trudniejsze do zmiany później. Pytaj, zanim zrobisz — zwłaszcza jeśli coś jest publiczne, kosztowne albo destrukcyjne. Właśnie dlatego zalecam trzymanie kodu na GitHubie. I klasyk problemów vibe codingu: trzymaj klucze i sekrety poza kodem. Możesz to modelowi po prostu powiedzieć; jeśli nie wiesz dokładnie, co to znaczy, model będzie wiedział.
Nawiasem mówiąc, to jedna z lepszych rzeczy ostatniego półrocza: modele nauczyły się na błędach, które popełnialiśmy z vibe codingiem w 2025 roku, i są dziś dużo lepsze w dobrych praktykach od samego początku. Możesz też kazać modelowi testować na prawdziwym wyniku: pokaż mi działający efekt, sprawdź go względem realnych sytuacji, o które prosiłem. Tak właśnie kierujesz model w bardziej użyteczną część przestrzeni rozwiązań. To jak prowadzenie statku. Nie zgadujesz jednego zdania promptu, po którym powstanie idealny program — po prostu jasno mówisz, czego chcesz, dajesz modelowi stabilne zadanie, trwały kontekst w opisanych plikach i sposób na jawne ujawnianie decyzji zamiast zakopywania ich w kodzie i domysłach.
Słownik części, po ludzku
To fragment, który warto zapisać i odtworzyć jeszcze raz, jeśli nie miałeś do czynienia z oprogramowaniem.
Interfejs to to, co człowiek widzi i czego dotyka.
Baza danych pamięta ustrukturyzowane informacje: urządzenie, numer modelu, datę serwisu, zadanie. Cokolwiek masz w głowie w formie uporządkowanej — od tego jest baza.
Uwierzytelnianie (authentication) dotyczy bezpieczeństwa i zmusza program do niezawodnej odpowiedzi na pytanie: kim jesteś?
Autoryzacja (authorization) odpowiada na pytanie: co wolno ci zobaczyć albo zmienić? Logowanie to uwierzytelnianie. Reguła, że moje gospodarstwo domowe nie może czytać rekordów innego gospodarstwa, to autoryzacja.
Host to komputer, który utrzymuje oprogramowanie dostępnym. Lovable może hostować za ciebie. Vercel jest częstym hostem dla aplikacji webowej. Render przydaje się przy usłudze w Pythonie. Raspberry Pi też może być hostem, gdy oprogramowanie ma mieszkać wyłącznie w twoim domu.
Integracja to wciągnięcie czegoś z zewnątrz: prognozy pogody, sygnału ze statku, kalendarza, usługi mailowej, innego modelu AI, do którego się odwołujesz.
Nie potrzebujesz wszystkich tych części naraz. Potrzebujesz zrozumieć, czego chcesz — a wtedy będziesz miał słowa, żeby to rozgryźć. Narzędzie porządkujące pliki na laptopie może nie potrzebować żadnych kont, żadnej bazy w chmurze i żadnego hosta. Ekran promowy może zacząć od SQLite na Raspberry Pi. Aplikacja domowa potrzebuje wspólnej bazy, bo dwie osoby muszą widzieć tę samą aktualną informację na różnych telefonach — i tyle.
Którą bazę wybrać
Powtórzę w tylu wariantach, w ilu potrafię: wybierz najprostsze możliwe rozwiązanie. Dla niezależnej osobistej aplikacji webowej, do której chcesz mieć dostęp również później, Supabase jest bardzo mocnym domyślnym wyborem — łączy bazę Postgres z zarządzanym logowaniem, przechowywaniem plików i usługami backendowymi, których i tak będziesz potrzebować. Alternatywą jest Firebase, dobry przy projekcie mobile-first albo już osadzonym w usługach Google. Własna baza buildera bywa najszybszą opcją. A SQLite jest zwykle najprostszym możliwym wyborem, bo dosłownie mówisz agentowi „skonfiguruj to na moim laptopie” i on to robi. Jeśli to wszystko, czego chcesz — tylko ty, na swoim laptopie — nie musisz nikomu nic płacić.
Pytanie nie brzmi więc „która baza jest najlepsza”. Pytanie brzmi: jaki jest najprostszy sposób dostarczenia tych danych osobie, która ich potrzebuje? Może to tylko ja, może ja i jeszcze jedna osoba. Zadaj sobie to pytanie — możesz je nawet zadać swojemu agentowi kodującemu.
Wdrożenie brzmi trudniej, niż jest
Wdrożenie oznacza tylko tyle: umieścić działający program tam, gdzie będzie działał dalej, i zadbać, żeby dotarła do niego zamierzona osoba. Może to być tak proste jak kliknięcie „publish” w Lovable i dostanie linku. Na Vercelu projekt łączy się z GitHubem: proponowana zmiana dostaje link podglądowy, a gdy ją zaakceptujesz, główna wersja staje się produkcyjną. Możesz wprost poprosić agenta kodującego, żeby spiął to z Vercelem i zrobił większość tej roboty za ciebie. Na Raspberry Pi wdrożenie może oznaczać utrzymywanie usługi w domu i udostępnienie jej tylko zatwierdzonym urządzeniom przez Tailscale — Codex albo Claude Code pomogą go skonfigurować. Przy Expo wdrożenie może oznaczać wewnętrzny build telefoniczny dla rodziny, zanim w ogóle pomyślisz o sklepie.
Zawsze wiedz, która wersja jest podglądem, a która prawdziwa — zwłaszcza w projekcie, który będziesz aktualizował. Agent nie powinien podmieniać działającej wersji, kiedy ty wciąż zastanawiasz się, czy nowa jest dobra. Zadbaj o to, żeby projekt przeszedł twój własny test zdrowego rozsądku, zanim go opublikujesz.
Bezpieczeństwo w zwykłych słowach
Chcesz, żeby twoje aplikacje były domyślnie prywatne. Wystaw je do publicznego internetu tylko wtedy, gdy naprawdę potrzebujesz publicznego dostępu. Używaj gotowego, zarządzanego systemu logowania — nie każ agentowi wymyślać przechowywania haseł, skoro istnieją usługi, które zrobią to za ciebie.
Sekrety, czyli klucze API i hasła, trzymaj w ustawieniach sekretów udostępnionych przez hosta; Vercel ma do tego osobny mechanizm. Nie mają czego szukać na widocznej stronie, w kodzie, na zrzucie ekranu, w transkrypcie czatu ani na GitHubie. Codex i Claude Code oba dobrze to rozumieją.
Zdecyduj, kto może czytać i zmieniać każdy typ informacji — i wymuś tę decyzję w bazie danych. Ukrycie przycisku to nie jest kontrola dostępu. Kontrola dostępu jest egzekwowana na poziomie bazy; Supabase jest w tym bardzo dobry. Jeśli z aplikacji korzystają dwa gospodarstwa domowe albo więcej, musisz utworzyć wiele kont i zadbać, żeby każde widziało wyłącznie rekordy przypisane do swojego logowania. To jedna z najczęstszych i najpoważniejszych wpadek w publicznym oprogramowaniu i bardzo łatwo ją przeoczyć, kiedy myśli się tylko o interfejsie i o tym, czy wygląda na skończony. Myśl o tym tak: muszę mieć pewność, że okno na te dane pokazuje wyłącznie dane, do których ta osoba ma prawo. I wymagaj od agentów, żeby tego pilnowali — uczyń z tego część testowanych scenariuszy.
Jeśli twoje dane są ważne, rób kopie zapasowe i udowodnij, że umiesz je odtworzyć. Zrób test: zrobiłem backup, teraz go przywracam, teraz sprawdzam, że przywrócenie się udało. Dla niektórych danych to nieistotne — sam budowałem kiedyś bazę polubień i zakładek z Twittera i mogę żyć z tym, że nie jest idealna. Ale dopasuj to do własnych standardów, a standardy zmieniaj razem ze zmianą profilu ryzyka. Prywatne przypomnienie o podlaniu roślin to jedno. Jeśli masz do czynienia z płatnościami, danymi dzieci, informacjami medycznymi albo dokumentami prawnymi — zleć przegląd oprogramowania, zanim zaczniesz go używać. Dlatego właśnie mówię: przy aplikacji osobistej nie zaczynaj od wrażliwych informacji. Nie włączaj sobie trybu hard na starcie. Zacznij od czegoś prostszego i pnij się w stronę bardziej bezpiecznych aplikacji.
Testowanie: nie ma substytutu dla człowieka
Niezależnie od poziomu bezpieczeństwa potrzebujesz sposobu, żeby wiedzieć, że program działa. Nie musisz zaczynać od słownika testera. Wystarczy, że spiszesz sytuacje, które mają znaczenie, i sprawdzisz je na urządzeniu, na którym naprawdę będziesz z tego korzystać.
Pamiętam, jak pracowałem nad czymś z moją dziewięcioletnią córką. Powiedziała: „Tato, moja aplikacja nie ma żadnych błędów”. Zapytałem, ile testowała. Odpowiedziała: wcale — no, może pięć minut. To nie jest wystarczające testowanie. Musisz sprawdzić, czy aplikacja działa we wszystkich scenariuszach, które napotkasz w normalnym użyciu.
Dla aplikacji domowej: czy mogę sfotografować urządzenie i utworzyć poprawny rekord? Czy aplikacja zachowuje numer modelu? Czy moja żona widzi tę samą listę zadań co ja? Czy któreś z nas może oznaczyć zadanie jako wykonane tak, żeby pokazało się to na drugim telefonie? Co się dzieje, gdy zdjęcie jest nieczytelne? Testuj także te ścieżki, przy których myślisz „to może pójść źle”. Sprawdź, co się wtedy stanie.
Nie ma substytutu dla ubrudzenia sobie rąk. Próbowałem tego: nie możesz po prostu poprosić agenta, żeby przetestował wszystko za ciebie. Nie możesz poprosić Lovable, Codeksa ani Claude Code i przyjąć, że jak wracają z komunikatem „gotowe”, to naprawdę jest gotowe. Musisz przetestować i sprawdzić, bo nie ma zamiennika dla człowieka, który mówi: to faktycznie działa.
Narzędzia, które autor zbudował
Jeśli zastanawiasz się, co zbudowałem, żeby ci w tym pomóc — przejdę przez kilka rzeczy, które wypuściłem dla swojej społeczności.
Open Brain przydaje się, gdy oprogramowanie potrzebuje wybranego osobistego kontekstu, dostępnego między narzędziami. Jest dobre w tych miękkich, nieostrych rzeczach, które czynią aplikację naprawdę wartościową. W aplikacji domowej zwykła baza trzyma urządzenia, daty serwisów i zadania. Open Brain dobrze radzi sobie z przechowywaniem mniej ustrukturyzowanego kontekstu w uporządkowany sposób: co powiedział technik, który oglądał lodówkę? Dlaczego wybrałeś tę część do zmywarki? Które problemy wracają? Dlaczego kran wciąż cieknie? Taki osobisty kontekst pozwala AI w aplikacji rozumieć dom o wiele lepiej, niż potrafi to sama baza danych.
Open Skills przydaje się, gdy chcesz, żeby twój agent budujący za każdym razem trzymał się tej samej metody. Instrukcja typu „pokazuj wybory”, „chroń sekrety”, „utrzymuj historię gita”, „sprawdzaj realne sytuacje” staje się wielokrotnego użytku umiejętnością, a Codex, Claude Code czy inny zgodny agent podchodzi do projektu w spójny sposób.
Open Engine przydaje się, gdy praca musi przechodzić od jednego narzędzia, agenta albo człowieka do drugiego bez opowiadania całej historii od nowa. Pierwsza prosta aplikacja zbudowana jednym agentem nie potrzebuje systemu przekazywania kontekstu. Ale projekt utrzymywany przez kilka narzędzi przez wiele miesięcy już może na tym skorzystać.
Ringer to bardziej zaawansowana droga, ale bardzo użyteczna. Staje się istotny, gdy kilku agentów zmienia system naraz i potrzebujesz jednego miejsca, w którym zdefiniujesz zmianę, sprawnie rozdzielisz pracę, dużo na tym zaoszczędzisz, sprawdzisz wynik i pokażesz właścicielowi systemu — czyli człowiekowi — co się wydarzyło. To de facto system multi-agentowy do budowania. Ludzie, którzy z niego korzystają, są zachwyceni, bo pozwala mieć wiele tanich agentów budujących oszczędnie pod względem tokenów. Ale nie bierz się za to przy pierwszym projekcie, jeśli nie czujesz się swobodnie w zarządzaniu systemem wieloagentowym. Mówię to zupełnie szczerze.
Te systemy rozwiązują osobne problemy. Co oprogramowanie wie — Open Brain. Jak zachowuje się budowniczy — Open Skills. Jak przemieszcza się praca — Open Engine. Jak nadzorować złożoną, delegowaną pracę oszczędnie — Ringer. Wszystkie pozostają opcjonalnymi elementami mapy.
Pierwsza godzina
Co bym zrobił w pierwszej godzinie? Zapisałbym tę jedną rzecz, którą od dawna chciałeś zbudować. Nazwałbym, jak to wygląda. Opisałbym, co dzieje się teraz i co powinno dziać się zamiast tego. Zidentyfikowałbym sygnał albo informację, które to umożliwiają. Potem powiedziałbym, gdzie ma się pojawić wynik: na jakim ekranie i dlaczego, kto ma to widzieć i co byłoby złego, gdyby zawiodło.
Kiedy to masz, możesz wrócić do tego materiału i wybrać środowisko budowania. Przy pierwszym projekcie — po prostu Lovable. Prywatna aplikacja webowa i minimum konfiguracji: Lovable jest bardzo łatwy. Możesz użyć zarządzanego backendu w rodzaju Lovable Cloud, chyba że już wiesz, że przenośność danych jest na tyle ważna, by uzasadnić Supabase. Ale nie musisz tam zaczynać. Jeśli chcesz większej kontroli, odpalasz Codeksa albo Claude Code — dziś tak dobrze integrują się z usługami takimi jak Vercel, że nie musisz nawet sam się do nich logować ani ich obsługiwać. Agenty zrobią to za ciebie. A jeśli twój projekt zależy od czujnika, będziesz potrzebował czegoś, co ten czujnik odczyta: Home Assistant, Raspberry Pi. To wszystko jest w zasięgu osób nietechnicznych, bo możesz zrobić zdjęcie swojego układu i kazać agentowi go zdiagnozować. Widziałem ludzi, którzy sterują swoim Raspberry Pi z Codeksa albo z Claude Code. To naprawdę proste.
I jeszcze jedno, czego nie mogę wystarczająco podkreślić. Ciągle słyszę: „to jest trudne, bo mój agent nie mówi zwykłym językiem i niczego nie tłumaczy”. Wymagaj, żeby agent wyjaśnił ci główne wybory, zanim zacznie. Na Substacku publikuję specjalną umiejętność do dokumentacji technicznej w zwykłym języku — zmusza agenta, żeby przestał mówić „po agentowemu”. Wtedy możesz powiedzieć: użyj tej umiejętności, wytłumacz mi bardzo prostym językiem, jakie mam opcje, a potem ja dokonam wyboru.
Dlaczego to ma znaczenie
Po co w ogóle budować oprogramowanie osobiste? Jedną z najpiękniejszych rzeczy w nim jest to, że może ewoluować razem z tobą. Oprogramowanie mieszka w tym samym miejscu co problem i co człowiek, któremu na nim zależy.
I to właśnie zmieniło się w świecie. Przez długi czas ludzie z umiejętnościami technicznymi nie mieszkali blisko prawdziwych życiowych problemów. A ludzie, którzy mieszkali blisko tych problemów — problemu promu, problemu utrzymania domu, twojego problemu — nie mieli umiejętności technicznych, żeby je rozwiązać. Dlatego nigdy nie udało nam się zbudować oprogramowania osobistego, które faktycznie by dla nas działało. To się zmieniło. My już wiemy, czego chcemy. Problemem było to, że nie umieliśmy tego zbudować. A teraz widzimy trasę dostatecznie wyraźnie, żeby zacząć, rozumieć swoje wybory i zostać u steru. Możemy pozostać właścicielami własnego oprogramowania.
Oto moje wyzwanie: wybierz życzenie. Nadaj mu najprostszy możliwy kształt, jaki potrafisz sobie wyobrazić. Upewnij się, że rozumiesz, co ma robić. Użyj partnera budowlanego, którego opisałem — i bierz się do roboty. Może to być tak proste jak: „popracujmy z Lovable i zobaczmy, jak daleko zajdziemy”.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Najpierw opisz zmianę, potem wybieraj narzędzia
Na czym polega: Zanim padnie nazwa jakiegokolwiek narzędzia, odpowiedz na pięć pytań: co dzieje się dziś, co ma się dziać zamiast tego, skąd bierze się potrzebna informacja, gdzie ma się pojawić wynik i kto ma go widzieć. Odpowiedzi same wskazują kształt techniczny.
Jak stosować: Zapisz te pięć odpowiedzi w kilku zdaniach, zanim otworzysz cokolwiek. Dopiero potem dopasuj jeden z pięciu kształtów.
Na co uważać: Częsty błąd to zaczynanie od narzędzia („zrobię appkę na iPhone’a”), które narzuca zakres pracy wielokrotnie większy niż potrzebny. Jeśli twój opis nie wymaga sklepu ani czujnika, nie ma powodu ich dokładać.
2.Pięć kształtów pokrywa większość życzeń
Na czym polega: Narzędzie lokalne, aplikacja webowa, natywna aplikacja mobilna, usługa w tle i projekt sprzętowy. Każdy ma inny koszt startu i inny zestaw wymaganych elementów.
Jak stosować: Przypisz swój pomysł do jednego kształtu i trzymaj się go w pierwszej wersji. Narzędzie lokalne często nie potrzebuje ani kont, ani bazy w chmurze, ani hosta.
Na co uważać: Kształty da się łączyć (projekt promowy to sprzęt plus mała aplikacja webowa), ale przy pierwszym projekcie każde dodane połączenie mnoży liczbę rzeczy, które mogą się zepsuć.
3.Aplikacja webowa jako domyślny wybór
Na czym polega: Web otwiera się z linku, działa w przeglądarce na każdym urządzeniu i daje się dodać do ekranu głównego telefonu — bez sklepu, bez konta dewelopera, bez weryfikacji.
Jak stosować: Traktuj natywną aplikację jako wyjątek zarezerwowany dla push, Bluetootha, lokalizacji w tle, NFC albo dystrybucji przez sklep. Wszystko inne udowodnij najpierw jako prywatną aplikację webową.
Na co uważać: Konta deweloperskie Apple i Google to koszt i proces weryfikacji. Płacenie tego podatku, zanim wiesz, czy ktokolwiek w domu będzie korzystał z twojej aplikacji, to strata.
4.Lovable jako pierwszy przystanek dla osoby nietechnicznej
Na czym polega: Hostowany builder przygotował już środowisko: nie instalujesz języka, nie uruchamiasz serwera, nie musisz znać wiersza poleceń. Opisujesz, dostajesz podgląd, publikujesz.
Jak stosować: Zbuduj jeden ekran i jeden rekord — na przykład jedno urządzenie w aplikacji domowej. Jeśli chcesz zachować przenośność, podłącz GitHuba od początku; Lovable tego nie wymaga, ale wtedy projekt można zabrać gdziekolwiek.
Na co uważać: Replit i Bolt są mocniejsze, ale mocniej wiążą projekt z jedną usługą. Jeśli budujesz w Replicie, projekt tam mieszka — sprawdź z góry, co byłoby potrzebne, żeby stamtąd wyjść z aplikacją i danymi.
5.Lovable Cloud kontra Supabase to decyzja o danych, nie o wygodzie
Na czym polega: Lovable Cloud jest łatwiejszy, bo builder zarządza bazą i logowaniem. Supabase wymaga więcej pracy, ale trzyma bazę Postgres i uwierzytelnianie w osobnej usłudze.
Jak stosować: Pierwsza aplikacja, cel „coś ma zadziałać” — Lovable Cloud. Dane, na których chcesz później zbudować kolejne narzędzie albo które chcesz przenieść — Supabase od startu.
Na co uważać: Zmiana interfejsu jest dużo łatwiejsza niż przenoszenie lat danych. Ta asymetria jest głównym argumentem za świadomym wyborem — ale nie paraliżuj się nią, obie drogi są do przeżycia.
6.Model, agent kodujący i builder to trzy różne warstwy
Na czym polega: Model to warstwa rozumowania i pisania kodu. Agent kodujący daje modelowi dostęp do folderu, poleceń i podglądów. Hostowany builder pakuje agenta razem ze środowiskiem i przyciskiem publikacji.
Jak stosować: Wybierz środowisko, które ci odpowiada, i osobno model, który ci odpowiada — nie muszą pochodzić od tej samej firmy. Przy odpowiednim kluczu API możesz podpiąć model otwarty do obsługiwanego narzędzia.
Na co uważać: Przy pierwszym projekcie użyj jednego środowiska. Wpuszczanie trzech agentów do projektu, żeby „robić multi-agenta”, nie daje kontroli — kontrola bierze się z posiadania plików, danych i decyzji.
7.Cztery pliki, które zmieniają rolę modelu
Na czym polega: project.md (dla kogo, przed i po, gdzie działa, co ma zostać prywatne), decisions.md (opcje, rekomendacja, uzasadnienie przy każdym wyborze dotyczącym kosztu, danych, dostępu czy wdrożenia), scenarios.md (realne sytuacje jako przypadki testowe) i krótki plik instrukcji dla agenta — agents.md dla Codeksa, claude.md dla Claude Code.
Jak stosować: Trwałą wiedzę o projekcie trzymaj w pierwszych trzech plikach; czwarty ma tylko mówić bieżącemu narzędziu, jak się zachowywać. Dzięki temu zmiana narzędzia nie kasuje kontekstu.
Na co uważać: Nie licz na jeden magiczny prompt. Bez pliku z decyzjami model będzie zakopywał wybory w kodzie i założeniach, a ty odkryjesz je dopiero wtedy, gdy zaczną boleć.
8.Sprzęt przestał być osobnym światem
Na czym polega: Raspberry Pi to mały komputer ogólnego przeznaczenia, ESP32 nadaje się do jednego czujnika lub jednego urządzenia, Home Assistant spina to, co już masz w domu. Agent kodujący rozpozna płytkę ze zdjęcia, wyjaśni piny i pomoże zdiagnozować układ.
Jak stosować: Zacznij od najprostszej opcji: jeśli czujniki już są w domu, użyj Home Assistant zamiast budować własną platformę. Do zdalnego dostępu z zewnątrz użyj Tailscale zamiast wystawiać Pi do internetu.
Na co uważać: Sprzęt wciąga koszt i czas nawet przy niedrogich elementach — projekt promowy to około 200 euro. Sięgaj po niego dopiero wtedy, gdy sygnału naprawdę nie da się zdobyć inaczej.
9.Bezpieczeństwo sprowadza się do czterech nawyków
Na czym polega: Prywatne domyślnie i publiczne tylko gdy trzeba. Gotowy, zarządzany system logowania zamiast wymyślania przechowywania haseł. Sekrety w mechanizmie sekretów hosta, nigdy w kodzie, na zrzucie ekranu ani na GitHubie. Kontrola dostępu wymuszona w bazie, nie w interfejsie.
Jak stosować: Wpisz regułę „konto widzi tylko swoje rekordy” do scenarios.md i testuj ją tak samo jak każdą inną funkcję. Jeśli dane są ważne — zrób backup i wykonaj próbne odtworzenie.
Na co uważać: Ukrycie przycisku to nie jest kontrola dostępu. Wyciek między kontami to jeden z najczęstszych i najpoważniejszych błędów, a przy patrzeniu tylko na interfejs jest praktycznie niewidoczny. Przy płatnościach, danych dzieci, danych medycznych czy prawnych zleć przegląd przed użyciem — i nie zaczynaj nauki od takich danych.
10.Deklaracja agenta „gotowe” nie jest dowodem
Na czym polega: Nie da się zlecić testowania w całości Lovable, Codeksowi ani Claude Code i przyjąć, że skoro odpowiadają „skończone”, to działa. Człowiek musi sprawdzić.
Jak stosować: Spisz konkretne sytuacje i przejdź je ręcznie na urządzeniu, którego naprawdę będziesz używał: czy zdjęcie tworzy poprawny rekord, czy numer modelu się zachował, czy druga osoba widzi tę samą listę, czy odznaczenie zadania pojawia się na drugim telefonie.
Na co uważać: Testuj ścieżki nieudane, nie tylko szczęśliwe — co się dzieje, gdy zdjęcie jest nieczytelne. Pięć minut klikania to nie testowanie, choćby aplikacja wyglądała na skończoną.