Skryté úspory v éře AI: Velký průvodce, jak správným psaním kódu a dat nafouknout paměť umělé inteligence

S nástupem pokročilých AI pomocníků, kteří pracují přímo s našimi projekty (jako je Claude Code, Cursor nebo lokální modely běžící na vašem počítači), se zásadně změnil způsob, jakým kód putuje infrastrukturou. Kód už nepíšeme jen pro lidi a pro samotný počítač, aby ho spustil. Stal se z něj text, který neustále posíláme přes internet do mozků velkých jazykových modelů (LLM).

V tomto novém světě se velikost paměti, kterou má AI k dispozici (tzv. kontextové okno), stává tou nejcennější komoditou a tokeny zase platidlem. Když touto pamětí plýtváme, nestojí nás to jen peníze na poplatcích za API. Umělá inteligence kvůli tomu prokazatelně ztrácí pozornost uprostřed dlouhých textů, snadněji zapomene důležité souvislosti a dělá v kódu hloupé chyby.

Tento článek dopodrobna rozebírá, jak AI text ve skutečnosti čte, kde všude v kódu i datech vznikají neviditelné ztráty a jak pomocí jednoduchých návyků ušetřit 10 % až 40 % paměti vašeho digitálního asistenta.

1. Jak umělá inteligence (ne)rozumí lidské estetice

Abychom pochopili, proč vizuálně krásný kód může zbytečně vyjídat paměť umělé inteligence, musíme se podívat na to, jak AI text vůbec zpracovává. Modely nečtou text po písmenech ani po celých slovech. Používají takzvané tokenizéry – systémy, které text rozřezávají na menší logické kousky neboli tokeny. Jeden token odpovídá zhruba čtyřem znakům textu.

Poznámka: Konkrétní počty tokenů v příkladech níže jsou ilustrativní. Přesné dělení se liší model od modelu a verze od verze — novější modely mají tokenizéry stále lépe optimalizované a některé z popsaných neeficiencí již částečně řeší. Principy ale zůstávají platné.

Problém je v tom, že tyto systémy se učily na běžných textech z internetu a hotovém kódu z internetových úložišť. Jakékoliv netypické prázdné znaky (mezery navíc) nedokážou zpracovat efektivně a začnou je složitě kouskovat.

A. Odsazování: Souboj mezer s tabulátory

Mnoho programátorských příruček striktně vyžaduje používat pro odsazení textu čtyři mezery. AI systémy jsou sice naprogramované tak, aby čtyři mezery vedle sebe vnímaly jako jeden kousek (token). Jenže jakmile se v kódu dostanete do hlubšího zanoření (například vnořené podmínky nebo cykly), tato magie přestane fungovat.

Pokud máte řádek odsazený na čtvrté úrovni zanoření, znamená to 16 mezer vedle sebe. AI je málokdy přečte jako čtyři čisté kousky. Kvůli statistické pravděpodobnosti v jejím systému se těchto 16 mezer rozpadne na podivnou kombinaci (např. blok 4 mezer + blok 2 mezer + 2 samostatné mezery + další 4 mezery). Výsledkem je, že na každém takovém řádku spotřebujete 5 až 8 tokenů jen za prázdné místo na začátku.

Oproti tomu skutečný znak tabulátoru (\t) je v systému AI zapsán jako jeden jediný, samostatný kousek.

Odsazení na 4. úrovni zanoření:
[Pomocí mezer]      --> [    ] [    ] [  ] [ ] [ ] [    ]  --> 6 tokenů (neefektivní)
[Pomocí tabulátoru] --> [\t] [\t] [\t] [\t]                --> 4 tokeny (vždy 1:1)

U průměrného souboru, který má 500 řádků, ušetříte přechodem na čisté tabulátory stovky tokenů. Pokud váš AI pomocník pročítá celou vaši složku s projektem, mluvíme o úspoře desítek tisíc tokenů za jedno jediné odpoledne.

B. Zarovnávání do sloupečků: Krása, která škodí

Mnoho programátorů rádo zarovnává znaménka rovná se nebo hodnoty pod sebe, aby kód vypadal jako úhledná tabulka:

