PM bez kódování dorazil do App Storu díky Claude Code
Blog

PM bez kódování dorazil do App Storu díky Claude Code

Project manager z Kyjeva postavil a vydal iOS aplikaci Respiro za šest týdnů pomocí Claude Code tím, že si vytvořil víc než patnáct specializovaných 'subagentů' — zajímavé jako proof‑of‑concept, ale také plné otazníků ohledně kvality kódu a bezpečnosti.

Když jsem narazila na příběh Kostiantyna Vlasenka z Mythical Games, který bez předchozích programátorských zkušeností dostal Respiro do App Storu za šest týdnů, zaujalo mě to hned ze dvou důvodů: praktická síla moderních asistenčních modelů a otázky, které podobné zrychlené workflow otevírá.

Krátce, co se stalo

Kostiantyn začal s prototypem v React Native (framework pro psaní mobilních aplikací v JavaScriptu) a poté narazil na problém s testováním Androidu. Podle popisu nechal Claude Code — Anthropicův nástroj pro generování kódu — přepsat aplikaci do Swiftu (nativní jazyk pro iOS) během několika hodin. A co je důležitější: nevytvořil jen jeden generický prompt, ale sestrojil přes 15 "subagentů" — malé specializované asistenty zaměřené na konkrétní oblasti jako TCA (The Composable Architecture, knihovní vzor pro správu stavu), Metal (Apple API pro GPU) nebo code review. Prakticky to používal jako tým, kterému šéfoval.

Proč mě to zajímá

Takové případy ukazují, že nástroje typu Claude Code nejsou jen pro rychlé prototypování — dokážou i zúročit produktovou znalost člověka, který samotný kód nepsal. To má velký dopad na to, kdo může dnes doručit funkční produkt: produktový manažer s dobrým prompt designem a znalostí domény může výrazně zkrátit cestu k hotovému release.

Zároveň se mi líbí, jak autor přemýšlel o dělení práce: specializované subagenty vnímal jako role v týmu, což je rozumný přístup pro komplexní projekty, kde jeden monolitický prompt lehce selže.

Co mě v tom ale zaráží (a co nám chybí)

Popis neříká, jak intenzivně proběhlo ruční testování na reálných zařízeních, jak řešili oprávnění a soukromí senzorů, jestli je zpracování dat na zařízení nebo v cloudu, a jak moc bylo potřeba kód doladit kvůli nečekaným edge caseům. To jsou zásadní věci, zvlášť u aplikace, která detekuje „stresové signály“ z hardwarových senzorů — nevíme, které senzory používají, jak robustní jsou signály a jaké jsou zdravotní či regulační důsledky.

Rychlé přepsání do Swiftu může vypadat skvěle, ale generovaný kód často potřebuje refaktoring, bezpečnostní audit a optimalizaci výkonu (obzvlášť pokud běží přes GPU přes Metal). Ačkoli autor uvádí, že teď běžně commituje kód v práci, nevíme, kolik práce za tím stálo v post‑release fázi.

Co z toho plyne dál (a co bych zkusila poradit)

Takové příběhy naznačují, že role v produkčním týmu se mohou promíchat — technická znalost už nemusí být až tak rigidní bariérou pro nasazení MVP. To otevírá prostor pro rychlejší validaci nápadů, ale taky nutí firmy zavést kontrolní procesy: automatizované testy, code review s lidským vývojářem a jasné zásady pro zpracování senzorických dat.

Když byste to chtěli replikovat, doporučila bych: 1) od začátku plánovat reálné testování na cílových zařízeních, 2) definovat přesné požadavky na soukromí a bezpečnost dat, 3) mít někoho, kdo rozumí platformě (iOS API, App Store pravidlům), a 4) považovat generovaný kód za první draft, ne za finální produkt.

Příběh Kostiantyna je skvělý signál pro produktové týmy a nezávislé tvůrce: s dobrým prompt‑designem a organizační strukturou agentů můžete dosáhnout hodně rychle. Nicméně důležitost tradičních kroků — testy, bezpečnost, audit — z toho nikam nezmizela.

Zdroje

Došlo k neočekávané chybě. Obnovit 🗙

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.