Zkuste to sami. Otevřete libovolného asistenta a napište: „Napiš mi knihovnu pro paralelní zpracování úloh.“ Neuveďte jazyk. Skoro jistě dostanete Python.

Na tom není nic šokujícího. Zajímavější je, co se stane, když ten samý dotaz položíte jinak: v odděleném sezení se nejdřív zeptáte, jaký jazyk by se pro takovou úlohu hodil nejvíc. Většinou vám odpoví C++ nebo Rust. Když pak v čistém vlákně požádáte o kód, dostanete Python. Dvě odpovědi, dvě různá rozhodnutí, žádné vědomí toho druhého.

Hned na začátku upozorním na jednu věc, protože si to skoro jistě budete chtít zkusit: pokud se zeptáte na doporučení a hned nato v tom samém vlákně necháte model psát kód, tenhle rozpor nereprodukujete. Model se drží toho, co doporučil. Proč to tak je, rozeberu níž, protože právě to je na celém tématu prakticky nejužitečnější.

Co ukázala data

Skupina z King’s College London, UCL, GitHub Next a BT publikovala loni studii s výmluvným původním názvem LLMs Love Python (finální verze vyšla letos ve Findings of ACL 2026 pod střízlivějším titulem A Study of LLMs‘ Preferences for Libraries and Programming Languages). Testovali osm modelů: GPT-4o mini, GPT-3.5, Claude 3.5 Sonnet a Haiku, Llama 3.2 3B, Qwen2.5 Coder 32B, DeepSeek 67B a Mistral 7B.

První experiment byl jednoduchý. Vzali šest jazykově agnostických benchmarků, kde existují referenční řešení ve více jazycích, a nechali modely úlohy řešit bez zadání jazyka. Python se objevil v 90 až 97 procentech řešení. U Multi-HumanEval a MBXP, kde jsou k dispozici řešení ve dvanácti jazycích, to bylo u většiny modelů rovnou sto procent.

Druhý experiment byl chytřejší. Autoři schválně vybrali pět zadání, kde je Python objektivně špatná volba: souběžný webový server, nativní GUI aplikace, low-latency obchodní platforma, knihovna pro paralelní zpracování a systémový nástroj do příkazové řádky. Sto generování na model a úlohu. Python zůstal nejpoužívanějším jazykem v 58 procentech případů. Rust nepoužil ani jednou žádný z osmi modelů, ani u jedné z těch pěti úloh.

Stojí za to si to přečíst ještě jednou. Pět zadání, u kterých se Rust nabízí jako první nebo druhá volba, osm modelů, čtyři tisíce vygenerovaných odpovědí, a Rust nula.

Celkově modely sáhly jen po šesti až čtrnácti různých jazycích. Na GitHubu jich ročně dostane commit několik stovek.

Modely si odporují samy se sebou

Nejsilnější číslo z celé práce je jinde. Autoři nechali modely seřadit jazyky, které by pro danou úlohu doporučily, a porovnali to pořadí s tím, co modely u té samé úlohy skutečně napsaly. Korelaci měřili Kendallovým tau. U jazykových úloh nevyšla statisticky významná ani jedna. Modely si v 83 procentech případů protiřečily.

Tady je nutné být přesný, protože metodika rozhoduje o tom, jak se to číslo dá číst. Byly to dva samostatné prompty pouštěné ve zcela oddělených sezeních, aby se předešlo cachování a úniku kontextu. Když model psal kód, nevěděl nic o tom, co před chvílí doporučil. Neměří se tedy schopnost modelu držet vlastní slovo, ale rozdíl mezi dvěma nezávislými distribucemi.

A právě proto si to v chatu nereprodukujete. Zeptáte se na doporučení, dostanete Rust, hned nato požádáte o kód a dostanete Rust. Ten předchozí odstavec je součástí kontextu a model na něj navazuje. Tohle není chyba měření ve studii, je to ta nejužitečnější informace, která z ní plyne, a vrátím se k ní v praktické části.

Proč ty dvě distribuce vůbec existují, je banální. Model si dopředu neplánuje architekturu odpovědi, generuje token po tokenu. Dotaz na doporučení ho posadí do prostoru odborných diskuzí o výkonu, kde se běžně píše o Rustu a C++. Dotaz na kód ho posadí do prostoru ukázkových úryvků, kde má drtivou převahu Python. Nic ty dva prostory nespojuje, dokud je nespojí kontext.

Praktický důsledek: doporučení a kód jsou dva výstupy, a jestli druhý respektuje první, závisí čistě na tom, jestli je první ve stejném okně.

