Když se zkušenosti vývojáře stávají promptovatelné

Narazil jsem na silný osobní text softwarového inženýra, který popisuje nepříjemný pocit: věci, do kterých deset let investoval profesní energii, se podle něj začínají stávat promptovatelné.

To je důležitý rámec. Zdroj není studie trhu práce a netvrdí, že LLM už nahradily softwarové inženýry. Je to osobní esej člověka, který se snaží pojmenovat, proč se mu mění pocit vlastní profesní hodnoty.

Autor píše, že letos dokončuje deset let profesionální zkušenosti. Začínal jako frontendový vývojář, ale poměrně rychle přešel k backendu. Postupně pracoval v oblastech financí, účetnictví a platebního zpracování.

Právě tam si budoval specializaci. Zmiňuje věci jako PCI compliance, podvojné účetnictví, escrow, reconciliation, payment lifecycles nebo idempotenci bankovních převodů. Jinými slovy: nešlo jen o “umět programovat”, ale o schopnost psát software v konkrétní doméně.

První pilíř: doménová znalost

První část textu je o doménové expertize.

Autor nastoupil do firmy ve finančním prostředí, kde dostal od prvního dne přístup k ChatGPT a Claude Enterprise. Firma ho zároveň povzbuzovala, aby AI používal i pro research, návrhy a kódování. S důležitou podmínkou: pořád měl kontrolovat a vlastnit každý řádek, který skončí v produkci.

Jeden z jeho prvních projektů se týkal přepracování starého online platebního systému. Firma ho na takovou práci najala mimo jiné kvůli jeho předchozí zkušenosti. Jenže design dokumenty měly být čitelné nejen pro inženýry, ale i pro product manažery.

Nejdřív psal dokumenty skoro bez AI. Pak mu manažer řekl, že sice dodává kód dobrým tempem, ale design dokumenty trvají moc dlouho. A že by měl AI používat víc.

Tady přichází první zlom. Autor píše, že modely sice pořád potřebovaly vedení, ale dokázaly pomoci s psaním i rozhodováním. A hlavně dokázaly spojovat body v doméně, u které si myslel, že její pochopení vzniká jen po letech praktické zkušenosti.

Moje čtení: autor netvrdí, že doménová znalost zmizela. Spíš říká, že její část, která dřív oddělovala zkušeného vývojáře od běžného generalisty, se začala přesouvat do práce s modelem.

Druhý pilíř: debugging a distribuované systémy

Druhý pilíř, o který se autor opíral, byl debugging.

Zpočátku podle něj LLM sice uměly pomoci s dokumenty a později i s kódem, ale pořád neuměly dobře debugovat složité problémy v produkci. To autor vnímal jako svou dlouhodobou výhodu. Měl zkušenosti s race conditions, distribuovanými systémy a chybami, které se neukážou v jednoduchém lokálním prostředí.

Pak podle jeho popisu přišly MCP integrace, agentní workflow a nové modely.

U Claude 4.5 uvádí, že model nebyl dokonalý. Podle autora vyřešil asi 60 % bugů, když dostal stack trace a kontext, například Sentry link se zapnutým Sentry MCP. Někdy prý navrhl řešení, které znělo věrohodně, ale bylo špatně.

Jenže zároveň začal vidět případy, kdy Claude Code jedním pokusem vyřešil bugy, které by mu dřív zabraly celý den. Později mluví ještě silněji: s novějšími modely, agentními workflow a DataDog MCP podle něj některé chyby napříč distribuovanými systémy řeší CLI nástroje za něj.

Tady je potřeba být opatrný. Je to autorova zkušenost z jeho prostředí, ne univerzální benchmark. Ale jako signál je to zajímavé: i debugging, který dlouho vypadal jako lidská výhoda, se může částečně přesunout do agentního workflow.

Třetí pilíř: kvalita kódu a architektura

Třetí část textu je o kvalitě kódu a architektuře.

Autor píše, že právě tady vidí poslední stojící pilíř. Má rád refactoring, dobrý návrh kódu, diskuse o trade-offech, DDD, hexagonální architekturu nebo čistou architekturu. Zároveň ale cítí, že se tenhle typ znalosti v oboru začíná zplošťovat do slova “taste”.

Jeho argument není, že agenti dnes píší krásně organizovaný kód. Naopak. Píše, že bez vedení snadno vytvoří kruhové závislosti, duplicity, zbytečné komentáře nebo smíchají čisté funkce se side efekty.

Obava je jiná: pokud se kód stále víc píše pro stroje a ne pro lidi, může se změnit práh toho, co tým považuje za přijatelné. Autor to formuluje tak, že lidé možná pořád nechtějí úplně neudržovatelný kód, ale “C” nebo “D” kvalita může začít stačit tam, kde by dřív tým mířil na “A” nebo “B”.

To je nepříjemná myšlenka. Ne proto, že by musela být pravdivá všude. Ale protože dobře vystihuje posun v motivaci: pokud hlavním čtenářem kódu přestává být člověk, mění se i hodnota lidské péče o strukturu.

Co z toho plyne

V závěru autor píše, že je stále zaměstnaný a v dohledné době se jako zaměstnaný vidí. Nejde tedy o okamžitý osobní kolaps.

Spíš popisuje nejistotu nad delším horizontem. Před osmi měsíci podle něj ve firmě proběhlo propouštění, které podle firmy nesouviselo s AI. Někteří propuštění kolegové si ale podle něj hledají práci dlouho a narážejí na podobný problém: doménová expertiza už nemusí být tak silný rozlišovací faktor.

Zmiňuje i změnu v náboru. Dřív se prý role označovaly konkrétněji podle oblasti. Teď firma hledá prostě “Software Engineer” a přiřazení k týmu přijde až po přijetí nabídky.

Autor zvažuje, jestli by měl svou expertizu přesunout jinam: třeba k matematice, statistice, pokročilému strojovému učení nebo výzkumné roli ve frontier labu. Zároveň ale popisuje praktické překážky: žádné takové laby v jeho zemi, hodně přihlášek, rodinné závazky a nejistotu, jestli by podobný skok vůbec stihl včas.

Moje čtení

Ten text je zajímavý právě tím, že není klidně analytický. Je úzkostný, osobní a místy záměrně vyhrocený.

Ale ukazuje otázku, kterou bude řešit čím dál víc vývojářů:

Co se stane s profesní hodnotou člověka, když se část jeho těžce nabytých zkušeností stane dostupná přes model, nástroje a dobře připravený kontext?

Možná odpověď není “vývojáři končí”.

Spíš: mění se to, co znamená být zkušený vývojář. Méně může stačit jen “znám tuto doménu” nebo “umím debugovat tyhle typy problémů”. Větší hodnotu může mít schopnost poznat, kdy model vypadá přesvědčivě, ale míří špatně; kdy návrh potřebuje lidský úsudek; a kdy rychlost začíná ničit dlouhodobou udržitelnost systému.

To není uklidňující odpověď.

Ale je to užitečnější otázka než jednoduché “AI nahradí / nenahradí programátory”.