Harness získává aktiva Augment Code pro propojení kódovacích agentů s dodávkou softwaru

Psaní změny kódu se stává jednodušším. Zajistit, aby byla tato změna otestována, zkontrolována, zabezpečena a spolehlivě fungovala pro zákazníky, zůstává mnohem větším úkolem. Harness sází na to, že další pokrok v AI vývoji softwaru přijde spojením těchto dvou světů.

Dne 8. října Harness oznámil, že získal vybraná aktiva Augment Code, včetně Cosmos, Auggie CLI, Code Context Engine a související technologie. Tým stojící za těmito produkty se připojuje k Harness. Cosmos se stane Harness Cosmos Software Factory Agent, čímž rozšíří platformu společnosti pro dodávku softwaru o inženýrskou práci, která probíhá před tím, než změna vstoupí do nasazovacího kanálu.

Rozlišení je podstatné: jedná se o akvizici vybraných aktiv a jejich přidruženého týmu, nikoli o deklarovaný nákup celé společnosti Augment Code. Význam spočívá v propojení technologií: agenti, kteří rozumí a upravují kódovou základnu, a systémy, které rozumí tomu, jak je kód testován, vydáván a provozován.

Co Harness přináší do své platformy

Oznámení umisťuje Cosmos jako výchozí bod pro stále autonomnější životní cyklus vývoje softwaru, tedy SDLC. Požadavek, přiřazený tiket nebo nahlášená chyba mohou spustit koordinovaný pracovní tok, ve kterém agenti naplánují změnu, napíšou kód a testy a otevřou pull request. Inženýři zůstávají zapojeni v rozhodovacích bodech, včetně schválení návrhu a konečného rozhodnutí o sloučení.

Jde o víc než jen vytvoření počátečního patche. Agenti Cosmos mohou pokračovat ve stejné pull request, když recenzenti zanechají komentáře nebo selžou kontroly. Předpřipravení experti, včetně Project Builder, PR Author, Deep Reviewer a PR Fixer, poskytují týmům pracovní postupy, které si mohou přizpůsobit svým úložištím a standardům.

Každý agent běží v izolovaném virtuálním stroji. Směrování modelu, integrace s GitHub, Jira a Slack, sdílená paměť, verzování a kontrola rozpočtu poskytují okolní infrastrukturu pro provádění této práce napříč inženýrskou organizací.

Tato kombinace představuje myšlenku softwarové továrny: opakovatelný proces, který posouvá práci k reviznímu výsledku. Důležitou jednotkou je dokončený inženýrský pracovní tok s důkazy a kontrolními body, nikoli počet řádků, které agent vytvoří.

Jak Cosmos funguje mimo chatové okno

stránka produktu Cosmos společnosti Augment přidává užitečné podrobnosti o tomto provozním modelu. Pull requesty, upozornění, plány a webhooky mohou aktivovat specializované experty. Týmy definují prostředí, integrace a lidské kontrolní body kolem těchto spouštěčů, což umožňuje zahájení práce, aniž by někdo ručně zadával nový prompt pro každou událost.

Cosmos také podporuje definování expertů a událostmi řízených pracovních toků jako verzovaného YAML, aplikaci změn prostřednictvím Auggie CLI a správu historie konfigurace v Git. To činí samotný pracovní tok agenta něčím, co tým může kontrolovat a měnit pomocí známých inženýrských postupů. Stránka produktu popisuje sdílené organizační znalosti a limity výdajů spolu s těmito kontrolami.

Pro vývojový tým to mění problém koordinace. Agent, který reaguje na přiřazený tiket, potřebuje jasně vymezený cíl, přístup k správným nástrojům a místo pro nahlášení výsledku. Agent spuštěný selháním kontroly potřebuje důkazy o selhání a oprávnění měnit příslušné soubory. Opakovaně použitelné pracovní toky mohou tyto požadavky zakódovat, ačkoliv jejich účinnost stále závisí na tom, jak pečlivě je organizace nakonfiguruje.

Code Context Engine je ústřední součástí dohody

Agenti pracující na podnikovém softwaru čelí problému, který samotná plynulá odpověď na kódování nedokáže vyřešit: nalezení správného kontextu. Úložiště může obsahovat více služeb, zastaralé implementace, místní konvence a závislosti, které je obtížné odvodit z jediného souboru.

Podle vysvětlení Code Context Engine společnosti Augment systém semanticky indexuje kód a získává informace relevantní k úkolu. Čerpá z vztahů napříč úložišti a službami, historie commitů, vzorů kódové základny a podpůrných materiálů, jako jsou dokumentace a tikety. Místo toho, aby byl celý repozitář vložen do promptu, řadí a kurátoruje relevantní kontext.