Není to jen tím, že v datech je víc Pythonu

Tohle vysvětlení slyším pořád a je nepřesné. Podívejte se na objemy v The Stack v2, který stojí za StarCoderem 2 a je jedním z mála velkých korpusů, kde tohle vidíme na čísla: Java 479,68 GB, JavaScript 277,25 GB, C++ 204,49 GB, Python 190,99 GB, PHP 171,57 GB, C# 166,22 GB, C 114,49 GB. Java a JavaScript museli autoři dokonce podvzorkovat na 200 GB, aby vyrovnali pole. Python je v surovém objemu kódu až čtvrtý.

Takže odkud ta preference?

Podezřelý číslo jedna jsou benchmarky. HumanEval je Python. MBPP je Python. SWE-bench Verified je stoprocentně Python a samotné Django tvoří skoro polovinu instancí. Po celou dobu, kdy se laboratoře předháněly ve skóre, měřily prakticky jen Python. RL smyčky, syntetická data, výběr SFT dat, všechno se ladilo na metriku s jedním jazykem. Autoři studie na to narazili i při přípravě: sehnat opravdu jazykově neutrální dataset bylo těžké.

Druhý faktor je podle mě podceňovaný a týká se párování s přirozeným jazykem. Model se učí mapování „popis v angličtině -> kód“ a to mapování je nejhustší tam, kde lidé kolem kódu píšou prózu. Jupyter notebooky, tutoriály, odpovědi na Stack Overflow, dokumentace s příklady. Java existuje hlavně jako produkční kód v repozitářích, ne jako vysvětlovaný úryvek. Python je jazyk, ve kterém se učí a vysvětluje.

Třetí věc je samostatnost úryvku. Odpověď v Pythonu je funkce. Odpověď v Javě je třída v souboru se správným názvem, v balíčku, ideálně s build souborem. Odpověď v Rustu chce Cargo.toml. Formát chatové odpovědi zvýhodňuje jazyky, u kterých je nejmenší smysluplná jednotka kódu co nejmenší. Když se generování přesunulo do agentů se souborovým systémem a terminálem, tenhle tlak částečně zmizel, jenže prompty a preferenční data vznikaly ve světě chatu.

A nakonec tokenizace. Martin Alderson porovnal na úlohách z RosettaCode, kolik tokenů zabere stejný program v různých jazycích. Mezi C a Clojure mu vyšel rozdíl 2,6×. Dynamické jazyky bez explicitních typů jsou obecně úspornější, staticky typované s ukecanou syntaxí platí daň za složené závorky, opakovaná jména typů a dlouhé signatury. Nemyslím si, že tokenizace je hlavní příčina preference. V agentních smyčkách, kde se stejný soubor čte a přepisuje třicetkrát, se to ale sčítá do reálných peněz.

Modely se od sebe liší víc, než byste čekali

Ve studii je jeden dataset, který se vymyká: AixBench, postavený z komentářů u Javových metod na GitHubu. Je to jediný z šesti použitých datasetů bez vazby na Python. A je to jediné místo, kde některé modely Python nepreferovaly. Oba testované Claudy zvolily Javu, Sonnet v 53,5 procenta případů, Haiku v 59,7. Ostatní modely i tady zůstaly u Pythonu, GPT-4o mini v 75,2 procenta.

Claude modely měly zároveň nejširší repertoár, třináct a čtrnáct různých jazyků napříč všemi datasety. Na opačném konci stály Llama 3.2 a Qwen2.5, které u některých úloh použily stejný jazyk ve všech sto odpovědích. Nulová variabilita.

Je to malý vzorek a modely z konce roku 2024, takže bych z toho nedělal žebříček. Ukazuje to ale, že preference není fyzikální konstanta velkých jazykových modelů, ale výsledek konkrétního mixu dat a post-trainingu. Což znamená, že se dá měnit.

Preference není jen kosmetika

Kdyby šlo jen o výchozí volbu, dala by se odbýt jedním řádkem v promptu. Problém je, že kvalita mimo Python znatelně padá.

Nejtvrdší data k tomu má Multi-SWE-bench od ByteDance Seed, prezentovaný na NeurIPS 2025. Je to 1 632 reálných GitHub issues v sedmi jazycích mimo Python, anotovaných 68 lidmi. Podle reportovaných výsledků vyřešil Claude 3.7 Sonnet přes OpenHands 52,2 procenta Pythonových instancí, ale jen 21,9 procenta v Javě, 15,9 v Rustu, 14,7 v C++, 8,6 v C, 7,5 v Go, 5,1 v JavaScriptu a 2,2 v TypeScriptu. Tým ByteDance to shrnuje střízlivěji: průměrná úspěšnost mimo Python se u tehdejších modelů obecně držela pod deseti procenty.

