Lekce 06.1: Jak řešit masivní úkoly (How to Tackle Massive Tasks)

⏱️ 3 min čtení • Lekce 06.1

🧠 Mentální model & teoretický rozbor

Největší zkouškou softwarového inženýra je dodat velkou, komplexní funkci (např. kompletní platební systém, migraci databáze nebo novou mikroservisu). Pokud takový úkol zadáte agentovi v jednom obřím promptu („Postav mi kompletní fakturační systém“), garantovaně selžete:

Agent se pokusí vytvořit 20 souborů najednou.
Polovina souborů bude nedokončená.
Kontext se bleskově zaplní a vývoj se zastaví v chaosu.

Inženýrské řešení spočívá ve Fraktální dekompozici úkolů (Fractal Task Decomposition):

FRAKTÁLNÍ DEKOMPOZICE VELKÉHO CÍLE:
┌─────────────────────────────────────────────────────────────┐
│ 1. ÚROVEŇ: EPOS / VELKÝ CÍL (Feature Goal)                  │
│    "Implementace platebního systému Stripe"                 │
└──────────────────────────────┬──────────────────────────────┘
                               │ Grilování & Architektonická specifikace
┌──────────────────────────────▼──────────────────────────────┐
│ 2. ÚROVEŇ: TECHNICKÁ SPECIFIKACE (Specifikace v Markdownu)   │
│    Datové toky, DB schémata, rozhraní, seznam testů         │
└──────────────────────────────┬──────────────────────────────┘
                               │ Rozpad na atomické jednotky
┌──────────────────────────────▼──────────────────────────────┐
│ 3. ÚROVEŇ: TICKETY O VELIKOSTI JEDNOHO SEZENÍ (Session Tickets)│
│    Ticket 1: Databázové schéma + migrace                    │
│    Ticket 2: Webhook handler + ověření kryptopodpisu        │
│    Ticket 3: Servisní vrstva pro checkout                   │
│    Ticket 4: UI komponenta ceníku                           │
│    Ticket 5: E2E integrační test                            │
└─────────────────────────────────────────────────────────────┘

Každý dílčí ticket má přesně takovou velikost, aby se pohodlně vešel do Smart Zone jednoho sezení!

🏢 Realistický scénář z praxe

Firma vyvíjí SaaS aplikaci pro generování reportů z databází. Úkol: Umožnit uživatelům plánovat automatické odesílání PDF reportů na e-mail každé pondělí v 8:00.

Vibe coder: Zadá agentovi celý úkol najednou. Agent začne míchat Cron joby, generování PDF, Nodemailer a UI dialog do jednoho sezení. Po hodině nic nefunguje.
Real Engineer:
1. Ticket 1: Databázová tabulka ReportSchedule + Prisma migrace. (Sezení 1 ➔ commit).
2. Ticket 2: Cron worker (BullMQ / Redis) pro spouštění úloh podle cron výrazu. (Sezení 2 ➔ commit).
3. Ticket 3: Generátor PDF z HTML šablony přes Puppeteer. (Sezení 3 ➔ commit).
4. Ticket 4: UI formulář pro nastavení frekvence reportu. (Sezení 4 ➔ commit). Každý krok byl stoprocentně otestován a nasazen v čistém kontextu!

💻 Konkrétní ukázky kódu & promptů

Pravidlo pro velikost jednoho ticketu (Session-Sized Chunk):

[!IMPORTANT] 1 TICKET = 1 SEZENÍ = 1 GIT COMMIT = MAX 30 MINUT PRÁCE AGENTA.

Pokud ticket vyžaduje úpravu více než 3–5 souborů, je příliš velký. Rozdělte ho na dva!

⚠️ Analýza selhání & Anti-patterns

Chyba: Předčasné spojování vrstev

Začít psát frontendové tlačítko dříve, než existuje a je otestován backendový endpoint.

Agent na frontendu začne hádat formát dat z backendu.
Výsledkem je nesoulad rozhraní (interface mismatch).
Pravidlo: Postupujte od datového jádra směrem k povrchu (Databáze ➔ Byznys logika ➔ API ➔ UI).

🛠️ Inženýrský postup krok za krokem (Playbook)

Rozepište velkou funkci na papír nebo do issue trackeru.
Identifikujte závislosti: Co musí vzniknout jako první?
Vytvořte sadu číslovaných ticketů (např. 01-db.md, 02-service.md, 03-api.md).
Exekvujte tickety jeden po druhém v čistých sezeních s příkazem /clear mezi nimi.

🧪 Praktické cvičení (Hands-on Lab)

Úkol:

Vezměte velkou funkci ze svého backlogu a rozložte ji na 4 samostatné session-sized tickety podle dekompozičního pravidla.