const kratkeJmeno        = "low";
const stredniJmeno       = "medium";
const uplneNejdelsiJmeno = "high";

Pro lidské oko je to skvělé, ale pro AI je to čisté plýtvání. Mezi textem kratkeJmeno a = vzniklo osm prázdných mezer. AI je nedokáže efektivně shluknout a vytvoří kvůli tomu několik zbytečných tokenů navíc.

Ještě horší je ale efekt dominové kostky v historii kódu. Pokud do tohoto bloku v budoucnu přidáte novou proměnnou s velmi dlouhým názvem, budete muset kvůli estetice posunout zarovnání všech řádků nad ní o dalších dvacet mezer doprava.

1. Pro vás: Úprava na pár vteřin.
2. Pro verzovací systém (Git): Změna na všech řádcích. Systém nahlásí, že se změnil celý blok kódu.
3. Pro AI: Úplné rozbití paměti. Moderní AI modely používají chytrou vyrovnávací paměť (cache). Pokud zjistí, že se text kódu nezměnil, načtou ho bleskově a s velkou slevou. Jakmile ale posunete mezery na pěti okolních řádcích, tato paměť se vymaže a vy platíte za analýzu celého bloku znovu.

2. Jazyky pod lupou: Python, HTML a Markdown tabulky

Tento princip plýtvání prázdným místem se projevuje napříč všemi technologiemi, často s nečekanými vedlejšími účinky.

Python: Když mezery způsobují chyby

Jazyk Python je unikátní tím, že bloky kódu neodděluje závorkami, ale právě přesným počtem mezer na začátku řádku. Pokud umělá inteligence generuje delší Python skript, stává se, že se při vypisování desítek mezer lidově řečeno „přepočítá“. Stačí, aby na jednom řádku udělala místo osmi mezer pouze sedm, a výsledný kód se v počítači nespustí (vyhodí chybu IndentationError).

Pokud naučíte AI používat v projektu tabulátory, tento problém téměř zmizí. Pro model je mnohem snazší spočítat „vygeneruj 2 tabulátory“ než „vygeneruj 8 mezer“. Kód je bezpečnější a AI ho vygeneruje rychleji.

Markdown tabulky: Obří žrout paměti

Když od AI v chatu požadujete tabulku, nebo jí sami tabulku posíláte v textovém formátu Markdown, lidé mají ve zvyku ji vizuálně zarovnávat, aby sloupce lícovaly:

| Jméno      | Město      | Věk |
|------------|------------|-----|
| Jan        | Praha      | 26  |
| František  | Bratislava | 34  |

Všechny ty pomlčky a mezery navíc, které drží sloupce pod sebou, jsou pro zobrazení v textovém editoru fajn, ale pro paměť AI je to katastrofa. Markdownu je přitom úplně jedno, jestli sloupce lícují. Úplně stejně mu stačí tento zápis:

| Jméno | Město | Věk |
|---|---|---|
| Jan | Praha | 26 |
| František | Bratislava | 34 |

Výsledná tabulka se na displeji ukáže naprosto stejně, ale ušetříte klidně polovinu tokenů. Pokud necháte AI vygenerovat rozsáhlý přehled, ušetříte hromadu času i paměti, když jí zakážete vizuální doplňování mezer do tabulek.

HTML a XML: Nejhorší kombinace

Formáty pro tvorbu webových stránek (HTML) nebo přenos dat (XML) jsou pro paměť AI nejnáročnější. Kombinují totiž dva problémy: jsou velmi upovídané (každý prvek musí mít začátek a konec, např. <uzivatel></uzivatel>) a bývají velmi hluboce zanořené. Na páté úrovni zanoření už s běžnými mezerami posíláte dvacet prázdných znaků před každým slovem.

Pokud dáváte AI analyzovat staženou webovou stránku, vždy se vyplatí ji před odesláním zbavit zbytečných konců řádků a prázdných mezer.

3. VELKÁ PÍSMENA: Podceňovaný žrout peněz

Rozdíl v tom, jak AI vnímá slova select, SELECT a Select, je pro většinu lidí šokující. Protože se texty na internetu píší primárně malými písmeny, má umělá inteligence pro celá běžná slova (jako jsou programátorské příkazy nebo názvy funkcí) připravené levné jednoslovné kousky.