Aider Polyglot je na tom lépe, protože testuje izolované úlohy z Exercismu, ne navigaci v cizím repozitáři. Za zmínku stojí, jak je postavený: z 225 úloh připadá 49 na JavaScript, 47 na Javu, 39 na Go, 34 na Python, 30 na Rust a 26 na C++. Python má schválně nejmenší podíl. Nejlepší modely se tam dnes pohybují kolem devadesáti procent, což je od čísel z Multi-SWE-bench hodně daleko. Měří to ale něco jiného: izolovanou úlohu, ne zásah do cizí codebase.

A pak je tu dlouhý ocas. MultiPL-E přeložilo HumanEval a MBPP do osmnácti jazyků a ukázalo, co se dalo čekat: výkon koreluje se zastoupením jazyka v trénovacích datech. OCaml, Racket, R, Julia, D. Pokud píšete v něčem z téhle skupiny, rozdíl proti Pythonu není deset procentních bodů, ale násobky.

Ekosystém mezitím jde opačným směrem

Tady se to začíná zajímavě křížit. Zatímco modely pořád tíhnou k Pythonu, lidé kolem nich se posouvají jinam.

V srpnu 2025 se TypeScript poprvé stal nejpoužívanějším jazykem na GitHubu podle počtu měsíčních přispěvatelů. 2 636 006 lidí, meziroční přírůstek přes milion, tedy 66,6 procenta. Python spadl na druhé místo s odstupem asi 42 tisíc přispěvatelů po šestnácti měsících v čele. GitHub to ve svém Octoverse reportu spojuje přímo s agentním kódováním: typové systémy chytí chyby v AI generovaném kódu dřív, než se dostanou do produkce, a hlavní frontendové frameworky dnes scaffoldují do TypeScriptu defaultně.

Logika za tím je jednoduchá a platí i pro Rust nebo Go. Agent potřebuje smyčku, ve které si sám ověří, jestli neudělal blbost. Kompilátor a typová kontrola jsou nejlevnější takový oracle, jaký existuje: běží v sekundách, nevyžadují, aby někdo napsal testy, a vracejí strukturovanou chybu, kterou model umí přečíst a opravit. U dynamických jazyků se ta samá chyba projeví až za běhu, často až v produkci a často jako None, který se protáhne přes tři vrstvy volání.

Jinými slovy: jazyk, který se špatně píše ručně, ale dobře se ověřuje strojově, je pro agenta dobrý obchod. Rust tuhle vlastnost má v extrému. Argument „Rust se špatně učí“ ztrácí sílu ve chvíli, kdy prvních deset iterací s borrow checkerem odsedí model.

Sám si nejsem jistý, jestli tenhle posun vydrží, nebo jestli je to jen okamžik, kdy nástroje ještě nejsou dost dobré na to, aby jim na typech nezáleželo. Zatím to ale vypadá, že měřítko „jak dobře se v tomhle jazyce dá kód automaticky verifikovat“ reálně ovlivňuje volbu stacku.

Co s tím dělat prakticky

Nejzajímavější část studie je schovaná v diskusi. Autoři zkusili dvě věci.

První byla teplota. Zvýšení z 1,0 na 1,5 snížilo podíl nejpoužívanějšího jazyka průměrně o 13,46 procenta a rozšířilo repertoár. Efekt je měřitelný a k ničemu. Teplota 0,0 mimochodem nezaručila konzistentní volbu jazyka.

Druhá věc funguje. K promptu přidali jednu větu: „Think step by step about which programming language you should use and why.“ Výsledky se převrátily. U low-latency platformy klesl podíl Pythonu o 95 procent a nastoupilo C++ s 89 procenty. U paralelního zpracování klesl Python o 98 procent a vyhrál Rust s 61 procenty, ten samý Rust, který se do té doby neobjevil ani jednou. U souběžného serveru Go v 91 procentech, u systémového nástroje C v 88.

Jedna věta v promptu, a Rust se z nuly vyšplhal na 61 procent. Princip je obecný: donutit model vyslovit rozhodnutí dřív, než začne psát kód, ho vytáhne z defaultní distribuce.