Praktickou hodnotu lze snadněji pochopit na příkladu. Požadavek na změnu platebního koncového bodu může také ovlivnit validaci, podřadnou službu, handler webhooku a testy. Získání těchto spojení může poskytnout kódovacímu agentovi lepší výchozí bod než samotný soubor koncového bodu. Jedná se o ilustraci problému, který technologie řeší, nikoli o záruku, že bude nalezena každá ovlivněná závislost.

Harness získává tuto schopnost kontextu spolu s nástroji, které ji využívají. Širší příležitost spočívá v propojení znalostí o tom, co kód dělá, s důkazy o tom, co se děje poté, co opustí úložiště.

Propojení úložiště s běžícím systémem

Harness již působí na straně doručení v životním cyklu. Jeho agenti pokrývají doručení softwaru, bezpečnostní testování, ochranu za běhu a řízení nákladů. Akvizice vytváří cestu, aby inženýrská práce připravená v Cosmosu mohla přejít do těchto následných pracovních toků.

Společnost Graf znalostí doručení softwaru je navržena tak, aby propojila informace z Git, CI/CD, cloudové infrastruktury, bezpečnostních a provozních nástrojů. Harness popisuje sémantickou vrstvu se strukturovanými vztahy, kanonickými identitami a filtrováním přístupu. Praktickým příkladem je vyřešení různých názvů stejné služby napříč repozitářem, Kubernetes a monitorovacími systémy.

Tento problém s identitou má důsledky. Zjištění zranitelnosti spojené s nasazenou službou je užitečnější, když lze sledovat k příslušnému artefaktu a verzi kódu. Selhání testu je třeba propojit se změnou, která je skutečně pod revizí. Shromažďování dalších logů automaticky nevybuduje tyto vztahy.

V oznámení o akvizici Harness popisuje propojení Code Context Engine a Grafu znalostí doručení softwaru jako plánovaný další krok. Zamýšlená smyčka zpětné vazby by vrátila následná zjištění do inženýrského pracovního postupu, aby agent mohl připravit opravu a znovu ji odeslat k validaci. Čtenáři by si měli uvědomit rozdíl mezi tímto směrem integrace a tvrzením, že každá část kombinovaného pracovního postupu je již dodána.

Autonomie stále vyžaduje rozhodnutí o vydání

Navrhovaná smyčka by mohla snížit známý zdroj inženýrské zátěže: rekonstruování problému a přenášení jeho kontextu mezi nástroji. Pokud testování odhalí regresi, užitečným výstupem je oprava spojená s neúspěšnou kontrolou, následovaná důkazy, že oprava funguje. Otevření dalšího pull requestu bez těchto důkazů by jen přesunulo úzké místo.

Lidský dohled zůstává součástí architektury. Izolace omezuje vykonávací prostředí, ale nestanovuje, že je patch správný. Testy, revize kódu, bezpečnostní kontroly a explicitní schvalovací hranice slouží různým účelům. Zelený testovací balík může stále přehlédnout požadavek a technicky platná změna může být i nadále nevhodná pro konkrétní vydání.

Pro zákazníky hodnotící kombinovanou platformu budou smysluplnými měřítky, jak často navrhované změny přežijí revizi, kolik úprav vyžadují a co se stane s spolehlivostí po vydání. Úsporu času při přípravě patche je třeba vyvážit časem stráveným jejím ověřením. To jsou hodnotící kritéria, nikoli výkonnostní výsledky předvedené v oznámení o akvizici.

Sázka na celou cestu od nápadu k produkci

Harness uvádí, že Cosmos je nyní k dispozici a že zákazníci mohou nadále používat své preferované nástroje pro kódování. To dává organizacím prostor přijímat pracovní postupy softwarové továrny selektivně, místo aby považovaly akvizici za povinnost nahradit celé své vývojové prostředí.

Strategická sázka je jasná. Jak se generování kódu stává rutinní schopností, těžším problémem je udržet kontext napříč rozhodnutími, která činí software použitelným: implementace, revize, testování, nasazení a provoz. Přenesení kódovacích aktiv Augment do Harness poskytuje společnosti komponenty na obou stranách tohoto rozdělení.

Akvizice bude nakonec posuzována podle toho, zda tyto komponenty vytvoří spolehlivou smyčku zpětné vazby. Pokud může zjištění v produkci vést k dobře vymezené opravě, ověřené proti správnému kódu a vydané podle politik týmu, přínos přesahuje rychlejší psaní kódu. Stane se tak lepším způsobem, jak převést inženýrskou práci na software, který zákazníci mohou používat.