Jakmile ale zapnete Caps Lock a napíšete slovo velkými písmeny, systém ho ve svém slovníku nenajde a musí ho složitě poslepovat z menších fragmentů.

Jak AI vnímá velikost písmen:

• select → 1 kousek: [select]
• SELECT → 2 kousky: [SE] + [LECT]
• migration → 1 kousek: [migration]
• MIGRATION → 3 kousky: [M] + [IGR] + [ATION]

Pokud píšete databázové skripty tradičním stylem, kde jsou všechna klíčová slova striktně velká (CREATE TABLE USERS), spotřebováváte na tato slova dvojnásobné množství paměti, než kdybyste vše převedli na malá písmena (create table users).

U složených názvů proměnných (jako je střídání velkých a malých písmen transactionId) je situace podobná. Velké písmeno uprostřed slova funguje jako řez a systém slovo rozdělí na dvě části. Pokud můžete, v databázích, kódu a konfiguracích je z pohledu úspory nejstabilnější používat malá písmena oddělená podtržítkem (transaction_id) nebo zkráceniny (tx_id).

4. Případová studie: Popis databáze (SQL vs. DBML)

Pokud vyvíjete databázové aplikace (například s moderními nástroji, které staví API přímo nad databází), váš AI pomocník potřebuje detailně znát strukturu vašich tabulek, aby vám mohl pomáhat. Předhodit mu kompletní export v surovém jazyce SQL (CREATE TABLE…) je ten nejrychlejší způsob, jak mu zaplnit paměť.

Zde je jasné srovnání, jak lze stejnou věc zapsat standardně v SQL a v úspornějším moderním formátu DBML. Mimochodem, pokud pracujete s PostgreSQL a nechcete schémata přepisovat ručně, můžete pro automatický export celé struktury do čistého DBML využít jednoduchý CLI nástroj pg_dbml.

Verze v SQL (Upovídaná, cca 45 tokenů)

CREATE TABLE "users" (
  "id" SERIAL PRIMARY KEY,
  "username" varchar(50) NOT NULL,
  "role_id" integer NOT NULL,
  CONSTRAINT "fk_users_role" FOREIGN KEY ("role_id") REFERENCES "roles" ("id")
);

Verze v DBML (Kompaktní, cca 18 tokenů)

Table users {
  id int [pk, increment]
  username varchar(50)
  role_id int
}
Ref: users.role_id > roles.id

Proč úspornější formát (DBML) ušetří přes 60 % paměti?

1. Čistý text: Neobsahuje neustále se opakující uvozovky, které AI často odsekává jako samostatné znaky.
2. Jednoduché vazby: SQL zápis cizího klíče (CONSTRAINT…) spotřebuje zhruba 15 tokenů. V moderním formátu DBML stačí napsat jeden kratičký řádek: Ref: users.role_id > roles.id (6 tokenů).
3. Srozumitelnost: Pro umělou inteligenci je mnohem snazší pochopit vztahy mezi tabulkami, když jsou zapsané přehledně na jednom místě, než když je musí dolovat z vnitřku složitých SQL příkazů.

5. Jak to zautomatizovat, aby netrpěly vaše oči

Cílem těchto pravidel není nutit vás psát ošklivý nebo nečitelný kód. Cílem je nastavit vaše vývojové prostředí tak, aby kód v editoru vypadal skvěle pro vás, ale při uložení na disk se automaticky očistil od zbytečného balastu (mezery navíc) a zkrátil na minimum. Tomu se říká čištění na úrovni řádků – konce řádků zůstanou zachovány, takže v historii změn je kód stále perfektně čitelný, ale zmizí z něj prázdná vata.

Krok 1: Nastavení automatického čističe (SQLFluff pro SQL)

Pro úpravu databázových souborů můžete použít bezplatný nástroj SQLFluff. Správná konfigurace zajistí, že se kód očistí od přebytečných mezer a převede se na malá písmena. Aby bylo ladění pravidel snadné, můžete si celou strukturu vizuálně vyzkoušet a naklikat přes SQLFluffUI, což vám ušetří čas s ručním přepisováním konfiguračních textů.