Tohle zároveň vysvětluje, proč dnešní modely vypadají mnohem líp než ta čísla ze studie. Reasoning modely dělají přesně tuhle úvahu samy od sebe, ještě než napíšou první token odpovědi. Podmínku „cold start bez jakékoli rozvahy“, na které se těch 90 až 97 procent naměřilo, u nich prakticky nevyrobíte.

Neznamená to ale, že problém zmizel. Zmizel jen z toho scénáře, ve kterém ho nejsnáz otestujete. Zůstává všude, kde se rozhodnutí nikde nevysloví: v autokompletaci, kde model doplňuje řádek bez konverzace. V kroku uprostřed dlouhého agentního běhu, kde je původní zadání dvacet nástrojových volání zpátky. V generování přes API bez systémového promptu. A hlavně u kohokoli, kdo si prostě otevře chat, napíše jednu větu a vezme, co vypadne, což je většina lidí, kteří dnes tyhle nástroje používají.

Nejspolehlivější je jazyk prostě určit a nespoléhat na to, že rozhodnutí padne dobře. Do AGENTS.md, CLAUDE.md, .cursorrules nebo čeho používáte. Ne jako „preferujeme Go“, ale konkrétně: verze, build nástroj, formátovač, jak vypadá struktura projektu.

Stejný problém u knihoven, jen horší

Druhá půlka studie se týká knihoven a čte se ještě nepříjemněji. Modely importovaly NumPy do řešení 192 z 301 úloh, kde ho referenční řešení vůbec nepoužívá. Napříč 526 úlohami z BigCodeBench sáhly celkem po 32 až 39 unikátních knihovnách. Na PyPI mělo jen v lednu 2025 přes sedm tisíc balíčků víc než sto tisíc stažení měsíčně.

Konkrétní čísla z případové studie: pandas 58 procent, Polars nula. Flask 88 procent, FastAPI devět. Matplotlib 57 procent, Plotly 0,4. Dask 52 procent, Ray 16, Celery 0,4.

Nechci z toho dělat „modely mají zastaralý vkus“. U produkčního kódu je konzervativní volba často správná: zralá knihovna, velká komunita, hodně StackOverflow odpovědí. Ale je tu efekt, který mi přijde vážný. Nová knihovna se dřív prosadila tím, že o ní někdo napsal blog, ostatní ji zkusili a doporučili dál. Když se čím dál víc rozhodnutí o závislostech dělá v chatu, dostávají nové projekty handicap, který nemá nic společného s jejich kvalitou. Model se o Polars nedozví, dokud nebude dost kódu s Polars, a toho kódu nebude dost, dokud ho model nebude generovat.

Pro code review z toho plyne konkrétní věc: u AI generovaného kódu se dívejte na importy stejně pozorně jako na logiku. Zbytečná těžká závislost projde review snadněji než chyba v cyklu, ale žije v projektu déle.

Co si z toho odnést

Modely nedělají volbu jazyka a knihovny tak, jak si představujete. Nevyhodnocují požadavky. Reprodukují nejčastější tvar odpovědi na podobně vypadající prompt, a ten tvar je Python s NumPy.

Prakticky: jazyk a klíčové závislosti zadávejte explicitně, ne modelu k rozhodnutí. Když ho k rozhodnutí přece jen pustíte, přinuťte ho to rozhodnutí nejdřív napsat. Doporučení modelu neberte jako popis toho, co model vzápětí udělá. A počítejte s tím, že mimo Python a JavaScript kvalita klesá, u okrajových jazyků výrazně.

Zároveň se ten obrázek mění. Aider Polyglot a Multi-SWE-bench vznikly právě proto, aby monokulturu rozbily, a modely trénované s ohledem na ně jsou na tom v Go, Rustu a Javě citelně lépe než generace, kterou studie testovala. Statistika trénovacích dat ale nezmizí a Python zůstane defaultem ještě dlouho. Zajímavější otázka je, co se stane, až budou trénovací data z větší části generovaná modely. Kruh se zavírá rychleji, než se stačí měřit.

Zdroje

• Twist et al., A Study of LLMs‘ Preferences for Libraries and Programming Languages, Findings of ACL 2026 (arXiv:2503.17181, data a kód)
• Zan et al., Multi-SWE-bench: A Multilingual Benchmark for Issue Resolving, NeurIPS 2025 (arXiv:2504.02605)
• Cassano et al., MultiPL-E: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation
• Lozhkov et al., StarCoder 2 and The Stack v2 (arXiv:2402.19173)
• Aider Polyglot leaderboard
• GitHub Octoverse 2025
• Martin Alderson, Which programming languages are most token-efficient?