TL;DR

AI rewolucjonizuje prototypowanie API – Gemini 2.5 Pro generuje 650-liniowy dokument OpenAPI w minuty zamiast dni pracy
Konkretny workflow – Od pomysłu przez prompt, walidację, aż do działającego mock API z dokumentacją
Narzędzia do walidacji – RateMyOpenAPI i OpenAPI Dr automatycznie sprawdzają jakość kodu i standardy
MockBin tworzy prototypy błyskawicznie – Upload pliku JSON i gotowy mock server z API w sekundach
Customer discovery na nowym poziomie – Klienci mogą testować rzeczywiste API zamiast oglądać slajdy
API product managerzy zarabiają 19% więcej – Stanowią tylko 5% wszystkich PM, ale obsługują 57% ruchu internetowego
Praktyczne checklisty – Gotowe listy kontrolne dla każdego etapu procesu prototypowania

Tworzenie prototypów API zawsze było czasochłonne. Emmanuel Paraskakis, doświadczony API product manager z 15-letnim stażem, pokazuje jak AI zmienia tę rzeczywistość. W praktycznym webinarze demonstruje, jak w 20 minut stworzyć profesjonalny prototyp API kompletny z dokumentacją i mock serverem.

API Lifecycle – fundament strategicznego podejścia

API lifecycle składa się z cyklu etapów, jak wyjaśnia Paraskakis. „Generally, people come up with an idea for an API product. They might or might not go out and talk to a few customers and prospective users with a prototype, and then they will design the API, build it, deploy it so people can use it.” Po deploymencie „the API stays stable for a while, or should stay stable for a while, and we can monitor what it does, who uses it, how effective it is. Then at some point, it’s time to evolve the API and iterate, and then we’ll go back around the circle once again.”

Paraskakis podkreśla kluczową rolę source of truth – dokumentów będących umową między wszystkimi stronami. „Without a source of truth, you will have relative chaos. People will be building whatever instead of building the same thing or the thing that you prototyped and agreed on with users.”

Najważniejszym elementem source of truth jest API description document. OpenAPI stanowi najbardziej rozpowszechniony standard tego typu dokumentacji.

Metodologia Lean w prototypowaniu API

Szczególnie ważny jest proces prototypowania, który Paraskakis dzieli na cztery fazy. Analiza polega na formowaniu pomysłów na podstawie strategii, wiedzy rynkowej czy analityki innych API.

Następny krok to written hypothesis – spisana hipoteza. Paraskakis rekomenduje Lean Canvas od Ash Maurya, ewolucję Business Model Canvas. Ten format szczególnie dobrze sprawdza się dla API.

Po sformułowaniu hipotezy przychodzi czas na prototyp. Pokazanie działającego rozwiązania jest znacznie skuteczniejsze niż dokumenty czy prezentacje.

Ostatnim etapem jest customer discovery – rozmowy z użytkownikami o hipotezie i demonstracja prototypu. Ten loop należy powtarzać wielokrotnie, aż do dopracowania koncepcji.

Cały proces „roughly follows the build, measure, learn loop that Eric Ries advocates in Lean Startup”, jak podkreśla Paraskakis, nawiązując do książki Eric Riesa.

OpenAPI jako standard branżowy

Jak pokazuje survey SmartBear, który Paraskakis przytacza – „I think it’s in 2023 that shows that perhaps 80% of respondents to the survey who are people who build APIs, 80% use open API. And also what’s notable is that 54 use JSON schema, and JSON schema is part of Open.”

OpenAPI to domain-specific language z własnymi słowami kluczowymi. Dokument opisuje:

Metadane API (nazwa, wersja)
Lokalizację serwerów
Zabezpieczenia
Interfejs i endpointy
Komponenty i schematy

Najnowsza wersja 3.1.1 oferuje pełną funkcjonalność. Demo wykorzystuje wersję 3.1.0 ze względu na najlepszą kompatybilność z narzędziami – „We’ll use 3.1zero today because it’s most compatible with tools.”

Główny problem OpenAPI? Bardzo trudne pisanie od zera. Dokumenty mogą mieć setki linii kodu. Deweloperzy gubią się w złożonej strukturze.

Rewolucja AI w generowaniu OpenAPI

Paraskakis wykorzystuje Gemini 2.5 Pro experimental – darmowy model z dużym context window. Pozwala to na pracę z rozbudowanymi dokumentami bez ograniczeń tokenów.

Kluczem sukcesu jest dopracowany prompt. Zawiera on:

