Appearance
KAM SE DÁ DOJÍT: FORGE
Z Jira ticketu rovnou merge request
Takhle vypadá vývoj, který splňuje laťku v obou osách AI Readiness. Forge je náš autonomní AI agent postavený na Agentic standardu. Ohodnotí zadání nebo z ohraničeného ticketu rovnou otevře MR k lidskému review. Dnes běží v provozu. Detaily a demo najdete na goforge.tech. plně automatickyběží bez zásahu člověka od labelu v Jiře až po MR
2 režimyohodnocení zadání · autonomní implementace
best effortimplementace bez garance. Výstup míří k lidskému review
V kostce
Forge zkracuje čas, který vývojáři tráví rutinní, dobře ohraničenou prací (bugfixy, drobné featury, refaktory, aktualizace závislostí, testy). Vývojář nebo PM označí ticket labelem, agent připraví změnu, ověří ji povinnými checky projektu a otevře MR. Člověk už jen reviduje a merguje. Výsledkem je rychlejší průchod ticketu od zadání k revizi při zachované kontrole: povinné kontroly projektu se nesnižují a finální rozhodnutí (merge) zůstává na člověku.
Tenhle stupeň automatizace je možný jen tehdy, když lidé i projekt splňují to, co AI Readiness měří. Je to konec cesty. Vyhodnocení ukáže, kde na ní stojíte, které kroky mají prioritu a kudy vede cesta dál.
🔥 Forge má vlastní web: goforge.tech
Tady na portálu ukazujeme Forge jako příklad cílového stavu, ke kterému AI Readiness směřuje. Ceník, kalkulačku úspor, ukázku běhu z provozu a možnost domluvit si demo najdete na goforge.tech.
🔀 Dvě funkce: ohodnotit zadání, nebo ho naprogramovat
Forge dělá přesně to, co Agentic standard staví na první místo, tedy kvalitní vstup a spec-driven development. Proto umí dvě věci:
🔍
1. Ohodnotí zadání
Ještě před vývojem projede ticket i repo a ohodnotí kompletnost zadání skóre 0–10 s konkrétními otázkami, co doplnit.
🔨
2. Naprogramuje ho
Z dobře ohraničeného ticketu sám otevře MR připravený k lidskému review.
🧮 Skóre zadání rozhoduje, kdo ho vezme
Hodnocení zadání není samoúčelné. Přímo rozhoduje o dalším kroku. Podle skóre se ticket automaticky nasměruje tam, kde dává největší smysl:
| Skóre zadání | Rozhodnutí |
|---|---|
| 8–10 | Zadání je jednoznačné → rovnou ho implementuje Forge (vznikne MR). |
| 5–7 | Zadání je dobré, ale vyžaduje lidský úsudek → implementuje vývojář. |
| < 5 | Zadání je neúplné → vrací se analytikovi k doplnění, nejde na vývoj. |
V kostce
Efekt je dvojí: nekompletní zadání se zachytí dřív, než zbytečně spotřebuje čas vývojáře, a jednoznačné tickety odbaví agent sám. Vývojářský čas se soustředí tam, kde je potřeba lidský úsudek, tedy do střední kategorie. Kvalita zadání se tak stává měřitelnou branou, ne otázkou náhody.
Analyzátor vrátí hodnocení jako komentář u ticketu. Obsahuje přehledné shrnutí toho, co je jasné, co chybí, a seznam otázek k doplnění. Ilustračně (fiktivní zadání):
🧪 Ukázka výstupu analyzátoru (fiktivní zadání)
Spec review: hodnocení zadání 6/10
Cíl je srozumitelný a v repozitáři plně proveditelný: přidat do seznamu objednávek filtr podle stavu. Dotčené místo (endpoint i komponenta seznamu) je jednoznačně identifikovatelné a existuje zavedený vzor pro obdobné filtry. Zadání je z pohledu „co" jasné, ale „jak" obsahuje několik nedořešených detailů, které by při špatném odhadu vedly k přepracování.
Otázky k zodpovězení před implementací:
- 🔴 Má filtr přijímat více stavů najednou (multiselect), nebo vždy jen jeden?
- 🔴 Jak se má zachovat u neznámého / smazaného stavu? Má vrátit chybu, nebo použít tichý fallback?
- 🟠 Má se zvolený filtr propisovat do URL (sdílitelný odkaz), nebo jen do stavu komponenty?
- 🟢 Řadí se výsledky po odfiltrování stejně jako dosud?
Výsledek: 6/10 → střední kategorie → implementaci vezme vývojář, ne agent.
ℹ️ Krok „ohodnocení zadání před vývojem" je přímo z Agentic standardu. Forge ho jen automatizuje. Zbytek této stránky popisuje druhou funkci: jak z hotového zadání vznikne MR.
🎯 Jaký problém řeší
Vývojářské týmy tráví značnou část kapacity drobnou, dobře ohraničenou prací. Je nutná, ale nevyžaduje kreativní návrh. Přesně tuto vrstvu Forge automatizuje:
- Zkracuje čas vývojářů strávený rutinou. Agent připraví MR, člověk jen reviduje a merguje.
- Zrychluje průchod ticketu ze zadání rovnou k MR s prošlými povinnými checky.
- Zachovává kvalitu a kontrolu. Povinné kontroly se nesnižují a merge zůstává na člověku.
- Nabízí neinvazivní napojení. Do repozitáře ani do CI nezasahujeme; Forge si zakládá vlastní větev a projekt se připojí jen konfigurací na své straně.
Forge je přenosný a nezávislý na platformě. Stejnou logikou obsluhuje GitLab i GitHub, bez vendor lock-inu a s plnou kontrolou nad modelem, náklady i daty. Která další napojení (ticketovací systémy, modely, git provideři) jsou v provozu a která ve vývoji, ukazuje sekce Rozsah na goforge.tech.
Na co se hodí a na co ne
Hodí se na dobře ohraničené tickety, jako jsou bugfixy, drobné featury, refaktory a aktualizace závislostí nebo testy. Velké nebo rizikové úkoly (nové moduly od nuly, rozsáhlé architektonické změny, riskantní datové migrace) zůstávají na člověku.
🧱 Jak to funguje uvnitř
Vnitřně je Forge plně automatická linka o čtyřech krocích. Nemá vlastní databázi a řídí se stavem ticketu a stavem v Gitu, takže je jednoduchý a odolný.
Následující diagram ukazuje cestu od ticketu až po připravený MR pro člověka:
🛰️
Dispečer
Pravidelný automatický job kontroluje označené tickety a spouští práci. Žádné ruční spouštění.
📦
Worker
Pro každý ticket se nastartuje jednorázový virtuální stroj označovaný jako worker. Naklonuje repozitáře a po doběhnutí se smaže; nic nepřežívá mezi tickety.
🧠
AI agent
Nejprve naplánuje, poté napíše změnu a sám ji zkontroluje. Teprve potom ji odevzdá.
🔗
Uzavření
Otevře MR a posune ticket k lidskému review. GitLab i GitHub stejnou logikou.
🔒 Ve výchozím stavu nemerguje: bezpečnostní princip
Nejdůležitější vlastnost Forge je zároveň bezpečnostní princip: ve výchozím stavu agent nemerguje sám. Výstupem každého běhu je otevřený MR, který čeká na lidské review. Review i merge provádí člověk v režimu tzv. human gate.
Human gate je výchozí pravidlo. Výjimku zapínáte vy.
Jedinou výjimkou je volitelný Brave mode: ticket označíte speciálním labelem, a když projdou všechny povinné checky projektu, Forge ho mergne sám. Rozhodnutí je vždy na vašem týmu a platí per ticket. Bez labelu drží human gate beze změny. Merge přitom nejde spustit textem zadání: rozhoduje label v ticketovacím systému, ne obsah ticketu.
🧊
Izolovaný běh
Jeden běh = jeden ticket v jednorázovém workeru, který se po doběhnutí smaže.
🔑
Minimální oprávnění
Agent smí založit větev a otevřít MR; mergovat smí jen tickety výslovně označené pro Brave mode. Citlivé přístupy vůbec nevidí.
🧯
Odolné vůči manipulaci
Ani nedůvěryhodný text ticketu si merge nevynutí. O Brave mode rozhoduje label, který nastavuje váš tým, ne obsah zadání.
🚦
Human gate
Bez Brave mode labelu se žádná změna nedostane do cílové větve bez lidského review.
🔄 Tok od ticketu k Code Review
Celá cesta běží automaticky: dispečer ticket vyzvedne, agent připraví změnu a otevře MR, a podle výsledku povinných checků (CI) se ticket buď posune k člověku, nebo ho agent ještě sám opraví.
ℹ️ Iterace jen na automatické kontrole. Forge se sám opravuje pouze při selhání CIpřed předáním člověku. Jakmile je ticket v Code Review, veškeré další opravy dělá už člověk.
✍️ Jak vypadá dobré zadání
Kvalita výstupu agenta je přímo daná kvalitou ticketu. Agent nemá žádný kontext mimo ticket a repo (nezná ústní domluvy ani chatová vlákna). Ať už ticket zakládá analytik, PM nebo vývojář, dobré zadání obsahuje:
- Cíl: jedna až dvě věty, co a proč se má udělat.
- Akceptační kritéria: konkrétní, ověřitelné podmínky „hotovo" (ideálně testovatelné).
- Dotčená oblast: modul / balíček / repo, kde se má změna odehrát (šetří čas i náklady).
- Přílohy a důkazy: screenshot chyby, log, ukázka dat.
Rychlý test vhodnosti: Zvládl by ticket nový člen týmu jen podle popisu, bez doptávání? Je jednoznačné, kdy je hotovo? Je to jedna ohraničená změna? Pokud ano, ticket je připravený pro agenta.
🧩 Vazba na Agentic standard
Forge není samostatný experiment. Je to produkční aplikace našeho Agentic standardu v praxi. Prvky standardu, které v něm poznáte:
📐
Spec-driven development
Agent nejprve naplánuje, plán se zkontroluje a teprve schválený plán se implementuje.
🧭
Kontext a výběr modelu
Agent dostane zadání i kontext projektu; na náročné kroky silnější model, na rutinu rychlejší.
🔌
Napojení na systémy
Umí si dohledat souvislosti v napojených nástrojích, včetně linkovaných ticketů a zadání.
🛡️
Validace a guardraily
Povinné kontroly se nesnižují, pojistky na počet pokusů a human gate jako výchozí pravidlo.
🔁
Orchestrace
Běží proaktivně sám bez lidského zásahu a ukazuje konkrétní příklad orchestrace agentů.
🧑💻
Vývojář jako orchestrátor
Člověk zadává, kontroluje a rozhoduje o mergi; rutinu odvádí agent.
Detailní rozpad těchto prvků najdete v Agentic standardu. Forge ho převádí do praxe: vývojář jako orchestrátor agentů, ne jako vykonavatel rutiny.