CodeBuddy NPC má fungovat jako AI kolega přímo v Git workflow

CodeBuddy NPC staví na myšlence, že AI nemá být jen chatem otevřeným vedle editoru, ale ověřeným účastníkem stávajícího vývojového procesu v Gitu, který reaguje na události. Vývojář může roli vyvolat zmínkou @ v Issue nebo pull requestu (PR). Agent pak pracuje asynchronně v cyklu analýza → plán → implementace → PR → ověření v CI → oprava → opětovné ověření. 16

Git jako pracovní kontext AI

V modelu označovaném jako AI Native Git slouží Git a související artefakty jako trvalá pracovní paměť agenta: historie repozitáře, Issues, pull requesty, výsledky CI/CD i pravidla kvality nesou kontext práce. Tým proto nemusí požadavky, zdrojový kód a logy z buildů ručně kopírovat do samostatného asistenta. NPC pracuje přímo nad artefakty, které už vývojový tým používá. 17

AI kolegové definovaní v YAML

CNB umožňuje vytvořit role AI specifické pro daný repozitář v souboru .cnb/settings.yml. Konfigurace může zahrnovat jejich název, prompt, importy znalostní báze i prvky pro interakci. Dokumentované události NPC se spouštějí při zmínce role v Issue nebo PR; volitelná konfigurace v .cnb.yml určuje, jak má daná role reagovat. 367

Díky tomu lze role specializovat například na:

• implementaci funkcí,
• rešerši a analýzu problému,
• kontrolu kódu,
• koordinaci většího úkolu.

U rozsáhlejší práce mohou souběžně působit i týmy více NPC s rozdílným zaměřením. 367

Od zadání až po opravu selhaného CI

Po vyvolání může CodeBuddy NPC načíst a interpretovat kódovou základnu, navrhnout postup, upravit kód, založit pull request, spustit testy a vyhodnotit neúspěšné běhy CI. Pokud validace selže, může iterovat nad opravami a znovu je ověřit, dokud výsledek nedosáhne stavu vhodného k akceptaci. Protože je návrh asynchronní, vývojář nemusí po celou dobu vést s agentem interaktivní konverzaci. 17

To neznamená, že každý výstup může být bez lidské kontroly automaticky nasazen do produkce. Jde především o architektonické zasazení AI do procesu, který už obsahuje review, testy a schvalovací brány. 17

Co dodává platforma CNB

Podkladovou vrstvu tvoří CNB: hostování Gitu, CI/CD pipeline, repozitáře artefaktů a cloudová vývojová prostředí. Pipeline YAML může definovat Docker image, dočasný image sestavený z Dockerfilu, dev container, připojené svazky, runnery označené podle CPU i znovupoužitelnou Docker cache. Build a test se tak mohou spouštět v opakovatelném izolovaném prostředí místo závislosti na lokálním počítači vývojáře. 54

Pipeline zároveň získávají dočasný CNB_TOKEN pro autorizované operace s kódem, artefakty a API. Jeho oprávnění se odvíjejí od události, která běh spustila, a po skončení běhu se token zničí. 15

Dohledatelnost a kontrola přístupu

Protože je práce vyvolaná z Issues či PR, zaznamenaná v commitech a pull requestech a ověřovaná přes pipeline a kvalitativní brány, zůstává zachována běžná inženýrská auditní stopa. Nejde o samostatnou, pro tým neviditelnou práci agenta. 19

Dokumentace CNB pro úložiště tajemství navíc popisuje řízení přístupu, omezení operací, auditní logy a vodoznaky pro práci s citlivými údaji. 9

Proč má klesat spotřeba tokenů

Tencent připisuje pokles spotřeby při prvním průchodu — z více než 20 000 tokenů přibližně na 2 000, tedy o více než 90 % — průběžné optimalizaci promptů, volání nástrojů, výstupu CLI a míry zásahů cache. Firma rovněž popisuje volbu modelové strategie podle náročnosti úkolu, aby se nákladnější schopnosti nepoužívaly stejně pro každou práci. 811

V tomto pojetí „AI inženýrské spolupráce“ AI pouze nezrychluje psaní kódu, ani nevykonává izolovaný příkaz. Má vystupovat jako řízený kolega: přijímá práci přes standardní týmové artefakty, používá skutečné buildovací a bezpečnostní kontroly, může spolupracovat s rolemi zaměřenými na různé činnosti a uzavírá zpětnou vazbu mezi plánováním, implementací, review, validací a nápravou. 17