Rolę AI („doświadczony architekt API”)
Wymagania techniczne (OpenAPI 3.1.0)
Standardy organizacyjne
Konwencje nazewnictwa
Zasady bezpieczeństwa
Struktura błędów i status codes

Prompt kończy się prostą specyfikacją funkcjonalną. W demo to było: „zbuduj Dad Joke API używając wszystkich powyższych zasad”.

📋 Checklista: Elementy skutecznego promptu AI

Definicja roli:

[ ] „Act as an experienced API architect”
[ ] Określ poziom doświadczenia AI

Wymagania techniczne:

[ ] Wersja OpenAPI (3.1.0 dla kompatybilności)
[ ] Format danych (JSON in/out)
[ ] Standardy HTTP status codes

Konwencje organizacyjne:

[ ] Zasady nazewnictwa endpoints (/resources, nie /getResources)
[ ] Wymagania bezpieczeństwa
[ ] Struktura błędów
[ ] Rate limiting guidelines
[ ] Przykłady schematów

Specyfikacja funkcjonalna:

[ ] Jasny opis co API ma robić
[ ] Referencja do wcześniejszych standardów („use all of the above”)

Praktyczna demonstracja – Dad Joke API

Model wygenerował 646 linii kodu OpenAPI w kilka minut. Dokument zawierał:

Pełną strukturę API
Endpointy do listowania i tworzenia żartów
Przykładowe dane („Why don’t scientists trust atoms? Because they make up everything”)
Rate limiting
Obsługę błędów
Kompletne schematy

Pierwszy test? Walidacja składni w Scalar OpenAPI Editor. Kod przeszedł bez błędów.

Walidacja jakości – narzędzia kontrolne

RateMyOpenAPI (Zooplo)

Narzędzie ocenia jakość dokumentu OpenAPI. Demo API otrzymało rzadki wynik 100% – dowód na skuteczność dopracowanego promptu i możliwości Gemini 2.5 Pro.

System oferuje:

CLI dla automatyzacji
GitHub Actions
API do integracji
Email z wynikami dla prostych testów

OpenAPI Dr

Drugi linter wykrył drobne problemy:

Duplikacja opisów
Problematyczne przykłady
Wskazania konkretnych linii do poprawy

Feedback loop z AI: błędy można skopiować z powrotem do modelu. AI automatycznie poprawia całą specyfikację.

📋 Checklista: Walidacja OpenAPI

Walidacja składni:

[ ] Wklej kod do OpenAPI Editor (editor.scalar.com – Mark, founder Scalar, korekta podczas webinaru: „don’t use that old editor”)
[ ] Sprawdź, czy nie ma błędów składniowych
[ ] Pobierz plik JSON na dysk

Walidacja jakości:

[ ] Upload pliku do RateMyOpenAPI (Zooplo)
[ ] Upload pliku do OpenAPI Dr
[ ] Przeanalizuj wyniki z obu linterów
[ ] Skopiuj błędy z powrotem do AI (jeśli są)
[ ] Regeneruj dokument OpenAPI (jeśli potrzeba)

Od specyfikacji do działającego prototypu

MockBin przekształca OpenAPI w funkcjonalny mock server w sekundach. Upload pliku JSON generuje:

Unikalny URL mock servera
Kompletną dokumentację API
Działające endpointy z przykładowymi odpowiedziami

Mock API przyjmuje żądania i zwraca realistyczne odpowiedzi. Nie przechowuje danych, ale symuluje prawdziwe zachowanie API.

Paraskakis demonstruje testowanie za pomocą HTTPie – „my favorite API client, which happens to be HTTP at this moment” – pokazując jak mock API zwraca prawidłowe odpowiedzi na rzeczywiste żądania HTTP.

📋 Checklista: Tworzenie mock API

Przygotowanie mock servera:

[ ] Przejdź do MockBin
[ ] Upload pliku JSON OpenAPI
[ ] Kliknij „Create”
[ ] Skopiuj URL mock servera
[ ] Przetestuj endpointy w dokumentacji

Customer discovery na nowym poziomie

Prototyp umożliwia rewolucyjne podejście do customer discovery. Zamiast pokazywać slajdy, klienci mogą testować rzeczywiste API.

Proces zbierania feedbacku:

Udostępnienie URL mock servera klientom
Testowanie przez użytkowników rzeczywistych żądań
Zbieranie konkretnych uwag o strukturze danych
Iteracyjne poprawianie na podstawie feedbacku