Stačí v projektu vytvořit konfigurační soubor s těmito pravidly:

[sqlfluff:indentation]
# Používáme tabulátory pro 100% předvídatelnou úsporu
indent_unit = tab
tab_width = 4

[sqlfluff:rules:layout.spacing]
# Vynutí přesně 1 mezeru kolem operátorů, smaže vizuální sloupečky
force_spacing = true

[sqlfluff:rules:capitalisation.keywords]
# Převod všech SQL příkazů na úspornější malá písmena
capitalisation_policy = lowercase

Krok 2: Automatické spouštění při uložení

Abyste na formátování nemuseli myslet, můžete si ve svém editoru (např. VS Code) nastavit automatické akce při uložení. Kód se sám vyčistí vteřinu předtím, než ho zapíšete do historie. Váš AI asistent pak v projektu uvidí už jen tuto úspornou verzi.

Podobně to funguje u datových souborů (např. konfigurace v JSON). Místo roztaženého formátu na padesát řádků je můžete nechat automaticky smrštit tak, aby každá ucelená část byla na jednom kompaktním řádku bez vnitřních mezer.

6. Jak zkrotit AI asistenta pomocí pravidel

Pokud používáte asistenty, kteří se sami pohybují ve vašem projektu, můžete jim chování upravit pomocí souboru pravidel. Většina z nich si při spuštění přečte soubor pravidel v kořeni vašeho projektu — název závisí na konkrétním nástroji (CLAUDE.md pro Claude Code, AGENTS.md pro OpenAI Codex a další). Podívejte se do dokumentace svého asistenta.

Do tohoto souboru jim můžete dát jasné instrukce, aby šetřili svou vlastní pamětí a hlavně aby vám neposíli zbytečně dlouhé odpovědi (výstupní tokeny od AI jsou totiž výrazně dražší než ty vstupní).

Zde je jednoduchý blok pravidel, který stačí do souboru zkopírovat:

## Pravidla pro úsporu tokenů a paměti

Při práci na tomto projektu se striktně drž následujících pravidel, abys šetřil kontextové okno a zrychlil odpovědi:

### 1. Strategie čtení kódu a vyhledávání
- **Cílené čtení:** Nikdy nečti celé velké soubory (>500 řádků), pokud potřebuješ vidět jen jednu konkrétní funkci. Používej nástroje pro čtení specifického rozsahu řádků.
- **Efektivní vyhledávání:** Raději přesně vyhledávej pomocí textových filtrů (grep/regex), než abys naslepo otevíral soubory a kontroloval jejich strukturu.

### 2. Pravidla pro generování odpovědí a kódu
- **Piš stručně (Žádná omáčka):** Neopakuj mé zadání a vynechej zdvořilostní fráze ("Jistě, rád vám s tím pomohu..."). Začni přímo odpovědí nebo blokem kódu.
- **Posílej jen změny (Zkrácený kód):** Když mi v chatu ukazuješ úpravu kódu, nikdy nevypisuj celý soubor znovu. Ukaž POUZE řádky, které se změnily. Nedotčené části kódu nahraď komentářem typu `// ... zbytek kódu ...`.
- **Styl kódu:** Při generování kódu používej pro odsazování výhradně jeden tabulátor (`\t`). Nikdy nepoužívej mezery pro vizuální zarovnávání textu do sloupců.

Výsledná tabulka úspor

Následující přehled ukazuje, jaký reálný dopad mají tyto drobné změny na množství dat, která musíte do AI posílat:

Závěr

Optimalizace kódu pro umělou inteligenci se stává novou užitečnou dovedností každého moderního tvůrce. Nemusíte kvůli tomu měnit to, jak kód vidíte vy sami – stačí správně nastavit automatické pomocníky v editoru. Vývojář nebo analytik, který dokáže udržet svůj projekt s nízkou „tokenovou stopou“, získává obrovskou výhodu: jeho AI asistent pracuje rychleji, dělá méně chyb, dokáže pojmout větší celky aplikace najednou a provoz celého systému stojí zlomek původní ceny.