AI agenti vs vývojáři: 5 rozdílů

AI agenti v vývoji: klíčové rozdíly oproti vývojářům a jejich vliv na proces

Agent založený na LLM generuje architektonickou dokumentaci pro legacy systém v Javě s 17 moduly bez dokumentace. Výsledek: detailní diagramy závislostí, popisy rozhraní, anotace komponent. Dokument napodobuje specifikaci zralého týmu. Nicméně v místech s historickými záplatami, jako proxy vrstva místo front zpráv, agent popsal jako standardní architekturu a vymyslel neexistující logiku bez jakýchkoli upozornění.

Vývojář by se zastavil a ověřil u autora kódu. Agent pracuje jen s viditelným kódem a doplňuje vysvětlení bez poznámek o předpokladech. Čím přesnější je průměrný výsledek, tím těžší odhalit chyby.

Pět zásadních rozdílů agenta oproti vývojáři

Absence projektové paměti

Agent zpracovává úkol izolováně, bez nahromaděného kontextu. V projektu polního účetnictví (offline reporty brigadírů) se konflikty synchronizace řeší ve prospěch serveru kvůli minulým chybám s duplicitami. Vývojář si vzpomene na migraci s unikátním indexem. Agent vyžaduje předání historie v kontextových dokumentech.

Pro katastrální utilitu (GKN/EGRN) společné probírání formátů trvalo týden: rozdíly polí, povinnost atributů. Bez toho agent generuje smysluplný, ale nepoužitelný kód.

Řešení: vedte kontextové soubory s architektonickými rozhodnutími a oborou.

Doslovné dodržování specifikace

Úkol: dialog pro výběr verze při konfliktu synchronizace. Agent napíše React komponentu pro jedno pole. V produkci se to zhroutí při konfliktu na více polích (datum, objem, komentář) – zbylé změny se ztratí.

Vývojář by upřesnil nejasnosti: společný dialog nebo podle polí, offline scénáře. Agent ignoruje model reálného světa.

// Příklad: kód agenta pro jedno pole
const ConflictDialog = ({ field, localValue, serverValue }) => (
  <Dialog>
    <p>{field}: {localValue} vs {serverValue}</p>
    <button>Lokální</button>
    <button>Server</button>
  </Dialog>
);

Brána kvality v SENAR: cíl, kritéria přijetí, negativní scénáře před startem.

Množení chyb

Při generování 11 katastrálních utilit se chyba ve vzorci souřadnic (několik cm odchylka, kritická pro dělení pozemků) opakovala ve třech. Rychlost agenta zesiluje úspěchy i selhání.

• Kontrolujte několik modulů z sady, ne jen jeden.
• Chyba v patternu se zkopíruje do všech podobných souborů.

Ignorování dlouhodobé architektury

Úkol: hledání podle odkazů v Sortule. Agent udělá přímý dotaz z handleru. Optimální pro skript, ale pro rostoucí projekt je potřeba servisní vrstva pro caching, ranking, A/B testy.

Po přidání sekce architektury do kontextu agent vrstvu stabilně používá.

Absence odpovědnosti za důsledky

Migrace DB: kaskádové mazání brigadíra vymaže reporty a fotky. Testy to nechytí – psané na schématu. Agent úkol zapomene hned.

Vývojář předvídá bugy za měsíc. Odpovědnost na lídrovi: ruční kontrola migrací.

Tři důsledky pro inženýrský proces

• Dvojitá kontrola: agent zrychluje, ale vyžaduje validaci na klíčových bodech – architektura, migrace, negativní scénáře.

• Kontext jako základ: ukládejte v repozitáři architektonická rozhodnutí, obor, historii. SENAR to standardizuje.

• Lidský filtr: agent je vykonavatel, ne stratég. iniciativa a odpovědnost zůstávají na člověku.

Co je důležité

• Agenti excelují ve statické analýze kódu, ale doplňují neviditelné detaily logikou bez upozornění.
• Doslovné provedení vyžaduje detailní specifikace s negativními případy.
• Chyby se množí v sériích modulů – selektivní kontrola je nutná.
• Architektonická rozhodnutí předávejte do kontextu předem.
• Plná odpovědnost za produkci leží na lídr vývojáři.

— Editorial Team