What Codex Unlocks for Notion: Jak jsem postavil Notion AI Voice Input za pár hodin a zvládl to i s týmem

Když se na vývoj dívám dlouhodobě, největší brzda většinou nebývá jen samotné kódování. Je to kontext: porozumět, jak věc funguje dnes, kam přesně ji vložit, jak ji zabalit pro různé platformy a jak to celé udržet tak, aby tým mohl pokračovat bez zbytečných ztrát.

U Notionu se mi to teď povedlo otočit díky Codexu. V rámci své práce na AI product engineering se mi podařilo postavit funkci Notion AI voice input, tedy hlasové zadávání místo psaní, a to napříč klienty na webu i v desktopu. A hlavní věc, která mi to celé učinila neskutečně cenným, byla rychlost a také to, že jsem to zvládl „sólo“, i když jsem současně měl na starosti podporu týmu.

V tomhle článku popíšu, co jsem si z toho odnesl, jak takový typ práce vypadá prakticky, a hlavně jak přenést ten princip „postav to rychle, ale správně“ do vlastních projektů.

Obsah

• 🚀 Proč je hlasové zadávání v Notionu tak zajímavé
• 🧠 „Kontext je superpower“: jak Codex zrychlil rozhodování
• ⏱️ Jak jsem to postavil za 3 až 4 hodiny (a co to vlastně znamenalo)
• 📱 Od mobilu k webu a desktopu v jednom kroku
• 👥 Jak jsem to zvládl i s týmem: agilita bez chaosu
• 🧩 Co je „odblokováno“ pro produkty, ne jen pro kód
• 🛠️ Jak jsem přemýšlel o práci: zadání, přesnost, ověření
• 🎤 Co obvykle dělá hlasové zadávání těžší, než to vypadá
• 🔍 Proč je „jedním shot“ reálně významné
• 📈 Dopad na tým: méně přerušení, víc toku práce
• 🌍 Co si z toho můžu odnést jako obecný princip pro vaše projekty
• ❤️ Proč mi to připadá „crazy“ (a proč to není jen hype)
• 📝 Krátké shrnutí

🚀 Proč je hlasové zadávání v Notionu tak zajímavé

Notion je pro spoustu lidí místo, kde si organizují práci, myšlenky a projekty. To znamená, že zadávání je základ. Většina lidí píše. Ale jsou situace, kdy je psaní méně pohodlné nebo pomalejší: když máte plné ruce, když chcete rychle zachytit nápad, nebo když pracujete v pohybu a chcete mluvit rovnou do aplikace.

Hlasové zadávání se proto nehodí jen jako „wow funkce“. Je to typ interface, který snižuje tření mezi myšlenkou a obsahem. U Notionu se navíc nabízí přirozené napojení na existující struktury a workflow: pokud už uživatel umí zadávat a organizovat obsah, hlasové zadávání může být jen další způsob, jak se dostat k výsledku.

V praxi jsem pracoval na tom, aby lidé mohli mluvit místo psaní. A přesně v tom se ukázalo, jak moc záleží na správné integraci do ekosystému aplikace: nejde jen o rozpoznání řeči, jde o to, aby to zapadlo do produktu a bylo konzistentní napříč platformami.

🧠 „Kontext je superpower“: jak Codex zrychlil rozhodování

Když se bavíme o nástrojích typu Codex, často se řeší hlavně výstup. Já ale na tom nejvíc oceňuju, že umí jít cestou branch out a zjistit kontext předtím, než se pustí do práce.

V mém případě to znamenalo, že nebylo potřeba ručně psát každou drobnost od nuly. Místo toho jsem mohl ukázat na to, co už existuje v mobilních aplikacích, a nechat nástroj, aby si vzal „co je pravda“ podle existující implementace.

Tenhle přístup je důležitý, protože v reálném produktu existuje spousta detailů, které si člověk uvědomí až ve chvíli, kdy to začne přepisovat nebo přenášet: napojení na UI, volání backendu, formát dat, stavové přechody, validace, edge cases a podobně.

Codex pro mě fungoval jako zrychlovač především ve chvíli, kdy už jsem měl vytyčenou stopu: „tady je feature v mobilu, pojď ji zkonzolidovat a přenést do webu a desktopu“.

⏱️ Jak jsem to postavil za 3 až 4 hodiny (a co to vlastně znamenalo)

Výsledek byl pro mě opravdu překvapivě rychlý. Se Codexem jsem byl schopný postavit tuhle funkci v řádu tří až čtyř hodin, a to celé s podporou toho, že jsem měl na místě existující vzor v mobilních aplikacích.

To „za pár hodin“ ale není jen o tom, že nástroj umí generovat kód. Je to o kombinaci tří věcí:

