O czym jest ten film
- Aktualizacja wyników aplikacji Amy: przekroczone 3 tys. dolarów miesięcznego przychodu przy marży około 85 proc. — rzadkość wśród produktów opartych na AI, gdzie marże zwykle wynoszą 20–30 proc.
- Autor tymczasowo odkłada pracę nad retencją z pierwszego tygodnia (swój dotychczasowy kompas) i zajmuje się zabezpieczeniem aplikacji na przyszłość.
- Impulsem jest nowa wersja Siri zapowiedziana do iOS 27 — i prognoza, że zmieni ona sposób, w jaki użytkownicy iPhone’ów wybierają aplikacje.
- Integrację z Siri autor zbudował jednym promptem do Claude Code, a potem analizuje, dlaczego poszło to tak szybko.
- Kluczowa przewaga Amy: posiłek wpisuje się jednym zdaniem. MyFitnessPal wymaga wyszukiwania i wybierania pozycji, Cal AI — zrobienia zdjęcia; głos nie obsłuży takich interfejsów.
- Siri rozpoznaje wyłącznie frazy zadeklarowane z góry, dlatego zapis posiłku wymaga dwóch kroków; autor spodziewa się, że dynamiczne frazy pojawią się w kolejnych wersjach.
- Druga duża inwestycja: serwer MCP i publiczne API, dzięki którym agenci tacy jak Claude czy Codex mogą zapisywać posiłki i analizować dietę użytkownika.
- Trzy główne przeszkody: OAuth wymusił budowę webowej ścieżki logowania, brak API trzeba było uzupełnić, a otwarte API wymaga limitów chroniących przed nadużyciami — każdy wpis kosztuje około pół centa.
- Najtrudniejszy okazuje się interfejs: jak wytłumaczyć MCP zwykłemu człowiekowi wewnątrz aplikacji na iPhone’a, skoro żadna aplikacja mobilna tego jeszcze nie robi.
- W tle: planowanie posiłków i zamawianie zakupów przez Codexa (z lekcją o sprawdzaniu koszyka), a w następnym odcinku — integracja z Apple Watch i wersja na Androida.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Jedno zdanie tekstu zamiast formularza — fundament przewagi
Na czym polega: Cała architektura Amy sprowadza się do jednej linijki tekstu, a cała ciężka robota AI odbywa się na serwerze, niewidocznie dla użytkownika. Dzięki temu asystent głosowy może korzystać z aplikacji dokładnie tak samo jak człowiek — i autor zbudował pełną integrację z Siri jednym promptem. Aplikacje oparte na wyszukiwaniu produktów (MyFitnessPal) albo na zdjęciach (Cal AI) takiej drogi nie mają.
Jak stosować: Jeśli projektujesz produkt, sprawdź, czy najczęstsza czynność użytkownika da się sprowadzić do jednego zdania. Jeśli tak — głos, zegarek i agenci dostaną tę samą ścieżkę co człowiek, bez dublowania pracy.
Na co uważać: To decyzja architektoniczna podjęta od pierwszego dnia, a nie funkcja dorobiona później. Dorabianie prostego wejścia do produktu pełnego formularzy i rozwijanych menu zwykle oznacza przebudowę, nie dodanie przycisku.
2.Integruj się z nowym Siri, zanim zmienią się nawyki użytkowników
Na czym polega: Apple zapowiedziało nową wersję Siri w iOS 27. Autor zakłada, że jeśli asystent stanie się naprawdę użyteczny, użytkownicy zaczną wzywać go kilka razy dziennie — a potem premiować aplikacje, które z nim dobrze współpracują.
Jak stosować: Nie czekaj na premierę systemu. Zbuduj integrację z wyprzedzeniem, zaczynając od jednej, najczęstszej czynności (u autora: zapisania posiłku), żeby w dniu premiery znaleźć się wśród gotowych.
Na co uważać: Przekonanie o sukcesie nowego Siri to przypuszczenie, nie pewnik. Warto jednak traktować integrację jako ubezpieczenie — stosunkowo tanie w porównaniu z kosztem późniejszego gonienia rynku.
3.Siri rozumie tylko frazy zdefiniowane na sztywno
Na czym polega: Aplikacja musi z góry zadeklarować zwroty, na które asystent ma reagować; dynamicznych fraz Siri jeszcze nie obsługuje. Dlatego zapis posiłku wymaga dwóch kroków: przywołania aplikacji hasłem, a dopiero potem podania treści.
Jak stosować: Wybierz krótką, naturalną frazę wywoławczą („zapisz posiłek w Amy”) i zaprojektuj dialog w dwóch krokach. Zostaw w architekturze miejsce na skrócenie ścieżki, gdy Apple udostępni frazy dynamiczne — autor planuje właśnie to.
Na co uważać: Nie obiecuj w komunikacji, że „wystarczy powiedzieć cokolwiek”. Obecnie konieczne jest użycie dokładnego hasła — inaczej użytkownicy poczują się wprowadzeni w błąd.
4.Dyktuj prompty do agentów kodujących
Na czym polega: Autor całe polecenia do Claude Code dyktuje, zamiast je wpisywać. Mowa jest szybsza od pisania, a polecenia z ust wychodzą dłuższe i bardziej szczegółowe — o jakości promptu często decyduje więc sposób jego podania, nie sam model.
Jak stosować: Wypróbuj narzędzie do dyktowania rozpoznające terminologię techniczną (nazwy usług chmurowych, modeli, plików). Niektóre potrafią też na samo polecenie głosowe oznaczać pliki w środowisku programistycznym.
Na co uważać: Ten fragment filmu to materiał sponsorowany. Pochwały konkretnego narzędzia traktuj jak reklamę i zrób własny test.
5.Deleguj agentowi zakupy, ale przeglądaj jego decyzje
Na czym polega: Autor układa jadłospisy w Codexie i tym samym agentem zamawia zakupy — narzędzie typu computer use steruje jego przeglądarką. Raz agent zamówił cztery funty cytryn (niecałe dwa kilogramy) do przepisu, w którym wystarczała jedna.
Jak stosować: Powtarzalne czynności w przeglądarce można zlecać agentowi, ale warto wprowadzić żelazną zasadę: każdy koszyk i każda decyzja angażująca pieniądze jest przeglądana przez człowieka przed zatwierdzeniem.
Na co uważać: Pomyłka z cytrynami wyszła na jaw dopiero przy odbiorze dostawy. Koszt błędu agenta bywa realny, a wykrywalny późno.
6.Buduj MCP, gdy użytkownicy ręcznie przenoszą dane do modeli
Na czym polega: MCP pozwala narzędziom takim jak Claude, ChatGPT czy Codex bezpiecznie działać w obcej usłudze. W Amy agent może zapisać posiłek, przeanalizować nawyki żywieniowe, podpowiedzieć zmiany w diecie. Wcześniej jedyna droga do takiej analizy to eksport danych z ustawień i wklejenie ich do czatu.
Jak stosować: Poszukaj sygnału: jeśli użytkownicy przenoszą dane z Twojego produktu do modeli ręcznie, to gotowy pomysł na pierwsze narzędzie w MCP.
Na co uważać: To wciąż teren pionierski — brakuje wzorców i punktów odniesienia. Zabudżetuj więcej czasu, niż podpowiada wcześniejsze doświadczenie: autor wycenił pracę na jeden dzień, a było „znacznie trudniej”.
7.OAuth wymusza webową stronę logowania — planuj ją wcześniej
Na czym polega: Zalecany sposób uwierzytelniania MCP to OAuth: użytkownik trafia na stronę, loguje się i klika „zezwól”, bez wklejania kluczy. Aplikacja czysto mobilna nie ma dokąd go wysłać — autor musiał najpierw zbudować webową ścieżkę logowania, łącznie z logowaniem przez Google i Apple.
Jak stosować: Jeśli planujesz MCP, wcześniej zaplanuj minimalną wersję webową do autoryzacji. Alternatywa — klucze API wklejane ręcznie — działa, ale bywa za trudna dla mniej technicznych użytkowników.
Na co uważać: To praca dodatkowa, niewidoczna dla użytkownika. Łatwo jej nie doszacować w harmonogramie.
8.Projektuj API pod pytania użytkowników, nie pod zasoby
Na czym polega: Pierwszy odruch autora to punkt końcowy zwracający dzisiejsze jedzenie. Rzeczywiste pytania brzmią raczej: „co jadłem w ostatnie dwa tygodnie”. Konieczna okazała się przebudowa pod zakresy dat.
Jak stosować: Zanim napiszesz pierwszy endpoint, wypisz pytania, jakie użytkownicy zlecą swoim agentom, i buduj pod nie. Traktuj API jak produkt z własnym doświadczeniem użytkownika.
Na co uważać: Przewidywanie użycia bywa zawodne — licz na iteracje po starcie, ale im lepiej odgadniesz pytania, tym mniej przebudów.
9.Limity chroniące AI nie mogą blokować legalnych scenariuszy
Na czym polega: Każdy wpis w Amy kosztuje około pół centa, więc otwarte API i otwarty MCP to gotowe zaproszenie dla nadużyć. Prosty limit „trzy wpisy na minutę” zepsułby jednak zupełnie legalny scenariusz: wieczorne dyktowanie całego dnia naraz.
Jak stosować: Stosuj wzorzec stopniowego wygaszania: pozwól na serię wpisów jednorazowo, a kolejne próby coraz mocniej spowalniaj, aż do pełnego zatrzymania. Połącz to z limitem kosztów przypadającym na użytkownika.
Na co uważać: Autor wstrzymuje się z ujawnianiem pozostałych zabezpieczeń, dopóki nie upewni się, że są szczelne — słusznie: publiczne opisanie mechanizmów obronnych ułatwia ich obejście.
10.Użytkownicy zaczną wybierać aplikacje przyjazne agentom
Na czym polega: Autor sam coraz więcej codziennych spraw załatwia przez Claude i Codexa — i sam zaczyna premiować usługi, które łączą się z nimi bez problemów. Przewiduje, że przeciętni konsumenci pomyślą podobnie, a impuls da im nowe Siri.
Jak stosować: Wydziel część czasu produktowego na pracę z wyprzedzeniem: integracje głosowe, API, MCP, zegarek. Wybierz jedną najczęstszą czynność użytkownika i upewnij się, że da się ją wykonać spoza aplikacji.
Na co uważać: To wczesna faza i brak twardych danych o masowym popycie. Traktuj to jako zakład o przewagę, nie pewnik — i pilnuj, by praca „na przyszłość” nie rozproszyła zespołu kosztem bieżących wskaźników.
Redakcyjne tłumaczenie
Wprowadzenie i liczby
Dziś krótka aktualizacja dotycząca aplikacji do liczenia kalorii, którą uruchomiłem kilka miesięcy temu. Zacznę od liczb, ale nagrywam ten film przede wszystkim dlatego, że sporo czasu poświęciłem na przygotowanie produktu na nadchodzące zmiany — i chcę się tym podzielić. Pokażę, co udało się wydać, a co ważniejsze, wyjaśnię, dlaczego moim zdaniem stawia to Amy w znacznie lepszej pozycji na przyszłość i jak przenieść te wnioski na własne projekty.
Jeśli oglądasz mnie po raz pierwszy — witaj. Nazywam się Chris i buduję aplikacje podnoszące produktywność. Zwykle każdy film poświęcam jednej z nich, a dziś jest to Amy. Krótko o kontekście: Amy to licznik kalorii urzącony jak Notatki od Apple — po lewej wpisujesz, co zjadłeś, a po prawej jak za dotknięciem różdżki pojawiają się kalorie. Pod względem wygody nie znam prostszego sposobu na zapisywanie posiłków.
Jeśli chodzi o liczby, właśnie przekroczyliśmy spory próg: 3 tysiące dolarów powtarzalnego przychodu miesięcznego. Ekscytujące, ale najbardziej dumny jestem z czegoś innego — marża wynosi około 85 procent. Jak na produkt oparty na AI to prawdziwa rzadkość, bo te marże bywają słabe, rzędu 20–30 procent. Skoro udało się połączyć taki przychód z taką marżą — z tego jestem naprawdę dumny.
Zmiana kursu: od retencji do zabezpieczania na przyszłość
To tyle z liczb, ale przede wszystkim chcę opowiedzieć, czego nauczył mnie ten miesiąc. Jeśli śledzisz moje filmy, wiesz, że od dawna całą energię kierowałem w poprawę retencji z pierwszego tygodnia — to miara pokazująca, ile osób siedem dni po rejestracji wciąż korzysta z aplikacji; traktuję ją jako swój kompas. Tym razem jednak zmieniłem kurs i zająłem się przygotowaniem Amy na to, co nadchodzi, bo zauważyłem kilka zmian w branży.
Rzecz jasna widać, że ludzie coraz częściej sięgają po narzędzia takie jak Claude czy ChatGPT, ale moim zdaniem na iPhone’ach dzieje się coś większego: Apple zapowiedziało nową wersję Siri. I dlatego to istotne. Powiedzmy szczerze — przez ostatnie lata Siri bywała obiektem żartów. Sam z niej nie korzystam, bo fatalnie wykonuje polecenia, i nie jestem w tym odosobniony. Jeśli jednak nowa wersja okaże się tak dobra, jak się mówi, to może się zmienić. A gdy użytkownicy iPhone’ów zaczną wzywać asystenta po kilka razy dziennie, to w najlepszym razie będą oczekiwać od swoich aplikacji bezproblemowej współpracy z nim. A z czasem — jestem tego niemal pewien — zaczną wybierać te aplikacje, które mają naprawdę dobrą integrację z Siri.
Nowa Siri ma zadebiutować wraz z iOS 27, którego w chwili nagrywania jeszcze nie ma. Żeby uprzedzić te wydarzenia, pierwszą decyzją dla bezpieczeństwa aplikacji było wydanie porządnej, dopracowanej integracji z asystentem. Pomyślałem sobie: nie powinno to być trudne, w końcu Claude Code da radę ogarnąć to za jednym zamachem. Otworzyłem więc narzędzie i powiedziałem: „Zbuduj integrację z Siri, w której użytkownik mówi, co zjadł, aplikacja to przetwarza i zwraca podgląd wartości odżywczych do potwierdzenia zapisu”. To dokładnie ten prompt, którego użyłem — i jedno to polecenie wystarczyło, żeby powstała działająca wersja. Potem doszły jeszcze dwa, trzy kolejne, czysto kosmetyczne.
Jak to działa? Mówisz: „Hej Siri, zapisz posiłek w Amy”. Asystent pyta, co jadłeś. Odpowiadasz: „Burger z In-N-Out i frytki”. I to naprawdę wszystko — na ekranie pojawiają się wartości odżywcze, żebyś mógł potwierdzić zapis. (Informacja dodatkowa: In-N-Out Burger — popularna sieć fast food na Zachodnim Wybrzeżu Stanów Zjednoczonych.)
Dlaczego poszło to tak szybko: architektura zbudowana pod tekst
Po wydaniu tej funkcji zacząłem się zastanawiać, czemu właściwie poszło tak gładko — aż podejrzanie szybko. I dotarło do mnie, że integracja z Siri powstawała tak łatwo dlatego, iż Amy ma nad innymi licznikami kalorii ogromną przewagę: jedzenie wprowadza się w niej wyłącznie tekstem. Wpisujesz jedną linijkę, ona trafia do mojego backendu, tam sztuczna inteligencja wykonuje wszystkie obliczenia i zwraca kalorie wraz z resztą wartości odżywczych.
Porównaj to z konkurencją. W MyFitnessPal, żeby cokolwiek zapisać, szukasz produktu, przeglądasz wyniki, wybierasz najlepiej pasujący, poprawiasz ilość i gramaturę, na końcu zapisujesz. I właśnie dlatego — moim zdaniem — MyFitnessPal nie ma porządnej integracji z Siri: gdy powiesz „zapisz burrito śniadaniowe w MyFitnessPal”, asystent nie ma pojęcia, jak manewrować między tymi rozwijanymi menu. Albo weź Cal AI, opartą przede wszystkim na zdjęciach: zdjęcia głosem się nie zrobi. Najwięcej, co osiągniesz, to „Hej Siri, otwórz Cal AI” — aplikacja uruchomi aparat i dopiero wtedy robię fotografię.
Więc sytuacja większości dużych liczników kalorii jest trochę patowa: w najlepszym razie potrafią polecić Siri, żeby otworzyła aplikację. W Amy całe doświadczenie opiera się na jednym kawałku tekstu, więc Siri może korzystać z aplikacji dokładnie tak, jak robi to człowiek — również wystarczy jej jedna linijka. Cała złożoność rozgrywa się w tle. Użytkownik niczego nie wybiera, bo tak produkt został zaprojektowany od początku: pisze swobodnie, co chce, a aplikacja ma dość rozumu, żeby się domyślić, o co chodzi. To zresztą część urody Amy — biorę bardzo złożony proces (spójrzcie na diagram pokazujący, co dzieje się po wpisaniu posiłku) i całość uruchamia się w ciągu sekundy, maksymalnie dwóch, całkowicie niewidocznie. Jednym z owoców tamtych inwestycji jest to, że bardzo dobra obsługa Siri spadła nam praktycznie za darmo.
Ograniczenie: frazy na sztywno
Pewnie zauważyłeś, że wymagało to dwóch kroków: musiałem powiedzieć „Hej Siri, zapisz posiłek w Amy”, a dopiero potem podać jedzenie. Chętnie obsłużyłbym wszystko za jednym razem — „zapisz w Amy mojego burgera z In-N-Out i frytki” — ale Apple na razie na to nie pozwala. Siri działa tak, że aplikacja musi zadeklarować konkretne zwroty, na które asystent ma reagować, i niestety trzeba je określić z góry. Nie jest jeszcze na tyle sprytna, żeby radzić sobie z dynamicznymi frazami — dlatego potrzebne są dwa kroki: przywołujesz aplikację ustalonym hasłem, a potem dopiero mówisz, co zjadłeś. Mam jednak przeczucie, że w kolejnych wersjach pojawią się frazy dynamiczne, a gdy tak się stanie, wprowadzę je do Amy.
Jaki z tego płynie wniosek? Jeśli budujesz aplikację i możesz zrobić integrację z Siri — zrób ją. Ale ważniejsza lekcja jest inna: projektując produkt, myśl z wyprzedzeniem o formach wejścia, które chcesz obsługiwać. Mówię też o zegarku, o wejściu z agentów — tych kanałów jest mnóstwo. A jeśli Twoja aplikacja nie daje użytkownikowi łatwego sposobu na wprowadzanie danych, warto poszukać pomysłowych rozwiązań, żeby to zmienić.
Fragment sponsorski: dyktowanie promptów
Może zauważyłeś, że budując integrację, dyktowałem polecenie do Claude Code. I właśnie tak zalecam pracę z agentami tego typu, także w Cursorze: wszystko dyktować, bo w ten sposób powstają znacznie bardziej szczegółowe prompty. Ja używam do tego WhisperFlow — i wielkie podziękowania dla nich za sponsoring tego filmu. WhisperFlow to sprytne zamawianie mowy na tekst, działające w dowolnej aplikacji. Twórcom oprogramowania pasuje idealnie, bo rozpoznaje terminologię techniczną: kiedy mówię „AWS”, „DynamoDB”, „Gemini 2.5 Flash-Lite”, „Supabase”, za każdym razem zapisuje to poprawnie. A jeśli pracujesz w Cursorze albo Windsurfie, narzędzie współpracuje z tymi środowiskami i potrafi samo oznaczać pliki: mówię „ulepsz style w subscription-overview.tsx”, a plik zostaje podpięty, zanim cokolwiek wpiszę. Działa na komputerze — więc przy Cursorze, Claude Code i ChatGPT, z których korzystam — a także na iOS i Androidzie. Ja używam go bez przerwy, odpisując na wiadomości czy komentarze pod filmami, i to właśnie dzięki niemu mogę odpowiadać tak obszernie. Link zostawiam w opisie, mam też kod na miesiąc gratisu — na dodatek do czternastu dni wersji Pro, które i tak dostajesz po rejestracji. Nie musieli tego robić; to ja o to poprosiłem, więc im dziękuję.
Z życia autora: agent planuje posiłki i zamawia zakupy
Następna rzecz, którą wydałem, zrodziła się z mojego własnego problemu. Ostatnio zabrałem się za planowanie posiłków i do tego konkretnie używam Codexa. Wybrałem go, bo ma znakomite narzędzie do sterowania komputerem, tzw. computer use: potrafi operować moim komputerem i przeglądarką oraz działać w moim imieniu. Kiedy ułożę z nim jadłospis na tydzień, każę mu też zamówić zakupy w Whole Foods. Przy okazji zabawna historia: tym razem przejrzałem koszyk za mało skrupulatnie i agent zamówił cztery funty cytryn — nieco ponad półtora kilograma — do przepisu, w którym wystarczała jedna. Zauważyłem to dopiero przy odbiorze dostawy. Wniosek: jeśli chcecie tak robić, dokładnie sprawdzajcie koszyk przed złożeniem zamówienia.
Czyli: Codex układa mi posiłki i zamawia zakupy. Brakowało tylko jednego — żeby po zjedzeniu móc mu powiedzieć: „zapisz to w Amy”. I dokładnie dlatego zabrałem się za budowę MCP. Dla nietechnicznych: MCP to w skrócie sposób, w jaki narzędzia AI — ChatGPT, Claude Code, Codex — mogą w bezpieczny sposób korzystać z usług trzecich, takich jak Amy. (Informacja dodatkowa: MCP to skrót od Model Context Protocol — otwartego standardu łączenia modeli AI z zewnętrznymi narzędziami i danymi.) W moim przypadku MCP pozwoli agentom zapisywać posiłki, analizować nawyki żywieniowe, a może nawet podpowiadać, co warto w diecie zmienić. To idealne uzupełnienie, bo wiele osób chce przejrzeć swoje jedzenie w dłuższej perspektywie — a dziś jedyna droga to wejście w ustawienia, wyeksportowanie danych i wklejenie ich do ChatGPT albo Claude. Dzięki MCP wystarczy podpiąć Amy do tych narzędzi i poprosić.
Problem pierwszy: OAuth wymusił webowe logowanie
Miałem już trochę doświadczenia, bo zbudowałem MCP dla mojej aplikacji do planowania dnia, Ellie. O ile mogłem się zorientować, żaden inny licznik kalorii nie udostępnia MCP — nie znalazłem ani jednego przykładu do nauki. To ekscytujące, bo oznacza, że jestem wśród pierwszych, ale i kłopotliwe: nie miałem wzorców, do których mógłbym się porównywać. Skoro robiłem to już przy Ellie, pomyślałem: z głowy, dam radę w dzień. Wyszło znacznie trudniej, niż zakładałem — z trzech powodów.
Pierwszy to uwierzytelnianie. Większość MCP pozwala na nie na dwa sposoby. Pierwszy: klucz API — użytkownik, dodając MCP do Claude czy ChatGPT, wkleja klucz, którym potwierdza tożsamość. Drugi to tzw. OAuth: przy próbie podłączenia użytkownik trafia na stronę autoryzacji, loguje się i klika „zezwól”, bez żadnych kluczy. OAuth jest standardem i zalecaną drogą budowy MCP. Jest tylko jedna przeszkoda: wymaga logowania przez przeglądarkę — potrzebna jest realna strona logowania i autoryzacji — a Amy to wyłącznie aplikacja na iOS, wersji webowej nie ma. Zanim w ogóle zabrałem się za MCP, musiałem więc zbudować całą webową ścieżkę logowania, łącznie z logowaniem przez Google i Apple, co też nie było trywialne. Na szczęście postawiłem w życiu mnóstwo stron, więc technicznie poszło łatwo — po prostu irytowało mnie, że w ogóle musiałem.
Problem drugi: brak API, a więc i publiczne API
Gdy autoryzacja była gotowa, napotkałem kolejną ścianę: Amy nie ma API. Wszystko dzieje się na urządzeniu, a urządzenie rozmawia z moim backendem. Nie było jak pozwolić klientowi trzeciemu — takiemu jak MCP — na kontakt z backendem. Standardowym rozwiązaniem jest właśnie API. Więc je zbudowałem: porządne, z przemyślanymi punktami końcowymi (endpointami). I pomyślałem sobie: skoro już przy tym jestem, zrobię z tego API publiczne. Tak też postanowiłem — oprócz MCP udostępniam otwarte API, żeby inni deweloperzy mogli budować na podstawie Amy.
Nie obeszło się bez wyzwań. Na pierwszy odruch zrobiłem endpoint zwracający dzisiejsze jedzenie — wydawało mi się, że to najczęstsze pytanie: „co dziś zjadłem?”. Dopiero po zbudowaniu dotarło do mnie, że ludzie będą zadawać pytania ogólniejsze: „co jadłem w ostatnie dwa tygodnie”, a nie tylko „co jadłem dziś”. Musiałem więc przebudować endpoint, żeby obsługiwał zakresy dat. I to był tylko jeden przykład. Mnóstwo takich sytuacji wymusiło przemyślenie, jak ludzie będą z tego korzystać — bo nawet mając API, wciąż projektuje się doświadczenie użytkownika. Trzeba z wyprzedzeniem przewidzieć sposoby użycia i przygotować pod nie odpowiednie endpointy. Sporo czasu pochłonęła mi burza mózgów: jak użytkownicy będą korzystać ze swoich agentów i czego potrzebują, żeby to było możliwe.
Problem trzeci: bezpieczeństwo i limity
Trzecia przeszkoda, związana z API, to bezpieczeństwo. Stanęła natychmiast, bo projektując API, uświadomiłem sobie, że wielkim scenariuszem będzie masowe wpisywanie: „zapisz mi cały dzień” albo „zapisz cały tydzień”. Kłopot w tym, że każde wpisanie czegoś w Amy sporo kosztuje — mniej więcej pół centa za wpis czy poprawkę, bo w tle pracuje masa skomplikowanej AI. W aplikacji na iOS łatwiej to chronić i mam na backendzie odpowiednie limity, ale otwarty MCP i otwarte API to gotowe zaproszenie dla nadużyć.
Zaskakująco dużą część wysiłku pochłonęło projektowanie limitów dla MCP. Zacząłem prosto: pozwolę na trzy wpisy na minutę, brzmi rozsądnie. Szybko okazało się, że to błąd — widzę przecież całkowicie legalny scenariusz, w którym ktoś wieczorem dyktuje do ChatGPT: „zapisz wszystkie moje dzisiejsze posiłki do Amy”. Przewiduję, że to będzie bardzo częste, gdy ludzie będą zapisywać wszystko na koniec dnia. Musiałem więc pozwolić na dużą serię wpisów, ale nie mogłem zgadzać się na takie serie w nieskończoność. Rozwiązaniem okazało się stopniowe wygaszanie: duża seria jest dozwolona, ale potem system zwalnia i w końcu zatrzymuje każdego, kto próbuje powtarzać takie zrywy. To bardzo popularny wzorzec przy projektowaniu limitów. Wdrożyłem jeszcze kilka rzeczy związanych z monitorowaniem nadużyć, ale na razie o nich nie opowiem, dopóki nie upewnię się, że wszystko jest szczelne.
Problem czwarty, najtrudniejszy: jak wytłumaczyć MCP na telefonie
Ostatnia przeszkoda okazała się — ku memu zaskoczeniu — najtrudniejsza: interfejs. Jak w ogóle wytłumaczyć MCP zwykłemu człowiekowi wewnątrz aplikacji na iPhone’a? Szukałem przykładów jak opętany, ale każdy, jaki znalazłem, dotyczył wersji webowej albo programu na komputer. Żadna aplikacja nie opowiada o MCP na telefonie. Wymagało to mnóstwa iteracji, ale w końcu doszedłem do rozwiązania: osobna strona w ustawieniach pokazuje wprost, co narzędzia AI mogą robić, wraz z banalnie prostymi instrukcjami podłączenia Amy. Instrukcje można skopiować albo wysłać sobie mailem, żeby spokojnie przeczytać je przy komputerze. Dorzuciłem też osobną sekcję dla API: zarządzanie kluczami i dokumentacja. Szczerze mówiąc, niewiele widziałem aplikacji mobilnych, które robią coś podobnego. Zapewne jeszcze będę to doszlifowywał, ale to był wspaniały problem projektowy: jak wziąć coś tak złożonego — i kojarzonego wyłącznie z desktopem albo webem — i upakować w strawnej formie na telefonie, zwłaszcza gdy chodzi o coś takiego jak API? Udało się — MCP i API Amy działają już dziś i można je wypróbować.
Co dalej i główne przesłanie
To były dwie główne rzeczy wydane w tym miesiącu w ramach przygotowania produktu na przyszłość. Pracowałem też nad mnóstwem innych — między innymi integracją z Apple Watch i wersją Amy na Androida — ale zostawiam je na następny film, bo każda zasługuje na osobne omówienie.
Najważniejsza myśl, którą chcę zostawić: warto poświęcić czas na myślenie z wyprzedzeniem, bo sposób, w jaki ludzie obcują z aplikacjami, zaraz zacznie się zmieniać. Widzę to na sobie — mnóstwo czasu spędzam w Claude i Codexie, żeby załatwiać codzienne sprawy, i sam zaczynam wybierać te usługi, które łączą się z tymi narzędziami bez szwanku. Jestem przekonany, że wy, deweloperzy, którzy to oglądacie, robicie dokładnie to samo. Wciąż jest wcześnie, ale moim zdaniem przeciętni konsumenci też zaczną tak myśleć: będą premiować aplikacje i usługi sprawnie dogadujące się z agentami, z których korzystają codziennie. Jeśli nowe Siri się przyjmie, zaczną wybierać te programy, które najlepiej współpracują z asystentem. Dlatego tak ważne jest, by już teraz przygotowywać swoje produkty na te zmiany — i wyprzedzać je, zamiast gonić.
To w zasadzie wszystko, czym chciałem się podzielić. Jeśli podoba Ci się ten rodzaj treści, zajrzyj na mój Instagram i TikTok — publikuję tam niemal co drugi dzień o budowaniu aplikacji. I oczywiście zasubskrybuj kanał. Dziękuję bardzo za obejrzenie — do zobaczenia w następnym filmie.