O čem zdroj je

Rozhovor Dana Shippera s Chrisem Pedregalem se věnuje tomu, jak Granola přemýšlí o AI-native práci, produktové strategii a organizaci rychle rostoucího startupu. Meetingové poznámky jsou vstupní bod; těžištěm je širší otázka, jak má software dát AI kontext, pracovní prostředí a jasně vymezené úlohy, aby byla skutečně užitečná.

Zdroj zároveň popisuje vývoj funkcí od raného experimentu po škálovatelný produkt, rozdíl mezi asynchronním delegováním a společnou prací s agentem i způsob, jak proměňovat pokročilé uživatelské postupy v nativní produktové funkce.

Klíčové idey

Nehádat se o funkci, ale o budoucí způsob práce

Kopie současné funkce nemusí být hlavní hrozbou. Meetingové poznámky jsou v tomto pohledu jen ranou částí větší změny pracovního rozhraní. Strategická otázka proto nezní, jak ubránit jednu dnešní kategorii, ale jaký širší job to be done bude produkt řešit, až se spolupráce lidí a AI promění.

To neznamená dělat všechno. Produkt může otevřít svůj kontext jiným agentům přes API nebo MCP a přitom se soustředit na několik úloh, kde bude výrazně lepší než obecné alternativy. Granola chce zpřístupnit meetingový kontext, ale vlastní hodnotu držet ve specifických meetingových use casech a v kvalitě zachyceného kontextu.

Hodnotu nejdřív najít, potom ji upevnit

Zdroj rozlišuje piráta a architekta. Pirát rychle hledá hodnotu, bez předčasné péče o dokonalou architekturu. Když se ukáže, že řešení funguje, přichází architekt: zmapuje codebase, určí strukturální pilíře a invarianty a převede prototyp do podoby, která je udržitelná a škálovatelná.

Stejná logika se promítá do vývoje funkcí. Postup začíná job to be done a hledáním různých tvarů řešení. Následuje malá validace s uživateli. Až po ověření, že by si lidé řešení skutečně vybrali, dává smysl investovat do spolehlivosti a škálování.

Růst firmy přitom nezjednodušuje práci zakladatele. Přechod z dvanácti na více než šedesát lidí přináší nové organizační problémy a tlak na konzistenci produktu. Úspěch tedy neznamená, že tým přestane pracovat na hranici svých dosavadních zkušeností.

Dvě plochy pro práci s agenty

Pro veřejné, asynchronní a týmově diskutovatelné úkoly se hodí sdílený kanál, například Slack. Agent tam může zveřejnit přehled opravených bugů, přijmout požadavek na vytvoření PR a průběžně komunikovat s týmem.

Hlubší spolupráce vyžaduje jiný prostor. Člověk a agent mají vidět stejnou věc a pracovat nad stejným stavem, například v Codexu nebo Claude desktop app. V takzvaném Codex-native modelu aplikace ukládá stav a vykresluje UI, zatímco uživatel do ní připojuje vlastního agenta. Člověk i agent si pak mohou předávat kontrolu.

Důležité je, aby agent nebyl jen oddělený volající API. Akce přes CLI nebo MCP musí měnit stav rozhraní, které uživatel sleduje. V editoru Proof může agent nastavit svou přítomnost i pozici v dokumentu. Uživatel tak ví, kde agent právě pracuje.

Kontext dává AI tvar

Flexibilní model sám o sobě nestačí. Software musí dodat strukturu, kontext a pracovní prostředí, ve kterém AI jedná jednoznačně. Rozhovor přirovnává AI ke svalům a vazům, zatímco software jsou kosti, které celku dávají formu.

U meetingů to znamená víc než transcript. Systém má rozlišit, kterého Chrise nebo Sama účastník myslí, a pracovat s rozhodnutími, akcemi, nuancemi, pauzami i způsobem, jakým lidé věci říkají. Kontext není doplněk k výstupu. Je to podmínka jeho použitelnosti.

Produkt má přijít dřív, než ho uživatel stihne chtít