• Existující implementace v mobilech jako reference.
• Jasně vymezený cíl: přenést Notion AI voice input na web a desktop.
• Schopnost nástroje pochopit kontext a navázat na něj tak, aby výsledky dávaly smysl v konkrétním kódu a architektuře.

Jinými slovy: nemusel jsem začínat „od prázdna“. Musel jsem hlavně smysluplně řídit směr a ověřit, že výsledek odpovídá tomu, co produkt potřebuje.

📱 Od mobilu k webu a desktopu v jednom kroku

Jedna z nejzajímavějších částí celého úsilí byla integrace přes různé platformy. Když máte feature už hotovou v mobilech, často narazíte na problém, že web a desktop mají jiný runtime, jiný způsob práce s komponentami a někdy i trochu odlišnou logiku pro tok dat.

V mém případě jsem „pointnul“ Codex na jednu z našich existujících funkcí v mobilních aplikacích. A přibližně „v jednom shot“ jsem dokázal vybudovat celý feature a následně jej přenést i na web a desktop klienty.

Co je na tom praktické? Namísto toho, abych psal implementaci znovu, jsem využil:

• stejný produktový záměr, jen v jiné vrstvě aplikace
• stejný datový model nebo aspoň podobný kontrakt
• stejné chování pro uživatele: mluví a dostanou očekávaný výstup do Notionu

Z pohledu vývojáře to snižuje riziko, že výsledná web/desktop verze bude „jiná“ a bude se pak muset dlouho dolaďovat jen kvůli nekonzistenci.

👥 Jak jsem to zvládl i s týmem: agilita bez chaosu

Mám na starosti tým lidí. A přiznám se, že tohle je přesně ta část, kde se moje nadšení zrychleného kódování potkalo s realitou leadershipu.

Tradičně mají manažeři (a obecně lidé v product engineering, kteří řídí) méně času psát kód. Není to vždy o tom, že by neměli schopnosti. Spíš je to o prioritách, recenzích, plánování, koordinaci a tom, aby tým měl jasný směr.

Codex pro mě znamenal něco víc než „rychlejší psaní“. Znamenal možnost postavit feature solo a zároveň stále podporovat tým. Díky tomu jsem nebyl v situaci, kdy musím volit mezi tím, že budu rukama dávat vývoj „dopředu“, nebo že budu mít hlavu ve vedení a řízení.

Výsledkem je, že se změnil poměr času mezi:

• tvorbou funkce
• ověřováním správnosti
• komunikací v týmu a podpůrnými aktivitami

Tohle je důležité i kulturně: když leadership umí prototypovat a rychle přinášet funkční kusy práce, tým typicky získá víc důvěry v roadmap, i když je tlak na tempo.

🧩 Co je „odblokováno“ pro produkty, ne jen pro kód

Moje zkušenost není jen o jedné konkrétní funkci. Vidím na tom širší princip: Codex odblokuje práci tam, kde klasicky vzniká nejvíc tření.

Typicky jde o činnosti jako:

• přenos feature mezi platformami (mobile → web/desktop)
• integrace do existujícího systému (ne psaní „od nuly“)
• rychlé prototypování bez ztráty vazby na skutečný kód
• orientace v kontextu (když nevíte, kde přesně to napojit)

V Notionu navíc záleží na konzistenci: uživatelé očekávají podobné chování napříč zařízeními. Když se feature přenese správně, lidé to ani nemusí vnímat jako „novou technologii“. Prostě to funguje.

🛠️ Jak jsem přemýšlel o práci: zadání, přesnost, ověření

Aby to celé dávalo smysl, je potřeba mít způsob práce. I když nástroj nabídne rychlost, stále musíte držet kvalitu.

V praxi jsem postupoval takhle (obecný model, který můžete použít i jinde):

1. Vyberte existující referenci (například už funkční implementaci v jiné platformě).
2. Jasně vymezte cíl: co má feature dělat a kde má existovat.
3. Nechte nástroj udělat „práci v kontextu“: integraci, přepis logiky, napojení na existující části.
4. Zkontrolujte chování (ne jen compile-time správnost).
5. Udržte konzistenci produktu: stejné očekávání pro uživatele napříč klienty.

Tohle mi přijde jako klíčová lekce: nejde o to nechat nástroj psát cokoliv. Jde o to dát mu správné mantinely a pak kvalitně otestovat výsledek.

🎤 Co obvykle dělá hlasové zadávání těžší, než to vypadá

Zní to jednoduše: uživatel mluví a aplikace píše. Ale v produktové realitě to bývá komplexní. I bez detailů implementace je užitečné vědět, na co typicky narážíte při vývoji hlasového inputu:

