Jak Claude mění designové workflow v Jane Street

Edwin Morris z Jane Street popisuje, proč dnes častěji staví funkční prototypy s Claude Code než mockupy ve Figmě.

7. června 2026

Edwin Morris z Jane Street popsal, že dnes při designu sahá po Claude Code častěji než po Figmě. Není to obecný manifest o tom, že AI nahradí designové nástroje. Je to osobní zkušenost designéra, který se dostal do prostředí, kde může díky AI stavět funkční prototypy přímo v reálném kódu.

Na začátku je důležitý kontext. Morris píše, že byl k LLM dlouho skeptický. Když zkoušel Copilot a Cursor na úpravy vlastní hry, výsledky nebyly funkční. V předchozí práci zkoušel Gemini na návrhy produktových zadání a wireframy, ale výstupy nakonec zahodil.

Zlom přišel až po nástupu do Jane Street. Najednou pracoval s věcmi, které pro něj byly nové: hlavně OCaml a Bonsai. V takovém prostředí se pro něj AI podpora stala užitečnější, protože nepomáhala s něčím, co už uměl výborně, ale s oblastmi, kde se teprve zabydloval.

Od mockupu k běžícímu prototypu

Zdrojem článku není tvrzení, že Figma přestává dávat smysl. Spíš popis konkrétní změny pracovního postupu.

Místo dlouhé práce nad spec dokumenty, mockupy, návrhy a následnou implementační diskusí autor častěji staví prototyp, který rovnou dělá to, co má na mysli.

Jeho postup vypadá přibližně takto:

  • napíše popis problému a návrhu
  • otevře editor
  • spustí build, server a Claude
  • použije popis jako prompt
  • dostane základní funkčnost do chodu
  • iteruje, dokud návrh nepůsobí správně
  • pushne změny do vývojového prostředí
  • zeptá se uživatelů na názor
  • pošle interní feature, tedy něco jako pull request

To je dost jiný typ designového artefaktu než statický mockup. Prototyp není jen obrázek budoucího UI. Je to běžící návrh v kódu, který se dá používat, zkoušet a měnit.

Příklad s JSQL

Autor uvádí konkrétní příklad: prototyp pro přidání LLM promptingu do JSQL inputu. JSQL je interní SQL dialekt, který Jane Street používá v mnoha uživatelských nástrojích.

Prototyp podle něj opravdu fungoval a několik dní s ním žil a testoval ho. Díky Claude mohl iterovat bez toho, aby každá drobná změna znamenala nové kolečko mezi designem a engineeringem.

Zmiňuje konkrétní úpravy:

  • ladění tlačítka Submit
  • přidání klávesových zkratek
  • úpravy textů
  • úpravy promptu
  • generované potvrzovací zprávy

V předchozí práci by podobné drobné změny podle něj vyžadovaly dny nebo týdny domlouvání mezi engineeringem a designem, případně by se vůbec nestaly.

Figma nezmizela, ale její role se změnila

Morris píše, že k tomuto způsobu práce nedošel hned. Po nástupu do Jane Street používal AI nejdřív na menší UX opravy. U větších nápadů pořád sahal po Figmě a dokumentech.

V posledních dvou měsících se ale podle něj situace, kdy použil Figmu, výrazně propadla. Připisuje to kombinaci lepších modelů, vlastní větší obratnosti s AI a lepší volby rozsahu úkolu.

Claude dnes používá i pro větší prototypy:

  • změny v uživatelském rozhraní
  • změny v datovém modelu
  • změny v knihovnách
  • prototypy se změnami přes 2000+ řádků
  • interaktivní prototypy nových aplikací

U některých nových aplikací podle zdroje Figmu pořád používá na počáteční návrh. U jiných ji ale přeskočí úplně a vizuální design iteruje od začátku s Claude.

Prototyp jako živý návrhový dokument

Tohle je možná nejzajímavější část článku.

Funkční prototyp má výhodu: ostatní si ho mohou vyzkoušet. Nemusí si představovat, jak by návrh fungoval podle statického mockupu.

Zároveň ale vzniká nové riziko. Když reviewer dostane hotově působící feature, může mít pocit, že už má jen zkontrolovat kód. Jenže autor chce, aby se na prototyp pořád nahlíželo jako na návrh, ne jako na hotovou produkční implementaci.

Řešení v Jane Street je zatím procesní. Morris do popisu píše připomínku, že:

  • prototyp je živý návrhový dokument
  • kód je určený k zahození
  • reviewer má dávat zpětnou vazbu hlavně k designu a uživatelské zkušenosti
  • produkční implementaci později převezme někdo jiný

To je důležitá výhrada. AI prototyp v tomto workflow není automaticky produkční kód. Je to návrhový artefakt, který náhodou běží.

Riziko iterativního myšlení

Autor také zmiňuje vlastní obavu: práce s Claude ho může držet v příliš iterativním způsobu myšlení. Pokud designér navrhuje hlavně to, co si myslí, že Claude dokáže vytvořit, může minout odvážnější nápady.

Přirovnává to ke starší debatě, jestli mají designéři umět programovat. Kritika byla podobná: jakmile začnete kódovat, můžete být méně ochotní dělat velké změny návrhu.

Morris zároveň píše, že kdyby do Jane Street nastoupil před érou LLM, pravděpodobně by se ve Figmě a dokumentech ještě víc usadil. OCaml a Bonsai by pro něj byly technicky vzdálené. Díky AI se ale znovu dostal k práci v médiu samotného produktu.

Co si z toho vzít

Moje čtení: článek není o tom, že Claude je lepší než Figma.

Je o posunu v tom, co může být designový artefakt. U některých týmů už návrh nemusí být jen mockup, ale funkční prototyp v reálném prostředí, který se dá dát uživatelům, reviewerům a týmu do ruky.

Praktický dopad je ale dvojí.

Na jedné straně může AI výrazně zkrátit cestu od nápadu k otestovatelnému prototypu. Na druhé straně tým musí jasně říct, jak se takový prototyp hodnotí: jako návrh, jako experiment, nebo jako produkční změna.

Bez tohoto rozlišení může AI workflow vytvořit stejný zmatek, jaký mělo původně odstranit.