V kritickém okamžiku uživatel často nebude čekat ani dvacet sekund. Granola proto před schůzkou generuje brief s kontextem účastníka a předchozích rozhovorů. Výstup je připravený v krátkém okně, kdy jej člověk opravdu potřebuje.

Zdroj popisuje podpůrnou funkci jako zábradlí: většinu času ustupuje do pozadí, ale při zakolísání musí být ihned dostupná a pevná. Četnost použití proto není úplná metrika hodnoty. Některé funkce mohou být vzácné, ale v momentu použití zásadní.

Pokročilí uživatelé navíc ukazují, co stojí za produktizaci. Tým může sledovat jejich komplexní postupy nad API nebo MCP a vybrané workflow převádět do jednodušší nativní zkušenosti. Příkladem je pre-meeting brief, který nejdřív vznikl jako složitý workflow uživatele v Claude Code a následně byl nahrazen jednodušší funkcí Granoly.

Knowledge k zapracování

  • Při kopírování současné funkce konkurencí formuluj další širší job to be done, místo abys jen rozšiřoval obranu existující funkce.
  • Nový produkt rozděl mezi piráta, který hledá hodnotu, a architekta, který po jejím potvrzení určí pilíře, invarianty a cestu ke škálování.
  • Novou funkci veď v pořadí: definice uživatelské potřeby, prozkoumání více variant, malá validace, teprve pak spolehlivé a škálovatelné provedení.
  • Asynchronní týmové delegování směřuj do sdíleného kanálu se stavovými přehledy. Pro soustředěnou práci používej společnou plochu člověka a agenta nad jedním stavem.
  • Pokud agent pracuje přes CLI nebo MCP, propoj jeho akce se stavem UI. Uživatel musí vidět důsledky jeho práce přímo v rozhraní.
  • U výstupů potřebných v krátkém časovém okně vyhodnoť předgenerování. Čekání v momentu potřeby může znehodnotit i jinak kvalitní výsledek.
  • Nestav AI funkci jen na transkriptu nebo obecném modelu. Připrav disambiguaci, relevantní kontext, rozhodnutí, akce a stav pracovního prostředí.
  • Sleduj opakované pokročilé workflow nad API a MCP. Produktizuj jen ta, která mají širší přínos a navazují na oblast, kde může být produkt výrazně lepší.
  • Nehodnoť podpůrné funkce pouze frekvencí použití. Zvlášť posuzuj jejich hodnotu v kritickém okamžiku.

Co bych z toho zapracoval

Pro Aibility bych oddělil dva režimy agentní práce. Veřejné asynchronní delegování by patřilo do sdíleného prostoru, kde je viditelné pro tým a dá se nad ním diskutovat. Pro složitější práci by vznikla společná pracovní plocha, v níž člověk i agent pracují nad stejným kontextem a stejným stavem. To přímo navazuje na rozlišení mezi týmovým kanálem a společným UI člověka s agentem.

Při vývoji nové vzdělávací funkce bych před implementací vyžadoval stručné pojmenování job to be done, několik prověřovaných variant a malou uživatelskou validaci. Teprve funkce s potvrzenou hodnotou by šla do škálování. Jde o praktické použití postupu: vymezit podobu řešení, ověřit ji s uživateli a poté budovat spolehlivý produkt.

Aibility bych navrhl jako zdroj relevantního kontextu pro jiné agenty, ale bez ambice vyhrát každou možnou úlohu. Smysl dává vybrat několik vzdělávacích nebo pracovních úloh, kde má být Aibility nejlepší, a kolem nich vybudovat hlubší kontext i strukturu.

Zavedl bych také pravidelný sběr pokročilých uživatelských postupů. Pokud lidé opakovaně kombinují kontext Aibility, agenty a externí nástroje stejným užitečným způsobem, je to kandidát na nativní funkci. Cílem není přepsat každý individuální experiment, ale zjednodušit ty, které mají širší hodnotu.

U výstupů, které mají pomoci v krátkém okamžiku, bych použil předgenerování. Takový výstup nemusí být středem rozhraní ani nejčastěji používanou funkcí. Má být připravený ve chvíli, kdy uživateli pomůže pokračovat.

Zdroj

Every: „Granola's Chris Pedregal on Building a $1.5B AI Company“