Lekcie 1–3 dali základ. Táto ho aplikuje na to, čo naozaj robíš: čítanie cudzieho kódu, hľadanie príčiny chyby, testy, dáta a vysvetľovanie ostatným. Všetko v obyčajnom chate — nič, čo by si musel inštalovať.
AI vo vývojárskom dni
Kurz je napísaný pre človeka, ktorý píše Javu a väčšinu dňa nestrávi písaním nového kódu, ale čítaním cudzieho, hľadaním príčiny chyby a vysvetľovaním ostatným, čo sa vlastne stalo. Všetko tu je na úrovni obyčajného chatu — otvoríš okno, vložíš text, dostaneš odpoveď.
Kde sa AI zmestí do tvojho dňa
Nie je náhradou žiadneho z týchto krokov — je urýchľovačom v každom z nich.
- 1Ticket
Z troch odstavcov od biznisu vytiahne, čo je vlastne zadanie a čo sa treba dopýtať.
- 2Cudzí kód
Za čo je trieda zodpovedná, kto ju volá a kde sa v nej mení stav. Mapa pred vstupom.
- 3Chyba
Stack trace a log na hypotézy zoradené podľa pravdepodobnosti, s návodom, ako ich overiť.
- 4Testy
Hraničné prípady, prázdne hodnoty, súbeh a zlé vstupy — zoznam, ktorý si sám neurobíš.
- 5Review
Prejde tvoj diff skôr než kolega. A pomôže napísať pripomienku, ktorá nikoho neurazí.
- 6Preklad
Popis PR, poznámka do ticketu, odpoveď podpore. To, čomu sa vývojári vyhýbajú najviac.
1. Cudzí kód, ktorý máš pochopiť
Väčšina práce na existujúcom projekte je čítanie, nie písanie. A práve tu je AI najsilnejšia: z triedy, ktorú vidíš prvýkrát, spraví mapu — za čo je zodpovedná, kto ju volá, kde sa mení stav. To je päť minút namiesto polhodiny skákania po súboroch.
„Idem sem pridať validáciu“ dá úplne iné vysvetlenie než „idem to zrýchliť“. Bez toho dostaneš prerozprávanie riadok po riadku.
„Kód neprepisuj“ patrí do promptu vždy, keď chceš pochopiť. Inak dostaneš svoju triedu prepísanú podľa vkusu modelu.
„Ak ti niečo chýba, napíš, čo mám doložiť“ — bez tejto vety si model rozhranie alebo konfiguráciu domyslí a nepovie ti to.
Prompt na skúšku
Skopíruj, doplň hranaté zátvorky a pošli.
Toto je trieda zo staršej aplikácie, ktorú som zdedil — [verzie, framework]. Idem do nej pridať [čo]. Vysvetli mi v piatich vetách, za čo je zodpovedná a kto ju pravdepodobne volá. Potom vypíš miesta, kde sa mení stav alebo sa deje niečo neočakávané, a pri každom napíš, prečo ti to príde podozrivé. Kód neprepisuj. Ak ti niečo chýba, napíš, čo ti mám doložiť. [trieda]
2. Chyby, logy a stack trace
Stack trace bez kontextu je pre model rovnaká hádanka ako pre teba. S kontextom je to iné: verzie, čo sa včera nasadilo, čo si už skúsil. Namiesto jednej sebavedomej odpovede si vypýtaj zoznam hypotéz — to je forma, ktorá zodpovedá tomu, ako sa chyby naozaj hľadajú.
„Päť možných príčin podľa pravdepodobnosti a ku každej, ako ju overím“ je použiteľnejšie než jedna odpoveď, ktorá môže byť vedľa.
Jedna veta, ktorá ti ušetrí polovicu zoznamu. Bez nej ti model odporučí presne to, čo si robil pred hodinou.
Vlož skutočný výpis, nie svoje prerozprávanie. Ale najprv z neho vyhoď údaje zákazníkov, tokeny a adresy serverov.
Prompt na skúšku
Skopíruj, doplň hranaté zátvorky a pošli.
[verzie a prostredie]. Toto padlo v produkcii, lokálne sa to nedá zopakovať. Včera sme nasadili [čo]. Už som skúsil [čo]. Daj mi päť hypotéz zoradených podľa pravdepodobnosti a ku každej napíš, ako ju viem za päť minút potvrdiť alebo vylúčiť. Neuvádzaj metódy ani nastavenia, ktoré v týchto verziách neexistujú — ak si nie si istý, označ to. [stack trace]
3. Testy a hraničné prípady
Toto je miesto, kde ti model doplní presne to, čo tebe chýba: odstup. Ty vieš, ako to má fungovať, a preto testuješ šťastnú cestu. Model netuší, čo si myslel, a preto sa pýta na prázdny zoznam, záporné číslo, dva paralelné požiadavky a dátum na prelome roka.
Vypýtaj si zoznam prípadov v slovenčine. Rozhodneš, ktoré dávajú zmysel, a až potom nechaj napísať testy.
Bez kontraktu ti model otestuje implementáciu namiesto správania — a taký test padne pri prvom refaktore.
Pri chybe si vypýtaj najprv test, ktorý ju reprodukuje. Až potom oprav. Inak nevieš, či si opravil to, čo si myslel.
Prompt na skúšku
Skopíruj, doplň hranaté zátvorky a pošli.
Toto je metóda a takto má fungovať: [kontrakt vlastnými slovami]. Vypíš zoznam prípadov, ktoré by som mal otestovať — vrátane prázdnych a neplatných vstupov, hraníc, súbežného volania a chýb z okolia. Ku každému jednou vetou, prečo je dôležitý. Kód testov zatiaľ nepíš, najprv chcem ten zoznam. [metóda]
4. Review — tvoje aj cudzie
Nechať si prejsť vlastný diff skôr, než ho uvidí kolega, je lacné a nepríjemne účinné. A opačný smer je ešte cennejší: keď máš k cudziemu kódu výhradu, ktorá znie ostro, model ti ju pomôže napísať tak, aby sa dala prijať.
„Buď prísny a nechváľ“ — inak dostaneš zoznam toho, čo je na tvojom kóde pekné.
Chyba, riziko, štýl. Bez toho splynie chýbajúce ošetrenie chyby s medzerou v odsadení.
„Prepíš túto poznámku tak, aby bola vecná a nevyznela ako útok na autora.“
Prompt na skúšku
Skopíruj, doplň hranaté zátvorky a pošli.
Toto je môj diff pred odoslaním na review: [diff]. Kontext: [čo mala zmena urobiť]. Buď prísny recenzent, nechváľ ma. Vypíš pripomienky zoradené podľa závažnosti: (1) chyby a riziká, (2) veci, ktoré sa v budúcnosti vypomstia, (3) štýl. Pri každej napíš konkrétny riadok. Kód neprepisuj — chcem pripomienky, nie hotovú verziu.
5. Dáta, SQL a výpisy
Dotaz podľa opisu, rozobratie cudzieho dotazu s tromi JOINmi, poriadok v exporte alebo v logu. Platí tu jedno pravidlo z lekcie 3, ktoré tu bolí najviac: keď má model niečo spočítať, nechaj to počítať kódom, nie odhadom. A produkčné dáta do chatu nepatria — na štruktúru stačí schéma a pár vymyslených riadkov.
Názvy stĺpcov a typy stačia. Skutočné riadky zo zákazníckej databázy sú únik, aj keď „len na rýchlo“.
„Vysvetli, čo sa stane pri veľkej tabuľke a čo by sa dalo zindexovať“ je polovica hodnoty.
Pri analýze výpisu alebo exportu povedz „použi kód, neodhaduj“. Inak dostaneš vierohodné, ale vymyslené číslo.
Prompt na skúšku
Skopíruj, doplň hranaté zátvorky a pošli.
Mám tieto tabuľky a stĺpce: [schéma]. Potrebujem dotaz, ktorý [čo má vrátiť]. Napíš ho pre PostgreSQL, vysvetli ho po častiach a napíš, ako sa bude správať pri [veľkosť] riadkov a čo by sa oplatilo zindexovať. Ak je v mojom opise nejednoznačnosť, spýtaj sa namiesto domýšľania.
6. Písanie okolo kódu a udržanie kroku
Commit message, popis pull requestu, poznámka do ticketu, odpoveď podpore. Nikto to nemá rád a všetci to musia robiť — a je to presne ten typ textu, kde model z tvojho diffu a dvoch viet spraví použiteľný výsledok. Rovnako tak vie zhrnúť, čo sa zmenilo medzi verziami Javy alebo knižnice, ktorú roky nikto neaktualizoval.
Čo sa mení, prečo, čo to ovplyvní a na čo sa má recenzent pozrieť. Vlož diff a nechaj napísať.
„Napíš to pre produktovú manažérku, bez technických pojmov“ — a hlavne bez sľubov nad rámec toho, čo si napísal.
Skok z Javy 8 na 21 alebo migrácia knižnice: vypýtaj si zhrnutie so zdrojmi a over ho v oficiálnej dokumentácii.
Prompt na skúšku
Skopíruj, doplň hranaté zátvorky a pošli.
Toto je môj diff: [diff]. Zmena mala [čo mala urobiť]. Napíš (1) commit message v imperatíve, max 72 znakov v prvom riadku, (2) popis pull requestu — čo sa mení, prečo, čo to ovplyvní a na čo sa má recenzent pozrieť, (3) poznámku do ticketu pre netechnického človeka, max 100 slov. Nesľubuj nič, čo v diffe nie je.
Štyri zlaté pravidlá
Zdrojový kód, konfigurácie a interné dokumenty patria zamestnávateľovi. Do osobného chatu ich nevkladaj — použi len nástroj, ktorý máš na to schválený, a keď nemáš žiadny, spýtaj sa skôr, než niečo vložíš.
Model si vie s istotou vymyslieť metódu, parameter alebo nastavenie, ktoré v tvojej verzii knižnice neexistuje. V próze si halucináciu všimneš, v kóde až pri kompilácii — alebo v horšom prípade až v produkcii.
Keď kód od modelu nevieš vysvetliť na review, nie je tvoj a nemá čo robiť v repozitári. Nechaj si ho najprv rozobrať po častiach.
Kód od modelu prechádza presne tým istým, čím prechádza tvoj. Žiadna výnimka preto, že „to napísala AI a vyzerá to dobre“.