30 rozmów z klientami z funkcjonalnym prototypem daje znacznie lepsze rezultaty niż teoretyczne dyskusje.

Wszechstronne zastosowania prototypu API

Działający prototyp ma znacznie szersze zastosowanie niż tylko customer discovery. Paraskakis wymienia konkretne przypadki użycia:

Internal pitches – „you can then go and pitch people internally and say, hey, we talk to users, this is what they want. Let me show you the exact thing that they want.”

Specyfikacja techniczna – prototyp służy jako konkretna specyfikacja dla zespołu deweloperskiego, eliminując nieporozumienia.

Unblocking front-end teams – „you can actually unblock front end teams to go and start their development while the backend team builds the API.” Zespoły frontend mogą rozpocząć pracę równolegle z backend.

Dokumentacja produktowa – „I’ve even used it to scaffold PRDs or stories or diagram and things to communicate what we’re going to build next.”

📋 Checklista: Customer discovery z prototypem API

Przygotowanie:

[ ] Przygotuj listę 30 potencjalnych klientów
[ ] Stwórz scenariusz rozmowy
[ ] Przygotuj URL mock servera

Podczas rozmowy:

[ ] Pokaż działającą dokumentację API
[ ] Pozwól klientowi przetestować endpointy
[ ] Zadaj pytania o strukturę danych
[ ] Zbierz feedback o naming conventions
[ ] Dokumentuj wszystkie uwagi

Po rozmowie:

[ ] Zaktualizuj hipotezę produktową
[ ] Zmodyfikuj prompt na podstawie feedbacku
[ ] Regeneruj OpenAPI (jeśli potrzeba)
[ ] Stwórz nową wersję mock API
[ ] Zaplanuj kolejne rozmowy

Kluczowe wnioski z demonstracji

Modele z dużym context window radzą sobie z rzeczywistą złożonością API. Gemini w wersji darmowej obsługuje dokumenty 650+ linii z pełną funkcjonalnością.

Deterministyczne narzędzia walidacji są niezbędne. AI może halucynować lub popełniać błędy. Automatyczna walidacja wykrywa problemy przed użyciem.

Feedback loop z AI działa. Model poprawia błędy po otrzymaniu informacji z linterów. Iteracyjne doskonalenie promptu daje lepsze rezultaty.

Zero-shot results są możliwe. „A good prompt can get you that zero shots result that we saw where you get like a very good, like 100% on Rate My Open API and an A plus on OpenAPI Dr.” Dopracowany prompt może dać doskonałe wyniki za pierwszym razem.

Individual contributors zyskują supermoce. „I think the most exciting thing is that as an individual product manager, as an individual contributor, you’re now way more powerful than you were. Creating a prototype and writing out open API was a pain. It could take days or weeks and now you can do it in 20 minutes.”

Automatyzacja jest kluczowa. GitHub Actions może zautomatyzować cały proces od generowania przez walidację do deploymentu mock servera.

Automatyzacja i najlepsze praktyki

Recommended workflow:

Prompt w repozytorium – własne standardy organizacyjne jako pliki w projekcie
GitHub Actions – automatyczne generowanie i walidacja
Custom GPT w OpenAI – „you can even create a custom GPT in OpenAI” z dedykowanymi standardami firmy
CLI tools – integracja z istniejącymi procesami
Schema repositories – „there’s a buddy of mine that’s developing a product that is going to be a schema repository that you can use with open API or with models. You can reference it and say, hey, these are the schemas that I want to use”

Dodatkowe narzędzia do eksploracji:

Dokumentacja: Thinio, Sudoku
Mock servers: Traffic Labs, Wiremock
Walidacja: OpenAPI Tools directory – „you can check this resource called OpenAI Tools… open API tools and it will show you validation tools, mock tools, documentation tools. Anything that you might need”
SDK generation: Speakeasy, API Matic, Stainless

Inspiracja i dalsze uczenie

Paraskakis wskazuje na Martin Davis z Zooplo jako źródło inspiracji: „go watch videos from Martin Davis of Zooplo on YouTube. He’s basically the inspiration for the demo that I showed you today. He started doing this and I kind of copied it from here.” Davis szczegółowo eksploruje różne modele AI w kontekście OpenAPI.

📋 Checklista: Automatyzacja procesu

Setup repozytorium:

[ ] Stwórz dedykowane repo dla API prototypów
[ ] Upload bazowego promptu jako plik
[ ] Skonfiguruj standardy organizacyjne jako templates

GitHub Actions:

