O czym jest ten film
- Autor omawia miesięczny update aplikacji do liczenia kalorii Amy, która przekroczyła 3000 dolarów miesięcznego przychodu (MRR) przy 85% marży zysku.
- Zamiast dalej optymalizować retencję, w tym miesiącu skupił się na „future-proofingu” aplikacji pod kątem nadchodzących zmian w branży AI.
- Kluczowym impulsem jest zapowiedź nowej, znacznie bardziej sprawnej wersji Siri w iOS 27.
- Zbudował integrację z Siri jednym promptem w Claude Code — dzięki temu, że Amy opiera się na prostym wejściu tekstowym, a nie na wyszukiwaniu z list czy zdjęciach.
- Porównuje to z konkurencją (MyFitnessPal, Cal AI), która przez skomplikowany interfejs nie jest w stanie zbudować sensownej integracji głosowej.
- Poleca dyktowanie promptów do agentów kodujących (Claude Code, Cursor) za pomocą narzędzia Whisper Flow (sponsor wideo).
- Opisuje budowę MCP (Model Context Protocol) dla Amy, żeby agenci AI (Claude, ChatGPT, Codex) mogli logować jedzenie i analizować nawyki żywieniowe użytkownika.
- Budowa MCP wymagała stworzenia od zera: logowania webowego (OAuth), publicznego API oraz mechanizmów zabezpieczających przed nadużyciami (rate limiting).
- Największym, nieoczekiwanym wyzwaniem okazało się UX — jak w prosty sposób wytłumaczyć przeciętnemu użytkownikowi aplikacji mobilnej, czym jest MCP i jak go podłączyć.
- Konkluzja: twórcy aplikacji powinni już teraz projektować pod kątem integracji z asystentami głosowymi i agentami AI, bo użytkownicy zaczną premiować aplikacje, które dobrze się z nimi łączą.
Redakcyjne tłumaczenie
Szybki update finansowy
Dziś krótki update na temat aplikacji do liczenia kalorii, którą uruchomiłem kilka miesięcy temu. Przejdziemy przez liczby, ale głównym powodem nagrania tego materiału jest to, że poświęciłem sporo czasu na „uodpornienie” aplikacji na przyszłość i chcę się tym z wami podzielić. Pokażę, co wdrożyłem i — co ważniejsze — dlaczego uważam, że to znacznie lepiej pozycjonuje aplikację na przyszłość oraz jak możecie zastosować to samo we własnych projektach.
Dla nowych widzów: nazywam się Chris i buduję aplikacje produktywnościowe. Zwykle w jednym odcinku skupiam się na jednej aplikacji, a dziś tą aplikacją jest Amy. Krótki kontekst: Amy to aplikacja do liczenia kalorii utrzymana w stylu Apple Notes. Po lewej stronie wpisujesz, co zjadłeś, a po prawej „magicznie” pojawiają się kalorie. To najbardziej bezobsługowa aplikacja do liczenia kalorii na rynku.
Jeśli chodzi o liczby — osiągnęliśmy spory kamień milowy: przekroczyliśmy 3000 dolarów miesięcznego przychodu cyklicznego (MRR). To dość ekscytujące, ale najbardziej dumny jestem z tego, że marża zysku wynosi około 85%. (Informacja dodatkowa: dla aplikacji opartej na AI to wynik nietypowo wysoki — koszty zapytań do modeli językowych zwykle zjadają dużą część przychodu). Zazwyczaj marże w aplikacjach AI są dość słabe, rzędu 20-30%. Osiągnięcie takiego przychodu przy utrzymaniu 85% marży to coś, z czego jestem naprawdę dumny.
To tyle jeśli chodzi o przychody — ale tak naprawdę chcę porozmawiać o tym, czego nauczyłem się w tym miesiącu. Jeśli śledzicie mój kanał, wiecie, że byłem mocno skupiony na poprawie retencji tygodnia pierwszego, czyli na tym, ile osób po zarejestrowaniu się nadal korzysta z aplikacji tydzień później. To moja główna metryka. Ale w tym miesiącu zmieniłem podejście i zacząłem skupiać się na „uodpornianiu” aplikacji na przyszłość, ponieważ zauważyłem kilka zmian w branży aplikacji.
Dlaczego nowa Siri zmienia zasady gry
Oczywiście widać, że ludzie coraz częściej korzystają z aplikacji AI, takich jak Claude czy ChatGPT, ale myślę, że dzieje się coś jeszcze większego — konkretnie na iPhonie. Apple ogłosiło właśnie nową wersję Siri. To istotne, ponieważ Siri przez ostatnie kilka lat była trochę żartem. Osobiście nie korzystam z Siri, bo jest bardzo słaba w wykonywaniu poleceń, i nie jestem w tym odosobniony. Ale jeśli nowa wersja jest tak dobra, jak twierdzą ludzie, myślę, że to może się zmienić.
Jeśli tak się stanie i użytkownicy iPhone’ów zaczną korzystać z Siri znacznie częściej — powiedzmy, wielokrotnie dziennie — zaczną też oczekiwać, że aplikacje, których używają, będą dobrze współpracować z nową Siri. A z czasem, myślę, zaczną też priorytetyzować aplikacje, które mają naprawdę dobrą integrację z Siri. Nowa Siri ma trafić do iOS 27, który w momencie nagrywania tego materiału jeszcze nie wyszedł.
Jak zbudowałem integrację z Siri w jednym prompcie
Żeby wyprzedzić tę zmianę, pierwszą rzeczą, jaką postanowiłem zrobić, była porządna integracja z Siri. Pomyślałem sobie: to chyba nie powinno być trudne, prawda? Claude Code powinien to zrobić za jednym podejściem. Otworzyłem więc Claude Code i napisałem: „Czy możesz zbudować integrację z Siri, w której ktoś mówi, co zjadł, wysyła to do aplikacji, ona to przetwarza i zwraca podgląd wartości odżywczych do zatwierdzenia zapisu?”. To dokładnie ten prompt, którego użyłem. I dał mi on działającą wersję funkcji. Od tego momentu wystarczyły jeszcze dwa-trzy prompty, żeby doszlifować stylistykę.
Działa to tak: mówisz „Hej Siri, zaloguj jedzenie w Amy”. Siri pyta, co zjadłeś. Odpowiadasz na przykład: „In-N-Out Burger i frytki”. I to dosłownie wszystko — aplikacja pokazuje informacje odżywcze, żebyś mógł potwierdzić, co zostało zapisane.
Po wdrożeniu tej funkcji pomyślałem: to poszło zaskakująco szybko, dlaczego? I doszedłem do wniosku, że powodem jest to, że Amy ma ogromną przewagę nad innymi aplikacjami do liczenia kalorii — sposób wprowadzania jedzenia opiera się wyłącznie na tekście. Wpisujesz jedną linijkę, ona trafia do mojego backendu, tam AI wykonuje wszystkie obliczenia i po prostu zwraca kalorie oraz pełne dane odżywcze.
Dlaczego konkurencja nie ma takiej przewagi
Porównajmy to z innymi aplikacjami w tej branży, na przykład MyFitnessPal. Żeby zalogować jedzenie, trzeba je wyszukać, przejrzeć opcje, wybrać najlepszą, zmienić ilość i wielkość porcji, a dopiero potem zapisać wpis. Właśnie dlatego, jak sądzę, MyFitnessPal nie ma sensownej integracji z Siri — bo jeśli powiesz Siri „zaloguj burrito na śniadanie w MyFitnessPal”, ona nie wie, co wybrać spośród wszystkich rozwijanych menu w tej aplikacji.
Weźmy inny przykład — Cal AI, aplikację opartą głównie na zdjęciach. Zdjęcia nie da się zrobić głosem. Maksimum, co można zrobić, to powiedzieć „Hej Siri, otwórz Cal AI”, a wtedy otworzy się aparat i dopiero wtedy robisz zdjęcie. Większość dużych aplikacji do liczenia kalorii utknęła więc w martwym punkcie — najwięcej, co mogą zrobić, to kazać Siri otworzyć aplikację.
W przypadku Amy całe doświadczenie opiera się na pojedynczym fragmencie tekstu, co oznacza, że Siri może wchodzić w interakcję z aplikacją dokładnie tak, jak robią to użytkownicy — bo ona też może po prostu wprowadzić jedną linijkę tekstu. Cała złożoność dzieje się całkowicie w tle. Użytkownik nie musi niczego wybierać, bo tak właśnie od początku była zaprojektowana ta aplikacja: żeby użytkownicy mogli po prostu wpisać dowolny, swobodny tekst, a aplikacja sama miała wystarczająco „rozumu”, żeby domyślić się, o co chodziło. To część piękna Amy — cały ten skomplikowany proces (obliczenia AI wykonywane w ciągu 1-2 sekund w tle) dzieje się dzięki wcześniejszej inwestycji w tę architekturę, dzięki czemu dostaliśmy naprawdę dobrą obsługę Siri praktycznie „za darmo”.
Ograniczenie: dwuetapowe wywołanie
Zauważycie jedną rzecz — integracja wymaga dwóch kroków. Musiałem powiedzieć: „Hej Siri, zaloguj jedzenie w Amy”, a potem osobno podać, co zjadłem. Wolałbym, żeby dało się zrobić to jednym poleceniem, np. „Zaloguj mojego burgera z In-N-Out i frytki w Amy”, ale niestety Apple na razie na to nie pozwala. Siri wymaga, żeby aplikacja z góry zdefiniowała konkretne frazy kluczowe, na które ma reagować — nie potrafi jeszcze obsługiwać dynamicznych fraz. Stąd te dwa kroki: najpierw przywołanie aplikacji stałą frazą „zaloguj jedzenie w Amy”, a potem dopiero podanie samego jedzenia. Podejrzewam jednak, że przyszłe wersje Siri będą obsługiwać dynamiczne frazy kluczowe, i wtedy zintegruję to z aplikacją.
Wniosek: myśl z wyprzedzeniem o sposobach wprowadzania danych
Główny wniosek jest taki: jeśli budujecie aplikację, zdecydowanie warto zbudować integrację z Siri, jeśli tylko się da. Ale ważniejsza lekcja jest szersza — budując aplikację, warto z wyprzedzeniem przemyśleć, jakie rodzaje wejścia (input) chcecie obsługiwać. Mówię tu też o integracji z zegarkiem, o wejściu agentowym (agentic input) — istnieje mnóstwo różnych typów wejścia. Jeśli wasza aplikacja nie ma sposobu na wprowadzanie danych niskim kosztem wysiłku (low friction), warto poszukać kreatywnych sposobów, żeby to zmienić.
Dyktowanie promptów zamiast pisania
Zauważyliście pewnie, że kiedy budowałem integrację z Siri, dyktowałem prompt do Claude Code. I tak właśnie polecam pracować z agentami takimi jak Claude Code czy Cursor — dyktować wszystko, bo dzięki temu prompty są dużo bardziej szczegółowe. Narzędzie, którego używam do dyktowania, to Whisper Flow — wielkie podziękowania dla nich za sponsorowanie tego materiału. Whisper Flow to inteligentne narzędzie do zamiany mowy na tekst, działające w dowolnej aplikacji.
Świetnie sprawdza się u programistów, bo rozpoznaje terminologię techniczną — kiedy mówię AWS, DynamoDB, Gemini 2.5 Flash Lite czy Supabase, za każdym razem rozpoznaje to poprawnie. Jeśli korzystacie z Cursora lub Windsurfa, Whisper Flow współpracuje z tymi środowiskami tak, że potrafi automatycznie „otagować” pliki — jeśli powiem „Popraw style w subscription-overview.tsx”, oznaczy ten plik bez konieczności ręcznego wpisywania nazwy. Dostępny jest na desktopie — dla Cursora, Claude Code czy ChatGPT, tak jak ja go używam — ale też na iOS i Androidzie. Korzystam z niego cały czas, kiedy odpowiadam na SMS-y czy komentarze na YouTube, i dzięki temu mogę dawać dużo bardziej szczegółowe odpowiedzi. (Informacja dodatkowa: link i kod rabatowy autor zamieszcza w opisie filmu — to fragment sponsorowany).
Skąd wziął się pomysł na MCP
Kolejna rzecz, którą wdrożyłem, wynikła z problemu w moim własnym życiu. Ostatnio zainteresowałem się planowaniem posiłków i korzystam do tego z Codex, głównie dlatego, że ma bardzo dobre narzędzie do obsługi komputera (computer use) — może kontrolować mój komputer i przeglądarkę oraz wykonywać za mnie akcje. Po zaplanowaniu posiłków na tydzień, każę mu też zamawiać produkty spożywcze z Whole Foods.
Zabawna historia z tym związana: w tym tygodniu nie sprawdziłem wystarczająco dokładnie koszyka i agent zamówił 4 funty cytryn, podczas gdy przepis wymagał tylko jednej. Zorientowałem się dopiero, gdy odebrałem dostawę. Jeśli więc planujecie robić coś podobnego — dokładnie sprawdzajcie koszyk przed złożeniem zamówienia.
Korzystałem więc z Codex do planowania posiłków, a nawet zamawiania produktów. Brakowało mi tylko jednego — żeby zaraz po zjedzeniu czegoś móc powiedzieć Codexowi: „zaloguj to w Amy”. I właśnie dlatego postanowiłem zbudować MCP. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to standardowy sposób, w jaki narzędzia AI, takie jak ChatGPT, Claude Code czy Codex, mogą bezpiecznie łączyć się z usługami zewnętrznymi i wykonywać w nich akcje).
W moim przypadku MCP pozwoliłoby agentom, takim jak Claude czy Codex, logować jedzenie za użytkownika, analizować nawyki żywieniowe, a nawet sugerować zmiany w diecie. To wydaje mi się sensowne, bo wiele osób chce analizować swoje nawyki żywieniowe, zwłaszcza w dłuższym okresie. Obecnie jedyny sposób, żeby to zrobić, to wejść w ustawienia, wyeksportować wszystkie dane, a potem wrzucić je do ChatGPT albo Claude. Dzięki MCP można po prostu podłączyć Amy do tych narzędzi i zapytać wprost.
Pierwsza przeszkoda: uwierzytelnianie
Miałem już pewne doświadczenie w budowaniu MCP, bo zrobiłem je dla mojej innej aplikacji do planowania dnia — Ellie. Ale nie znalazłem żadnej innej aplikacji do liczenia kalorii z dostępnym MCP, więc nie miałem żadnego przykładu do przestudiowania. Z jednej strony było to ekscytujące, bo oznaczało, że jestem jednym z pierwszych, którzy to robią, ale z drugiej strony utrudniało sprawę, bo nie miałem żadnych standardów, z którymi mógłbym porównać swoje rozwiązanie.
Skoro robiłem to już wcześniej z Ellie, pomyślałem: to powinno pójść łatwo, może zrobię to w jeden dzień. Okazało się jednak dużo trudniejsze, niż się spodziewałem.
Pierwszym problemem było uwierzytelnianie. Większość MCP dopuszcza dwa sposoby autoryzacji. Pierwszy to klucz API — kiedy użytkownik dodaje MCP do Claude czy ChatGPT, musi wkleić klucz API, żeby się uwierzytelnić. Druga opcja to OAuth — kiedy użytkownik próbuje połączyć MCP z Claude czy ChatGPT, zostaje przekierowany na stronę autoryzacji, loguje się i klika „autoryzuj”. Bez żadnych kluczy API. OAuth jest właściwie standardem i zalecanym sposobem budowania MCP.
Problem w tym, że OAuth wymaga logowania przez przeglądarkę — czyli faktycznej strony logowania i autoryzacji, a Amy jest wyłącznie aplikacją na iOS, bez wersji webowej. Zanim więc w ogóle zabrałem się za MCP, musiałem zbudować całe doświadczenie logowania — webową wersję Amy umożliwiającą przejście przez ten proces autoryzacji, w tym obsługę logowania przez Google i Apple, co również było dość skomplikowane. Na szczęście zbudowałem już mnóstwo stron internetowych, więc poszło stosunkowo łatwo, choć trochę irytujące było to, że w ogóle musiałem to robić.
Druga przeszkoda: brak API
Po zbudowaniu procesu autoryzacji natrafiłem na kolejny problem — Amy w ogóle nie miała API. Wszystko w aplikacji dzieje się na urządzeniu, a urządzenie komunikuje się z moim backendem, obsługującym różne usługi. Nie było więc żadnej możliwości, żeby zewnętrzny klient, taki jak MCP, mógł komunikować się z moim backendem. Standardowym rozwiązaniem tego problemu jest zbudowanie API — więc właśnie to zrobiłem: zbudowałem pełnoprawne API dla Amy, z porządnymi endpointami.
Uznałem, że skoro już to robię, mogę od razu udostępnić to API publicznie, żeby deweloperzy mogli budować na jego podstawie. Pojawiło się jednak kilka wyzwań. Na przykład moim pierwszym pomysłem było zbudowanie endpointu do pobierania „dzisiejszego” jedzenia, bo wydawało mi się, że to będzie najczęstszy przypadek użycia — sprawdzenie, co zjadłem dzisiaj. Ale po zbudowaniu tego zrozumiałem, że ludzie będą zadawać bardziej ogólne pytania, na przykład „co jadłem przez ostatnie dwa tygodnie”, a nie tylko „co jadłem dziś”. Musiałem więc przebudować endpoint, żeby obsługiwał zakresy dat.
To był tylko jeden przykład — takich sytuacji było wiele, gdzie musiałem dokładnie przemyśleć, jak użytkownicy będą korzystać z API, żeby uczynić je faktycznie użytecznym. Nawet przy budowie API trzeba myśleć o doświadczeniu użytkownika (UX) — trzeba z wyprzedzeniem przewidzieć, jak ludzie będą go używać, i zbudować odpowiednie endpointy, które obsłużą te przypadki. Dużo czasu poświęciłem na burzę mózgów: jak ludzie będą korzystać ze swoich agentów i jakie endpointy API muszę zbudować, żeby to umożliwić.
Trzecia przeszkoda: bezpieczeństwo i limity zapytań
Kiedy z tym uporałem się, pojawił się trzeci problem, powiązany z API — bezpieczeństwo. Wyszło to na jaw od razu, kiedy projektując API zorientowałem się, że częstym przypadkiem użycia będzie masowe wprowadzanie danych (bulk entry) — ludzie będą chcieli zalogować cały dzień albo cały tydzień jedzenia naraz.
Problem w tym, że każdy pojedynczy wpis w Amy kosztuje sporo pieniędzy — mniej więcej pół centa za każdym razem, gdy ktoś coś wpisuje lub edytuje, bo w tle działa cała skomplikowana logika AI. W aplikacji na iOS łatwiej to zabezpieczyć — mam tam limity zapytań (rate limits) i inne mechanizmy po stronie backendu, ale otwarte MCP i otwarte API znacznie zwiększają ryzyko nadużyć.
Sporym wyzwaniem, co mnie zaskoczyło, było zaprojektowanie odpowiednich limitów zapytań dla MCP. Na początku spróbowałem prostego rozwiązania: powiedzmy, trzy wpisy na minutę — to brzmiało rozsądnie. Ale szybko zorientowałem się, że to nie działa, bo widzę realny scenariusz, w którym ktoś w ChatGPT dyktuje: „zaloguj wszystkie moje dzisiejsze posiłki w Amy”. To będzie się zdarzać bardzo często, kiedy ludzie logują wszystko na koniec dnia. Musiałem więc pozwolić na duże, jednorazowe wsady danych (burst), ale nie mogłem pozwolić, żeby ktoś robił takie wsady w nieskończoność, jeden po drugim.
Rozwiązaniem było wdrożenie tzw. stopniowego wychładzania (gradual cool down) — pozwalam na duży, jednorazowy wsad wpisów, ale kolejne takie wsady są coraz bardziej spowalniane, aż w końcu użytkownik musi przestać. To dość powszechny wzorzec projektowania limitów zapytań. Wdrożyłem jeszcze kilka dodatkowych mechanizmów monitorowania nadużyć, ale na razie nie będę o nich mówić szczegółowo, dopóki nie upewnię się, że są w pełni szczelne.
Czwarta, najtrudniejsza przeszkoda: UX
Ostatni problem, z którym się zmierzyłem — i który okazał się najtrudniejszy, choć się tego nie spodziewałem — dotyczył UX. Jak w ogóle wytłumaczyć zwykłemu użytkownikowi, czym jest MCP, w aplikacji na iPhone’a? Bardzo się starałem znaleźć jakieś przykłady, ale każdy przykład MCP w ustawieniach, jaki znalazłem, dotyczył wersji webowej albo aplikacji desktopowej. Żadna aplikacja mobilna nie mówi o MCP w kontekście telefonu.
Zajęło to sporo iteracji, ale oto, na czym się zatrzymałem: dedykowana strona ustawień, która pokazuje dokładnie, co narzędzia AI mogą zrobić w aplikacji, wraz z bardzo prostymi instrukcjami, jak podłączyć Amy do swoich narzędzi AI. Instrukcje można skopiować albo wysłać sobie mailem, żeby przeczytać je później na komputerze. Dodałem też osobną sekcję dla API, gdzie można zarządzać kluczami API i przeczytać dokumentację. To znów coś, czego naprawdę niewiele aplikacji mobilnych robi. Prawdopodobnie będę jeszcze iterował nad tą stroną, ale to było naprawdę ciekawe wyzwanie projektowe — jak wziąć coś tak skomplikowanego, co zwykle spotyka się tylko na desktopie czy w wersji webowej, i skondensować to tak, żeby było przyswajalne na telefonie, zwłaszcza w przypadku czegoś takiego jak API.
Udało się to jednak wdrożyć i już dziś można wypróbować zarówno MCP Amy, jak i publiczne API.
Podsumowanie i wnioski na przyszłość
To były dwie główne rzeczy, które wdrożyłem w tym miesiącu w ramach uodparniania aplikacji na przyszłość. Pracowałem też nad kilkoma innymi rzeczami, w tym integracją z Apple Watch oraz aplikacją na Androida, ale zostawię to na osobny materiał, bo uważam, że te tematy zasługują na dedykowany odcinek.
Najważniejsza rzecz, którą chcę wam przekazać, jest taka: naprawdę warto poświęcić czas na myślenie z wyprzedzeniem, bo sposób, w jaki ludzie korzystają z aplikacji, zaraz zacznie się zmieniać. Sam to zauważam u siebie — spędzam mnóstwo czasu w aplikacjach takich jak Claude czy Codex, żeby robić codzienne rzeczy w swoim życiu. I osobiście też zaczynam priorytetyzować usługi, które płynnie łączą się z tymi narzędziami. Jestem pewien, że wy, deweloperzy oglądający ten materiał, robicie podobnie.
To jeszcze wczesny etap, ale myślę, że zwykli, przeciętni konsumenci zaczną myśleć tak samo. Zaczną priorytetyzować aplikacje i usługi, które płynnie łączą się z agentami, których używają na co dzień. Na przykład jeśli nowa Siri się przyjmie, ludzie zaczną wybierać aplikacje, które dobrze z nią współpracują. Dlatego uważam, że naprawdę warto już teraz uodparniać swoje aplikacje na przyszłość i wyprzedzać te zmiany.
To wszystko, czym chciałem się dziś z wami podzielić.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Traktuj nadchodzącą, lepszą Siri jako sygnał do działania
Na czym polega: Apple zapowiedziało znacznie bardziej sprawną wersję Siri w iOS 27, co może zmienić sposób, w jaki użytkownicy iPhone’ów wchodzą w interakcję z aplikacjami — częściej głosowo, wielokrotnie dziennie.
Jak stosować: Jeśli budujesz aplikację na iOS, już teraz zaplanuj, jak Siri mogłaby wykonywać kluczowe akcje w twojej aplikacji, zamiast czekać, aż funkcja stanie się popularna, a konkurencja cię wyprzedzi.
Na co uważać: Autor opiera się na zapowiedziach Apple, a nie na przetestowanej, wydanej wersji systemu — traktuj to jako prognozę, nie pewnik, i unikaj inwestowania nieproporcjonalnie dużych zasobów, zanim funkcja faktycznie trafi do użytkowników.
2.Projektuj wprowadzanie danych jako pojedynczy, prosty krok
Na czym polega: Amy zyskała łatwą integrację z Siri niemal „za darmo”, bo cały model interakcji od początku opierał się na jednej linijce swobodnego tekstu — bez menu, list wyboru czy zdjęć.
Jak stosować: Projektując rdzeń aplikacji, dąż do tego, żeby główna akcja użytkownika dała się sprowadzić do jednego prostego wejścia (tekst, głos), które łatwo zautomatyzować lub podłączyć pod głos czy agenta AI.
Na co uważać: Ten model działa dobrze dla prostych, jednorodnych danych (np. „co zjadłem”), ale nie każdy produkt da się sprowadzić do jednej linijki tekstu — czasem złożoność interfejsu wynika z realnej złożoności danych, a nie złego projektu.
3.Dyktuj prompty do agentów kodujących zamiast je pisać
Na czym polega: Autor poleca dyktowanie promptów do narzędzi takich jak Claude Code czy Cursor (za pomocą Whisper Flow), bo mówiąc, naturalnie podaje się więcej szczegółów niż pisząc.
Jak stosować: Przy pracy z agentami AI spróbuj dyktować dłuższe, bardziej opisowe polecenia zamiast skracać je do kilku słów wpisywanych z klawiatury — więcej kontekstu zwykle oznacza lepszy rezultat za pierwszym razem.
Na co uważać: To rekomendacja sponsorowana (Whisper Flow jest sponsorem materiału) — warto ocenić jakość rozpoznawania mowy dla własnej terminologii technicznej przed zakupem, niezależnie od entuzjazmu autora.
4.Sprawdzaj dokładnie akcje agentów działających autonomicznie
Na czym polega: Autor korzysta z Codex do planowania posiłków i automatycznego zamawiania zakupów, ale niedopilnowany agent zamówił 4 funty cytryn zamiast jednej sztuki.
Jak stosować: Kiedy pozwalasz agentowi AI wykonywać realne akcje (zakupy, płatności, wysyłki), zawsze wprowadź krok potwierdzenia przez człowieka przed finalizacją, zwłaszcza gdy w grę wchodzą pieniądze.
Na co uważać: Błędy tego typu bywają drobne i łatwe do przeoczenia (literówka w ilości), a konsekwencje odkrywa się dopiero po fakcie — np. przy odbiorze dostawy, kiedy nie da się już nic cofnąć.
5.Rozważ zbudowanie MCP, jeśli twoja aplikacja przechowuje dane, które warto analizować agentem AI
Na czym polega: MCP (Model Context Protocol) pozwala narzędziom takim jak Claude czy ChatGPT bezpiecznie wykonywać akcje w usłudze zewnętrznej — w tym przypadku logować jedzenie i analizować nawyki żywieniowe bezpośrednio z poziomu agenta.
Jak stosować: Jeśli twoja aplikacja gromadzi dane, które użytkownicy chcieliby analizować lub eksportować do AI (nawyki, historia, statystyki), zbadaj, czy MCP nie zastąpiłby żmudnego ręcznego eksportu danych.
Na co uważać: Brak innych przykładów w danej branży (jak w tym przypadku wśród aplikacji do liczenia kalorii) oznacza brak sprawdzonych wzorców — trzeba liczyć się z tym, że trzeba będzie podejmować własne decyzje projektowe bez punktu odniesienia.
6.Standard OAuth dla MCP wymaga wersji webowej, nawet jeśli twój produkt jest tylko mobilny
Na czym polega: Rekomendowany sposób uwierzytelniania w MCP to OAuth, który wymaga strony logowania i autoryzacji w przeglądarce — czego aplikacja czysto mobilna (bez wersji web) po prostu nie ma.
Jak stosować: Jeśli planujesz zbudować MCP dla aplikacji mobilnej, załóż z wyprzedzeniem, że będziesz musiał zbudować minimalną stronę webową obsługującą logowanie (w tym logowanie przez Google/Apple), zanim w ogóle zabierzesz się za sam MCP.
Na co uważać: Alternatywą jest uwierzytelnianie kluczem API, które jest prostsze technicznie, ale mniej wygodne dla użytkownika i odbiega od zalecanego standardu — wybór między tymi opcjami wpływa na całą architekturę projektu.
7.Projektuj publiczne API pod kątem realnych scenariuszy użycia, nie oczywistych domysłów
Na czym polega: Pierwszy pomysł autora (endpoint na „dzisiejsze” jedzenie) okazał się zbyt wąski — użytkownicy pytają raczej o zakresy dat (np. „ostatnie dwa tygodnie”), więc endpoint trzeba było przeprojektować.
Jak stosować: Przed zbudowaniem endpointów API poświęć czas na burzę mózgów: jak konkretnie ludzie i ich agenci AI będą formułować zapytania, a nie tylko jak wygląda najbardziej oczywisty przypadek użycia.
Na co uważać: Nawet z API trzeba myśleć w kategoriach UX — źle zaprojektowane endpointy oznaczają kosztowne przebudowy później, kiedy okaże się, że nie obsługują realnych zapytań użytkowników czy agentów.
8.Zabezpiecz otwarte API/MCP limitami zapytań dopasowanymi do realnego wzorca użycia
Na czym polega: Proste, sztywne limity (np. „trzy wpisy na minutę”) nie sprawdzają się, gdy legalny przypadek użycia to masowe logowanie danych naraz (np. cały dzień posiłków). Autor wdrożył „stopniowe wychładzanie” — pozwala na duże, jednorazowe wsady, ale spowalnia kolejne próby.
Jak stosować: Projektując rate limiting dla API czy MCP, przeanalizuj legalne scenariusze masowego użycia (bulk actions) i zaprojektuj limity, które je dopuszczają, jednocześnie chroniąc przed ciągłym nadużywaniem.
Na co uważać: Zbyt restrykcyjne limity zniechęcą uczciwych użytkowników do korzystania z funkcji, a zbyt luźne otworzą drzwi do kosztownych nadużyć — zwłaszcza gdy, jak w tym przypadku, każde wywołanie generuje realny koszt (np. zapytania do modelu AI).
9.Zaprojektuj prostą, zrozumiałą prezentację funkcji technicznych (MCP, API) w interfejsie mobilnym
Na czym polega: Autor nie znalazł żadnego przykładu aplikacji mobilnej, która w czytelny sposób tłumaczy użytkownikowi, czym jest MCP i jak go podłączyć — wszystkie istniejące przykłady dotyczyły wersji webowych lub desktopowych.
Jak stosować: Buduj dedykowaną, uproszczoną sekcję ustawień z jasnymi instrukcjami krok po kroku (najlepiej z opcją wysłania ich sobie mailem/skopiowania), zamiast zakładać, że przeciętny użytkownik zrozumie żargon typu „OAuth” czy „endpoint”.
Na co uważać: To obszar, w którym nie ma jeszcze utartych wzorców projektowych (design patterns) — trzeba liczyć się z wieloma iteracjami i brakiem gotowych „najlepszych praktyk”, na których można by się oprzeć.
10.Zacznij już teraz projektować produkt pod kątem integracji z agentami AI, zanim stanie się to oczekiwaniem rynku
Na czym polega: Autor obserwuje, że coraz więcej codziennych czynności (także poza kontekstem zawodowym) przenosi się do interakcji z narzędziami AI, i przewiduje, że przeciętni użytkownicy zaczną premiować usługi, które dobrze łączą się z tymi narzędziami.
Jak stosować: Regularnie analizuj, jakie nowe „kanały wejścia” pojawiają się w ekosystemie (asystenci głosowi, agenci, zegarki) i oceniaj, czy twój produkt jest gotowy na integrację z nimi, zanim stanie się to wymogiem konkurencyjnym.
Na co uważać: To wciąż wczesny etap trendu — inwestowanie zbyt dużych zasobów w integracje, które mogą się nie przyjąć (np. jeśli nowa Siri okaże się rozczarowaniem), niesie ryzyko przedwczesnej optymalizacji pod niepewną przyszłość.