• Rozpoznávání řeči a jeho přesnost v různých prostředích.
• Segmentace a časování: kdy považovat vstup za dokončený.
• Chybové stavy (špatný mikrofon, offline, odmítnutí permission).
• Uživatelský feedback: indikace, kdy aplikace poslouchá.
• Napojení na UI a flow v Notionu: kam se text vloží, jak se bude chovat při editaci.
• Konzistence napříč platformami: web může fungovat jinak než nativní mobil.

Právě proto je dobré, když už máte nějakou implementaci v jedné platformě a můžete ji použít jako základ. Ušetříte si spoustu slepých uliček a můžete se soustředit na přenos a integraci.

🔍 Proč je „jedním shot“ reálně významné

Když řeknu „jedním shot“, obvykle tím nemyslím magii. Myslím tím, že se nepřešlapovalo v kruhu. Že jsem z jednoho směru dokázal získat kompletní feature a pak ho jen přenést na další platformy.

U většiny týmových projektů je realita taková, že přenos mezi platformami se často rozpadá na:

• nejdřív hledání správných míst v kódu
• pak přepsání datových vrstev
• pak úpravy UI a interakcí
• potom dolaďování hran a edge cases

Codex mi pomohl zkrátit první část: hledání správného kontextu. A jakmile máte kontext, zbytek bývá výrazně rychlejší.

📈 Dopad na tým: méně přerušení, víc toku práce

Z hlediska managementu je důležité, aby vývoj nebrzdily dlouhé cykly „někdo něco začne, ale pak se to zastaví na integraci, na kterou nikdo nemá kapacitu“.

Když jsem dokázal feature postavit v relativně krátkém čase a zvládnout to paralelně se svou rolí v týmu, získal tým výhodu:

• rychleji se vidí, jak feature bude fungovat
• snáz se plánují další kroky
• diskuse v týmu se opírá o konkrétní výsledek, ne jen o plán

Tohle je ten rozdíl mezi „budeme to řešit“ a „tady to máme v ruce“.

🌍 Co si z toho můžu odnést jako obecný princip pro vaše projekty

Pokud stavíte software, pravděpodobně se vám dějí stejné věci jako mně. Tím největším přínosem se pro mě stala kombinace: rychlost plus pochopení kontextu.

V závěru si položte otázku, kde ve vašem procesu vzniká nejvíc tření. Může to být například:

• přenos feature mezi částmi produktu
• integrace do starších modulů
• přepracování existujících částí tak, aby seděly do nové architektury
• zrychlené prototypování pro validaci nápadu

A pak zkuste stejný vzorec, jaký jsem použil u Notion AI voice input:

1. Narovnejte zadání a řekněte, jaká je reference.
2. Udržte jasný cíl (kde to má fungovat, co to má dělat).
3. Nechte nástroj řešit implementační detaily, ale vy držte kontrolu nad očekáváním.
4. Ověřte chování jako produkt, ne jako matematiku.

Tím se z „rychlého generování kódu“ stane rychlé doručení hodnoty.

❤️ Proč mi to připadá „crazy“ (a proč to není jen hype)

Upřímně, nejvíc mě baví ten kontrast: jsem člověk, který má tým a odpovědnost. A přesto jsem dokázal postavit feature, které obvykle trvá déle, a to s takovou mírou samostatnosti, že mi to připadá skoro neuvěřitelné.

Ten pocit „crazy“ není o tom, že bych si myslel, že automatizace udělá práci za všechny. Je to o tom, že nástroj posouvá hranici toho, co může jeden člověk stihnout v rámci reality teamu.

Manažeři a product eng lidé často bojují s tím, že nemají čas psát. Codex změnil můj poměr: umím přinést funkční kus práce rychle, a pak se zase vrátit k podpoře týmu.

📝 Krátké shrnutí

Notion AI voice input je ukázka toho, jak Codex může odblokovat vývoj tam, kde typicky vzniká nejvíc zpoždění. Klíčové body, které bych si odnesl:

• Byl jsem schopný postavit feature v řádu tří až čtyř hodin.
• Vyšel jsem z existující implementace v mobilních aplikacích a přenesl ji na web a desktop.
• Codexova hodnota byla v tom, že nejdřív hledá kontext a teprve pak pracuje na řešení.
• Jako člověk s týmem jsem to dokázal dělat solo a zároveň stále podporovat tým.

Jestli na vašem projektu nejvíc trpíte integrací, přenosem mezi platformami nebo orientací v kontextu, možná je to přesně oblast, kde stojí za to vyzkoušet podobný přístup. Ne proto, abyste zrychlili „kód“, ale abyste zrychlili doručení hodnoty.