[ ] Skonfiguruj action do generowania OpenAPI
[ ] Dodaj automatyczną walidację (RateMyOpenAPI CLI)
[ ] Skonfiguruj drugi linter (OpenAPI Dr)
[ ] Setup automatycznego deploymentu do mock servera

Integracja z narzędziami:

[ ] Połącz z API modelu AI (Gemini, OpenAI)
[ ] Skonfiguruj CLI tools dla linterów
[ ] Setup powiadomień o błędach walidacji

Przyszłość API product management

Statystyki, które przytacza Paraskakis, pokazują ogromną szansę zawodową:

Tylko 5% product managerów specjalizuje się w API/platform – „API and platform product managers are only 5% of the total of product managers”
57% ruchu internetowego to API calls – „APIs are maybe a couple of years ago were 57% the majority of Internet traffic and rising”
19% wyższe zarobki – „API product managers and platform product managers on average, and this is from stats that I’ve seen, get paid about 19% more, 1 9% more, which is significant”

Wzrost znaczenia agentów AI i LLM jeszcze bardziej podkreśla rolę dobrze zaprojektowanych API, jak podkreśla Paraskakis: „I think APIs are becoming more and more important and it’s more and more important, especially with agents and LLMs, to get them right. And for that we need API product managers and platform product managers.”

Dalsze uczenie się

Paraskakis prowadzi kursy na Maven, w tym „API Product mastery for experienced PMs”, z którego pochodzi demonstrowany workflow. Oferuje również bezpłatne lightning lessons, w tym sesje o API documentation z AI oraz budowaniu API z code generation.

Kompletny workflow – master checklista

📋 Checklista: Kompletny proces prototypowania API z AI

Przygotowanie:

[ ] Wybierz model AI z dużym context window (np. Gemini 2.5 Pro)
[ ] Przygotuj standardy organizacyjne do promptu
[ ] Zdefiniuj konwencje nazewnictwa API
[ ] Określ wymagania bezpieczeństwa

Generowanie OpenAPI:

[ ] Skopiuj bazowy prompt ze standardami
[ ] Zmodyfikuj specyfikację funkcjonalną (ostatnia linia promptu)
[ ] Uruchom AI i wygeneruj dokument OpenAPI
[ ] Skopiuj wygenerowany kod (przycisk „Copy code”)

Walidacja i kontrola jakości:

[ ] Sprawdź składnię w OpenAPI Editor
[ ] Przetestuj w dwóch różnych linterach
[ ] Popraw błędy przez feedback loop z AI
[ ] Pobierz finalna wersję JSON

Tworzenie prototypu:

[ ] Upload do MockBin
[ ] Przetestuj wszystkie endpointy
[ ] Przygotuj dokumentację dla klientów

Customer discovery:

[ ] Przeprowadź 30 rozmów z klientami
[ ] Zbierz konkretny feedback techniczny
[ ] Iteruj prototyp na podstawie uwag

Przygotowanie do implementacji:

[ ] Zapisz wszystkie decyzje projektowe
[ ] Stwórz specyfikację dla dev teamu
[ ] Zaprezentuj wyniki stakeholderom

Praktyczne wskazówki implementacji

Co zrobić, gdy chcesz wdrożyć ten proces:

Zacznij od płatnych modeli – lepsze rezultaty niż darmowe wersje
Dostosuj prompt do standardów swojej organizacji
Zautomatyzuj walidację w CI/CD pipeline
Użyj minimum dwóch różnych linterów
Stwórz repozytorium schematów dla konsystentności

Jak skutecznie zbierać feedback:

Udostępnij działający URL zamiast dokumentacji
Pozwól klientom na rzeczywiste testowanie API
Iteruj na podstawie konkretnych uwag technicznych
Dokumentuj wszystkie zmiany wynikające z feedbacku

Rekomendowane książki do pogłębienia tematu:

„Lean Startup” – Eric Ries (metodologia build-measure-learn)
„Running Lean” – Ash Maurya (Lean Canvas framework)
„Continuous API Management” – Mehdi Medjaoui (API lifecycle management)
„API Design Patterns” – JJ Geewax (best practices projektowania API)
„Platform Revolution” – Geoffrey Parker (strategia produktów platformowych)

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: https://maven.com/p/da039e/build-your-own-api-prototype-in-20-minutes-with-ai

Tag: Customer Discovery

Jobs to Be Done – różne soczewki patrzenia na klientów #EN163

Jak AI skraca prototypowanie API z tygodni do 20 minut – kompletny przewodnik #EN104